使用消息隊(duì)列可以幫助我們實(shí)現(xiàn)系統(tǒng)解耦、流量管控等功能。但使用過程中可能會(huì)遇到各種各樣的問題，比如系統(tǒng)資源使用率高、集群節(jié)點(diǎn)宕機(jī)等，進(jìn)而影響我們生產(chǎn)業(yè)務(wù)正常開展。為了不讓消息隊(duì)列失控，增加監(jiān)控是非常必要的。今天來聊一聊 Kafka 有哪些重要的監(jiān)控指標(biāo)。
1 基礎(chǔ)指標(biāo)
基礎(chǔ)指標(biāo)是監(jiān)控系統(tǒng)常見的監(jiān)控指標(biāo)，這里介紹 4 個(gè)方面：
- CPU、內(nèi)存、硬盤、網(wǎng)絡(luò) I/O 等資源使用情況，Kafka 提供了 BytesIn/BytesOut 指標(biāo)來監(jiān)控帶寬使用率；
- TCP 連接數(shù)、文件描述符使用情況；
- JVM 監(jiān)控指標(biāo)，Kafka 也是一個(gè) JVM 進(jìn)程，需要監(jiān)控堆內(nèi)存使用情況、FULL GC 頻率和時(shí)長、JVM 線程數(shù)等；
- 網(wǎng)絡(luò)延遲。
2 Broker 指標(biāo)
2.1 UnderReplicatedPartitions
Kafka 分區(qū) Leader 節(jié)點(diǎn)收到消息后，會(huì)同步給 Follower 節(jié)點(diǎn)。集群健康的情況下，UnderReplicatedPartitions 值等于 0，這時(shí)同步正常的 Follower 節(jié)點(diǎn)數(shù)量（也就是 ISR）等于總的 Follower 節(jié)點(diǎn)數(shù)量。如果這個(gè)指標(biāo)值大于0，比如等于 1，說明有一個(gè) Follower 同步異常，如下圖：
圖片
2.2 ISRShrink/ISRExpand
這個(gè)指標(biāo)表示 ISR 收縮和擴(kuò)容的頻率。如果這個(gè)指標(biāo)的值很高，那集群中必定有 Follower 節(jié)點(diǎn)頻繁地進(jìn)入或退出 ISR。這個(gè)時(shí)候就需要定位有 Follower 頻繁進(jìn)出 ISR 的原因。
2.3 ActiveControllerCount
Kafka Broker 集群中有一個(gè)節(jié)點(diǎn)是 Controller 節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)非常重要，負(fù)責(zé)監(jiān)聽 Partition、Topic 和 Broker 的變化，以及元數(shù)據(jù)管理。
ActiveControllerCount 指標(biāo)表示當(dāng)前 Broker 節(jié)點(diǎn)是否是 Controller 節(jié)點(diǎn)，集群健康的情況下，有且僅有一個(gè) Broker 節(jié)點(diǎn)這個(gè)指標(biāo)值是 1。如果有多個(gè) Broker 這個(gè)指標(biāo)值是 1，或者所有 Broker 指標(biāo)值都是 0，就需要進(jìn)行故障排查。
圖片
2.4 offlinePartitionCount
這個(gè)指標(biāo)只有 Controller 節(jié)點(diǎn)有。表示處于不可用狀態(tài)的 Partition 的數(shù)量，也就是 Partition 沒有活躍的 Leader 節(jié)點(diǎn)的數(shù)量。健康的集群，這個(gè)值是 0，如果這個(gè)值不是 0，就得盡快排查原因，防止影響業(yè)務(wù)。
2.5 LeaderElectionRateAndTimeMs
當(dāng)分區(qū) Leader 節(jié)點(diǎn)掛了之后，就會(huì)觸發(fā)選舉新的 Leader。這個(gè)指標(biāo)值表示選舉新 Leader 的頻率（每秒多少次）和集群中無 Leader 節(jié)點(diǎn)的時(shí)長。觸發(fā) Leader 選舉，肯定是舊的 Leader 下線，所以需要定位分析原因。
2.6 UncleanLeaderElectionsPerSec
當(dāng) Broker 集群找不到分區(qū) Leader 時(shí)，需要從 ISR 集合中選出新的 Leader 節(jié)點(diǎn)。而如果 ISR 集合沒有節(jié)點(diǎn)，那就得從未同步的 Follower 中選出 Leader 節(jié)點(diǎn)，讓集群處于可用狀態(tài)，但這個(gè)時(shí)候因?yàn)橄⑽赐剑瑫?huì)有消息丟失。所以這個(gè)指標(biāo)有數(shù)據(jù)時(shí)，代表可能有消息丟失。
2.7 TotalTimeMs
Broker 處理一筆請(qǐng)求的總時(shí)間。比如處理 Producer 發(fā)送請(qǐng)求、Consumer 拉取請(qǐng)求、Follower 拉取請(qǐng)求。這個(gè)時(shí)間如果出現(xiàn)了比較大的波動(dòng)，需要查看 Broker 的資源情況并考慮應(yīng)對(duì)方案。
3 Producer
生產(chǎn)者也可以加一些指標(biāo)來監(jiān)控發(fā)送消息的情況。
3.1 request-latency-avg
平均請(qǐng)求時(shí)間，這個(gè)指標(biāo)包括生產(chǎn)者發(fā)送消息到收到響應(yīng)的延遲，這個(gè)指標(biāo)會(huì)影響 Producer 端的吞吐量。
3.2 wAIting-threads
發(fā)送緩存區(qū)中阻塞的用戶線程數(shù)，如果這個(gè)指標(biāo)變高，意味著生產(chǎn)者被阻塞的線程數(shù)變高，需要排查原因。
4 Consumer
4.1 records-lag
消費(fèi)者在當(dāng)前分區(qū)上落后于生產(chǎn)者的數(shù)量，如果這個(gè)值變大，有可能當(dāng)前這個(gè)分區(qū)的消息量突增，也可能消費(fèi)者消費(fèi)能力下降，需要關(guān)注。
5 總結(jié)
Kafka 的監(jiān)控指標(biāo)非常多，關(guān)鍵指標(biāo)是必須要監(jiān)控的，其他指標(biāo)可以根據(jù)需要添加，同時(shí)也可以加入日志相關(guān)的監(jiān)控。希望本文能對(duì)你理解 Kafka 有所幫助。
