Kafka Monitor項目的動機有三個：

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

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

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

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

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

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

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

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