原文地址：https://www.douyacun.com/article/60f482659925e7fbef70db7836c96d7e

监控指标

grafana dashboards https://grafana.com/grafana/dashboards/10973

阿里云kafka arms监控 https://help.aliyun.com/document_detail/141108.html?spm=a2c4g.11186623.6.570.7b1b65732naKbX

Kafka各指标的含义: https://docs.confluent.io/current/kafka/monitoring.html?spm=a2c4g.11186623.2.13.47ed6688HS2ItR

看了一下其他kafka监控文章都没有自信说明kafka各项指标，指标含义，以及如何收集，再次自信整理了一下kafka监控指标、含义以及如何收集：

broker度量指标
- 正在复制的分区数量 - 关键指标
- 活跃控制器数量
- 请求处理器空闲率
- 请求度量指标
topic度量指标
- 主题流入字节速率
- 主题流出字节速率
- 主题流入消息速率
partition度量指标
- 分区数量
- 首领分区数量
- 离线分区数量
- 分区占用磁盘大小
- 分区文件数量
- 分区消息最大偏移量
- 分区消息最小偏移量

jmx-exporter 指标收集

prometheus 提供了 jmx_exporter 来收集 kafka 指标

Github：https://github.com/prometheus/jmx_exporter

配置文件：https://github.com/prometheus/jmx_exporter/blob/master/example_configs/kafka-2_0_0.yml

配合kafka启动脚本，修改 bin/kafka_server_start.sh，添加常量，只需要在一个实例中添加即可

export KAFKA_OPTS="-javaagent:$base_dir/jmx_prometheus_javaagent-0.15.0.jar=7071:$conf_dir/kafka-2_0_0.yml"

prometheus targets 收集 metrics

static_configs:
  - targets: ['127.0.0.1:7071']

如果是docker启动的prometheus，而kafka是宿主机启动的话

static_configs:
  - targets: ['docker.for.mac.host.internal:7071']

broker 度量指标

under replicated partitions : 正在复制分区数量

JMX MBean: kafka.server:type=RelicaManager,name=UnderReplicatedPartitions

Prometheus:

kafka_cluster_partition_underreplicated 各个topic patition
kafka_server_replicamanager_underreplicatedpartitions 总

如果说 broker 只有一个可监控的度量指标，那么它一定是指 under replicated partitions

该 topic 下的 partition，其中副本处于失效或者失败的比率。失败或者失效是指副本不处于 ISR 队列中。目前控制副本是否处于 ISR 中由 replica.log.max.ms 这个参数控制。

Kafka具有副本的功能，不同的broker上保存了每个parition的不同副本，具体存在几台broker上，是由配置的副本因子所决定的。尽管有大量副本的存在，但kafka只会在最初把数据写入partition的leader（一个leader多个follower），leader是随机的在ISR（in-sync replicas）池（所有处于同步状态的partition副本）中选举出来的。另外，消费者只会读取partition leader，这样follower副本将作为备份存在，以保证kafka的高可用性，从而防某个broker挂掉。

如果 Under Replicated Partitions 非同步数量一直不变说明存在broker已经下线了，我启动了3个broker，topic demo partition 3 replication-factor 3, 主动下线 broker-id: 2

./kafka-topics.sh --describe --under-replicated-partitions 可以查看具体是哪个broker出现了问题

	Topic: demo	Partition: 0	Leader: 1	Replicas: 1,0,2	Isr: 1,0
	Topic: demo	Partition: 1	Leader: 1	Replicas: 2,1,0	Isr: 1,0
	Topic: demo	Partition: 2	Leader: 0	Replicas: 0,2,1	Isr: 1,0

active controller count : 活跃控制器数量

如果集群没有控制器，集群就无法对主题和分区创建，broker故障作出响应，问题很严重

控制器：负责分区副本leader选举，第一个broker通过向zookeeper创建一个临时节点 /controller 让自己成为控制器，控制器只能有一个。

当broker离开集群后，有些分区副本就会失去leader，控制器会遍历剩下的分区，选举新leader并通知素有分区

当有新broker加入集群后，控制器会检查该broker是否包含现有分区的副本

JMX MBean: kafka.controller:type=KafkaController,name=ActiveControllerCount

Prometheus: kafka_controller_kafkacontroller_activecontrollercount

request handler avg idle percent : 请求处理空闲率

Kafka 使用了两个线程池来处理客户端的请求:网络处理器线程池和请求处理器线程池。

网络处理器线程池负责通过网络读入和写出数据

network-processor-idle

JMX MBean: kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

Prometheus: kafka_network_processor_idlepercent

请求处理器线程池负责处理来自客户端的请求，包括从磁盘读取消息和往磁盘写入消息

JMX MBean: kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

Prometheus: kafka_server_kafkarequesthandlerpool_requesthandleravgidlepercent_count

数值越低，说明broker的负载越高。如果空闲百分比低于20%，说明存在潜在的问题，如果低于10%，说明出现了性能问题

请求度量指标

百分位：0.50、0.75、0.95、0.98、0.99、0.99

kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower} broker处理请求耗费的所有时间，从收到请求开始计算，直到将响应返回给请求者
kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request={Produce|FetchConsumer|FetchFollower} 请求停留在队列中的时间，从收到请求开始计算，直到开始处理请求
kafka.network:type=RequestMetrics,name=LocalTimeMs,request={Produce|FetchConsumer|FetchFollower} leader处理请求花费的时间
kafka.network:type=RequestMetrics,name=ResponseQueueTimeMs,request={Produce|FetchConsumer|FetchFollower} 请求在响应队列中等待的时间，响应在发送给请求者之前停留在队列的时间
kafka.network:type=RequestMetrics,name=RemoteTimeMs,request={Produce|FetchConsumer|FetchFollower} 等待follower花费的时间，请求处理完毕之前，用于等待跟随者的时间
kafka.network:type=RequestMetrics,name=ResponseSendTimeMs,request={Produce|FetchConsumer|FetchFollower} 实际发送响应的时间

topic 度量指标

bytes in : 主题流入字节

broker接收的生成者客户端消息流量字节数据

JMX MBean：kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec

Prometheus：kafka_server_brokertopicmetrics_bytesin_total

OneMinuteRate: 前1分钟的平均值 irate(kafka_server_brokertopicmetrics_bytesin_total[1m])

FiveMinuteRate: 前5分钟的平均值 irate(kafka_server_brokertopicmetrics_bytesin_total[5m])

FifeenMinuteRate: 前15分钟的平均值 irate(kafka_server_brokertopicmetrics_bytesin_total[15m])

bytes out : 主题流出字节

流出字节速率显示的是消费者从 broker 读取消息的速率

JMX MBean: kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

Prometheus: kafka_server_brokertopicmetrics_bytesout_total

messages in 主题流入的消息

消息速率：每秒生成消息的个数

JMX MBean: kafka.server:type=BrokerTopicMetrics,name=MessageInPerSec

Prometheus: kafka_server_brokertopicmetrics_messagesin_total

为什么没有消息的流出速率?

brocker是将整个消息批次发送消费者，并没有展开批次，也就不会计算消费消息的数量

Partition 分区指标

partition count 分区数量

分配给broker的分区总数，包括broker的每一个分区副本，不管是首领还是副本

JMX MBean: kafka.server:type=ReplicaManager,name=PartitionCount

Prometheus: kafka_server_replicamanager_partitioncount

Number of Leaders per Broker 首领数量

broker 首领分区数量

JMX MBean: kafka.server:type=ReplicaManager,name=LeaderCount

Prometheus: kafka_server_replicamanager_leadercount

Offline Partitions 离线分区

该度量只能由集群控制器提供，显示了集群里没有首领的分区数量，发生这种情况主要有2个原因：

包含分区副本的所有broker都关闭
由于消息数量不匹配，没有同步副本能够拿到首领身份 (unclean.leader.enable = false)

JMX MBean: kafka.controller:type=kafkaController,name=offlinePartitionsCount

Prometheus: kafka_controller_kafkacontroller_offlinepartitionscount

离线分区会影响生产者客户端，导致消息丢失，问题很严重

json 配置