在2016年4月份舉行的Kafka峰會上，LinkedIn在Apache 2.0許可協議下開源了Kafka Monitor，并于近日詳細介紹了該監控工具的架構以及他們最初的構建動機。在年初的時候，LinkedIn曾在一篇有關Kafka整體應用的文章中簡單地提及過Kafka Monitor，但并沒有詳細介紹該項目的語義組成或者背后的動機。

Kafka Monitor項目的動機有三個：

需要監控和測試Kafka部署并跟蹤主干穩定性，以便他們能夠盡早捕獲正在開發的變更集中的問題；

需要不間斷地在生產集群上監控SLA，并不斷地在測試集群上運行回歸測試；

現有的監控框架無法滿足其用例的擴展性、模塊化需求，他們需要一個自定義的客戶端庫。

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

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

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

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

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

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

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

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

文章轉載自 開源中國社區[http://www.oschina.net]

總結

以上是生活随笔為你收集整理的LinkedIn 详细介绍了他们开源的 Kafka Monitor的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。