关于阿里云:问题盘点｜使用-Prometheus-监控-Kafka我们该关注哪些指标

作者：阿里云可观测

Kafka 作为以后宽泛应用的中间件产品，承当了重要 / 外围业务数据流转，其稳固运行关乎整个业务零碎可用性。本文旨在分享阿里云 Prometheus 在阿里云 Kafka 和自建 Kafka 的监控实际。

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

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

Producer： 通过 push 模式向 Kafka Broker 发送音讯。发送的音讯能够是网站的页面拜访、服务器日志，也能够是 CPU 和内存相干的系统资源信息。

Kafka Broker： 用于存储音讯的服务器。Kafka Broker 反对程度扩大。Kafka Broker 节点的数量越多，集群的吞吐率越高。

Group： 通过 pull 模式从 Kafka Broker 订阅并生产音讯。

ZooKeeper： 治理集群的配置、选举领导（Leader）分区，并且在 Group 发生变化时，进行负载平衡。

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. 不反对事务

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

2. 数据集成： 将音讯导入 MaxCompute、OSS、RDS、Hadoop、HBase 等离线数据仓库。

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

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 来保留集群的的元信息，以保证系统的可用性。

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 的体系架构和应用场景，咱们从 Metrics 采集、监控大盘、告警指标等 3 方面定义了 Kafka Metric 监控的参考模型。

Metrics 采集

即咱们须要采集哪些 Kafka 相干的 Metric，以便能实现业务监控。上面别离从 Producer、Broker 和 Consumer 三个方面进行探讨。

1. Producer 指标

生产者是将音讯推送到 Broker Topic 的利用。如果生产者失败，消费者将得不到新的信息。咱们倡议关注如下 Producer 的次要指标。

2. Broker 指标

因为所有音讯都必须通过 Kafka Broker 能力被应用，所以对集群中 Broker 的监控是最外围的。咱们倡议关注如下次要指标：

3. Consumer 指标

Consumer 是 Kafka 音讯起点。咱们倡议关注如下次要指标：

4. Zookeeper 指标

ZooKeeper 是 Kafka 的一个要害组件（v3.x 之前），ZooKeep 停机将使 Kafka 进行运行。

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。

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 的全套反对。

上面别离介绍如何应用阿里云 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….

阿里云 Kafka 实例监控大盘

阿里云 Kafka 生产组监控大盘

阿里云 Kafka Topic 监控大盘

应用阿里云 Prometheus 配置阿里云 Kafka 告警

用户能够登录阿里云 Prometheus 控制台，进入“云服务监控”实例的“集成核心”界面，抉择“云产品自监控集成”tab，点击“音讯队列 Kafka”，弹出窗口中的“告警”tab 页，即可查看和新增阿里云 Kafka 的 Prometheus 告警。创立 Prometheus 告警的具体操作步骤，详见 Prometheus 告警规定文档。

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

阿里云 Prometheus 提供了 13 条默认告警指标（继续更新中），涵盖了实例、Group 和 Topic 的要害指标，不便用户疾速配置常见告警规定。

应用阿里云 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 实例，而后填写配置信息。

配置连贯 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）数量。

3. 配置自建 Kafka 的根底监控告警

进入 Prometheus 实例的集成核心，点击“Kafka（根底版）”，在弹出界面抉择“告警”tab 页，即可查看 / 新增以后 Prometheus 实例的 Kafka 根底版告警规定。创立 Prometheus 告警的具体操作步骤，详见 Prometheus 告警规定文档。

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

目前 Kafka 根底版监控提供了 4 个告警指标。用户可依据理论状况，实例化告警规定。

Consumer Topic 音讯沉积。
分区数量过多：为 Kafka Broker 定义保护性告警，防止分区数量过多导致性能急剧下降。
存在 Under Replicated 分区。
无效 Broker 数量缩小。

部署自建 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）。

查看高级监控大盘

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

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

自建 Kafka Topic 大盘

展现各个 Kafka Topic 全链路指标：

Producer：展现 Producer 端的要害指标，包含音讯发送速度、音讯压缩率、发送提早等。
Server（即 Kafka Broker）：展现该 Topic 对应的分区数、入 / 出音讯速率、入 / 出音讯流量。
Consumer：展现音讯生产速率、生产提早和 Rebalance 等。

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

进入 Prometheus 实例的集成核心，点击“Kafka（高级版）”，在弹出界面抉择“告警”tab 页，即可查看 / 新增以后 Prometheus 实例的 Kafka 高级版告警规定。Kafka 高级版提供 Producer、Instance 和 Consumer 三方面的告警指标，供用户抉择和配置。创立 Prometheus 告警的具体操作步骤，详见 Prometheus 告警规定文档。

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

关于阿里云:问题盘点｜使用-Prometheus-监控-Kafka我们该关注哪些指标

Kafka 简介

Kafka 是什么？

Kafka 特点

劣势

须要留神的问题

Kafka 典型实用场景

Kafka 外围概念

次要 Kafka 版本介绍

Kafka Metric 监控参考模型

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

比照

应用阿里云 Prometheus 监控 Kafka

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

结束语