小数据运维之Kafka监控_vlambda技术博客

vlambda
2021-08-28

小数据运维之Kafka监控

在前文中留了个小尾巴，Kafka的监控，这里从Kafka监控的指标获取，监控工具选择，重要监控指标来看看这个问题。

Kafka 监控指标的获取

Kafka自身提供了大量监控指标，市面上的监控工具也是获取了这些监控指标然后再进行集成和展示的。Kafka的监控指标是JMX来获取，在使用JMX之前需要确保Kafka开启了JMX的功能（在Apache版本中是默认关闭的，默认关闭）。Kafka在启动时需要通过配置JMX_PORT来设置JMX的端口号并以此来开启JMX的功能。

下面以Apache Kafka 2.5为例来看看如何开启：

JMX_PORT=9988 ./bin/kafka-server-start.sh -daemon ./config/server.properties

可以看到只需要在启动命令前添加JMX_PORT=<Port> 即可，我们再深入了解下会发现kafka-server-start.sh实际上是去调用kafka-run-class.sh

exec $base_dir/kafka-run-class.sh $EXTRA_ARGS kafka.Kafka "$@"

在kafka-run-class.sh 有这样段代码会激活JMX的配置

# JMX settingsif [ -z "$KAFKA_JMX_OPTS" ]; then KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false "fi
# JMX port to useif [ $JMX_PORT ]; then KAFKA_JMX_OPTS="$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT "fi

配置好JMX_PORT之后，还需要重启Kafka Server，然后就可以获取到相应的监控的数据了。

Kafka 监控工具的选择

Kafka的监控工具比较热门的有如下几个：

Kafka-Manager: 现在使用比较多的可能是它了，是Yahoo开源的，集Kafka 监控和运维为一体，缺点可能是现在更新和维护比较少了，对高版本的Kafka不够友好。
Kafka-Egale: 这也是一个比较热门的开源项目，更偏向于监控方面，运维方面稍弱。
Logi-KafkaManager: 滴滴最近开源的Kafka监控和运维管理工具，和前二个产品不同，它更偏向于Kafka的管理和运维，并将一些滴滴对于大集群Kafka管理的想法(Region, 逻辑集群)融入到了产品中，我个人还处于谨慎试用阶段，后面有了实战经验以后再点评一下

这3个监控工具的部署都不麻烦，我们在先使用了Yahoo的Kafka-Manager，现在正在试用Logi-KafkaManager。每个公司都有自己的独特需求，开源的工具有时候很难满足，尤其是一般大家都一般已经有了一套自己的监控报警系统，如何将Kafka的监控和报警融入现有的体系是另外一个问题，后面我也会分享下自己的经验。

Kafka Broker监控指标

Kafka 的监控指标非常多，从运维的角度来看，我们最需要关注的Kafka Broker集群的健康状况。这里从这二篇文章整理了些这块的重点，其中尤其推荐confluent的这篇文档。

https://www.datadoghq.com/blog/monitoring-kafka-performance-metrics/

https://docs.confluent.io/platform/current/kafka/monitoring.html

Broker可靠性指标（健康）

UnderReplicatedPartitions：正在复制分区数量，这个是Kafka Broker监控最核心的指标，也是需要告警的指标，如果这个数值大于0，代表Broker上有失效的副本，也就是说| ISR | < | current replicas |
OfflinePartitionsCount (只有controller有): 这个指标报告了没有活跃leader的partition数，由于所有的读写操作都只在partition leader上进行，因此非0的这个值需要被告警出来。
ActiveControllerCount：每个集群有且仅能有一个Controller，当这个指标不为1时也需要进行告警。

这几个Broker的核心指标，也是最值得设置报警的几个指标，可以看到，核心指标还是和Partition相关，我们需要认真理解Kafka Partition的概念。

还有些Broker专有的指标也值得在监控大屏上看看：

LeaderCount: Number of leaders on this broker. This should be mostly even across all brokers. 这个如果每个Broker上的个数不相同，需要进行再平衡。
PartitionCount：Number of partitions on this broker. This should be mostly even across all brokers.
RequestHandlerAvgIdlePercent：Average fraction of time the request handler threads are idle. Values are between 0 and 1. 数值越低，说明broker的负载越高。如果空闲百分比低于20%，说明存在潜在的问题，如果低于10%，说明出现了性能问题

以下这几个指标是Broker和Topic层面都有的指标，只是获取Topic metric时需要指定topic

BytesInPerSec/BytesOutPerSec: 每秒流入和流出的流量，这二个是在Brokert/Topic端最直观的衡量当前Broker/Topic的吞吐量的指标，当前集群的吞吐量就是每个Broker指标的和。
MessagesInPerSec：这个代表消息流入Broker/Topic的速率，但是并没有MessagesOutPerSec

Kafka broker本身服务器的监控同样也至关重要，Disk，Memory等等也都需要监控起来，这里就不一一列举了。

Kafka Producer/Consumer监控指标

作为大数据运维，Kafka Broker的监控是一定需要做的，也基本可以独立完成的，但Producer和Consumer的监控，就需要靠开发同学的配合了， Kafka Producer 和 Consumer 监控指标值得关注的有：

Request-rate: 每秒请求次数
Response-rate: 每秒响应次数

生产者Topic指标

record-send-rate: topic每秒生产记录数

消费者Topic指标

records-consumed-rate：topic每秒消费记录

消费者监控需要关注的另外一个点是要看消费的速度是否能跟得上生产的速度，否则就会出现积压，这也就是所谓的Lag，需要注意的是该值是针对每个分区层面的：

LAG 值 = 当前最新生产的消息的位移值（即 LOG-END-OFFSET 列值）- 该消费者组当前最新消费消息的位移值（即 CURRENT-OFFSET 值）

那么这里有3个重要指标值得关注：

records-lag：分区当前消费Lag
records-lag-max：消费者在测试窗口时间内曾经达到的最大的 Lag 值，一个正常工作的消费者，它的 Lag 值应该很小，甚至是接近于 0 的，这表示该消费者能够及时地消费生产者生产出来的消息，滞后程度很小。反之，如果一个消费者 Lag 值很大，通常就表明它无法跟上生产者的速度，最终 Lag 会越来越大，从而拖慢下游消息的处理速度。
records-lead-min: 此消费者在测试窗口时间内曾经达到的最小的 Lead 值。Lead 值是指消费者最新消费消息的位移与分区当前第一条消息位移的差值。Lag 越大的话，Lead 就越小，反之也是同理。一旦监测到 Lead 越来越小，甚至是快接近于 0 了，可能预示着消费者端要丢消息了。因为分区要被消费的数据可能要被Kafka 清理了。

小结

监控是一个需要在生产实战中慢慢积累的工作，生产实战中出了问题以后才会慢慢发现哪些指标可以帮助发现问题，哪些指标只能是看看而已。本文还只是处于纸上谈兵的阶段，后面再逐渐完善。