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

作者:阿里云可观测

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

Kafka 简介

Kafka 是什么?

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

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

 title=

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 核心概念

 title=

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 的主要指标。

 title=

2. Broker 指标

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

 title=

 title=

 title=

3. Consumer 指标

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

 title=

4. Zookeeper 指标

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

 title=

  • 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 的全套支持。

 title=

使用阿里云 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....

 title=

阿里云 Kafka 实例监控大盘

 title=

阿里云 Kafka 消费组监控大盘

 title=

阿里云 Kafka Topic 监控大盘

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

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

https://help.aliyun.com/docum...

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

 title=

 title=

  • 使用阿里云 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/docum...

https://help.aliyun.com/docum...

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

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

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

 title=

 title=

配置连接 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)数量。

 title=

 title=

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

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

https://help.aliyun.com/docum...

 title=

目前 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)。

 title=

 title=

  • 查看高级监控大盘

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

 title=

  • 自建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粒度的流量明细指标。

 title=

  • 自建 Kafka Topic 大盘

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

  • Producer:展示Producer端的关键指标,包括消息发送速度、消息压缩率、发送延迟等。
  • Server(即Kafka Broker):展示该Topic对应的分区数、入/出消息速率、入/出消息流量。
  • Consumer:展示消息消费速率、消费延迟和Rebalance等。

 title=

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

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

 title=

  • 自建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 监控!

15 声望
6 粉丝
0 条评论
推荐阅读
阿里云消息队列 Kafka 生态集成的实践与探索
Apache Kafka是一个分布式流平台,作为互联网领域不可或缺的消息组件,在全球获得了广泛的应用。在使用过程中,Kafka一般被作为消息流转的核心枢纽,上下游系统通过Kafka实现异步,削峰填谷。在大数据处理和实时...

阿里巴巴中间件阅读 264

vue项目部署到阿里云服务器(windows - Nginx代理)
项目构成:前端:vue+vant-ui,数据库:mysql,后端:node.js部署方式:nginx代理一,首先要拥有自己的服务器,阿里,腾讯都可以,我用的是阿里的购买方式省略...购买完成后,会跳到实例界面,也就是你的服务器实...

墨城2阅读 768

Serverless部署应用并使用Cloudflare加速和支持HTTPS
Serverless 是一种云计算模型,它使开发人员能够构建和运行应用程序,而无需关心底层的服务器基础设施。在传统的应用程序开发中,开发人员需要管理服务器的配置、扩展和维护等任务。而在 Serverless 模型中,这些...

MartinDai2阅读 781

Prometheus的使用
在Prometheus的架构设计中,Prometheus Server 并不直接服务监控特定的目标,其主要任务负责数据的收集,存储并且对外提供数据查询支持。因此为了能够能够监控到某些东西,如主机的CPU使用率,我们需要使用到Expo...

代码的路2阅读 537

阿里云-使用CNFS作为网络存储并共享NAS
之前写过K8S使用阿里云存储卷,并在helm安装redis、rabbitmq和elasticsearch的过程中使用alicloud-nas-fs,但是事后发现,每次安装都会重复生成NAS,但是NAS每个账号最多添加20个,所以这不符合需求,通过跟阿里工...

Awbeci阅读 2.2k

阿里云蒋林泉:aliyun.com全面升级、飞天免费试用计划发布、全栈Serverless化
2013 年,飞天操作系统全球范围内首次突破单一集群 5000 台服务器规模(飞天 5K),并率先对外提供这一能力。此后十年,飞天操作系统多次成功支撑阿里双 11 和 12306 春运购票等极限并发场景。飞天为阿里云打造了...

阿里云开发者阅读 2.2k

Kruise Rollout v0.3.0:教你玩转 Deployment 分批发布和流量灰度
Kruise Rollout 是 OpenKruise 社区开源提出的一个渐进式交付框架。其设计理念是提供一组能够将流量发布与实例灰度相结合,支持金丝雀、蓝绿、A/B Testing等多样化发布形式,以及支持基于 Prometheus Metrics 等...

阿里云云原生2阅读 453

15 声望
6 粉丝
宣传栏