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