CentOS 上常用的 Kafka 监控工具与方案
开源与自托管方案
- Kafka Manager（CMAK）：多集群管理、Broker 级 JMX 监控、支持消费者进度查看；在 CentOS 7.6 可用；缺点是编译耗时、无访问控制与告警、内存占用偏高。
- Kafka Eagle：安装简单（解压即用）、支持 钉钉/微信/Email 等告警，需 MySQL/SQLite 存储；相较 Kafka Manager 内存占用更低。
- Kafka Offset Monitor：轻量，查看消费者组与 Topic 信息；对 新版本 Consumer 与安全支持较弱，项目已近 2 年未维护。
- JMXTool + InfluxDB + Grafana：将 JMX 指标写入 InfluxDB，在 Grafana 可视化；配置相对繁琐。
- Prometheus + Grafana：主流时序监控方案，配合 JMX Exporter/kafka_exporter 采集指标，Grafana 展示与告警；适合长期可观测性建设。
- kafka_exporter：社区维护的 Prometheus Exporter，直连 Kafka 集群采集指标，支持 SSL/TLS、多版本 Kafka；可作为系统服务部署，默认监听 9308。
- Burrow：专注 消费者组滞后（Lag） 与健康检测，及时发现消费延迟与异常。
- Kafka Tool / Kafdrop：桌面 GUI 与 Web UI，便于 集群/主题/消费者组 可视化与日常管理（偏观测与管理）。
商业与托管方案
- Confluent Control Center：Confluent 官方商业版，提供集中化的 监控、性能与告警 能力，适合需要高级特性与统一管控的团队。
命令行与轻量检查
- kafka-consumer-groups.sh：查看 消费者组、分区与滞后等，适合快速排查消费延迟。
- kafkacat：非 JVM 的生产/消费/元数据查看工具，便于 连通性与元数据 快速验证（如 kafkacat -L -J 查看集群与分区信息）。
关键监控指标与告警建议
- 集群健康
- ActiveControllerCount 应为 1；UnderReplicatedPartitions 长期为 0；OfflinePartitionCount 为 0。
- 性能与稳定性
- 请求延迟与吞吐：Produce/Fetch 请求的 平均/分位数延迟 与 请求总数；LeaderElectionRateAndTimeMs 突增需排查 Broker/网络。
- 可用性风险：UncleanLeaderElectionsPerSec > 0 可能带来消息丢失风险。
- 消费者滞后
- records-lag / consumer_lag 持续上升表示消费能力不足或反压，建议基于历史峰值设置动态阈值。
- 资源与容量
- BytesIn/BytesOut、CPU/内存/磁盘 I/O、JVM 堆/GC、网络延迟与连接数；磁盘剩余空间低于 20% 需预警/扩容。
- 参考阈值示例
- UnderReplicatedPartitions > 0、ActiveControllerCount ≠ 1、UncleanLeaderElectionsPerSec > 0、Lag 超历史峰值的 2 倍、磁盘剩余 < 20% 触发告警。
快速落地组合
- 轻量可视化：部署 Kafka Eagle 或 Kafdrop，快速获得 Topic/消费者组/堆积 概览与基础告警。
- 企业级可观测：采用 Prometheus + Grafana，配合 kafka_exporter/JMX Exporter；示例抓取配置：
- scrape_configs: job_name: “kafka” static_configs: targets: [“192.168.1.10:9308”]（kafka_exporter 默认端口 9308）。
- 消费滞后专项：在 Prometheus 中监控 kafka_consumer_group_consumer_lag / records_lag_max 并设置分级告警。
