Kafka，作为分布式高吞吐发布订阅的消息系统，广泛应用于消息队列、大数据流计算分析等场景。本文介绍了 Kafka 系统监控方案，以及站在用户视角阐述如何监控好 Kafka 实际产品。
Kakfa 监控实践
监控工具选择
实际使用中对比了多种 Kafka 监控工具，最终选择如下几种工具：
Kafka Monitor：这是 LinkedIn 开源的 Kafka 核心功能监控工具，并且提供了可视化界面。它可以模拟数据生产并消费，基本上覆盖了黑盒监控大部分指标，包括集群核心功能、数据读写、读写延迟等。使用者使用成本也相对简单，只需对接告警系统即可。
如果你的产品用到了 Kafka，强烈推荐使用 Kafka Monitor。
▲图一 Kafka Monitor 可视化界面
▲表一 Kafka Monitor 监控指标样例
Kafka Manager：这是 Yahoo 开源的 Kafka 管理工具，更偏重于对 Kafka 集群指标采集，同时也有一些主题管理功能。
▲图二 Kafka Manager 界面
**Jmxtrans+Influxdb：**Jmxtrans 通过 Jmx 端口可以采集 Kafka 多种维度监控数据，预存储在 Influxdb。Jmxtrans 也是非常优秀的工具，通过它采集的数据项很多，因此采集项筛选是一个难题，筛选后的数据不仅可以作为仪表盘展现使用，也可以为后续产品层面的监控做准备。
集群层面的空间使用率相关数据，需要自研工具来完成，附件中提供了参考脚本。
▲图三 Kafka 运维仪表盘部分指标
监控指标
确定黑盒监控指标
黑盒监控指标不符合预期说明集群不能正常工作或出现异常，它更多是一种现象。常用的黑盒监控指标有：集群核心功能、数据读写、读写延迟等。
确定白盒监控指标
对比其他存储组件，大部分监控指标是通用的，或者能找到类似的监控指标，白盒监控是黑盒监控的补充，服务于故障定位，从集群容量、流量、延迟、错误四个方面梳理。
▲表二 梳理 Kafka 监控指标分类
部分采集指标
核心功能
采集项：produce-availability-avg
说明：单独创建监控主题，对其进行功能监控，覆盖消息生成、写入、消费整个生命周期
数据来源：Kafka Monitor
主题操作
采集项：topic-function
说明：覆盖主题的整个生命周期（创建出的主题要清理，否则主题过多，在实例恢复时会很慢）
数据来源：自研
延迟
采集项：records-delay-ms-avg
说明：生产、消费延迟时间
来源：Kafka Monitor
采集项：records-delay-ms-max
说明：最大延迟时间
来源：Kafka Monitor
流量
采集项：kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=*
说明：某一主题每秒写入
来源：Jmxtrans
采集项：kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topic=*
说明：某一主题每秒读出
数据来源：Jmxtrans
采集项：kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec,topic=*
说明：某一主题每秒写入消息数
数据来源：Jmxtrans
采集项：kafka.network:type=RequestMetrics,name=RequestsPerSec,request=Produce
说明：每秒 Produce 的请求次数
数据来源：Jmxtrans
容量
采集项：kafka.log:type=Log,name=Size,topic=,partition=
说明：分区大小
数据来源：Jmxtrans
采集项：topicSizeALL
说明：某一主题大小（需要基于各 Broker 数据进行计算）
数据来源：自研
错误
采集项：kafka.controller:name=OfflinePartitionsCount,type=KafkaController
说明：没有 Leader 的分区数
数据来源：Jmxtrans
采集项：kafka.controller:name=ActiveControllerCount,type=KafkaController
说明：是否为活跃控制器（整个集群只能有 1 个实例为 1）
数据来源：Jmxtrans
采集项：kafka.server:type=ReplicaFetcherManager,name=MaxLag,clientId=Replica
说明：副本落后主分片的最大消息数量
数据来源：Jmxtrans
采集项：kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
说明：正在做同步的分区数量
数据来源：Jmxtrans
采集项：kafka.server:type=ReplicaManager,name=LeaderCount
说明：Leader 的 Replica 的数量
数据来源：Jmxtrans
采集项：kafka.server:clientId=,name=ConsumerLag,partition=,topic=*,type=FetcherLagMetrics
说明：消费延迟量（Lag）
数据来源：Jmxtrans
采集项：kafka.log:type=Log,name=LogEndOffset,topic=,partition=
说明：每个分区最后的 Offset
数据来源：Jmxtrans
Kafka 监控经验
通过 Jmxtrans 获取到采集项之后，如果期望获取到全局数据，则必须对所有 Broker 上的数据进行汇总计算，附件中提供了部分 Jmxtrans 采集项计算脚本。
在分区大小告警阈值设置上，主题的某个分区不要过大（我们场景，最大为 800G），否则，在迁移分区时会很慢。
Kafka 在不同数据目录分配分区时，会按照分区数来均衡。因此，实际部署中，不同实例最好做到：数据目录大小、数据目录数一致。否则，在集群达到上千个主题后，你的分区迁移工作量会很大。
预采集数据。监控并不能一蹴而就，随着产品或集群变化，需要迭代。因此，需要预采集那些当前看似没有价值的数据，当需要时，所存即所用。另外，从历史故障中进行总结，也可以发掘一些待采集的监控数据。
针对 Kafka，一个可行的监控数据存储、展现工具集：Jmxtrans+Influxdb+Grafana。Grafana 既可以充当巡检仪表盘，也可充当监控数据查看工具。
在 Kafka 采集项获取或分析数据时，Jmxcmd 也是不错的小工具。
Kafka 实际产品监控
数据总线、Kafka 消息队列等公有云产品，一般是基于 Kafka 来实现。按照上述监控方法完善 Kafka 集群监控，可以做到大部分 Kafka 问题都能及时发现。但对用户来说，产品本身的监控才更为重要。
产品 SLO 指标
按照 Google SRE 提出的 SLO（Service Level Objectives 服务等级目标）和“错误预算”理论与实践，需要从用户视角对 Kafka 相关产品进行分析并监控。
以“数据总线”产品为例，这些产品一般提供给用户的核心功能主要有：
数据接入
数据归档
在我们实际产品中，总结了历史故障，确立了当前产品的 SLO 指标，并对其进行监控。部分 SLO 指标：
流数据总线生命周期健康>99.9%
重点用户主题健康>99.9%
归档延迟数据<20 分钟
▲图四 数据总线 SLO 及错误预算部分指标预览
满足多租户
如果只关注整体 SLO 指标，那么有些租户可能会遗漏，对于这些租户的核心功能也需要监控，此时，我们需要借助已有监控工具预采集的数据，这些数据包含了所有主题的相关数据。这样，当我们需要知道用户的主题时，就能快速搜索到对应主题的流量、延迟等密切指标，及时反馈到租户。
可以为租户搜索到的部分指标：
kafka.cluster:name=UnderReplicated,partition=*,type=Partition
kafka.log:name=LogEndOffset,partition=*,type=Log
kafka.log:name=LogStartOffset,partition=*,type=Log
kafka.log:name=Size,partition=*,type=Log
kafka.server:name=BytesInPerSec,type=BrokerTopicMetrics
kafka.server:name=BytesOutPerSec,type=BrokerTopicMetrics
kafka.server:name=MessagesInPerSec,topic=*,type=BrokerTopicMetrics
▲图五 搜索某租户部分 SLO 指标结果
附录：
Kafka 监控相关脚本
https://github.com/cloud-op/monitor/tree/master/kafka
文章转载自微信公众号京东云。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论