Kafka监控架构设计
歡迎支持筆者新作：《深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理》和《RabbitMQ實(shí)戰(zhàn)指南》，同時(shí)歡迎關(guān)注筆者的微信公眾號(hào)：朱小廝的博客。
歡迎跳轉(zhuǎn)到本文的原文鏈接：https://honeypps.com/mq/kafka-monitor-architecture-design/
目前的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)需要說明：
下面我們?cè)賮硖接懴聰?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è)請(qǐng)求獲取原始數(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)以及其背后的含義。
歡迎跳轉(zhuǎn)到本文的原文鏈接：https://honeypps.com/mq/kafka-monitor-architecture-design/
歡迎支持筆者新作：《深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理》和《RabbitMQ實(shí)戰(zhàn)指南》，同時(shí)歡迎關(guān)注筆者的微信公眾號(hào)：朱小廝的博客。
總結(jié)
以上是生活随笔為你收集整理的Kafka监控架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kafka分区分配计算(分区器Parti
- 下一篇： Kafka解析之失效副本