Linux環境下Kafka監控的核心指標分類及說明
一、Broker核心指標
Broker是Kafka集群的核心節點，其監控指標直接反映集群的穩定性和性能：
- UnderReplicatedPartitions：處于“未同步”狀態的Partition數量（即ISR集合外的副本數）。若該值持續大于0，說明副本同步出現問題，可能導致數據丟失。
- ActiveControllerCount：當前活躍的Controller數量（Kafka集群中負責分區Leader選舉的節點）。正常情況下應始終為1，若為0則表示集群失去主控，無法進行Leader選舉。
- OfflinePartitionsCount：離線Partition數量（無Leader的Partition）。若該值大于0，說明部分Partition無法提供服務，需立即排查Broker宕機或分區Leader選舉失敗問題。
- UncleanLeaderElectionsPerSec：未清理Leader選舉的頻率（即非ISR副本成為Leader的次數）。該值越高，數據丟失風險越大，需通過
min.insync.replicas參數限制非ISR副本成為Leader的可能性。
- BytesInPerSec/BytesOutPerSec：Kafka集群的每秒入站/出站字節數（吞吐量）。反映集群的數據流入流出速度，可用于評估集群負載是否飽和。
- RequestHandlerIdleRatio：請求處理器空閑比例（1 - 忙碌線程數/總線程數）。若該值長期低于0.3，說明Broker處理能力不足，需增加Broker節點或調整線程池配置。
- JVM指標：包括堆內存使用率（
MemHeapUsedPercent）、Full GC次數（FullGCCount）、線程數（ThreadCount）。JVM內存泄漏或頻繁Full GC會導致Broker停頓，影響集群可用性。
二、Topic與Partition核心指標
Topic和Partition是Kafka存儲和轉發的基本單位，其監控指標用于評估數據分布和存儲狀態：
- MessagesInPerSec：Topic每秒消息生產速率（生產者發送到Topic的消息數）。反映Topic的寫入負載，可用于判斷是否需要擴容分區。
- BytesInPerSec/BytesOutPerSec：Topic每秒入站/出站字節數（生產者寫入和消費者讀取的字節數）。結合分區數可計算每個分區的平均吞吐量。
- LogSize/LogEndOffset：Partition日志文件的總大?。?code>LogSize）和最新偏移量（
LogEndOffset）。兩者的差值即為未消費的消息量（需結合消費者偏移量計算Lag）。
- PartitionCount：Topic的分區數量。分區數過少會導致并行度不足，過多會增加ZooKeeper負擔，需根據業務需求調整。
- ISR（In-Sync Replicas）數量：與Leader副本保持同步的副本數量（
IsrCount）。若ISR數量低于min.insync.replicas配置值，生產者發送消息會失?。ǔ窃O置acks=0），需確保ISR數量滿足可靠性要求。
三、Producer核心指標
Producer負責向Kafka發送消息，其監控指標用于評估消息發送的可靠性和性能：
- RecordSendRate：每秒發送的消息數（生產者成功發送到Broker的消息數）。反映生產者的寫入速率，若持續低于預期，可能是網絡問題或Broker負載過高。
- RecordRetryRate：每秒重試發送的消息數（生產者因失敗而重試的消息數）。重試次數過多說明網絡不穩定或Broker不可用，需檢查網絡連接或Broker狀態。
- RequestLatencyAvg：請求平均延遲（生產者發送請求到收到響應的時間）。延遲過高會影響生產者的吞吐量，需優化網絡或調整Broker參數（如
num.network.threads）。
- Errors/FailedBatches：發送失敗的次數/批次（生產者發送失敗的消息數或批次數）。若該值持續大于0，需檢查生產者配置（如
acks、retries）或Broker是否正常。
四、Consumer核心指標
Consumer負責從Kafka消費消息，其監控指標用于評估消費的及時性和可靠性：
- ConsumerLag（FetchLag）：消費者消費滯后量（
LogEndOffset - ConsumerOffset）。反映消費者處理消息的速度，若Lag持續增長，說明消費者處理能力不足，需增加消費者實例或優化消費邏輯。
- RecordsConsumedRate：每秒消費的消息數（消費者成功處理的消息數）。反映消費者的消費速率，若持續低于生產者速率，會導致消息堆積。
- FetchRequestsPerSec：每秒Fetch請求次數（消費者向Broker請求消息的次數）。若該值過高，可能是消費者批量大?。?code>fetch.max.bytes）設置過小，需調整參數以提高吞吐量。
- RebalanceCount/Frequency：消費者組Rebalance次數/頻率（消費者組重新分配分區的次數）。過于頻繁的Rebalance會影響消費性能，需檢查消費者實例的穩定性（如是否頻繁宕機）或
session.timeout.ms配置。
五、集群與操作系統指標
集群和操作系統的狀態直接影響Kafka的運行，需監控以下基礎指標：
- ZooKeeper指標（Kafka 2.8前）：包括ZooKeeper連接數（
ZooKeeperConnections）、請求延遲（ZooKeeperRequestLatencyAvg）、內存使用（ZooKeeperMemoryUsed）。ZooKeeper是Kafka的核心協調服務，其異常會導致集群無法正常工作。
- 操作系統指標：
- 磁盤：磁盤使用率（
DiskUsage）、I/O等待時間（DiskIOWait）、inode使用率（InodeUsage）。磁盤滿或I/O瓶頸會導致Broker性能下降。
- CPU：CPU使用率（
CpuUsage）、負載平均值（LoadAverage）。CPU過載會導致請求延遲增加。
- 網絡：網卡入流量/出流量（
NetInBytes/NetOutBytes）、連接數（TcpConnections）。網絡帶寬不足會影響數據傳輸效率。
