Prometheus+Grafana通過kafka_exporter監控kafka

---

原文地址： CSDN：GeekXuShuo：[Prometheus 監控之 kafka](https://blog.csdn.net/qq_25934401/article/details/84840740)

---

默認情況下, Kafka metrics 所有的 metric 都可以通過 JMX 獲取，暴露kafka metrics 支持兩種方式
1.在 Kafka Broker 外部, 作爲一個獨立進程, 通過 JMX 的 RMI 接口讀取數據. 這種方式的好處是有任何調整不需要重啓 Kafka Broker 進程, 缺點是多維護了一個獨立的進程。
2.在 Kafka Broker 進程內部讀取 JMX 數據, 這樣解析數據的邏輯就在 Kafka Broker 進程內部, 如果有任何調整, 需要重啓 Broker。

一、暴露 kafka-metric 方式

第一種需要外部多維護一個程序，而且還要考慮之後各種版本升級，實現起來比較繁瑣，還好的是github上有許多優秀的開源kafka_exporter 下載過來直接啓動就好了。
git項目地址：https://github.com/danielqsj/kafka_exporter
下載地址： https://github.com/danielqsj/kafka_exporter/releases/download/v1.2.0/kafka_exporter-1.2.0.linux-amd64.tar.gz

要在你想監控kafka的機器上裝上kafka_exporter，每個都要裝，如157、158、159：

啓動：

# 解壓kafka_exporter，進到目錄，執行命令：
nohup ./kafka_exporter --kafka.server=10.131.178.157:9092 &

kafka_exporter --kafka.server=kafka:9092 [--kafka.server=another-server ...]

經測試，這種方式可以獲取到kafka的指標數據，但是沒有合適的Grafana的Dashboard支撐。

二、jmx_exporter方式

（這種方式，自己搭建起來後，9999端口和9991端口一直打不開，暫未查明原因，還在研究之中。）

第二種是讀取 JMX 的數據. Prometheus 官方的組件 jmx_exporter 把兩種實現都提供了：

• jmx_prometheus_httpserver 通過獨立進程讀取 JMX 的數據
• jmx_prometheus_javaagent 使用 Java Agent 方式, 儘量無侵入(僅需在 java 命令行中使用 -javaagent 參數)的啓動 in-process library, 讀取 JMX 數據.
• Prometheus 採用了 PULL 方式, Prometheus 主動抓取 metrics 數據, 而不是靠客戶端主動 PUSH 數據, 因此 jmx_prometheus 都是通過暴露 HTTP 端口的方式暴露 metrics 數據, 方便 Prometheus 抓取數據。

2.1 下載jmx_prometheus_javaagent和kafka.yml

wget https://raw.githubusercontent.com/prometheus/jmx_exporter/master/example_configs/kafka-0-8-2.yml
wget https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.6/jmx_prometheus_javaagent-0.6.jar

打開 kafka-server-start.sh 文件
添加幾行代碼：

export JMX_PORT="9999"
export KAFKA_OPTS="-javaagent:/path/jmx_prometheus_javaagent-0.6.jar=9991:/path/kafka-0-8-2.yml"

然後重啓kafka。
訪問 http://localhost:9991/metrics 可以看到各種指標了。

2.2 監控指標

2.3 預警指標分析

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions **
含義: 正在複製的 Partition 的數量.
建議報警閾值: > 0 就建議報警. 但如果 Kafka 集羣正在 reassign partition 時, 這個值也會 >0

kafka.controller:type=KafkaController,name=OfflinePartitionsCount
含義: 沒有 Leader 的 Partition 的數量. 處於這個狀態的 Partition 是不可讀也不可寫
建議報警閾值: >0 一旦出現就報警.

kafka.controller:type=KafkaController,name=ActiveControllerCount
含義: 活躍的 Controller 的數量.
建議報警閾值: != 0 就趕緊報警

kafka.server:type=ReplicaManager,name=PartitionCount
含義: 集羣中 Partition 的總數
建議報警閾值: 感覺這個報警不可控.

kafka_controller_controllerstats_leaderelectionrateandtimems
含義: Leader election rate 領導人選舉率

UncleanLeaderElectionsPerSec
含義: Unclean leader election rate 爭議的 leader 選舉次數

描述：所有的topic的消息速率(消息數/秒)
Mbean名：“kafka.server”:name=“AllTopicsMessagesInPerSec”,type=“BrokerTopicMetrics”
正常的值：

描述：所有的topic的流入數據速率(字節/秒)
Mbean名：“kafka.server”:name=“AllTopicsBytesInPerSec”,type=“BrokerTopicMetrics”
正常的值：

描述：producer或Fetch-consumer或Fetch-follower的請求速率(請求次數/秒)
Mbean名：“kafka.network”:name="{Produce|Fetch-consumer|Fetch-follower}-RequestsPerSec",type=“RequestMetrics”
正常的值：

描述：所有的topic的流出數據速率(字節/秒)
Mbean名： “kafka.server”:name=“AllTopicsBytesOutPerSec”,type=“BrokerTopicMetrics”
正常的值：

描述：刷日誌的速率和耗時
Mbean名： “kafka.log”:name=“LogFlushRateAndTimeMs”,type=“LogFlushStats”
正常的值：

描述：正在做複製的partition的數量(|ISR| < |all replicas|)
Mbean名：“kafka.server”:name=“UnderReplicatedPartitions”,type=“ReplicaManager”
正常的值：0

描述：當前的broker是否爲controller
Mbean名：“kafka.controller”:name=“ActiveControllerCount”,type=“KafkaController”
正常的值：在集羣中只有一個broker的這個值爲1

描述：選舉leader的速率
Mbean名：“kafka.controller”:name=“LeaderElectionRateAndTimeMs”,type=“ControllerStats”
正常的值：如果有broker掛了，此值非0

描述：Unclean的leader選舉速率
Mbean名：“kafka.controller”:name=“UncleanLeaderElectionsPerSec”,type=“ControllerStats”
正常的值：0

描述：該broker上的partition的數量
Mbean名： “kafka.server”:name=“PartitionCount”,type=“ReplicaManager”
正常的值：應在各個broker中平均分佈

描述：Leader的replica的數量
Mbean名： “kafka.server”:name=“LeaderCount”,type=“ReplicaManager”
正常的值：應在各個broker中平均分佈

描述：ISR的收縮(shrink)速率
Mbean名：“kafka.server”:name=“ISRShrinksPerSec”,type=“ReplicaManager”
正常的值：如果一個broker掛掉了，一些partition的ISR會收縮。當那個broker重新起來時，一旦它的replica完全跟上，ISR會擴大(expand)。除此之外，正常情況下，此值和下面的擴大速率都是0。

描述：ISR的擴大(expansion)速率
Mbean名： “kafka.server”:name=“ISRExpandsPerSec”,type=“ReplicaManager”
正常的值：參見ISR的收縮(shrink)速率

描述：follower落後leader replica的最大的消息數量
Mbean名：“kafka.server”:name="([-.\w]+)-MaxLag",type=“ReplicaFetcherManager”
正常的值：小於replica.lag.max.messages

描述：每個follower replica落後的消息速率
Mbean名：“kafka.server”:name="([-.\w]+)-ConsumerLag",type=“FetcherLagMetrics”
正常的值：小於replica.lag.max.messages

描述：等待producer purgatory的請求數
Mbean名：“kafka.server”:name=“PurgatorySize”,type=“ProducerRequestPurgatory”
正常的值：如果ack=-1，應爲非0值

描述：等待fetch purgatory的請求數
Mbean名：“kafka.server”:name=“PurgatorySize”,type=“FetchRequestPurgatory”
正常的值：依賴於consumer的fetch.wait.max.ms的設置

描述：一個請求(producer,Fetch-Consumer,Fetch-Follower)耗費的所有時間
Mbean名：“kafka.network”:name="{Produce|Fetch-Consumer|Fetch-Follower}-TotalTimeMs",type=“RequestMetrics”
正常的值：包括了queue, local, remote和response send time

描述：請求(producer,Fetch-Consumer,Fetch-Follower)在請求隊列中的等待時間
Mbean名：“kafka.network”:name="{Produce|Fetch-Consumer|Fetch-Follower}-QueueTimeMs",type=“RequestMetrics”
正常的值：

描述：請求(producer,Fetch-Consumer,Fetch-Follower)在leader處理請求花的時間
Mbean名：“kafka.network”:name="{Produce|Fetch-Consumer|Fetch-Follower}-LocalTimeMs",type=“RequestMetrics”
正常的值：

描述：請求(producer,Fetch-Consumer,Fetch-Follower)等待follower花費的時間
Mbean名：“kafka.network”:name="{Produce|Fetch-Consumer|Fetch-Follower}-RemoteTimeMs",type=“RequestMetrics”
正常的值：producer的ack=-1時，非0才正常

描述：發送響應花費的時間
Mbean名：“kafka.network”:name="{Produce|Fetch-Consumer|Fetch-Follower}-ResponseSendTimeMs",type=“RequestMetrics”
正常的值：

描述：consumer落後producer的消息數量
Mbean名：“kafka.consumer”:name="([-.\w]+)-MaxLag",type=“ConsumerFetcherManager”
正常的值：
建議對GC耗時和其他參數和諸如系統CPU，I/O時間等等進行監控。在client端，建議對"消息數量/字節數"的速率(全局的和對於每一個topic)，請求的"速率/大小/耗時"進行監控。還有consumer端，所有partition的最大的落後情況和最小的fetch請求的速率。consumer爲了能跟上，最大落後數量需要少於一個threshold並且最小fetch速率需要大於0.

2.4 Grafana Dashboard JSON

json文件鏈接:https://pan.baidu.com/s/1H6MesKpqi80R14OF5k7auQ 密碼:kiox