Prometheus 監控之 kafka


初探

默認情況下, 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_exporter --kafka.server=kafka:9092 [--kafka.server=another-server ...]

     
     
    
   
   
           
    
    
   
  
  
          
  • 1

Grafana畫圖也有許多優秀的開源dashboard

第二種是讀取 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

我們這里選擇第二種jmx_prometheus_javaagent 方式收集kafka指標

部署流程:
下載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

     
     
    
   
   
           
    
    
   
  
  
          
  • 1
  • 2
打開 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"

     
     
    
   
   
           
    
    
   
  
  
          
  • 1
  • 2

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

監控指標

部分監控指標解釋,不一定准確,請參考。還有參考 monitoring kafafka 有詳細的指標信息

指標 解釋
kafka_server_replicafetchermanager_maxlag Max
kafka_server_replicamanager_isrexpands_total ISR expansion rate 擴大率(ISR是in-sync replicas的簡寫)
kafka_server_replicamanager_isrshrinks_total ISR shrink rate 收縮率
kafka_server_replicamanager_underreplicatedpartitions # of under replicated partitions (|ISR| < |all replicas|)
kafka_network_requestmetrics_responsesendtimems Time to send the response Produce
kafka_network_socketserver_networkprocessoravgidlepercent The average fraction of time the network processors are idle
kafka_network_requestmetrics_responsesendtimems
kafka_network_requestmetrics_requestqueuetimems Time the request waiting in the request queue Produce
kafka_network_requestmetrics_remotetimems Time the request waits for the follower Produce
kafka_network_requestmetrics_localtimems Time the request being processed at the leader Produce
kafka_log_logflushstats_logflushrateandtimems_count Log flush latency
kafka_server_replicafetchermanager_minfetchrate Max lag in messages btw follower and leader replicas > 4000
kafka_controller_controllerstats_uncleanleaderelectionspersec Unclean leader election has occurred last 15m
kafka_server_replicamanager_underreplicatedpartitions Under replicated partitions
kafka_controller_kafkacontroller_activecontrollercount 活躍的 Controller 的數量
kafka_controller_controllerstats_uncleanleaderelectionspersec 爭議的 leader 選舉次數
kafka_controller_controllerstats_controlledshutdownrateandtimems 將ISR中處於關閉狀態的副本從集合中去除掉,返回一個新的ISR集合,然后選取第一個副本作為leader,然后令當前AR作為接收LeaderAndIsr請求的副本。
kafka_controller_kafkacontroller_offlinepartitionscount 從活着的ISR中選擇一個broker作為leader,如果ISR中沒有活着的副本,則從assignedReplicas中選擇一個副本作為leader,leader選舉成功后注冊到Zookeeper中,並更新所有的緩存。
broker指標
kafka_server_brokertopicmetrics_messagesin_total 所有topic消息(進出)流量 消息寫入總量
kafka_server_brokertopicmetrics_bytesrejected_total 扔掉的流量
kafka_server_brokertopicmetrics_failedfetchrequests_total 當前機器fetch請求失敗的數量
kafka_server_brokertopicmetrics_bytesout_total 輸出的流量
kafka_server_brokertopicmetrics_bytesin_total 輸入的流量
kafka_server_brokertopicmetrics_failedproducerequests_total 當前機器produce請求失敗的數量
kafka_server_replicamanager_partitioncount 該broker上的partition的數量
kafka_server_replicamanager_leadercount Leader的replica的數量
kafka_network_requestmetrics_totaltimems{FetchConsumer\FetchFollower\Produce} 一個請求FetchConsumer\FetchFollower\Produce耗費的所有時間

預警指標分析

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.

Grafana畫圖

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

在這里插入圖片描述


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM