速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

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

  • 2019-08-11
  • 本文字数:2799 字

    阅读完需:约 9 分钟

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

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


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


2019-08-11 08:309863

评论

发布
暂无评论
发现更多内容

Agisoft Metashape Professional (3D建模软件)中文破解版-mac/win

理理

从理论到实践:ByConity在ELT中的实施与效果

Sunny_媛

ByConity

中文版iWall for Mac(最好用的动态桌面壁纸软件)附壁纸资源

Rose

Topaz Sharpen AI for mac破解版 图像清晰度增强软件

Rose

Bitmap 和 布隆过滤器傻傻分不清?你这不应该啊

EquatorCoco

算法

Smooze Pro for Mac 鼠标增强工具专业版 v2.1.20激活版

Rose

Nuke 15.0v2激活版 for mac安装教程 nuke电影特效合成软件

Rose

初学者浅析C++类与对象

快乐非自愿限量之名

c++

数据库系列:主从延时优化

不在线第一只蜗牛

数据库

迪士尼视频怎么下载?DispCam DisneyPlus Video Downloader迪士尼视频下载工具

Rose

项目管理中的安全文化:建立与维护指南

爱吃小舅的鱼

项目管理软件 项目安全管理 安全审核

一个项目的项目进度与安排应该怎么构建

爱吃小舅的鱼

项目进度

uml建模 Astah Pro激活版 附注册机

理理

PlistEdit Pro for Mac:专业级plist编辑器,高效管理你的Mac设置!

理理

Mac FoneLab iOS Unlocker:iOS用户的救星,解决锁屏难题!

Rose

mac音频传输工具 Loopback v2.3.2免激活版 下载安装 支持M1/M2/M3

Rose

区块链NFT开发音乐版权系统的流程

北京木奇移动技术有限公司

数字版权保护 区块链数字版权交易 软件外包公司 NFT技术

NFT开发音乐版权系统的技术框架

北京木奇移动技术有限公司

数字版权保护 软件外包公司 NFT技术

项目管理专家如何磨练自己的管理能力?

爱吃小舅的鱼

风险识别 项目管理软件 项目规划 团队沟通

“管理者应该是‘造钟者’,不应是报时人”

虚实的星空

日常思考

新技术发展背景下的业务连续性保障新思路

agnostic

资金安全 稳定性保障 技术风险 线上演练

如何保障研发项目进度

爱吃小舅的鱼

项目进度

NFT技术开发音乐版权系统的技术原理

北京木奇移动技术有限公司

区块链数字版权交易 软件外包公司 NFT技术

功能强大的 MongoDB 客户端工具 NoSQLBooster for MongoDB for Mac 无限试用版

Rose

NFT开发数字版权系统的注意事项

北京木奇移动技术有限公司

区块链数字藏品 区块链数字版权交易 软件外包公司 NFT技术

易未央-AI 風雲:35. 陰陽交替的節奏

因田木

AI 陰陽五行

Capture One 23 Pro:专业摄影师的首选,卓越品质,轻松呈现!

Rose

你为什么不应该过度关注go语言的逃逸分析

不在线第一只蜗牛

Go 后端 开发语言

高效工作!Magnet pro for mac分屏工具

理理

LED电子显示屏与LED背光显示屏区别

Dylan

技术 场景 LED显示屏 全彩LED显示屏 led显示屏厂家

区块链NFT智能合约的技术难点

北京木奇移动技术有限公司

智能合约开发 软件外包公司 NFT技术

你与Kafka监控进阶,只差一个“视角”的距离_软件工程_京东云应用研发部_InfoQ精选文章