作者：阿里云可观测

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

Kafka 简介

Kafka 是什么？

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

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

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

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

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

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 的首要目标。

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

2. Broker 目标

因为一切音讯都必须经过 Kafka Broker 才干被运用，所以对集群中 Broker 的监控是最中心的。咱们主张重视如下首要目标：

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

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

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

3. Consumer 目标

Consumer 是 Kafka 音讯结尾。咱们主张重视如下首要目标：

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

4. Zookeeper 目标

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

问题盘点｜使用 Prometheus 监控 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。

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

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

运用阿里云 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 页检查。

kafka.console.aliyun.com/

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

阿里云 Kafka 实例监控大盘

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

阿里云 Kafka 消费组监控大盘

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

阿里云 Kafka Topic 监控大盘

  • 运用阿里云 Prometheus 装备阿里云 Kafka 告警

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

help.aliyun.com/document_de…

阿里云 Prometheus 供给了 13 条默许告警目标（继续更新中），涵盖了实例、Group 和 Topic 的要害目标，方便用户快速装备常见告警规矩。

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

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

  • 运用阿里云 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 监控。

help.aliyun.com/document_de…

help.aliyun.com/document_de…

  • 运用阿里云 Prometheus 进行自建 Kafka 的根底监控

1. 布置自建 Kafka 的根底监控

登录阿里云 Prometheus 控制台，拜访 ARMS 接入中心，点击组件运用“Kafka（根底版）”的“增加”按钮，在弹出界面挑选 Kafka 所布置的环境（现在支撑“阿里云容器服务环境”和“阿里云 ECS 环境”），挑选 Kafka 地点的 Prometheus 实例，然后填写装备信息。

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

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

装备衔接 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）数量。

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

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

3. 装备自建 Kafka 的根底监控告警

进入 Prometheus 实例的集成中心，点击“Kafka（根底版）”，在弹出界面挑选“告警”tab 页，即可检查/新增当时 Prometheus 实例的 Kafka 根底版告警规矩。创立 Prometheus 告警的具体操作步骤，详见 Prometheus 告警规矩文档。

help.aliyun.com/document_de…

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

现在 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）。

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

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

  • 检查高档监控大盘

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

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

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

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

  • 自建 Kafka Topic 大盘

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

  • Producer：展现Producer端的要害目标，包含音讯发送速度、音讯紧缩率、发送推迟等。

  • Server（即Kafka Broker）：展现该Topic对应的分区数、入/出音讯速率、入/出音讯流量。

  • Consumer：展现音讯消费速率、消费推迟和Rebalance等。

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

  • 装备自建Kafka的高档监控告警

进入Prometheus实例的集成中心，点击“Kafka（高档版）”，在弹出界面挑选“告警”tab页，即可检查/新增当时Prometheus实例的Kafka高档版告警规矩。Kafka高档版供给Producer、Instance和Consumer三方面的告警目标，供用户挑选和装备。创立Prometheus告警的具体操作步骤，详见Prometheus告警规矩文档。

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

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