Kafka 是什么？
Kafka 是分布式、高吞吐、可扩展的实时数据流平台。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 核心概念
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 的主要指标。
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。
Kafka 典型问题场景及其排查/解决方法3
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 和自建 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/
阿里云 Kafka 实例监控大盘
阿里云 Kafka 消费组监控大盘
阿里云 Kafka Topic 监控大盘
使用阿里云 Prometheus 配置阿里云 Kafka 告警
用户可以登录阿里云 Prometheus 控制台，进入“云服务监控”实例的“集成中心”界面，选择“云产品自监控集成”tab，点击“消息队列 Kafka”，弹出窗口中的“告警”tab 页，即可查看和新增阿里云 Kafka 的 Prometheus 告警。创建 Prometheus 告警的详细操作步骤，详见 Prometheus 告警规则文档。
https://help.aliyun.com/document_detail/331981.html
阿里云 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/document_detail/161845.html
https://help.aliyun.com/document_detail/445268.html
使用阿里云 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/document_detail/331981.html
目前 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（高级版）”，在弹出界面选择“大盘”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消耗。