Kafka监控指标Linux上关注啥

一、Broker核心指标（Linux下通过JMX/工具监控的关键Broker状态）

• UnderReplicatedPartitions：处于复制状态的Partition数量（即ISR集合小于总副本数的分区数）。若该值长期大于0，说明副本同步滞后，需检查Broker网络或磁盘性能。
• OfflinePartitionsCount：离线Partition数量。非0值表示有分区未分配Leader，可能导致数据不可用，需立即排查Broker宕机或分区分配问题。
• UncleanLeaderElectionsPerSec：未清理Leader选举的频率（即允许从非ISR副本中选举Leader的次数）。非0值会破坏数据一致性（可能丢失数据），需确保unclean.leader.election.enable=false并监控该值是否为0。
• ActiveControllerCount：活跃Controller数量。Kafka集群中应始终保持1个活跃Controller（用于管理分区Leader选举），若该值不为1，说明集群元数据管理异常。
• BytesInPerSec/BytesOutPerSec：Broker每秒接收/发送的字节数（即吞吐量）。反映集群数据流入流出负载，结合业务预期判断是否需要扩容Broker或分区。

二、机器层面指标（Linux系统资源使用情况）

• CPU使用率：通过top、htop或/proc/stat监控Kafka进程（java进程）的CPU占用。过高可能因消息堆积、压缩操作或GC频繁导致，需优化JVM参数或增加Broker节点。
• 内存使用：通过free -m、top查看系统内存及Kafka进程的%MEM占用。Kafka依赖堆外内存（PageCache），需合理配置JVM堆内存（避免过大导致GC停顿），并通过vmstat监控swap使用（避免内存溢出）。
• 磁盘I/O：使用iostat -x 1监控磁盘的read/write速率、await（IO等待时间）、%util（磁盘利用率）。Kafka是磁盘顺序IO密集型应用，%util长期超过70%需升级磁盘（如SSD）或优化分区分布。
• 网络流量：通过netstat -antp、ss -s或iftop监控网卡的RX/TX速率（接收/发送流量）。网络带宽瓶颈会导致吞吐量下降，需检查网卡配置（如升级万兆网卡）或优化分区跨Broker分布。

三、JVM指标（Kafka运行环境监控）

• 堆内存使用：通过JMX监控MemHeapUsed（已用堆内存）与MemHeapMax（最大堆内存）的比例。建议设置为70%-80%（避免频繁Full GC），可通过jstat -gc <pid>查看GC次数和时间。
• GC情况：监控Young GC（ParNew）和Old GC（CMS/G1）的频率及耗时。频繁Full GC会导致Broker停顿，需调整JVM堆大小（-Xmx/-Xms）或更换GC策略（如G1GC）。

四、生产者核心指标（通过JMX或Kafka Exporter监控）

• 提交速度：每秒发送的消息数（MessagesInPerSec）或字节数（BytesInPerSec）。反映生产者写入负载，结合batch.size（批量大小）和linger.ms（等待时间）参数优化吞吐量。
• 发送成功率：成功发送的消息数与总发送数的比例（record-send-rate/request-rate）。若成功率低，需检查网络连接、Broker可用性或acks配置（如acks=all会增加失败概率）。
• 错误率：发送失败的次数（record-error-rate）。非0值需排查生产者配置（如retries重试次数）、Broker负载或网络问题。

五、消费者核心指标（通过Kafka Exporter/Burrow监控）

• 消费速度：每秒消费的消息数（records-consumed-rate）或字节数（bytes-consumed-rate）。反映消费者处理能力，若低于生产速度，需扩展消费者实例或优化消费逻辑。
• 消费成功率：成功消费的消息数与总消费数的比例。若成功率低，需检查消费者配置（如auto.offset.reset）、分区分配（Consumer Group是否均衡）或业务处理逻辑。
• 消费延迟（Lag）：分区最新偏移量与消费者当前偏移量的差值（consumer-lag）。反映消息积压情况，若Lag持续增长，需增加消费者实例或提升消费处理速度。

六、其他重要监控指标

• 分区与副本状态：通过kafka-topics.sh --describe查看分区Leader分布（应均匀分布在各Broker）、ISR集合大小（应满足min.insync.replicas配置，确保数据可靠性）。
• 请求延迟：生产者/消费者的请求响应时间（Produce-TotalTimeMs/Fetch-TotalTimeMs）。延迟过高可能因Broker负载高、网络延迟或磁盘IO慢导致，需针对性优化。
• 请求队列等待时间：请求在Broker队列中的等待时间（Produce-QueueTimeMs/Fetch-QueueTimeMs）。过长说明Broker处理能力不足，需增加Broker或分区。