大家好，我是君哥。

使用消息隊列可以幫助我們實現(xiàn)系統(tǒng)解耦、流量管控等功能。但使用過程中可能會遇到各種各樣的問題，比如系統(tǒng)資源使用率高、集群節(jié)點宕機等，進而影響我們生產(chǎn)業(yè)務(wù)正常開展。為了不讓消息隊列失控，增加監(jiān)控是非常必要的。今天來聊一聊 Kafka 有哪些重要的監(jiān)控指標。

1 基礎(chǔ)指標

基礎(chǔ)指標是監(jiān)控系統(tǒng)常見的監(jiān)控指標，這里介紹 4 個方面：

• CPU、內(nèi)存、硬盤、網(wǎng)絡(luò) I/O 等資源使用情況，Kafka 提供了 BytesIn/BytesOut 指標來監(jiān)控帶寬使用率；
• TCP 連接數(shù)、文件描述符使用情況；
• JVM 監(jiān)控指標，Kafka 也是一個 JVM 進程，需要監(jiān)控堆內(nèi)存使用情況、FULL GC 頻率和時長、JVM 線程數(shù)等；
• 網(wǎng)絡(luò)延遲。

2 Broker 指標

2.1 UnderReplicatedPartitions

Kafka 分區(qū) Leader 節(jié)點收到消息后，會同步給 Follower 節(jié)點。集群健康的情況下，UnderReplicatedPartitions 值等于 0，這時同步正常的 Follower 節(jié)點數(shù)量（也就是 ISR）等于總的 Follower 節(jié)點數(shù)量。如果這個指標值大于0，比如等于 1，說明有一個 Follower 同步異常，如下圖：

圖片

2.2 ISRShrink/ISRExpand

這個指標表示 ISR 收縮和擴容的頻率。如果這個指標的值很高，那集群中必定有 Follower 節(jié)點頻繁地進入或退出 ISR。這個時候就需要定位有 Follower 頻繁進出 ISR 的原因。

2.3 ActiveControllerCount

Kafka Broker 集群中有一個節(jié)點是 Controller 節(jié)點，這個節(jié)點非常重要，負責(zé)監(jiān)聽 Partition、Topic 和 Broker 的變化，以及元數(shù)據(jù)管理。

ActiveControllerCount 指標表示當(dāng)前 Broker 節(jié)點是否是 Controller 節(jié)點，集群健康的情況下，有且僅有一個 Broker 節(jié)點這個指標值是 1。如果有多個 Broker 這個指標值是 1，或者所有 Broker 指標值都是 0，就需要進行故障排查。

圖片

2.4 offlinePartitionCount

這個指標只有 Controller 節(jié)點有。表示處于不可用狀態(tài)的 Partition 的數(shù)量，也就是 Partition 沒有活躍的 Leader 節(jié)點的數(shù)量。健康的集群，這個值是 0，如果這個值不是 0，就得盡快排查原因，防止影響業(yè)務(wù)。

2.5 LeaderElectionRateAndTimeMs

當(dāng)分區(qū) Leader 節(jié)點掛了之后，就會觸發(fā)選舉新的 Leader。這個指標值表示選舉新 Leader 的頻率（每秒多少次）和集群中無 Leader 節(jié)點的時長。觸發(fā) Leader 選舉，肯定是舊的 Leader 下線，所以需要定位分析原因。

2.6 UncleanLeaderElectionsPerSec

當(dāng) Broker 集群找不到分區(qū) Leader 時，需要從 ISR 集合中選出新的 Leader 節(jié)點。而如果 ISR 集合沒有節(jié)點，那就得從未同步的 Follower 中選出 Leader 節(jié)點，讓集群處于可用狀態(tài)，但這個時候因為消息未同步，會有消息丟失。所以這個指標有數(shù)據(jù)時，代表可能有消息丟失。

2.7 TotalTimeMs

Broker 處理一筆請求的總時間。比如處理 Producer 發(fā)送請求、Consumer 拉取請求、Follower 拉取請求。這個時間如果出現(xiàn)了比較大的波動，需要查看 Broker 的資源情況并考慮應(yīng)對方案。

3 Producer

生產(chǎn)者也可以加一些指標來監(jiān)控發(fā)送消息的情況。

3.1 request-latency-avg

平均請求時間，這個指標包括生產(chǎn)者發(fā)送消息到收到響應(yīng)的延遲，這個指標會影響 Producer 端的吞吐量。

3.2 waiting-threads

發(fā)送緩存區(qū)中阻塞的用戶線程數(shù)，如果這個指標變高，意味著生產(chǎn)者被阻塞的線程數(shù)變高，需要排查原因。

4 Consumer

4.1 records-lag

消費者在當(dāng)前分區(qū)上落后于生產(chǎn)者的數(shù)量，如果這個值變大，有可能當(dāng)前這個分區(qū)的消息量突增，也可能消費者消費能力下降，需要關(guān)注。

5 總結(jié)

Kafka 的監(jiān)控指標非常多，關(guān)鍵指標是必須要監(jiān)控的，其他指標可以根據(jù)需要添加，同時也可以加入日志相關(guān)的監(jiān)控。希望本文能對你理解 Kafka 有所幫助。