Kafka Monitor項(xiàng)目的動(dòng)機(jī)有三個(gè)：

需要監(jiān)控和測(cè)試Kafka部署并跟蹤主干穩(wěn)定性，以便他們能夠盡早捕獲正在開(kāi)發(fā)的變更集中的問(wèn)題； 需要不間斷地在生產(chǎn)集群上監(jiān)控SLA，并不斷地在測(cè)試集群上運(yùn)行回歸測(cè)試； 現(xiàn)有的監(jiān)控框架無(wú)法滿(mǎn)足其用例的擴(kuò)展性、模塊化需求，他們需要一個(gè)自定義的客戶(hù)端庫(kù)。

網(wǎng)站可靠性工程部門(mén)過(guò)去已經(jīng)監(jiān)控了輸入速率、離線(xiàn)分區(qū)數(shù)和正在復(fù)制的分區(qū)數(shù)等指標(biāo)，以確定Kafka集群的可用性和系統(tǒng)整體的健康狀況。然而，問(wèn)題在于，這類(lèi)原始的值本身無(wú)法表明集群在終端用戶(hù)體驗(yàn)方面是否真的可用。

在LinkedIn的公開(kāi)出版物Keystone Pipeline里，他們提到了兩個(gè)潛在的Kafka候選監(jiān)控方案，微軟的一個(gè)項(xiàng)目和Netflix Kafka監(jiān)控，但最終確定它們不適合自己的應(yīng)用場(chǎng)景。

Kafka Monitor允許開(kāi)發(fā)人員組合模擬各種故障場(chǎng)景的模塊，如GC中斷、broker硬殺及“滾動(dòng)彈出（rolling bounces）”、磁盤(pán)故障，并隨著場(chǎng)景進(jìn)行收集有關(guān)服務(wù)運(yùn)行時(shí)行為的指標(biāo)。每次當(dāng)生產(chǎn)者創(chuàng)建消息時(shí)拋出的異常被捕獲，衡量生產(chǎn)者服務(wù)錯(cuò)誤率的指標(biāo)就會(huì)增加。消費(fèi)者服務(wù)會(huì)跟蹤一個(gè)由Kafka分區(qū)分割的增量索引計(jì)數(shù)器以及消息凈荷的時(shí)間戳，以便度量消息丟失率、重復(fù)率以及端到端延遲。

Kafka Monitor實(shí)例運(yùn)行在一個(gè)單獨(dú)的Java進(jìn)程中，運(yùn)行多個(gè)測(cè)試，介于用戶(hù)或消費(fèi)者服務(wù)與Kafka集群之間。Kafka Monitor收集的運(yùn)行時(shí)指標(biāo)包括生產(chǎn)者服務(wù)的生產(chǎn)效率、消費(fèi)者服務(wù)的消費(fèi)效率、消息丟失、消息重復(fù)和端到端延遲。多個(gè)Kafka Monitor跨多個(gè)Kafka集群運(yùn)行大量的測(cè)試場(chǎng)景，這可以由一個(gè)復(fù)制服務(wù)通過(guò)鏡像方式捕獲跨集群的總體延遲指標(biāo)。

Kafka Monitor原生支持Java，但也為非JVM語(yǔ)言提供了一個(gè)REST接口。這對(duì)開(kāi)源社區(qū)有著特殊的意義，LinkedIn的Dong Lin表示：

我們一般會(huì)脫離Apache Kafka主干，并每季度生成一個(gè)新的內(nèi)部版本，或者吸收Apache Kafka的新特性。脫離主干的一個(gè)顯著的好處是，部署在LinkedIn生產(chǎn)集群中的Kafka經(jīng)常有已經(jīng)在Apache Kafka主干中檢測(cè)到的問(wèn)題，他們可以在Apache Kafka正式版本發(fā)布之前進(jìn)行修復(fù)。

Kafka項(xiàng)目本身包含一些系統(tǒng)測(cè)試，每次代碼撿入時(shí)都會(huì)運(yùn)行，鑒于和Kafka主干的緊密關(guān)系，LinkedIn計(jì)劃實(shí)現(xiàn)類(lèi)似的系統(tǒng)測(cè)試。他們希望將Kafka Monitor和類(lèi)似Simoorg這樣的錯(cuò)誤注入框架以及Graphite或類(lèi)似的框架集成，以便能夠通過(guò)一個(gè)單獨(dú)的Web服務(wù)查看Kafka Monitor集群生成的所有指標(biāo)。

LinkedIn還簡(jiǎn)單地提到了如何設(shè)置基本的監(jiān)控，生成并可視化核心指標(biāo)。他們的GitHub頁(yè)面提供了詳細(xì)的信息。