LinkedIn開源Kafka Monitor

一個關於Kafka的監控測試框架

原文請查閱連接。

Apache Kafka 已經成爲了一個面向大規模流數據的，標準的消息系統。在Linkedin這樣的公司， 它被用做各種數據管道的主力，支持一系列關鍵服務。它已經成爲確保企業基礎架構健壯、容錯和高性能的核心組件。

在過去， Kafka 網站高可用工程師 （SRE）必須依賴Kafka服務器的報告來度量、監控一個Kafka集羣 （例如，訪問流量，離線分區計數，under-replicated分區計數，等等）。若是任何一個指標不可用，或者任何指標的值是異常的， 都有多是某些方面出錯了，SRE則 須要介入問題排查。然而，從一個Kafka集羣得到這些指標並不像聽起來那麼容易—不管集羣是否可用， 一個很低的流入流出值並不沒有必要告訴咱們，也不能爲最終用戶提供一個基於可用性經驗的、細粒度的參考結果 （好比說，在這個事件中描述道：只是一個分區的子集異常了）。隨着咱們的集羣增加得越發龐大，爲愈來愈多的重要業務提供服務， 可靠、精確地度量Kafka集羣可用性的能力，也就變得愈來愈重要。

爲了監控可用性，有必要主幹的穩定性，從功能上或性能方面儘量早的捕獲可回溯的信息。 Apache Kafka 在虛擬機中包含一系列單元測試和系統測試方法，用於檢測錯誤。 到目前爲止，咱們仍然能發現一些偶發錯誤，它們直到Kafka在真實的集羣中已經部署不少天甚至幾周以後才顯現。 這些錯誤會引發許多運行時開銷或者致使服務中斷。有些時候該問題很難被重現，SRE工程師只能在開發者找到緣由以前回退到上一個版本， 這顯然要增長Kafka的部署和維護成本。在許多狀況下，這些錯誤能夠在更早的階段就被探查出來， 假如咱們能夠在一個具有多樣化故障轉移的環境部署Kafka，同時加載生產規模的流量、延長持續時間。

Kafka Monitor 是一個監控測試Kafka部署狀況的框架，能夠幫助咱們針對上面的不足提供如下能力： （a）在生產集羣持續監測SLA （b）在測試集羣持續進行迴歸測試。 在最近的 KafkaSummit 咱們已經宣佈在 Github上開源 Kafka Monitor。 接下來咱們將繼續開發 Kafka Monitor 並把它做爲咱們事實上的Kafka認證解決方案。 咱們但願它也能使別的公司從中收益，那些但願驗證和監控它們本身的Kafka部署狀況的公司。

設計概覽

Kafka Monitor 使得這些事情變得很容易： 在真實的生產集羣中，開發和執行長時間運行特定的Kafka系統測試，基於用戶提供的SLA監控已經部署的Kafka。

開發者能夠建立新的測試，經過組裝可複用的組件，用來仿真各類各樣的場景（例如 GC 中斷，代理被硬殺，回滾，磁盤故障，等等），收集指標；用戶能夠運行 K afka Monitor測試用例，在這些場景執行的時候能夠伴隨用戶定義的定時任務， 不管是測試集羣仍是生產集羣，都可以驗證，Kafka在這些場景下，是否可以達到預期效果。 爲了實現上述目標，Kafka Monitor 的設計模型包含一系列測試結果收集器和服務。

一個Kafka Monitor 實例運行在一個單獨的Java進程，在相同的進程裏能夠再產生多個測試用例和服務。 下面的示意圖表達了服務，測試用例和Kafka Monitor實例之間的關係，也能夠知道Kafka Monitor 如何在Kafka集羣和用戶之間相互做用。

測試

一個典型的測試，將仿真一系列場景，基於某些前期已經定義的定時任務，須要啓動一些生產者／消費者，上報指標，驗證指標值是否符合前期定義的斷言。舉個例子，Kafka Monitor 可以啓動一個生產者，一個消費者，每五分鐘反射一個隨機代理（比方說，若是說它是監控一個測試集羣）。Kafka Monitor 接下來就能夠度量可用性，消息丟包率，揭露JMX指標，用戶能夠在一個實時的健康儀表盤看到這些信息。 若是消息丟包率比一些閥值還要大，它能發出告警，這些閥值基於用戶特定的可用性模型肯定。

服務

咱們歸納了仿真邏輯，針對持續長時間場景的服務，目的是爲了加快、簡化從複用組件組裝測試的過程。 一個服務將再產生它本身的線程，去執行那些場景、測量指標。舉例說明，咱們如今已經具有以下服務：

• [ ] 生產者服務，生成Kafka消息，測量生產速率和可用性指標。
• [ ] 消費者服務，消費Kafka消息，測量消息丟包率，消息複製速率以及端到端時延。這些服務依賴於生產者服務來提供消息，它會嵌入一個消息序列號和時間戳。
• [ ] 代理反射服務，可以基於預約義的定時任務提供一個發射代理。

一種測試須要由許多服務組成，驗證一系列超時場景。舉例來講，咱們能夠建立一個測試，包含一個生產者服務，一個消費者服務，以及一個代理反射服務。這個生產者服務和消費者服務，將被配置爲從同一個主題發送和接收消息。那麼這個測試將驗證消息丟包率持續爲0。

使用多個Kafka Monitor實例進行集羣間性能測試

當全部的服務和相同的Kafka Monitor實例必須運行在同一個物理機器上的時候，咱們能夠啓動多個Kafka Monitor 實例在不一樣的集羣， 一塊兒協做完成一個精密控制的端到端測試。在下面這個測試示意圖中，咱們啓動了兩個Kafka Monitor 實例在兩個集羣中。 第一個Kafka Monitor 實例包含一個生產者服務，提供給Kafka 集羣1。消息從集羣1反射到集羣2。 最後，在第二個Kafka Monitor 實例的消費者服務，處理了消息，來自集羣2中的同一個主題，而且報告了經過集羣通道的端到端時延。

Kafka Monitor 在LinkedIn的應用

監控Kafka集羣部署狀況

在2016年早些時候，咱們部署了Kafka Monitor用來監控可用性和端到端時延，包括LinkedIn的每個Kafka集羣。 本項目的 wiki 展現了更多細節，以及這些指標是如何度量的。這些基本可是關鍵的指標，對於積極地監控咱們Kafka集羣的SLA很是有用。 在端到端工做流中驗證客戶端庫 正如早先發布的一篇BLOG中說明的那樣，咱們有一個客戶端的庫，纏繞在普通的Apache Kafka生產者和消費者， 用於提供一些 Apache Kafka 沒法支持的特性，例如Avro編碼，審計和大消息支持。咱們也有一個REST客戶端， 它容許非JAVA應用程序從Kafka生產和消費數據。這些客戶端庫和每個新的Kafka release版本，驗證它們的功能可用性是很是重要的。 Kafka Monitor容許用戶將客戶端庫做爲插件，加入到它的端到端工做流中。咱們已經部署的Kafka Monitor實例， 已經在測試中使用咱們封裝的客戶端和REST客戶端，用於驗證它們的性能和功能，使得這些客戶端庫和Apache Kafka的每個新的release版本都能符合要求。

驗證Apache Kafka新的內部Release版本

咱們一般每一個季度都會從Apache Kafka的主幹版本複製代碼，而後創建一個新的內部release版本，或者吸取Apache Kafka新的特性。 從主幹複製代碼的一個重要的收益就是，部署Kafka到LinkedIn的生產集羣以後，一般能在Apache Kafka的主幹版本上探查到一些問題， 這樣的話咱們就能在Apache Kafka 官方正式的release發佈以前得到修復。 基於複製Apache Kafka主幹版本可能存在的風險，咱們作了額外的工做，在一個測試集羣中驗證每一個內部release版本—從生產集羣中得到鏡像流量—幾周之前生產環境部署新的release。 舉例來講，咱們執行回退或者硬殺掉代理的時候，須要檢查JMX指標去驗證確實有一個控制進程而且沒有離線分區，爲了驗證Kafka在故障遷移場景中的可用性。 在過去，這些步驟都是手工進行的，很是消耗時間，而且咱們有大量事件和許多場景須要測試，這種方式的伸縮性就很是差。咱們切換到Kafka Monitor以後， 這個過程就自動化了，而且能夠覆蓋更多故障遷移的場景，並且是能夠持續進行的。

相關工做的比較

Kafka Monitor對其它公司而言也是有用的，能夠幫助驗證他們本身的客戶端庫和Kafka集羣。 固然Microsoft也已經在Github上有了一個開源項目，也是監控室Kafka集羣的可用性和端到端時延。 一樣地，在這篇發表的博客中，Netflix介紹了一種監控服務，即發送持續的心跳消息，同時度量這些消息的時延。 Kafka Monitor本身的特色就是專一於可擴展性，模塊化以及客戶端庫和多樣化場景支持。

開始

Kafka Monitor的源代碼能夠從Github下載，基於Apache 2.0 受權協議。使用指南，設計文檔和將來規劃在README文件和項目wiki中能夠查閱。咱們很樂於聽到你對該項目的反饋意見。當Kafka Monitor被設計用來做爲，測試和監控Kafka部署狀況的框架的時候，咱們視線了一個基本的可是有用的測試，確保你能開箱即用。這些測試能夠度量可用性，端到端時延，消息丟包率以及消息複製速率，經過運行一個生產者和一個消費者，它們使用同一個主題生產／處理消息。你能夠在終端看到這些指標，基於HTTP GET請求、程序化地得到它們的值，甚至隨着時間查看它們的值，經過一個簡單（快速啓動）的圖形界面，以下面的截圖所示。關於如何運行測試、查看指標的詳細介紹內容請參閱項目網站。

將來的工做

咱們的計劃中有許多工做要作，改進、提高Kafka Monitor，使它更有用。

加強測試場景

每次執行代碼check-in的時候，Apache Kafka包含了一大批系統測試。咱們計劃在Kafka Monitor中實現一個簡單的測試， 而後部署到LinkedIn的測試集羣，最終作到持續運行這些測試。這使得咱們能夠在問題發生的時候進行性能回溯， 還能夠驗證各類特性的是否可用，例如限額、管理操做，受權，等等。

整合Graphite和相似的框架

它對用戶來講很是有用，能夠在他們的組織內，經過一個簡單的web服務查看全部跟Kafka相關的指標。 咱們計劃在Kafka Monitor 中提高現有的報表服務，這樣用戶就可以導出Kafka Monitor的指標到Graphite或者他們選擇的其它框架 整合故障注入框架 咱們也計劃將Kafka Monitor與故障注入框架整合（名叫 Simoorg），能夠測試、收集Kafka在更全面的故障遷移場景中的處理能力，例如磁盤故障或者數據錯誤。

鳴謝

Kafka Monitor可以被設計和實現出來，應該感謝LinkedIn Kafka 團隊的努力。

咱們在招聘

LinkedIn 數據流基礎設施羣組 正在 招聘Kafka方向的軟件開發工程師和網站可用性工程師， 致力於咱們的流數據處理平臺（Samza）以及咱們的下一代變化捕獲技術。 更多細節請聯繫 Kartik Paramasivam 。

更多精彩內容掃碼關注公衆號：RiboseYim's Blog：https://riboseyim.github.io