Kafka 架構
?上面綠色部分 PRODUCER（生產者）和下面紫色部分 CONSUMER（消費者）是業務程序，通常由研發人員埋點解決監控問題，如果是 Java 客戶端也會暴露 JMX 指標。組件運維監控層面著重關注藍色部分的 BROKER（Kafka 節點）和紅色部分的 ZOOKEEPER。
ZooKeeper 也是 Java 語言寫的，監控相對簡單，另外 ZooKeeper 支持 mntr 四字命令，可以獲取 ZooKeeper 內部健康狀況。新版 ZooKeeper 連四字命令都不需要了，直接內置暴露了 Prometheus 協議的 metrics 接口，直接抓取即可。
重點關注 Broker 節點的監控，也就是 Kafka 自身的監控，通常從四個方面著手。
- Kafka 進程所在機器的監控，重點關注 CPU、硬盤 I/O、網絡 I/O。
- JVM 監控，Kafka 是個 Java 進程，所以需要常規的 JVM 監控，通過 JMX 方式暴露。
- Kafka 自身的指標、也是通過 JMX 方式暴露，比如消息數量、流量、分區、副本的數量等。
- 各個 consumer 的 lag 監控，即消息堆積量，是各類 MQ 都應該監控的指標。
JMX（Java Management Extensions）是一個為應用程序植入管理功能的框架。Java 程序接入 JMX 框架之后，可以把一些類的屬性和方法暴露出來，用戶就可以使用 JMX 相關工具來讀取或操作這些類。
Kafka 的配置文件在 config 目錄，各種腳本在 bin 目錄，要讓 Kafka 開啟 JMX，肯定是要修改某個配置項或者調整某個腳本的，具體調整哪里呢？我們在 Kafka 的部署目錄搜索一下看看。
grep -i jmx -r config
grep -i jmx -r binJMX 數據分兩類，一類是和 JVM 相關的，一類是和 Kafka 相關的。
ThreadCount 表示 JVM 里的線程數，類似的還有 DaemonThreadCount，表示后臺線程數，PeakThreadCount 表示歷史峰值線程數。JVM 要重點關注 GC 的情況和內存的情況。
GC 主要看次數和時間，分為 YongGC 和 FullGC，YongGC 很正常，頻率也比較高，FullGC 正常情況下很少發生，如果經常發生，FullGC 程序的性能就會受影響。GC 次數的指標是 kafka_java_garbage_collector_CollectionCount，是一個 Counter 類型單調遞增的值。GC 時間的指標是 kafka_java_garbage_collector_CollectionTime，也是一個 Counter 類型單調遞增的值。
內存的指標是 kafka_java_memory_pool_Usage_used，單位是 byte。有個 name 標簽標識了具體是哪個區域的內存大小，比如 Eden 區、Survivor 區、Old 區。
Kafka 指標
- 活躍控制器數量：MBean：broker kafka.controller:type=KafkaController,name=ActiveControllerCount。一個 Kafka 集群有多個 Broker，正常來講其中一個 Broker 會是活躍控制器，且只能有一個。從整個集群角度來看，SUM 所有 Broker 的這個指標，結果應該為 1。如果
- 非同步分區數量：MBean：kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions。這個指標是對每個 Topic 的每個分區的統計，如果某個分區主從同步出現問題，對應的數值就會大于 0。
- 離線分區數量：MBean：kafka.controller:type=KafkaController,name=OfflinePartitionsCount。這個指標只有集群控制器才有，其他 Broker 這個指標的值是 0，表示集群里沒有 leader 的分區數量。
- 離線日志目錄數量：MBean：kafka.log:type=LogManager,name=OfflineLogDirectoryCount。Kafka 是把收到的消息存入 log 目錄，如果 log 目錄有問題，比如寫滿了，就會被置為 Offline，及時監控離線日志目錄的數量顯然非常有必要。
- 流入流出字節和流入消息：這是典型的吞吐指標，既有 Broker 粒度的，也有 Topic 粒度的，名字都一樣，Topic 粒度的指標數據 MBean ObjectName 會多一個 topic=xx 的后綴。
- 流入字節：MBean：kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec。這個指標 Kafka 在使用 Yammer Metrics 埋點的時候，設置為了 Meter 類型，所以 Yammer 會自動計算出 Count、OneMinuteRate、FiveMinuteRate、FifteenMinuteRate、MeanRate 等指標，也就是 1 分鐘、5 分鐘、15 分鐘內的平均流入速率，以及整體平均流入速率。
- 流出字節：MBean：kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec。和 BytesInPerSec 類似，表示出向流量。不過需要注意的是，流出字節除了普通消費者的消費流量，也包含了副本同步流量。
- 流入消息：MBean：kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSecBytesInPerSec 和 BytesOutPerSec 都是以 byte 為單位統計的，而 MessagesInPerSec 是以消息個數為單位統計的，也是 Meter 類型，相關屬性都一樣。
- 分區數量：MBean：kafka.server:type=ReplicaManager,name=PartitionCount這個指標表示某個 Broker 上面總共有多少個分區，包括 leader 分區和 follower 分區。如果多個 Broker 分區不均衡，可能會造成有些 Broker 消耗硬盤空間過快，這是需要注意的。
- leader 分區數量：MBean：kafka.server:type=ReplicaManager,name=LeaderCount這個指標表示某個 Broker 上面總共有多少個 leader 分區，leader 分區負責數據讀寫，承接流量，所以 leader 分區如果不均衡，會導致某些 Broker 過分繁忙而另一些 Broker 過分空閑，這種情況也是需要我們注意的。
此文章為8月Day8學習筆記，內容來源于極客時間《運維監控系統實戰筆記》，推薦該課程。
)
