Kafka生产者报LeaderNotAvailableError，ZooKeeper异常排查求助

一、优先验证ZooKeeper集群运行状态 #

Kafka的元数据完全依赖ZooKeeper，ZK异常会直接导致Kafka无法获取分区Leader信息，触发LeaderNotAvailableError。

• 检查所有ZK节点运行状态：
  进入ZK容器执行 zkServer.sh status，确认每个节点的角色（leader/follower），若出现Error contacting service. It is probably not running.，说明节点未正常启动。
• 核查ZK资源占用：
  用top或docker stats查看ZK容器的CPU、内存使用率；同时查看宿主机dmesg日志，搜索zookeeper或oom-kill关键词，确认是否因内存超限被OOM Killer终止。
• 检查ZK核心配置：
  确认ZOOKEEPER_HEAP_SIZE环境变量（或zoo.cfg中的Xmx参数），默认1G的堆内存在高负载场景可能不足，建议调整为2-4G；同时检查maxClientCnxns参数，避免因客户端连接耗尽导致服务异常。

二、排查ZooKeeper集群一致性与连通性 #

• 验证ZK集群内部通信：
  在任意ZK节点执行zkCli.sh，输入ls /brokers/ids查看Kafka Broker的注册信息，若命令超时或返回空，说明ZK集群内部通信异常。
• 分析ZK完整日志：
  除已提供的报错外，搜索QuorumPeer、election、quorum关键词，排查是否存在节点无法加入集群、Leader选举失败等问题，这类问题会导致ZK无法正常对外提供服务。
• 检查ZK数据目录：
  确认dataDir和dataLogDir的挂载状态、磁盘空间及权限，ZK进程需要对这些目录拥有读写权限。

三、验证Kafka与ZooKeeper的交互逻辑 #

• 检查Kafka的ZK配置：
  确认zookeeper.connect配置包含所有3个ZK节点（格式：zk1:2181,zk2:2181,zk3:2181/kafka）；同时核查zookeeper.session.timeout.ms参数，建议设置为30000ms，超时过短会导致Broker频繁断开ZK连接。
• 深挖Kafka Broker日志：
  搜索zookeeper、leader election、metadata关键词，排查是否存在Broker无法从ZK获取元数据、分区选举失败的日志，比如Failed to update metadata、Partition ... leader not available。
• 测试Kafka生产者连通性：
  使用kafka-console-producer.sh发送测试消息，同时实时监控Broker和ZK日志，捕捉新的报错信息。

四、容器环境特殊排查点 #

• 验证容器网络连通性：
  确认ZK与Kafka容器处于同一网络，用ping、telnet测试2181（ZK）、9092（Kafka）端口的互通性。
• 检查容器资源限制：
  执行docker inspect <容器ID>，查看HostConfig下的Memory、CpuShares配置，确认是否因内存限制过低导致ZK进程被终止。
• 核查容器重启历史：
  用docker ps -a查看ZK容器是否存在频繁重启情况，通过docker logs --tail 100 <容器ID>查看最近启动日志，确认启动失败原因。

内容的提问来源于stack exchange，提问作者Omri. B