Kafka 監(jiān)控架構(gòu)設(shè)計(jì)

目前的Kafka監(jiān)控產(chǎn)品有很多，比如Kafka Manager、 Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等，都有各自的優(yōu)缺點(diǎn)，就個(gè)人而言用的最多的還是Kafka Manager，不過這些并不是十分的完美。如果有條件，自定義實(shí)現(xiàn)一套符合自身公司業(yè)務(wù)特色與發(fā)展的監(jiān)控系統(tǒng)尤為重要。本文主要講述筆者個(gè)人對(duì)Kafka監(jiān)控架構(gòu)的認(rèn)知與想法。

Kafka監(jiān)控主要分為數(shù)據(jù)采集、數(shù)據(jù)存儲(chǔ)以及數(shù)據(jù)展示3個(gè)部分。

• 數(shù)據(jù)采集主要從各種數(shù)據(jù)源采集監(jiān)控?cái)?shù)據(jù)并做一些必要的運(yùn)算然后發(fā)送給數(shù)據(jù)存儲(chǔ)模塊進(jìn)行存儲(chǔ)。數(shù)據(jù)源可以是kafka-zk、kafka自身（消費(fèi)__consumer_offset）、JMX（主要是通過JMX來監(jiān)控kafka的指標(biāo)，故kafka啟動(dòng)的時(shí)候需要指定JMX_PORT）、zabbix（或者其他類似的工具，主要用來監(jiān)控集群硬件指標(biāo)）。
• 數(shù)據(jù)存儲(chǔ)是指將采集的原始數(shù)據(jù)經(jīng)過一定的預(yù)處理后進(jìn)行相應(yīng)的存儲(chǔ)，方便數(shù)據(jù)清洗（這個(gè)步驟可以省略）和數(shù)據(jù)展示。數(shù)據(jù)存儲(chǔ)可以采用Opentsdb之類的基于時(shí)間序列的數(shù)據(jù)庫，方便做一些聚合計(jì)算。
• 數(shù)據(jù)展示，顧名思義是將經(jīng)過預(yù)處理的、存儲(chǔ)的數(shù)據(jù)展示到監(jiān)控頁面上，提供豐富的UI給用戶使用。當(dāng)然數(shù)據(jù)展示模塊也可以繞過數(shù)據(jù)存儲(chǔ)模塊直接向數(shù)據(jù)采集模塊，亦或者是數(shù)據(jù)源直接拉取數(shù)據(jù)。至于數(shù)據(jù)是從存儲(chǔ)模塊拉取還是更底層的源頭拉取，要看是否需要?dú)v史時(shí)間段的值或者是是否需要最新值。

經(jīng)過上面的分析整個(gè)監(jiān)控系統(tǒng)可以大致概括為以下的模型：

不過上面的模型架構(gòu)只是針對(duì)單一集群以及單機(jī)版的Collector，如果涉及到多個(gè)集群，就需要考慮均衡負(fù)載以及HA等方面的因素。我們針對(duì)這個(gè)模型做進(jìn)一步的改進(jìn)，主要是針對(duì)數(shù)據(jù)采集模塊的改進(jìn)，如下圖所示：

每臺(tái)數(shù)據(jù)采集物理機(jī)上都部署一個(gè)主進(jìn)程的服務(wù)，主進(jìn)程負(fù)責(zé)根據(jù)需要?jiǎng)?chuàng)建Collector子進(jìn)程，每個(gè)Collector子進(jìn)程對(duì)應(yīng)采集一個(gè)Kafka集群的監(jiān)控?cái)?shù)據(jù)。當(dāng)某個(gè)集群需要被監(jiān)控時(shí)，通過監(jiān)控頁面設(shè)置或者其他途徑將集群的一些重要信息（比如kafka的地址、kafka-zk的地址、zabbix的地址、jmx端口號(hào)等）存儲(chǔ)起來并在zookeeper中/monitor/clusters/路徑下創(chuàng)建對(duì)應(yīng)的子節(jié)點(diǎn)（實(shí)節(jié)點(diǎn)），當(dāng)然為了方面也可以將這些重要信息作為data直接存儲(chǔ)在這個(gè)子節(jié)點(diǎn)中。各個(gè)主進(jìn)程監(jiān)聽/monitor/clusters/下的子節(jié)點(diǎn)的變化，如果發(fā)現(xiàn)有新的節(jié)點(diǎn)加入，就以搶占的方式創(chuàng)建Collector，并在/monitor/pids/路徑下創(chuàng)建對(duì)應(yīng)集群的虛節(jié)點(diǎn)。

這里有幾點(diǎn)需要說明：

1. 各個(gè)主進(jìn)程的“搶占”可以通過zookeeper自身的功能實(shí)現(xiàn)，通過在/monitor/pids/路徑下創(chuàng)建相應(yīng)的虛節(jié)點(diǎn)，如果創(chuàng)建成功則說明搶占成功，反之則失敗。
2. 在/monitor/pids/路徑下創(chuàng)建虛節(jié)點(diǎn)是在Collector中創(chuàng)建的而不是在主進(jìn)程中創(chuàng)建的，也就是說主進(jìn)程監(jiān)聽到新節(jié)點(diǎn)的加入首先是創(chuàng)建Collector的實(shí)例，然后Collector的實(shí)例再創(chuàng)建對(duì)應(yīng)的虛節(jié)點(diǎn)，如果創(chuàng)建成功則告知主進(jìn)程創(chuàng)建成功，如果創(chuàng)建失敗則返回失敗。
3. Collector之后再初始化一些進(jìn)行資源采集的資源，比如與kafka-zk、kafka等建立連接。如果初始化成功則可以進(jìn)行數(shù)據(jù)采集；如果失敗則關(guān)閉自身，對(duì)應(yīng)的虛節(jié)點(diǎn)的session也隨之結(jié)束，也就意味著對(duì)應(yīng)虛節(jié)點(diǎn)的自動(dòng)刪除。
4. 主進(jìn)程也要監(jiān)聽/monitor/pids/路徑下的節(jié)點(diǎn)變化，一旦監(jiān)聽到節(jié)點(diǎn)增加則說明某個(gè)原本自身要搶占創(chuàng)建的已被其他主進(jìn)程搶占。在2中所說的Collector創(chuàng)建虛節(jié)點(diǎn)成功與否告知主進(jìn)程，其實(shí)這里也可以省去這一步，主進(jìn)程可以監(jiān)聽/monitor/pids/路徑的變化來感知是否創(chuàng)建成功。主進(jìn)程一旦監(jiān)聽到/monitor/pids/路徑下的節(jié)點(diǎn)減少，則首先判斷這個(gè)節(jié)點(diǎn)是否在/monitor/clusters/下存在，如果不存在則不做處理，如果存在則啟動(dòng)搶占任務(wù)。
5. 主進(jìn)程和子進(jìn)程可以通過ProcessBuilder來實(shí)現(xiàn)。
6. 主進(jìn)程自身可以搶占創(chuàng)建/monitor/pids/路徑下的虛節(jié)點(diǎn)，然后監(jiān)控Collector進(jìn)程狀態(tài)。如果Collector進(jìn)程假死，而主進(jìn)程無法直觀感知，所以就將創(chuàng)建虛節(jié)點(diǎn)并保持session的工作就留給了Collector子進(jìn)程。
7. 主進(jìn)程和子進(jìn)程的關(guān)系也可以演變?yōu)檫M(jìn)程和線程的對(duì)應(yīng)關(guān)系，但是這樣改變之后對(duì)各個(gè)集群的日志存盤以及問題的追蹤會(huì)添加不必要的麻煩。

下面我們再來探討下數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)展示這兩者之間的關(guān)系。正常邏輯下，監(jiān)控頁面通過調(diào)取數(shù)據(jù)存儲(chǔ)模塊的api來獲取數(shù)據(jù)并展示在頁面上。試想下如果一個(gè)監(jiān)控頁面需要調(diào)取幾十個(gè)指標(biāo)，然后還要經(jīng)過一定的計(jì)算之后才展示到頁面之上，那么這個(gè)頁面的渲染速度必然會(huì)受到一定的限制。

就拿指標(biāo)UnderReplicatedPartitions來說，如果只能用一個(gè)指標(biāo)來監(jiān)控Kafka，那么非它莫屬。UnderReplicatedPartitions表示集群中副本處于同步失敗或失效狀態(tài)的分區(qū)數(shù)，即ISR<；AR。這個(gè)指標(biāo)的獲取也很簡單，通過JMX調(diào)取kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions。UnderReplicatedPartitions的值為0則大吉大利，如果大于0則需要很多步驟來檢測異常原因，比如：檢測是否只發(fā)生在一個(gè)topic上；檢測是否只發(fā)生在一個(gè)broker上；如果不是前兩種，極可能是集群原因，那么集群原因又可能是由于負(fù)載不均衡導(dǎo)致的等等（UnderReplicatedPartitions的異常評(píng)估可以參考筆者下一篇文章）。
UnderReplicatedPartitions背后要伴隨著一堆的指標(biāo)來評(píng)估異常的緣由，就以負(fù)載不均衡來說，還涉及到復(fù)雜的計(jì)算：一個(gè)Broker的負(fù)載涉及其所承載的partitions的個(gè)數(shù)、leaders的個(gè)數(shù)、網(wǎng)絡(luò)讀寫速度、IO讀寫速度、CPU使用率等，要評(píng)判一個(gè)集群中是否有負(fù)責(zé)不均衡的情況出現(xiàn)，就需要將這些指標(biāo)進(jìn)行歸一化處理，然后再做均方差，如果超過設(shè)定的閾值即可評(píng)判集群發(fā)生了負(fù)載不均衡的現(xiàn)象。如果監(jiān)控頁面從opentsdb中發(fā)送多個(gè)請求獲取原始數(shù)據(jù)，然后再內(nèi)部進(jìn)行復(fù)雜的計(jì)算之后再程序在頁面上，這個(gè)過程的耗時(shí)可以想象。更令人憂傷的是這么多的過程只是用來展示了一個(gè)指標(biāo)，而一個(gè)頁面的呈現(xiàn)可能要涉及到很多個(gè)指標(biāo)。

有了問題我們就需要解決它，這里筆者引入了一個(gè)新的模塊ComputeServer來進(jìn)行數(shù)據(jù)預(yù)處理，然后將處理后的數(shù)據(jù)以HTTP RESTful API接口的方式提供給下游。下游的監(jiān)控頁面和存儲(chǔ)模塊只需要通過這個(gè)接口讀取數(shù)據(jù)即可，無需過多的計(jì)算，從而提升了效率。新的架構(gòu)模型如下圖所示：

上圖還引入了一個(gè)kafka的模塊，這個(gè)主要是用來將多個(gè)Collector與ComputeServer解耦，如果多個(gè)懸而未定Collector與ComputeServer直接交互必然是一個(gè)浩大工程。Kafka模塊可以針對(duì)每個(gè)集群創(chuàng)建對(duì)應(yīng)的topic；亦或者是創(chuàng)建一個(gè)單獨(dú)的topic，然后劃分多個(gè)partition，每個(gè)集群的ID或者名稱作為消息的Key來進(jìn)行區(qū)分。后者不必強(qiáng)求每個(gè)集群對(duì)應(yīng)到獨(dú)立的partition中，ComputeServer在消費(fèi)的時(shí)候可以獲取Key來辨別集群。而消息的Value就是Collector采集的原始數(shù)據(jù)，這里的消息的大小有可能超過Kafka Broker的默認(rèn)單條消息的大小1000012B，不過筆者不建議調(diào)高這個(gè)值以及對(duì)應(yīng)人max.request.size和max.partition.fetch.bytes參數(shù)的大小。可以開啟壓縮或者在Collector拆包以及在ComputeServer端解包的方式來進(jìn)一步的解決消息過大的問題。還有一個(gè)就是這里的Kafka不建議開啟日志壓縮的功能，因?yàn)镵afka不僅是一個(gè)功能稍弱的消息中間件，同時(shí)也是一個(gè)功能弱化的時(shí)間序列數(shù)據(jù)庫，Kafka本身可以根據(jù)時(shí)間范圍來拉取對(duì)應(yīng)的消息。在opentsdb不可靠的時(shí)候，完全可以使用kafka替代，只不過kafka出來的數(shù)據(jù)需要多做有些聚類運(yùn)算。

在上圖中的①和②可以加入數(shù)據(jù)清洗邏輯亦或者是告警邏輯，將異常數(shù)據(jù)攔截出來，傳入其他的告警系統(tǒng)等來做進(jìn)一步的處理。

上圖中的ComputeServer的HA可以簡單的通過LVS+Keepalived實(shí)現(xiàn)。

至此，一個(gè)包含數(shù)據(jù)采集+計(jì)算+存儲(chǔ)+展示的監(jiān)控架構(gòu)已經(jīng)聊完。后面會(huì)另有文章來細(xì)說下Kafka中的監(jiān)控指標(biāo)以及其背后的含義。

本文的重點(diǎn)是你有沒有收獲與成長，其余的都不重要，希望讀者們能謹(jǐn)記這一點(diǎn)。同時(shí)我經(jīng)過多年的收藏目前也算收集到了一套完整的學(xué)習(xí)資料，包括但不限于：分布式架構(gòu)、高可擴(kuò)展、高性能、高并發(fā)、Jvm性能調(diào)優(yōu)、Spring，MyBatis，Nginx源碼分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多個(gè)知識(shí)點(diǎn)高級(jí)進(jìn)階干貨，希望對(duì)想成為架構(gòu)師的朋友有一定的參考和幫助

需要更詳細(xì)思維導(dǎo)圖和以下資料的可以加一下技術(shù)交流分享群：“708 701 457”免費(fèi)獲取