写点什么

问题盘点|使用 Prometheus 监控 Kafka,我们该关注哪些指标

  • 2023-01-12
    浙江
  • 本文字数:9628 字

    阅读完需:约 32 分钟

作者:阿里云可观测


Kafka 作为当前广泛使用的中间件产品,承担了重要/核心业务数据流转,其稳定运行关乎整个业务系统可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实践。

Kafka 简介

Kafka 是什么?

Kafka 是分布式、高吞吐、可扩展的实时数据流平台。


Kafka 广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等大数据领域,已成为大数据生态中不可或缺的部分。


1·.png


Producer: 通过 push 模式向 Kafka Broker 发送消息。发送的消息可以是网站的页面访问、服务器日志,也可以是 CPU 和内存相关的系统资源信息。


Kafka Broker: 用于存储消息的服务器。Kafka Broker 支持水平扩展。Kafka Broker 节点的数量越多,集群的吞吐率越高。


Group: 通过 pull 模式从 Kafka Broker 订阅并消费消息。


ZooKeeper: 管理集群的配置、选举领导(Leader)分区,并且在 Group 发生变化时,进行负载均衡。

Kafka 特点

优势

1. 通信模式:持列队和发布/订阅两种通信模式。


2. 高吞吐量、低延迟: 在较廉价的硬件上,Kafka 也能做到每秒处理几十万条消息,延迟最低只有几毫秒。


3. 持久性: Kafka 可以将消息持久化到普通磁盘。


4. 可扩展性: Kafka 集群支持热扩展,可以动态向集群添加新节点。


5. 容错性: 允许集群中节点失败(若副本数量为 n,则允许 n-1 个节点失败)。

需要注意的问题

1. Topic/分区数过多,导致性能急速下降: Kafka Topic/分区过多(如,对于普通磁盘,单机超过 500 个 topic/分区),会导致存储碎片化,load 会发生明显的飙高现象,topic/分区越多,load 越高,发送消息响应时间越长。


2. 消息丢失: 以下 2 种使用不当的场景,可能导致消息丢失,应根据业务场景避免。


  • 生产消息:如果 acks!=all 或者消息副本数不大于 1,则在 Kafka Broker 机器异常宕机时,可能导致消息丢失。

  • 消费消息:消费端在未完全处理完消息时即提交 offset,则在消费端异常时,可能导致部分消息丢失。


3. 重复消费: 生产者可能由于某种原因(如网络抖动或 Kafka broker 宕机)没有收到 Kafka broker 的成功确认,然后重复发送消息,最终导致消费者收到多个相同的业务消息。此场景需要消费者支持的消息幂等性来解决。


4. 消息乱序: Kafka 只能保证同一分区内的消息有序性,不同分区之间消息不能保证有序性。


5. 不支持事务

Kafka 典型适用场景

1. 大数据领域: 网站行为分析、日志聚合、应用监控、流式数据处理、在线和离线数据分析等领域。


2. 数据集成: 将消息导入 MaxCompute、OSS、RDS、Hadoop、HBase 等离线数据仓库。


3. 流计算集成: 与 StreamCompute、E-MapReduce、Spark、Storm 等流计算引擎集成。

Kafka 核心概念

2.png


Broker: 一个 Kafka 服务端节点。


集群(Cluster): 由多个 Broker 组成的集合。


消息(Message): 也叫 Record,Kafka 中信息传递的载体。消息可以是网站的页面访问、服务器的日志,也可以是和 CPU、内存相关的系统资源信息,但对于消息队列 Kafka 版,消息就是一个字节数组。


Producer: 向 Kafka 发送消息的应用。


Consumer: 从 Kafka 接收消息的应用。


消费者组(Consumer Group): 一组具有相同 Group ID 的 Consumer。当一个 Topic 被同一个 Group 的多个 Consumer 消费时,每一条消息都只会被投递到一个 Consumer,实现消费的负载均衡。通过 Group,您可以确保一个 Topic 的消息被并行消费,提高 Kafka 的吞吐量。


主题(Topic): 消息的主题,用于分类消息。在每个 Broker 上都可以创建多个 Topic。


副本(Replica): 每一个分区都有多个副本。当主分区(Leader)故障的时候会选择一个备分区(Follower)上位,成为 Leader。在 Kafka 中默认副本的最大数量是 10 个,且副本的数量不能大于 Broker 的数量,Follower 和 Leader 是在不同的机器,同一机器对同一个分区也只可能存放一个副本。


分区(Partition): 一个有序不变的消息序列,用于存储消息。一个 Topic 由一个或多个分区组成,每个分区中的消息存储于一个或多个 Broker 上。在一个分区中消息的顺序就是 Producer 发送消息的顺序。


位点(Offset): 分区中每条消息的位置信息,是一个单调递增且不变的值。


消费位点: 分区被当前 Consumer 消费了的消息的最大位点。


堆积量: 当前分区下的消息堆积总量,即最大位点减去消费位点的值。堆积量是一个关键指标,如果发现堆积量较大,则 Consumer 可能产生了阻塞,或者消费速度跟不上生产速度。此时需要分析 Consumer 的运行状况,尽力提升消费速度。可以清除所有堆积消息,从最大位点开始消费,或按时间点进行位点重置。


重平衡(Rebalance): 消费者组内某个消费者实例挂掉后,其他消费者实例自动重新分配订阅主题分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。


Zookeeper: Kafka 集群依赖 Zookeeper 来保存集群的的元信息,以保证系统的可用性。

主要 Kafka 版本介绍

  • 0.x:早期孵化版本。

  • 1.x:优化 Streams API、增强可观测性和可调试性、支持 Java9、优化 SASL 认证等、优化 Controller 管理等。

  • 2.x:性能显著提升、增强 ACL 支持、支持 OAuth2 bearer、支持动态更新 SSL、增强可观察能力、支持 Java 11(不再支持 Java 7)、支持增量协作再平衡等。

  • 3.x:去掉 zookeeper 依赖、支持 Java 17(不再支持 Java8 和 Scala 12)、不再支持 v0 和 v1 消息、性能大幅提升等。


推荐使用 2.x 和 3.x 版本。

Kafka Metric 监控参考模型

结合 Kafka 的体系架构和使用场景,我们从 Metrics 采集、监控大盘、告警指标等 3 方面定义了 Kafka Metric 监控的参考模型。


  • Metrics 采集


即我们需要采集哪些 Kafka 相关的 Metric,以便能完成业务监控。下面分别从 Producer、Broker 和 Consumer 三个方面进行讨论。


1. Producer 指标


生产者是将消息推送到 Broker Topic 的应用。如果生产者失败,消费者将得不到新的信息。我们建议关注如下 Producer 的主要指标。


3.png


2. Broker 指标


因为所有消息都必须通过 Kafka Broker 才能被使用,所以对集群中 Broker 的监控是最核心的。我们建议关注如下主要指标:


4.png


5.png


6.png


3. Consumer 指标


Consumer 是 Kafka 消息终点。我们建议关注如下主要指标:


7.png


4. Zookeeper 指标


ZooKeeper 是 Kafka 的一个关键组件(v3.x 之前),ZooKeep 停机将使 Kafka 停止运行。


8.png


  • Kafka 监控大盘


建议默认监控大盘至少包含以下指标 panel:


1. Producer


  • topic 消息生产量随时间的变化:便于我们快速确定流量来源,并为基础设施的变更配置提供依据。

  • 请求/响应速率随时间的变化:密切关注峰值和下降对于确保连续服务可用性至关重要。

  • 请求平均延迟随时间的变化:由于延迟与吞吐量有很强的相关性,观察此变化,有助于我们判断是否需要修改 batch.size 参数。

  • IO 等待随时间的变化:如果我们发现等待时间过长,就意味着生产者无法足够快地获取所需的数据。


2. Broker


  • 存在失效副本的分区数量的变化:如果此指标突增,则很可能某个 Broker 发生了异常。

  • ISR 数量变化:除 Broker 或 Partition 数量变化会触发 ISR 数量变化外,其它情况下的当前指标变化都需要我们注意。

  • 有效 Broker 数量变化。

  • 有效 Controller 数量变化。

  • 离线分区数的变化:此指标大于 0,则意味着这些数量的分区不可用,该分区的消费者和生产者都将被阻塞。

  • Leader 选举速率和耗时的变化:发生选举,则意味着某个 Leader 的丢失;耗时过长,则会导致此期间消息无法接收生产者消息和消费者的请求。

  • 请求耗时:通常该值应相当稳定,波动很小。

  • 网络流量:提供潜在瓶颈所在位置的信息,为我们判断是否启用消息的端到端压缩提供依据。

  • 生产/拉取 purgatory 消息数量:通过观察 purgatory 中消息数量,有助于我们确定消息生产或拉取耗时长的原因。


3. Broker JVM


Full GC 频率和耗时:GC 频率高或耗时长,都对 Broker 性能有重大影响。据此,我们可以判断是否需要对内存进行扩容。


4. Consumer


  • group 消费延迟数量的变化:该指标越大,则消息堆积越多。

  • 消费流量的变化:显示消费消息的网络流量/消息流量大小变化。

  • 拉取数据速率的变化:消费者是否健康的重要指标。


5. Zookeeper


  • 待处理的请求数的变化。

  • 平均请求响应耗时的变化:如果耗时突增,则可能导致整个 Kafka 集群的协调机制受阻。

  • 客户端连接数的变化:连接数的突变,通常伴随着 Broker 的加入、退出或丢失。

  • 打开的文件句柄数和剩余数的变化:如果剩余数不足,则可能导致 Broker 无法连接到 Zookeeper。

  • 同步请求 pending 数量的变化。

  • Kafka 告警规则


我们建议配置如下告警规则:


1. Producer


  • 发送失败消息数:当前发送失败的消息达到一定数量时告警。

  • 发送重试消息数:当单位时间内发送重试的消息数量达到阀值时告警。

  • 发送耗时长:发送耗时大于 x 毫秒。


2. Broker


  • Controller 正常:有效 Controller 数量不为 1。

  • 无离线分区:离线分区数大于 0。

  • 无 UnClean Leader 选举:Unclean Leader 选举速率大于 0。

  • Broker 不可用:有效 Broker 数量减少。

  • ISR 收缩:Topic 分区的 ISR 数量小于 n。

  • 分区不可用:Topic 分区处于 Under Replicated 状态。

  • Topic/分区容量:Topic/分区数量大于 n。

  • 实例消息流入/出量:当前实例的流量超过或低于某个阀值时告警。

  • Topic 消息流入/出量:当前某个 Topic 的流量超过或低于指定阀值时告警。

  • 磁盘容量:磁盘使用率大于 x%(参考值:85%)。

  • CPU 使用率:大于 80%。


3. Broker JVM:


FullGC 频率:对频繁的 FGC 告警。


4. Consumer


消息堆积:group 消费延迟数量大于 n(根据业务流量,适当配置 n 的大小)。


5. Zookeeper


同步请求 pending 数量大于 n。

Kafka 典型问题场景及其排查/解决方法

  • Topic 消息发送慢,并发性能低


1. 场景描述


某个或某几个 Topic 的消息并发发送性能低。在指标上直接体现为 Producer 的平均请求延迟大、平均生产吞吐量小。


2. 问题原因


通常消息发送慢有如下几种典型原因:


  • 网络带宽不足,导致 IO 等待。

  • 消息未压缩,导致网络流量超负荷。

  • 消息未批量发送,或批量阀值配置不恰当,导致发送速率慢。

  • Topic 分区数量不足,导致 Broker 接收消息积压。

  • Broker 磁盘性能低,导致磁盘同步慢。

  • Broker 分区数总量过多,导致碎片化,磁盘读写过载。


3. 排查/解决办法


  • 根据上述原因,我们逐一查看对应的监控指标/大盘,定位并解决问题:

  • 确认 Producer 的“平均 I/O 等待时间”指标是否符合预期或有陡增?以便确认 Producer 到 Broker 之间的网络带宽是否满足业务流量要求?如果不满足,则需要硬件资源扩容。

  • 确认 Producer 的“平均压缩率指标”,确保压缩率符合预期?如果压缩过低,则需要 Producer 端进行排查、修正。

  • 确认 Producer 的“平均请求包大小”是否过小?如果是的话,则需要考虑加大 Producer 发送消息的 batchsize,同时调整 linger.ms 的阀值,以避免请求消息碎片化。

  • 查看 Topic 分区数,分区数较小时,考虑增加分区数,以水平扩展 Broker 的并发接收消息容量。

  • 确认 Broker 磁盘 IO 使用率是否在安全范围内?如果使用率已经较高,则考虑水平扩容 Broker 数量以分担磁盘压力,或升级磁盘为 SSD 以提升 IO 性能。

  • 确认 Broker 的 CPU 使用率是否在安全范围内?如果使用率已经较高,则考虑垂直或水平扩容 Broker,同时考虑增加 Topic 分区数,以提升 Topic 并发接收消息能力。

  • 查看集群的总分区数和单个 Broker 的分区数量,确保在规划的容量范围内。否则应考虑水平扩容 Broker 数量,以避免碎片化磁盘读写导致的性能下降。

  • Topic 消息堆积


1. 场景描述


某个或某几个 Topic 的消息堆积持续增加。在指标上直接体现为 group 消费延迟数量持续增加。


2. 问题原因


通常消息堆积有如下几种典型原因:


  • Producer 生产消息流量增大。

  • Consumer 由于业务变化导致消费延迟增加。

  • Consumer 数量不足。

  • Consumer 数量频繁变化,导致 Group 不断做再平衡(Rebalance)。

  • Broker 未收到 Consumer 消费确认消息。


3. 排查/解决方法


根据上述可能的原因,我们逐一查看对应的监控指标/大盘,定位并解决问题:


  • 确认 Producer 的“消息生产量”指标是否有明显增加?如果有显示增加,则我们需要对应增加消费者数量。

  • 确认 Consumer 的“消息消费流量”指标是否明显下降?如果有显示下降,则说明消费者的业务处理耗时增加,我们需要确认业务消耗,或增加消费者数量。

  • 通过 Kafka Broker 提供的命令,确认 Topic 对应的 Consumer 数量与实际的 Consumer 数量是否一致?如果不一致,则说明某些 Consumer 未正确连接到 Broker,需要排查 Consumer 是否正常运行。

  • 观察 Consumer 的数量是否频繁变化而触发反复再平衡(Rebalance),如果是,则我们需要排查确认各个 Consumer 是否正常运行。

  • 由于网络或其它原因,可能导致 Consumer 与 Broker 之间的连接不稳定,Consumer 能持续消费消息,但 Broker 却始终认为消息未确认,导致消费位点不变。此时可能需要确认 Consumer 与 Broker 之间的网络稳定性、甚至重启 Consumer。


4. 自建 Prometheus 监控 Kafka 的痛点


自建 Prometheus 观测 Kafka,我们将面临的典型问题有:


  • 由于安全、组织管理等因素,用户业务通常部署在多个相互隔离的 VPC,需要在多个 VPC 内都重复、独立部署 Prometheus,导致部署和运维成本高。

  • 每套完整的自建观测系统都需要安装并配置 Prometheus、Grafana、AlertManager 等,过程复杂、实施周期长。

  • 开源 Kafka JMX Agent 在某些场景下占用 CPU 高,对自建 Kafka 业务有一定干扰。

  • 对于阿里云消息队列 Kafka 版(简称阿里云 Kafka),自建 Prometheus 无法监控到,导致无法实现一站式、全局视角的监控建设。

  • 对于部署在 ECS 上的自建 Kafka,自建 Prometheus 缺少与阿里云 ECS 无缝集成的服务发现(ServiceDiscovery)机制,无法根据 ECS 标签来灵活定义抓取 targets。如果自行实现类似功能,则需要使用 GOlang 语言开发代码(调用阿里云 ECS POP 接口)、集成进开源 Prometheus 代码、编译打包后部署,实现门槛高、过程复杂、版本升级困难。

  • 开源 Grafana Kafka 大盘不够专业,缺少结合 Kafka 原理/特征和最佳实践进行深入优化。

  • 缺少 Kafka 告警指标模板,需要用户自行研究、配置告警规则,工作量大,且很可能缺少 Kafka 领域的专业技术沉淀。

对比

阿里云 Prometheus 监控是一款全面对接开源 Prometheus 生态,支持类型丰富的组件观测,提供多种开箱即用的预置观测大盘,且提供全面托管的混合云/多云 Prometheus 服务。除了支持阿里云容器服务、自建 Kubernetes、Remote Write 外,阿里云 Prometheus 还提供混合云+多云 ECS 应用的 metric 观测能力;并且支持多实例聚合观测能力,实现 Prometheus 指标的统一查询,统一 Grafana 数据源和统一告警。


阿里云 Prometheus 提供了阿里云 Kafka 和自建 Kafka 的全套支持。


9.png

使用阿里云 Prometheus 监控 Kafka

下面分别介绍如何使用阿里云 Prometheus 监控阿里云 Kafka 和自建 Kafka。


  • 使用阿里云 Prometheus 监控阿里云 Kafka


阿里云 Kafka 针对开源的 Apache Kafka 提供全托管服务,解决开源产品的痛点。用户只需专注于业务开发,无需部署运维。相较于开源 Apache Kafka,消息队列 Kafka 版成本更低、弹性更强、可靠性更高。


阿里云 Kafka 现已默认集成了阿里云 Prometheus 监控。由于阿里云 Kafka 无需用户部署和运维,因此 Prometheus 监控聚焦在“使用 Kafka”场景,主要透出的指标有:


  • 实例/Group/Topic 各级的流量指标

  • Group 和 Topic 的消息堆积指标

  • 实例磁盘使用率指标

  • Group 的 Rebalance 指标

  • 查看阿里云 Kafka 监控大盘


阿里云 Kafka 提供了实例、Group 和 Topic 等三个监控大盘。通过这三个大盘,用户可以快捷、清晰地掌握 Kafka 消息的生产和消费情况,快速定位使用阿里云 Kafka 过程中遇到的问题。


用户可登录阿里云 Kafka 控制台,进入 Kafka 实例详情界面“Prometheus 监控”菜单或 tab 页查看。


https://kafka.console.aliyun.com/


10.png


阿里云 Kafka 实例监控大盘


11.png


阿里云 Kafka 消费组监控大盘


12.png


阿里云 Kafka Topic 监控大盘


  • 使用阿里云 Prometheus 配置阿里云 Kafka 告警


用户可以登录阿里云 Prometheus 控制台,进入“云服务监控”实例的“集成中心”界面,选择“云产品自监控集成”tab,点击“消息队列 Kafka”,弹出窗口中的“告警”tab 页,即可查看和新增阿里云 Kafka 的 Prometheus 告警。创建 Prometheus 告警的详细操作步骤,详见 Prometheus 告警规则文档。


https://help.aliyun.com/document_detail/331981.html


阿里云 Prometheus 提供了 13 条默认告警指标(持续更新中),涵盖了实例、Group 和 Topic 的关键指标,方便用户快速配置常见告警规则。


13.png


14.png


  • 使用阿里云 Prometheus 监控自建 Kafka


除了阿里云 Kafka 外,阿里云 Prometheus 同时提供了自建 Kafka 的监控接入能力。支持容器服务(包含 ACK、ASK、注册集群等)和 ECS 这两个环境类型的 Kafka 监控,提供基础和高级两个版本:


  • 基础版:收集 Broker 数量、Topic 分区、消息组 Lag 等基础指标,Kafka 服务端无端任何配置或重启。

  • 高级版:除基础版能力外,通过 JMX Agent,收集生产者、服务端、消费者及其内部各模块的的重要指标,实现全链路、一体化的专家级 Kafka 监控。但需要进行 JMX Agent 注入和进程重启。


与阿里云 Kafka 的监控场景不同,自建 Kafka 时,用户除了需要关注“使用 Kafka”的例行指标外,还需要进一步关注“运维 Kafka”的内部指标。因此需要深入抓取 Kafka 生产者、服务端、消费者及其内部各模块的重要指标,以便分析和排查 Kafka 本身各环节的可能问题,因此我们推荐使用高级版,以便全面掌握自建 Kafka 的运行状态。


对于 ZooKeeper 和其它基础监控(磁盘、网络等),请参考使用 Prometheus 监控 ZooKeeper 和 Node Exporter 组件接入配置 Prometheus 监控。


https://help.aliyun.com/document_detail/161845.html

https://help.aliyun.com/document_detail/445268.html


  • 使用阿里云 Prometheus 进行自建 Kafka 的基础监控


1. 部署自建 Kafka 的基础监控


登录阿里云 Prometheus 控制台,访问 ARMS 接入中心,点击组件应用“Kafka(基础版)”的“添加”按钮,在弹出界面选择 Kafka 所部署的环境(目前支持“阿里云容器服务环境”和“阿里云 ECS 环境”),选择 Kafka 所在的 Prometheus 实例,然后填写配置信息。


15、.png


16.png


配置连接 Kafka 所需的各项信息:


Exporter 名称:当前 Kafka 监控唯一命名。


Kafka 地址:填写 Kafka Broker 的连接地址。多个 Broker 地址之间使用逗号或分号来分隔。


  • 容器服务内,则可以使用 Kafka Broker 的 IP 或 Service 地址。

  • ECS 环境内,则可以使用 Kafka Broker 的 IP 或 DNS 地址。


metrics 采集间隔(秒): 监控数据采集时间间隔。


Kafka 版本:选择确定 Kafka 服务端的版本号,目前最高支持 3.2.0。


开启 SASL:选择确定 Kafka 服务端是否使用 SASL。


SASL 用户名:如果开启 SASL,则填写对应的用户名。


SASL 密码:如果开启 SASL,则填写对应的用户名密码。


SASL 方法:选择确定 SASL 方法,目前支持 plain、scram-sha512 和 scram-sha256 等三种。


开启 TLS:选择确定 Kafka 服务端是否使用 TLS。


忽略 TLS 安全校验:如果 Kafka 服务端开启 TLS,且是自签名证书,则选择忽略 TLS 安全校验。


2. 查看自建 Kafka 的基础监控大盘


进入 Prometheus 实例的集成中心,点击“Kafka(基础版)”,在弹出界面选择“大盘”tab 页,点击大盘缩略图,即可查看对应 Grafana 大盘。基础版监控大盘主要展示:


  • Kafka Broker 数量。

  • 每个 Topic 的分区数。

  • 每个 Topic 的消息入/出/堆积数量。

  • 每个 Topic 的 ISR(In-Sync Replicas)数量。


17.png


18.png


3. 配置自建 Kafka 的基础监控告警


进入 Prometheus 实例的集成中心,点击“Kafka(基础版)”,在弹出界面选择“告警”tab 页,即可查看/新增当前 Prometheus 实例的 Kafka 基础版告警规则。创建 Prometheus 告警的详细操作步骤,详见 Prometheus 告警规则文档。


https://help.aliyun.com/document_detail/331981.html


19.png


目前 Kafka 基础版监控提供了 4 个告警指标。用户可根据实际情况,实例化告警规则。


  • Consumer Topic 消息堆积。

  • 分区数量过多:为 Kafka Broker 定义保护性告警,避免分区数量过多导致性能急剧下降。

  • 存在 Under Replicated 分区。

  • 有效 Broker 数量减少。

使用阿里云 Prometheus 进行自建 Kafka 的高级监控

  • 部署自建 Kafka 的高级监控


首先需要用户按照部署和配置 JMX Agent 文档,自行在 Kafka Producer、Broker 和 Consumer 端安装和配置 JMX Agent,以便将暴露 Kafka Metric 给阿里云 Prometheus。


然后访问 ARMS 接入中心,点击组件应用“Kafka(高级版)”的“添加”按钮,在弹出界面选择 Kafka 所部署的环境(目前支持“阿里云容器服务环境”和“阿里云 ECS 环境”),选择 Kafka 所在的 Prometheus 实例,然后填写监控接入的配置信息。


  • Exporter 名称:当前 Kafka 监控唯一命名。

  • kafka 实例名称:Kafka 实例名称,通过该名称,将 Kafka Producer、Broker 和 Consumer 进行关联,实现 Topic 全链路的大盘展示。

  • JMX Agent 监听端口:部署 JMX Agent 时配置的监听端口。

  • metrics 采集路径:Prometheus 采集 JMX Agent 的 http path,默认是 /metrics。

  • metrics 采集间隔(秒):监控数据采集时间间隔。

  • Pod/ECS 标签/值:部署 JMX Agent 时,给 Pod/ECS 配置的标签和标签值,Prometheus 通过此标签进行服务发现(Service Discovery)。


20.png


21.png


  • 查看高级监控大盘


进入 Prometheus 实例的集成中心,点击“Kafka(高级版)”,在弹出界面选择“大盘”tab 页,点击大盘缩略图,即可查看对应 Grafana 大盘。高级版监控提供了 Intance 和 Topic 两个视角的大盘。


22.png


  • 自建 Kafka Instance 大盘


展示 Kafka Broker 内部各项指标:


  • 核心指标:展示 Broker 数量、OffLine 分区数、Under Replicated 分区数、Contrller 数量、CPU/网络等关键信息。

  • JVM 指标:展示 JVM 的内存和 GC 关键信息。

  • 分区指标:展示分区数量、ISR、Unclean Leader 选举、Replica Lag、Offline 分区、Under Replicated 分区等明细信息。

  • 时间指标:展示 Produce、Request、Fetch 等各个环境的时间指标。

  • 集群流量指标:展示集群的总体流量指标。

  • Broker 流量指标:展示 Broker 粒度的流量明细指标。


23.png


  • 自建 Kafka Topic 大盘


展示各个 Kafka Topic 全链路指标:


  • Producer:展示 Producer 端的关键指标,包括消息发送速度、消息压缩率、发送延迟等。

  • Server(即 Kafka Broker):展示该 Topic 对应的分区数、入/出消息速率、入/出消息流量。

  • Consumer:展示消息消费速率、消费延迟和 Rebalance 等。


24.png


  • 配置自建 Kafka 的高级监控告警


进入 Prometheus 实例的集成中心,点击“Kafka(高级版)”,在弹出界面选择“告警”tab 页,即可查看/新增当前 Prometheus 实例的 Kafka 高级版告警规则。Kafka 高级版提供 Producer、Instance 和 Consumer 三方面的告警指标,供用户选择和配置。创建 Prometheus 告警的详细操作步骤,详见 Prometheus 告警规则文档。


25.png


  • 自建 Kafka Producer:提供了消息发送失败率、消息发送耗时、消息发送重试率等 3 个告警指标,方便用户对 Producer 端的异常进行告警。

  • 自建 Kafka Instance:提供了分区数量过多、存在 OffLine 分区、存在 UnClean Leader 选举、存在 Under Replicated 分区、有效 Broker 数量减少、有效 Controller 数量、实例消息拒绝量、实例消息流入/出量、Topic 消息流入/出量等 13 个告警指标,覆盖了 Kafka Broker 各方面异常。

  • 自建 Kafka Consumer:提供了消息消费堆积告警指标,通过该告警规则,用户能第一时间掌握消费异常情况。

结束语

阿里云 Prometheus 的 Kafka 监控,以阿里云消息队列 Kafka 丰厚运维实践为基础,结合 Kafka 社区运维建议,提供了阿里云 Kafka 和自建 Kafka 监控的一体化解决方案。


针对自建 Kafka 的场景特点,提供了基础版和高级版监控接入,满足用户不同场景、不同深度的 Kafka 监控需求。同时支持容器服务环境和 ECS 环境的 Kafka 部署,满足用户不同环境的监控需求。Kafka 高级版提供 200+个有效 metric、10+个关键大盘 panel、60+个辅助大盘 Panel、17 个告警指标(持续更新中),为用户提供全链路、一体化的专家级 Kafka 监控支撑,保障业务稳定运行。


后续我们将持续优化自建 Kafka 高级版的部署便利性,以进一步简化用户部署 JMX Agent 的操作。同时还将深度优化 JMX Agent 的性能,减少对自建 Kafka Broker 的 CPU 消耗。


点击此处,免费开通 Prometheus 监控!

发布于: 刚刚阅读数: 3
用户头像

云原生技术是云时代释放云价值的最短路径。 2020-06-11 加入

还未添加个人简介

评论

发布
暂无评论
问题盘点|使用 Prometheus 监控 Kafka,我们该关注哪些指标_kafka_阿里巴巴中间件_InfoQ写作社区