你与 Kafka 监控进阶，只差一个“视角”的距离

Kafka，作为分布式高吞吐发布订阅的消息系统，广泛应用于消息队列、大数据流计算分析等场景。本文介绍了 Kafka 系统监控方案，以及站在用户视角阐述如何监控好 Kafka 实际产品。

Kakfa 监控实践

监控工具选择

实际使用中对比了多种 Kafka 监控工具，最终选择如下几种工具：

Kafka Monitor：这是 LinkedIn 开源的 Kafka 核心功能监控工具，并且提供了可视化界面。它可以模拟数据生产并消费，基本上覆盖了黑盒监控大部分指标，包括集群核心功能、数据读写、读写延迟等。使用者使用成本也相对简单，只需对接告警系统即可。

如果你的产品用到了 Kafka，强烈推荐使用 Kafka Monitor。

Kafka Manager：这是 Yahoo 开源的 Kafka 管理工具，更偏重于对 Kafka 集群指标采集，同时也有一些主题管理功能。

**Jmxtrans+Influxdb：**Jmxtrans 通过 Jmx 端口可以采集 Kafka 多种维度监控数据，预存储在 Influxdb。Jmxtrans 也是非常优秀的工具，通过它采集的数据项很多，因此采集项筛选是一个难题，筛选后的数据不仅可以作为仪表盘展现使用，也可以为后续产品层面的监控做准备。

集群层面的空间使用率相关数据，需要自研工具来完成，附件中提供了参考脚本。

监控指标

确定黑盒监控指标

黑盒监控指标不符合预期说明集群不能正常工作或出现异常，它更多是一种现象。常用的黑盒监控指标有：集群核心功能、数据读写、读写延迟等。

确定白盒监控指标

对比其他存储组件，大部分监控指标是通用的，或者能找到类似的监控指标，白盒监控是黑盒监控的补充，服务于故障定位，从集群容量、流量、延迟、错误四个方面梳理。

部分采集指标

核心功能

• 采集项：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 指标，那么有些租户可能会遗漏，对于这些租户的核心功能也需要监控，此时，我们需要借助已有监控工具预采集的数据，这些数据包含了所有主题的相关数据。这样，当我们需要知道用户的主题时，就能快速搜索到对应主题的流量、延迟等密切指标，及时反馈到租户。

可以为租户搜索到的部分指标：

• 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

附录：

Kafka 监控相关脚本

https://github.com/cloud-op/monitor/tree/master/kafka

文章转载自微信公众号京东云。