Kafka監(jiān)控架構設計

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

讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：域名注冊、網絡空間、營銷軟件、網站建設、張店網站維護、網站推廣。

Kafka監(jiān)控主要分為數據采集、數據存儲以及數據展示3個部分。

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

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

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

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

這里有幾點需要說明：

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

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

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

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

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

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

上圖中的ComputeServer的HA可以簡單的通過LVS+Keepalived實現。

至此，一個包含數據采集+計算+存儲+展示的監(jiān)控架構已經聊完。后面會另有文章來細說下Kafka中的監(jiān)控指標以及其背后的含義。

---

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

需要更詳細思維導圖和以下資料的可以加一下技術交流分享群：“708 701 457”免費獲取

分享標題：Kafka監(jiān)控架構設計
文章URL：http://muchs.cn/article12/jpejdc.html

成都網站建設公司_創(chuàng)新互聯，為您提供網站導航、商城網站、企業(yè)建站、網站收錄、品牌網站制作、網站維護

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯