一個(gè)關(guān)于Kafka的監(jiān)控測(cè)試框架

原文請(qǐng)查閱鏈接。

Apache Kafka 已經(jīng)成為了一個(gè)面向大規(guī)模流數(shù)據(jù)的，標(biāo)準(zhǔn)的消息系統(tǒng)。在Linkedin這樣的公司，
它被用作各類數(shù)據(jù)管道的主力，支持一系列關(guān)鍵服務(wù)。它已經(jīng)成為確保企業(yè)基礎(chǔ)架構(gòu)健壯、容錯(cuò)和高性能的核心組件。

在過去， Kafka 網(wǎng)站高可用工程師 （SRE）必須依賴Kafka服務(wù)器的報(bào)告來度量、監(jiān)控一個(gè)Kafka集群
（例如，訪問流量，離線分區(qū)計(jì)數(shù)，under-replicated分區(qū)計(jì)數(shù)，等等）。如果任何一個(gè)指標(biāo)不可用，或者任何指標(biāo)的值是異常的，
都有可能是某些方面出錯(cuò)了，SRE則 需要介入問題排查。然而，從一個(gè)Kafka集群獲得這些指標(biāo)并不像聽起來那么容易—無論集群是否可用，
一個(gè)很低的流入流出值并不沒有必要告訴我們，也不能為最終用戶提供一個(gè)基于可用性經(jīng)驗(yàn)的、細(xì)粒度的參考結(jié)果
（比如說，在這個(gè)事件中描述道：只是一個(gè)分區(qū)的子集異常了）。隨著我們的集群增長得愈加龐大，為越來越多的重要業(yè)務(wù)提供服務(wù)，
可靠、精確地度量Kafka集群可用性的能力，也就變得越來越重要。

為了監(jiān)控可用性，有必要主干的穩(wěn)定性，從功能上或性能方面盡可能早的捕獲可回溯的信息。
Apache Kafka 在虛擬機(jī)中包含一系列單元測(cè)試和系統(tǒng)測(cè)試方法，用于檢測(cè)錯(cuò)誤。
到目前為止，我們?nèi)匀荒馨l(fā)現(xiàn)一些偶發(fā)錯(cuò)誤，它們直到Kafka在真實(shí)的集群中已經(jīng)部署很多天甚至幾周之后才顯現(xiàn)。
這些錯(cuò)誤會(huì)引起許多運(yùn)行時(shí)開銷或者導(dǎo)致服務(wù)中斷。有些時(shí)候該問題很難被重現(xiàn)，SRE工程師只能在開發(fā)者找到原因之前回退到上一個(gè)版本，
這顯然要增加Kafka的部署和維護(hù)成本。在許多情況下，這些錯(cuò)誤可以在更早的階段就被探查出來，
假如我們可以在一個(gè)具備多樣化故障轉(zhuǎn)移的環(huán)境部署Kafka，同時(shí)加載生產(chǎn)規(guī)模的流量、延長持續(xù)時(shí)間。

Kafka Monitor 是一個(gè)監(jiān)控測(cè)試Kafka部署情況的框架，可以幫助我們針對(duì)上面的不足提供以下能力：
（a）在生產(chǎn)集群持續(xù)監(jiān)測(cè)SLA （b）在測(cè)試集群持續(xù)進(jìn)行回歸測(cè)試。
在最近的 KafkaSummit 我們已經(jīng)宣布在 Github上開源 Kafka Monitor。
接下來我們將繼續(xù)開發(fā) Kafka Monitor 并把它作為我們事實(shí)上的Kafka認(rèn)證解決方案。
我們希望它也能使別的公司從中收益，那些希望驗(yàn)證和監(jiān)控它們自己的Kafka部署情況的公司。

設(shè)計(jì)概覽

Kafka Monitor 使得這些事情變得很容易：
在真實(shí)的生產(chǎn)集群中，開發(fā)和執(zhí)行長時(shí)間運(yùn)行特定的Kafka系統(tǒng)測(cè)試，基于用戶提供的SLA監(jiān)控已經(jīng)部署的Kafka。

開發(fā)者可以創(chuàng)建新的測(cè)試，通過組裝可復(fù)用的組件，用來仿真各種各樣的場(chǎng)景（例如 GC 中斷，代理被硬殺，回滾，磁盤故障，等等），收集指標(biāo)；用戶可以運(yùn)行 K afka Monitor測(cè)試用例，在這些場(chǎng)景執(zhí)行的時(shí)候可以伴隨用戶定義的定時(shí)任務(wù)，
無論是測(cè)試集群還是生產(chǎn)集群，都能夠驗(yàn)證，Kafka在這些場(chǎng)景下，是否能夠達(dá)到預(yù)期效果。 為了實(shí)現(xiàn)上述目標(biāo)，Kafka Monitor 的設(shè)計(jì)模型包含一系列測(cè)試結(jié)果收集器和服務(wù)。

一個(gè)Kafka Monitor 實(shí)例運(yùn)行在一個(gè)單獨(dú)的Java進(jìn)程，在相同的進(jìn)程里可以再產(chǎn)生多個(gè)測(cè)試用例和服務(wù)。
下面的示意圖表達(dá)了服務(wù)，測(cè)試用例和Kafka Monitor實(shí)例之間的關(guān)系，也可以知道Kafka Monitor 如何在Kafka集群和用戶之間相互作用。

KafkaMonitor OverView

測(cè)試

一個(gè)典型的測(cè)試，將仿真一系列場(chǎng)景，基于某些前期已經(jīng)定義的定時(shí)任務(wù)，需要啟動(dòng)一些生產(chǎn)者／消費(fèi)者，上報(bào)指標(biāo)，驗(yàn)證指標(biāo)值是否符合前期定義的斷言。舉個(gè)例子，Kafka Monitor 能夠啟動(dòng)一個(gè)生產(chǎn)者，一個(gè)消費(fèi)者，每五分鐘反射一個(gè)隨機(jī)代理（比方說，如果說它是監(jiān)控一個(gè)測(cè)試集群）。Kafka Monitor 接下來就可以度量可用性，消息丟包率，揭露JMX指標(biāo)，用戶可以在一個(gè)實(shí)時(shí)的健康儀表盤看到這些信息。
如果消息丟包率比一些閥值還要大，它能發(fā)出告警，這些閥值基于用戶特定的可用性模型確定。

服務(wù)

我們概括了仿真邏輯，針對(duì)持續(xù)長時(shí)間場(chǎng)景的服務(wù)，目的是為了加快、簡化從復(fù)用組件組裝測(cè)試的過程。
一個(gè)服務(wù)將再產(chǎn)生它自己的線程，去執(zhí)行那些場(chǎng)景、測(cè)量指標(biāo)。舉例說明，我們現(xiàn)在已經(jīng)具備如下服務(wù)：

• 生產(chǎn)者服務(wù)，生成Kafka消息，測(cè)量生產(chǎn)速率和可用性指標(biāo)。
• 消費(fèi)者服務(wù)，消費(fèi)Kafka消息，測(cè)量消息丟包率，消息復(fù)制速率以及端到端時(shí)延。這些服務(wù)依賴于生產(chǎn)者服務(wù)來提供消息，它會(huì)嵌入一個(gè)消息序列號(hào)和時(shí)間戳。
• 代理反射服務(wù)，能夠基于預(yù)定義的定時(shí)任務(wù)提供一個(gè)發(fā)射代理。

一種測(cè)試需要由許多服務(wù)組成，驗(yàn)證一系列超時(shí)場(chǎng)景。舉例來說，我們可以創(chuàng)建一個(gè)測(cè)試，包含一個(gè)生產(chǎn)者服務(wù)，一個(gè)消費(fèi)者服務(wù)，以及一個(gè)代理反射服務(wù)。這個(gè)生產(chǎn)者服務(wù)和消費(fèi)者服務(wù)，將被配置為從同一個(gè)主題發(fā)送和接收消息。那么這個(gè)測(cè)試將驗(yàn)證消息丟包率持續(xù)為0。

使用多個(gè)Kafka Monitor實(shí)例進(jìn)行集群間性能測(cè)試

當(dāng)所有的服務(wù)和相同的Kafka Monitor實(shí)例必須運(yùn)行在同一個(gè)物理機(jī)器上的時(shí)候，我們可以啟動(dòng)多個(gè)Kafka Monitor 實(shí)例在不同的集群，
一起協(xié)作完成一個(gè)精密控制的端到端測(cè)試。在下面這個(gè)測(cè)試示意圖中，我們啟動(dòng)了兩個(gè)Kafka Monitor 實(shí)例在兩個(gè)集群中。
第一個(gè)Kafka Monitor 實(shí)例包含一個(gè)生產(chǎn)者服務(wù)，提供給Kafka 集群1。消息從集群1反射到集群2。
最后，在第二個(gè)Kafka Monitor 實(shí)例的消費(fèi)者服務(wù)，處理了消息，來自集群2中的同一個(gè)主題，并且報(bào)告了通過集群通道的端到端時(shí)延。

KafkaMonitor

Kafka Monitor 在LinkedIn的應(yīng)用

監(jiān)控Kafka集群部署情況

在2016年早些時(shí)候，我們部署了Kafka Monitor用來監(jiān)控可用性和端到端時(shí)延，包括LinkedIn的每一個(gè)Kafka集群。
本項(xiàng)目的 wiki 展示了更多細(xì)節(jié)，以及這些指標(biāo)是如何度量的。這些基本但是關(guān)鍵的指標(biāo)，對(duì)于積極地監(jiān)控我們Kafka集群的SLA非常有用。
在端到端工作流中驗(yàn)證客戶端庫
正如早先發(fā)布的一篇BLOG中說明的那樣，我們有一個(gè)客戶端的庫，纏繞在普通的Apache Kafka生產(chǎn)者和消費(fèi)者，
用于提供一些 Apache Kafka 無法支持的特性，例如Avro編碼，審計(jì)和大消息支持。我們也有一個(gè)REST客戶端，
它允許非JAVA應(yīng)用程序從Kafka生產(chǎn)和消費(fèi)數(shù)據(jù)。這些客戶端庫和每一個(gè)新的Kafka release版本，驗(yàn)證它們的功能可用性是非常重要的。
Kafka Monitor允許用戶將客戶端庫作為插件，加入到它的端到端工作流中。我們已經(jīng)部署的Kafka Monitor實(shí)例，
已經(jīng)在測(cè)試中使用我們封裝的客戶端和REST客戶端，用于驗(yàn)證它們的性能和功能，使得這些客戶端庫和Apache Kafka的每一個(gè)新的release版本都能符合要求。

驗(yàn)證Apache Kafka新的內(nèi)部Release版本

我們通常每個(gè)季度都會(huì)從Apache Kafka的主干版本復(fù)制代碼，然后建立一個(gè)新的內(nèi)部release版本，或者吸收Apache Kafka新的特性。
從主干復(fù)制代碼的一個(gè)重要的收益就是，部署Kafka到LinkedIn的生產(chǎn)集群之后，通常能在Apache Kafka的主干版本上探查到一些問題，
這樣的話我們就能在Apache Kafka 官方正式的release發(fā)布之前獲得修復(fù)。
基于復(fù)制Apache Kafka主干版本可能存在的風(fēng)險(xiǎn)，我們做了額外的工作，在一個(gè)測(cè)試集群中驗(yàn)證每個(gè)內(nèi)部release版本—從生產(chǎn)集群中獲得鏡像流量—幾周以前生產(chǎn)環(huán)境部署新的release。
舉例來說，我們執(zhí)行回退或者硬殺掉代理的時(shí)候，需要檢查JMX指標(biāo)去驗(yàn)證確實(shí)有一個(gè)控制進(jìn)程并且沒有離線分區(qū)，為了驗(yàn)證Kafka在故障遷移場(chǎng)景中的可用性。
在過去，這些步驟都是手工進(jìn)行的，非常消耗時(shí)間，并且我們有大量事件和許多場(chǎng)景需要測(cè)試，這種方式的伸縮性就非常差。我們切換到Kafka Monitor之后，
這個(gè)過程就自動(dòng)化了，并且可以覆蓋更多故障遷移的場(chǎng)景，而且是可以持續(xù)進(jìn)行的。

相關(guān)工作的比較

Kafka Monitor對(duì)其它公司而言也是有用的，可以幫助驗(yàn)證他們自己的客戶端庫和Kafka集群。
當(dāng)然Microsoft也已經(jīng)在Github上有了一個(gè)開源項(xiàng)目，也是監(jiān)控室Kafka集群的可用性和端到端時(shí)延。
同樣地，在這篇發(fā)表的博客中，Netflix介紹了一種監(jiān)控服務(wù)，即發(fā)送持續(xù)的心跳消息，同時(shí)度量這些消息的時(shí)延。
Kafka Monitor自己的特點(diǎn)就是專注于可擴(kuò)展性，模塊化以及客戶端庫和多樣化場(chǎng)景支持。

開始

Kafka Monitor的源代碼可以從Github下載，基于Apache 2.0 授權(quán)協(xié)議。使用指南，設(shè)計(jì)文檔和未來規(guī)劃在README文件和項(xiàng)目wiki中可以查閱。我們很樂于聽到你對(duì)該項(xiàng)目的反饋意見。當(dāng)Kafka Monitor被設(shè)計(jì)用來作為，測(cè)試和監(jiān)控Kafka部署情況的框架的時(shí)候，我們視線了一個(gè)基本的但是有用的測(cè)試，確保你能開箱即用。這些測(cè)試可以度量可用性，端到端時(shí)延，消息丟包率以及消息復(fù)制速率，通過運(yùn)行一個(gè)生產(chǎn)者和一個(gè)消費(fèi)者，它們使用同一個(gè)主題生產(chǎn)／處理消息。你可以在終端看到這些指標(biāo)，基于HTTP GET請(qǐng)求、程序化地獲得它們的值，甚至隨著時(shí)間查看它們的值，通過一個(gè)簡單（快速啟動(dòng)）的圖形界面，如下面的截圖所示。關(guān)于如何運(yùn)行測(cè)試、查看指標(biāo)的詳細(xì)介紹內(nèi)容請(qǐng)參閱項(xiàng)目網(wǎng)站。

KafkaMonitor

未來的工作

我們的計(jì)劃中有許多工作要做，改進(jìn)、提升Kafka Monitor，使它更有用。

增強(qiáng)測(cè)試場(chǎng)景

每次執(zhí)行代碼check-in的時(shí)候，Apache Kafka包含了一大批系統(tǒng)測(cè)試。我們計(jì)劃在Kafka Monitor中實(shí)現(xiàn)一個(gè)簡單的測(cè)試，
然后部署到LinkedIn的測(cè)試集群，最終做到持續(xù)運(yùn)行這些測(cè)試。這使得我們可以在問題發(fā)生的時(shí)候進(jìn)行性能回溯，
還可以驗(yàn)證各種特性的是否可用，例如限額、管理操作，授權(quán)，等等。

整合Graphite和類似的框架

它對(duì)用戶來說非常有用，可以在他們的組織內(nèi)，通過一個(gè)簡單的web服務(wù)查看所有跟Kafka相關(guān)的指標(biāo)。
我們計(jì)劃在Kafka Monitor 中提升現(xiàn)有的報(bào)表服務(wù)，這樣用戶就能夠?qū)С鯧afka Monitor的指標(biāo)到Graphite或者他們選擇的其它框架
整合故障注入框架
我們也計(jì)劃將Kafka Monitor與故障注入框架整合（名叫 Simoorg），可以測(cè)試、收集Kafka在更全面的故障遷移場(chǎng)景中的處理能力，例如磁盤故障或者數(shù)據(jù)錯(cuò)誤。

鳴謝

Kafka Monitor能夠被設(shè)計(jì)和實(shí)現(xiàn)出來，應(yīng)該感謝LinkedIn Kafka 團(tuán)隊(duì)的努力。

我們?cè)谡衅?/h4>

LinkedIn 數(shù)據(jù)流基礎(chǔ)設(shè)施群組 正在 招聘Kafka方向的軟件開發(fā)工程師和網(wǎng)站可用性工程師，
致力于我們的流數(shù)據(jù)處理平臺(tái)（Samza）以及我們的下一代變化捕獲技術(shù)。
更多細(xì)節(jié)請(qǐng)聯(lián)系 Kartik Paramasivam 。