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

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括亞?wèn)|網(wǎng)站建設(shè)、亞?wèn)|網(wǎng)站制作、亞?wèn)|網(wǎng)頁(yè)制作以及亞?wèn)|網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，亞?wèn)|網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到亞?wèn)|省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

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

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

不過(guò)上面的模型架構(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í)，通過(guò)監(jiān)控頁(yè)面設(shè)置或者其他途徑將集群的一些重要信息（比如kafka的地址、kafka-zk的地址、zabbix的地址、jmx端口號(hào)等）存儲(chǔ)起來(lái)并在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)聽(tīng)/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)需要說(shuō)明：

1. 各個(gè)主進(jìn)程的“搶占”可以通過(guò)zookeeper自身的功能實(shí)現(xiàn)，通過(guò)在/monitor/pids/路徑下創(chuàng)建相應(yīng)的虛節(jié)點(diǎn)，如果創(chuàng)建成功則說(shuō)明搶占成功，反之則失敗。
2. 在/monitor/pids/路徑下創(chuàng)建虛節(jié)點(diǎn)是在Collector中創(chuàng)建的而不是在主進(jìn)程中創(chuàng)建的，也就是說(shuō)主進(jìn)程監(jiān)聽(tīng)到新節(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)聽(tīng)/monitor/pids/路徑下的節(jié)點(diǎn)變化，一旦監(jiān)聽(tīng)到節(jié)點(diǎn)增加則說(shuō)明某個(gè)原本自身要搶占創(chuàng)建的已被其他主進(jìn)程搶占。在2中所說(shuō)的Collector創(chuàng)建虛節(jié)點(diǎn)成功與否告知主進(jìn)程，其實(shí)這里也可以省去這一步，主進(jìn)程可以監(jiān)聽(tīng)/monitor/pids/路徑的變化來(lái)感知是否創(chuàng)建成功。主進(jìn)程一旦監(jiān)聽(tīng)到/monitor/pids/路徑下的節(jié)點(diǎn)減少，則首先判斷這個(gè)節(jié)點(diǎn)是否在/monitor/clusters/下存在，如果不存在則不做處理，如果存在則啟動(dòng)搶占任務(wù)。
5. 主進(jìn)程和子進(jìn)程可以通過(guò)ProcessBuilder來(lái)實(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)程無(wú)法直觀感知，所以就將創(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è)集群的日志存盤(pán)以及問(wèn)題的追蹤會(huì)添加不必要的麻煩。

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

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

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

上圖還引入了一個(gè)kafka的模塊，這個(gè)主要是用來(lái)將多個(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來(lái)進(jìn)行區(qū)分。后者不必強(qiáng)求每個(gè)集群對(duì)應(yīng)到獨(dú)立的partition中，ComputeServer在消費(fèi)的時(shí)候可以獲取Key來(lái)辨別集群。而消息的Value就是Collector采集的原始數(shù)據(jù)，這里的消息的大小有可能超過(guò)Kafka Broker的默認(rèn)單條消息的大小1000012B，不過(guò)筆者不建議調(diào)高這個(gè)值以及對(duì)應(yīng)人max.request.size和max.partition.fetch.bytes參數(shù)的大小?？梢蚤_(kāi)啟壓縮或者在Collector拆包以及在ComputeServer端解包的方式來(lái)進(jìn)一步的解決消息過(guò)大的問(wèn)題。還有一個(gè)就是這里的Kafka不建議開(kāi)啟日志壓縮的功能，因?yàn)镵afka不僅是一個(gè)功能稍弱的消息中間件，同時(shí)也是一個(gè)功能弱化的時(shí)間序列數(shù)據(jù)庫(kù)，Kafka本身可以根據(jù)時(shí)間范圍來(lái)拉取對(duì)應(yīng)的消息。在opentsdb不可靠的時(shí)候，完全可以使用kafka替代，只不過(guò)kafka出來(lái)的數(shù)據(jù)需要多做有些聚類運(yùn)算。

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

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

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

---

本文的重點(diǎn)是你有沒(méi)有收獲與成長(zhǎng)，其余的都不重要，希望讀者們能謹(jǐn)記這一點(diǎn)。同時(shí)我經(jīng)過(guò)多年的收藏目前也算收集到了一套完整的學(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)獲取

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國(guó)云服務(wù)器，動(dòng)態(tài)BGP最優(yōu)骨干路由自動(dòng)選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨(dú)有T級(jí)流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動(dòng)現(xiàn)已開(kāi)啟，新人活動(dòng)云服務(wù)器買多久送多久。

新聞標(biāo)題：Kafka監(jiān)控架構(gòu)設(shè)計(jì)-創(chuàng)新互聯(lián)
當(dāng)前地址：http://weahome.cn/article/dcsdoh.html