监控显示存在离线分区却无法定位的Kafka集群问题求助

针对你遇到的非生产三节点Kafka集群中kafka_controller_kafkacontroller_offlinepartitionscount指标长期显示1个离线分区，但实际未找到对应异常分区的问题，可按以下步骤排查：

一、聚焦控制器节点日志定位异常来源 #

该指标由集群控制器生成，优先查看当前控制器Broker的日志，获取离线分区的具体线索：

• 先确定当前控制器节点：

  zkCli.sh get /controller
  

• 在控制器节点的controller.log中搜索离线分区相关日志：

  grep -i "offline\|OfflinePartitionsCount" /path/to/kafka/logs/controller.log | tail -100
  

  日志中可能会记录被标记为离线的分区ID、所属主题等关键信息，即使主题已被删除，控制器仍可能残留相关计数。

二、清理ZooKeeper中的残留元数据 #

Kafka的核心元数据存储在ZK，若主题删除不彻底或元数据同步异常，可能导致控制器计数错误：

1. 对比ZK与集群实际存在的主题：

   # 列出ZK中存储的所有主题
   zkCli.sh ls /brokers/topics
   # 列出集群实际存在的主题
   kafka-topics.sh --list --bootstrap-server <你的Broker地址>:9092
   

   若ZK中存在集群已无的"幽灵主题"，进入该主题的分区节点查看详情：

   zkCli.sh ls /brokers/topics/<幽灵主题名>/partitions
   

2. 检查未完成的主题删除请求：

   zkCli.sh ls /admin/delete_topics
   

   若存在残留的主题名称，手动删除该ZK节点：

   zkCli.sh delete /admin/delete_topics/<残留主题名>
   

3. 查看控制器状态节点是否有异常记录：

   zkCli.sh get /controller_state
   

三、强制刷新集群元数据缓存 #

Broker本地元数据缓存可能与ZK不一致，触发全量刷新：

• 临时修改所有Broker的元数据过期时间，强制拉取最新ZK数据：

  # 对每个Broker执行，设置元数据1秒过期
  kafka-configs.sh --bootstrap-server <你的Broker地址>:9092 --alter --entity-type brokers --entity-name <BrokerID> --add-config metadata.max.age.ms=1000
  # 等待10秒后恢复默认值（默认300000毫秒）
  kafka-configs.sh --bootstrap-server <你的Broker地址>:9092 --alter --entity-type brokers --entity-name <BrokerID> --delete-config metadata.max.age.ms
  

• 非生产环境可直接重启所有Broker，彻底清除本地缓存。

四、清理磁盘上的残留分区日志 #

即使ZK元数据清理完成，Broker磁盘上可能残留已删除主题的分区日志，导致控制器误判：

• 查看log.dirs配置指定的日志目录：

  ls -l /path/to/kafka/logs/
  

• 删除不属于现有主题的日志目录（确认数据无价值后操作），随后重启对应Broker。

五、验证修复结果 #

完成上述操作后，等待5-10分钟，通过以下方式验证：

1. 查看kafka_controller_kafkacontroller_offlinepartitionscount指标是否回归0；
2. 再次确认所有分区状态正常：

   kafka-topics.sh --describe --bootstrap-server <你的Broker地址>:9092 | grep -E "Leader: -1|Under replicated"
   

内容的提问来源于stack exchange，提问作者Justinas Lelys