Kafka监控

概述

Kafka监控对于确保Kafka集群的健康运行和高性能至关重要；但在监控 Kafka 时，如果我们只监控Broker 的话，就难免以偏概全。单个 Broker 启动的进程虽然属于 Kafka 应用，但它也是一个普通的 Java 进程，更是一个操作系统进程。因此，我觉得有必要从 Kafka 主机、JVM和 Kafka 集群本身这三个维度进行监控

监控维度

Kafka 主机

主机级别的监控是揭示线上问题的第一步，主要包括以下几个方面：

  1. 机器负载（Load）：查看主机的负载情况，load average 的值可以揭示系统的整体负载状态。
  2. CPU 使用率：监控 CPU 的使用率，可以使用 top 命令查看单个进程的 CPU 占用情况。
  3. 内存使用率：包括空闲内存（Free Memory）和已使用内存（Used Memory），这些指标帮助了解系统内存的使用情况。
  4. 磁盘 I/O 使用率：包括读使用率和写使用率，用于监控磁盘的读写性能。
  5. 网络 I/O 使用率：监控网络接口的使用情况，了解网络流量和性能。
  6. TCP 连接数：查看系统中打开的 TCP 连接数量，判断网络连接的繁忙程度。
  7. 打开文件数：监控系统中打开文件的数量，防止文件句柄耗尽。
  8. inode 使用情况：监控文件系统的 inode 使用情况，防止 inode 耗尽

JVM

Kafka Broker 进程是一个普通的 Java 进程，因此对 JVM 的监控同样重要。主要包括以下几个方面：

  1. Full GC 发生频率和时长：监控 Full GC 的频率和持续时间，评估 Full GC 对 Broker 进程的影响。
  2. 活跃对象大小：监控堆上存活的活跃对象大小，这对于设定堆大小和调优 JVM 各个代的堆大小非常重要。
  3. Minor GC 频率和时长：同样需要关注 Minor GC 的频率和时长，以优化 GC 性能。
  4. 堆大小（Heap Size）：监控堆大小和各代（新生代和老年代）的分配情况。
  5. GC 回收器类型：了解所使用的 GC 回收器类型及其配置，以优化 GC 性能

Kafka 集群

监控 Kafka 集群的关键指标，主要包括以下几个方面：

  1. 端口：查看 Broker 进程是否启动，端口是否建立。
  2. 查看 Broker 端关键日志：涉及 Broker 端服务器日志 server.log，控制器日志 controller.log
    以及主题分区状态变更日志 state-change.log
  3. 查看 Broker 端关键线程的运行状态：Log Compaction 线程（用于处理日志）、副本拉取消息的线程（这类线程执行 Follower 副本向 Leader 副本拉取消息的逻辑）
  5. Broker 端的关键 JMX 指标：
    • BytesIn/BytesOut：即 Broker 端每秒入站和出站字节数。你要确保这组值不要接近你的
      网络带宽，否则这通常都表示网卡已被“打满”，很容易出现网络丢包的情形。
    • NetworkProcessorAvgIdlePercent：即网络线程池线程平均的空闲比例。通常来说，你
      应该确保这个 JMX 值长期大于 30%。如果小于这个值，就表明你的网络线程池非常繁
      忙，你需要通过增加网络线程数或将负载转移给其他服务器的方式，来给该 Broker 减
      负。
    • RequestHandlerAvgIdlePercent：即 I/O 线程池线程平均的空闲比例。同样地，如果
      该值长期小于 30%，你需要调整 I/O 线程池的数量，或者减少 Broker 端的负载。
    • UnderReplicatedPartitions：即未充分备份的分区数。所谓未充分备份，是指并非所有
      的 Follower 副本都和 Leader 副本保持同步。一旦出现了这种情况，通常都表明该分区
      有可能会出现数据丢失。因此，这是一个非常重要的 JMX 指标。
    • ISRShrink/ISRExpand：即 ISR 收缩和扩容的频次指标。如果你的环境中出现 ISR 中副
      本频繁进出的情形，那么这组值一定是很高的。这时，你要诊断下副本频繁进出 ISR 的
      原因，并采取适当的措施。
    • ActiveControllerCount：当前处于激活状态的控制器数量，正常情况下应该为 1，如果多个 Broker 上该值都为 1，说明可能存在脑裂问题。
  6. Topic 和 Partition 监控：监控每个 Topic 和 Partition 的状态和健康状况，了解数据分布和负载情况。
  7. 监控 Kafka 客户端：
    • 客户端所在的机器与 Kafka Broker 机器之间的网络往返时延
    • 从 Producer 角度，你需要关注的 JMX 指标是 request-latency，即消息生产请求的延时。这个 JMX 最直接地表征了 Producer 程序的 TPS
    • 从 Consumer 角度来说，records-lag 和 records-lead 是两个重要的 JMX 指标
    • 如果你使用了 Consumer Group，那么有两个额外的 JMX 指标需要你关注下，一个是 join rate，另一个是 sync rate；它们说明了 Rebalance 的频繁程度