主机监控

  1. 主机监控：监控Kafka集群Broker所在的节点机器的性能
  2. 常见的主机监控指标
    • 机器负载
    • CPU使用率
    • 内存使用率，包括空闲内存和已使用内存
    • 磁盘IO使用率，包括读使用率和写使用率
    • 网络IO使用率
    • TCP连接数
    • 打开文件数
    • inode使用情况

JVM监控

  1. 重点指标
    • Full GC发生频率和时长
    • 活跃对象大小
    • 应用线程总数
  2. 设置堆大小
    • 经历一次Full GC后，堆上存活的活跃对象大小为S，可以安全地将老年代堆大小设置为1.5S或者2S
  3. 从0.9.0.0版本开始，社区将默认的GC收集器设置为G1，而G1的Full GC是由单线程执行的，速度非常慢
    • 一旦发现Broker进程频繁Full GC，可以开启G1的**-XX:+PrintAdaptiveSizePolicy，获知引发Full GC的原因**

集群监控

  1. 查看Broker进程是否启动，端口是否建立
    • 在容器化的Kafka环境，容器虽然启动成功，但由于网络配置有误，会出现进程已经启动但端口未成功监听的情形
  2. 查看Broker端关键日志
    • Broker端服务器日志server.log – 最重要
    • 控制器日志controller.log
    • 主题分区状态变更日志state-change.log
  3. 查看Broker端关键线程的运行状态
    • 这些关键线程的意外挂掉，往往无声无息，但却影响巨大
    • Log Compaction线程，这类线程以kafka-log-cleaner-thread开头
      • 挂掉后，所有Compaction操作都会中断，导致Kafka内部的位移主题所占用的磁盘空间越来越大
    • 副本拉取消息的线程，通常以ReplicaFetcherThread开头
      • 挂掉后，系统会表现为对应Follower副本不再从Leader副本拉取消息，Follower副本的Lag会越来越大
  4. 查看Broker端关键JMX指标
    • BytesIn/BytesOut
      • kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
      • kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec
      • Broker端每秒入站和出站字节数，要确保这组值不要接近网络带宽，容易出现网络丢包的情形
    • NetworkProcessorAvgIdlePercent
      • kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent
      • 网络线程池平均的空闲比例，要确保该值长期大于30%
    • RequestHandlerAvgIdlePercent
      • kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent
      • IO线程池平均的空闲比例，要确保该值长期大于30%
    • UnderReplicatedPartitions
      • kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions
      • 未充分备份的分区数，一般为0
        • 未充分备份，即并非所有的Follower副本都和Leader副本保持同步，此时可能会出现数据丢失
    • ISRShrink/ISRExpand
      • kafka.server:type=ReplicaManager,name=IsrShrinksPerSec
      • kafka.server:type=ReplicaManager,name=IsrExpandsPerSec
      • ISR收缩和扩容的频次指标
    • ActiveControllerCount
      • kafka.controller:type=KafkaController,name=ActiveControllerCount
      • 当前处于激活状态的控制器数量
        • 正常情况下，Controller所在Broker上的这个JMX指标值为1，其它Broker上这个值为0
        • 如果发现存在多台Broker上该值都是1时，通常表明集群中出现了脑裂，此时一定要查看网络连通性
        • 脑裂是非常严重的分布式故障，Kafka目前依托ZK来防止脑裂
        • 一旦出现脑裂，Kafka是无法保证正常工作的
  5. 监控Kafka客户端
    • 首先要关心的是客户端所在机器与Kafka Broker机器之间的网络往返时延（RTT），可以借助ping命令
    • 生产者
      • 以kafka-producer-network-thread开头的线程，负责实际消息发送
      • 一旦该线程挂掉，Producer将无法正常工作，但Producer进程不会自动挂掉
    • 消费者
      • 关注以kafka-coordinator-heartbeat-thread开头的线程，心跳线程事关Rebalance
    • JMX
      • 生产者：request-latency，消息生产请求的延时，最直接表征Producer程序的TPS
      • 消费者：records-lag、records-lead，直接反应消费者的消费进度
      • 消费者组：join rate、sync rate，表征Rebalance的频繁程度

参考资料

Kafka核心技术与实战