原创
Kafka,作为分布式高吞吐发布订阅的消息系统,广泛应用于消息队列、大数据流计算分析等场景。本文介绍了Kafka系统监控方案,以及站在用户视角阐述如何监控好Kafka实际产品。enjoy:
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
你与Kafka监控进阶,只差一个“视角”的距离
▲图五 搜索某租户部分SLO指标结果
附:
Kafka监控相关脚本
https://github.com/cloud-op/monitor/tree/master/kafka