#作者：张桐瑞
文章目录
一、为什么监控 Kafka 这么难？
Kafka 作为分布式消息系统，其复杂性源于多层架构耦合：
- 单机多角色：单个 Broker 既是 Java 进程，也是操作系统进程，依赖 CPU / 内存 / 磁盘等资源。
- 集群强依赖：分区副本分布、Leader 选举、数据同步等机制涉及多节点协作。
- 客户端联动：生产者 / 消费者的性能直接影响集群负载，网络延迟、线程状态等需协同监控。
核心问题：监控什么？怎么监控？需从主机→JVM→集群三个维度层层深入。
二、主机监控：揭示问题的第一扇窗
目标：监控 Broker 所在节点的硬件资源使用情况，定位底层性能瓶颈。
（一）核心指标与工具
（二）关键场景解析
- 机器负载异常案例
top - 14:23:10 up 22 days, 3:17, 2 users, load average: 4.85, 2.76, 1.26
Tasks: 200 total, 1 running, 199 sleeping, 0 stopped, 0 zombie
%Cpu(s): 25.3 us, 3.2 sy, 0.0 ni, 71.1 id, 0.3 wa, 0.0 hi, 0.0 si
KiB Mem : 16384 total, 2048 free, 12288 used, 2048 buff/cache
- 现象：1 分钟负载 4.85＞4 核，说明 CPU 资源竞争激烈，进程排队等待执行。
- 排查：查看%CPU列高占用进程（如 Broker 的 Java 进程），结合jstack分析线程是否阻塞在 I/O 或锁竞争。
- CPU 使用率误区
- 误区：单看top中%CPU列（如 102.3%）≠ 真实 CPU 使用率。
- 真相：该值是进程占用所有 CPU 核的总和（多核场景下可能超过 100%）。
- 计算方式：%CPU值 / CPU 核数 = 单核心平均使用率（例：102.3% / 4 核 ≈ 25.6%）。
三、JVM 监控：深入 Broker 进程内核
目标：监控 Kafka Broker 的 Java 虚拟机状态，避免 GC 停顿、内存泄漏等问题。
（一）核心监控指标
（二）实战调优案例
- 堆内存配置优化
1)场景：Full GC 后活跃对象 700MB，原堆大小设置 16GB。
2)问题：大堆导致 GC 耗时久（G1 收集器单线程 Full GC），可能触发超时异常。
3)优化：老年代设为活跃对象的 1.5-2 倍（1.4GB），总堆大小控制在 3-4GB（避免浪费 + 提升 GC 效率）。 - GC 日志分析示例
2023-10-01T10:05:30.123+0800: 1234.567: [GC pause (G1 Humongous Allocation)
java.lang.ref.ReferenceQueue$Lock@12345678: 827M->645M(1024M), 0.0019078 secs]
关键信息：
- 827M→645M：GC 后堆存活对象从 827MB 降至 645MB。
- 0.0019s：Minor GC 耗时极短（正常），若 Full GC 频繁出现需排查大对象或内存泄漏。
四、集群监控：把握分布式系统脉搏
（一）基础存活检查
进程与端口
1)命令：ps -ef | grep kafka（检查 Broker 进程是否存活）
2)命令：netstat -anlp | grep 9092（检查监听端口是否正常）
3)场景：容器化部署时易出现 “进程存活但端口未绑定”（如网络配置错误）。关键日志监控
1)server.log：记录 Broker 启动、错误、状态变更（如 Leader 选举、副本同步失败）。
2)controller.log：控制器日志（集群分区管理核心，异常可能导致元数据混乱）。
3)state-change.log：分区状态变更日志（如 ISR 变动、分区上线 / 下线）。
（二）核心线程监控
- 必查线程列表
- 监控方法
- 命令行：jstack | grep “线程前缀”（检查线程状态是否为RUNNABLE）。
- 工具：集成 Prometheus+Grafana，通过 JMX 采集线程状态指标。
（三）JMX 指标精要
Kafka 暴露超 200 个 JMX 指标，以下为必监控项：
- 基础性能指标
1)kafka.server:type=BrokerTopicMetrics,name=BytesIn：Broker 每秒入站字节数（生产者写入流量）。
2)kafka.server:type=BrokerTopicMetrics,name=BytesOut：Broker 每秒出站字节数（消费者读取流量）。
3)阈值：单网卡流量＜带宽 80%，避免丢包。 - 线程池健康度
1)kafka.server:type=ThreadPool,name=NetworkProcessorAvgIdlePercent：网络线程池空闲比例（理想值＞30%）。
2)kafka.server:type=ThreadPool,name=RequestHandlerAvgIdlePercent：I/O 线程池空闲比例（理想值＞30%）。
3)调优：若低于阈值，增加num.network.threads（默认 3）或num.io.threads（默认 8）。 - 副本与分区状态
1)kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions：未充分备份分区数（理想值 0）。
2)kafka.server:type=ReplicaManager,name=ISRShrinkRate/ISRExpandRate：ISR 收缩 / 扩容频率（频繁变动需排查副本同步延迟）。 - 控制器状态
1)kafka.controller:type=KafkaController,name=ActiveControllerCount：活跃控制器数量（正常为 1，多节点为 1 时可能脑裂）。
（四）客户端监控要点
网络连通性
1)工具：ping （RTT 应＜50ms，超过 100ms 可能影响性能）。
2)案例：某客户生产者 TPS 低，发现 RTT=1s，优化网络后性能提升 3 倍。客户端线程
1)生产者：kafka-producer-network-thread（消息发送线程，挂掉导致生产阻塞）。
2)消费者：kafka-coordinator-heartbeat-thread（心跳线程，异常触发 Rebalance 失败）。核心 JMX 指标
1)生产者：producer.request-latency（请求延迟，反映 TPS 瓶颈）。
2)消费者：consumer.records-lag（消费滞后量，值持续增大可能堆积）。
3)消费组：consumer.join-rate/sync-rate（Rebalance 频率，高值需优化分区数或组配置）。
五、监控工具链推荐
