Kafka监控架构设计
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/kafka-monitor-architecture-design/
目前的Kafka監控產品有很多，比如Kafka Manager、 Kafka Monitor、KafkaOffsetMonitor、Kafka Web Console、Burrow等，都有各自的優缺點，就個人而言用的最多的還是Kafka Manager，不過這些并不是十分的完美。如果有條件，自定義實現一套符合自身公司業務特色與發展的監控系統尤為重要。本文主要講述筆者個人對Kafka監控架構的認知與想法。
Kafka監控主要分為數據采集、數據存儲以及數據展示3個部分。
- 數據采集主要從各種數據源采集監控數據并做一些必要的運算然后發送給數據存儲模塊進行存儲。數據源可以是kafka-zk、kafka自身（消費__consumer_offset）、JMX（主要是通過JMX來監控kafka的指標，故kafka啟動的時候需要指定JMX_PORT）、zabbix（或者其他類似的工具，主要用來監控集群硬件指標）。
- 數據存儲是指將采集的原始數據經過一定的預處理后進行相應的存儲，方便數據清洗（這個步驟可以省略）和數據展示。數據存儲可以采用Opentsdb之類的基于時間序列的數據庫，方便做一些聚合計算。
- 數據展示，顧名思義是將經過預處理的、存儲的數據展示到監控頁面上，提供豐富的UI給用戶使用。當然數據展示模塊也可以繞過數據存儲模塊直接向數據采集模塊，亦或者是數據源直接拉取數據。至于數據是從存儲模塊拉取還是更底層的源頭拉取，要看是否需要歷史時間段的值或者是是否需要最新值。
經過上面的分析整個監控系統可以大致概括為以下的模型：
不過上面的模型架構只是針對單一集群以及單機版的Collector，如果涉及到多個集群，就需要考慮均衡負載以及HA等方面的因素。我們針對這個模型做進一步的改進，主要是針對數據采集模塊的改進，如下圖所示：
每臺數據采集物理機上都部署一個主進程的服務，主進程負責根據需要創建Collector子進程，每個Collector子進程對應采集一個Kafka集群的監控數據。當某個集群需要被監控時，通過監控頁面設置或者其他途徑將集群的一些重要信息（比如kafka的地址、kafka-zk的地址、zabbix的地址、jmx端口號等）存儲起來并在zookeeper中/monitor/clusters/路徑下創建對應的子節點（實節點），當然為了方面也可以將這些重要信息作為data直接存儲在這個子節點中。各個主進程監聽/monitor/clusters/下的子節點的變化，如果發現有新的節點加入，就以搶占的方式創建Collector，并在/monitor/pids/路徑下創建對應集群的虛節點。
這里有幾點需要說明：
下面我們再來探討下數據存儲和數據展示這兩者之間的關系。正常邏輯下，監控頁面通過調取數據存儲模塊的api來獲取數據并展示在頁面上。試想下如果一個監控頁面需要調取幾十個指標，然后還要經過一定的計算之后才展示到頁面之上，那么這個頁面的渲染速度必然會受到一定的限制。
就拿指標UnderReplicatedPartitions來說，如果只能用一個指標來監控Kafka，那么非它莫屬。UnderReplicatedPartitions表示集群中副本處于同步失敗或失效狀態的分區數，即ISR<；AR。這個指標的獲取也很簡單，通過JMX調取kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions。UnderReplicatedPartitions的值為0則大吉大利，如果大于0則需要很多步驟來檢測異常原因，比如：檢測是否只發生在一個topic上；檢測是否只發生在一個broker上；如果不是前兩種，極可能是集群原因，那么集群原因又可能是由于負載不均衡導致的等等（UnderReplicatedPartitions的異常評估可以參考筆者下一篇文章）。UnderReplicatedPartitions背后要伴隨著一堆的指標來評估異常的緣由，就以負載不均衡來說，還涉及到復雜的計算：一個Broker的負載涉及其所承載的partitions的個數、leaders的個數、網絡讀寫速度、IO讀寫速度、CPU使用率等，要評判一個集群中是否有負責不均衡的情況出現，就需要將這些指標進行歸一化處理，然后再做均方差，如果超過設定的閾值即可評判集群發生了負載不均衡的現象。如果監控頁面從opentsdb中發送多個請求獲取原始數據，然后再內部進行復雜的計算之后再程序在頁面上，這個過程的耗時可以想象。更令人憂傷的是這么多的過程只是用來展示了一個指標，而一個頁面的呈現可能要涉及到很多個指標。
有了問題我們就需要解決它，這里筆者引入了一個新的模塊ComputeServer來進行數據預處理，然后將處理后的數據以HTTP RESTful API接口的方式提供給下游。下游的監控頁面和存儲模塊只需要通過這個接口讀取數據即可，無需過多的計算，從而提升了效率。新的架構模型如下圖所示：
上圖還引入了一個kafka的模塊，這個主要是用來將多個Collector與ComputeServer解耦，如果多個懸而未定Collector與ComputeServer直接交互必然是一個浩大工程。Kafka模塊可以針對每個集群創建對應的topic；亦或者是創建一個單獨的topic，然后劃分多個partition，每個集群的ID或者名稱作為消息的Key來進行區分。后者不必強求每個集群對應到獨立的partition中，ComputeServer在消費的時候可以獲取Key來辨別集群。而消息的Value就是Collector采集的原始數據，這里的消息的大小有可能超過Kafka Broker的默認單條消息的大小1000012B，不過筆者不建議調高這個值以及對應人max.request.size和max.partition.fetch.bytes參數的大小。可以開啟壓縮或者在Collector拆包以及在ComputeServer端解包的方式來進一步的解決消息過大的問題。還有一個就是這里的Kafka不建議開啟日志壓縮的功能，因為Kafka不僅是一個功能稍弱的消息中間件，同時也是一個功能弱化的時間序列數據庫，Kafka本身可以根據時間范圍來拉取對應的消息。在opentsdb不可靠的時候，完全可以使用kafka替代，只不過kafka出來的數據需要多做有些聚類運算。
在上圖中的①和②可以加入數據清洗邏輯亦或者是告警邏輯，將異常數據攔截出來，傳入其他的告警系統等來做進一步的處理。
上圖中的ComputeServer的HA可以簡單的通過LVS+Keepalived實現。
至此，一個包含數據采集+計算+存儲+展示的監控架構已經聊完。后面會另有文章來細說下Kafka中的監控指標以及其背后的含義。
歡迎跳轉到本文的原文鏈接：https://honeypps.com/mq/kafka-monitor-architecture-design/
歡迎支持筆者新作：《深入理解Kafka:核心設計與實踐原理》和《RabbitMQ實戰指南》，同時歡迎關注筆者的微信公眾號：朱小廝的博客。
總結
以上是生活随笔為你收集整理的Kafka监控架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Kafka分区分配计算(分区器Parti
- 下一篇： Kafka解析之失效副本