Confluent Docker cp-kafka-connect 4.0.0：HTTP500超时与COORDINATOR_NOT_AVAILABLE问题

从你描述的情况来看，核心问题是Kafka Connect的消费者组（connect03）无法找到Group Coordinator，导致Connect服务无法正常初始化，进而REST请求超时。结合你已经尝试过的操作（自动/手动创建主题、更换groupId），可以从以下几个方向深入排查：

1. 验证Connect存储主题的完整性与配置合规性 #

Confluent Connect对config、offsets、status三个主题有明确的配置要求，哪怕主题被创建，参数不符合要求也会导致协调器问题：

• 检查主题的分区数与副本数：
  执行以下命令查看三个主题的详细信息：

  kafka-topics --bootstrap-server kafka1.kafka:9092 --describe --topic connect03-config
  kafka-topics --bootstrap-server kafka1.kafka:9092 --describe --topic connect03-offsets
  kafka-topics --bootstrap-server kafka1.kafka:9092 --describe --topic connect03-status
  

  注意：

  • config主题建议设置为1个分区，副本数需匹配你的Kafka集群节点数（3节点集群则副本数=3）；
  • offsets主题建议至少25个分区，副本数=集群节点数；
  • status主题建议至少5个分区，副本数=集群节点数。
    同时确认每个主题的Leader是否存在，ISR（In-Sync Replicas）列表是否包含所有副本——如果ISR不完整，说明部分副本同步异常，会影响协调器选举。

• 检查主题的权限配置：
  确保Connect使用的账号对这三个主题有READ、WRITE权限，尤其是offsets主题（消费者组的偏移量存储依赖它）。可以用kafka-acls工具验证权限：

  kafka-acls --bootstrap-server kafka1.kafka:9092 --list --topic connect03-offsets
  

2. 检查消费者组的协调器状态 #

直接查看connect03消费者组的协调器信息，确认是否存在协调器或选举异常：

kafka-consumer-groups --bootstrap-server kafka1.kafka:9092 --describe --group connect03

如果输出中COORDINATOR字段显示(unknown)或报错，说明协调器未成功选举。此时可以尝试删除该消费者组（确保无正在运行的Connect实例），然后重启Connect：

kafka-consumer-groups --bootstrap-server kafka1.kafka:9092 --delete --group connect03

3. 验证Kafka Broker的组协调器相关配置 #

检查Broker的以下配置是否合理（通常在server.properties中）：

• group.min.session.timeout.ms与group.max.session.timeout.ms：Connect的消费者默认会话超时时间需要落在这个区间内。Confluent 4.0.0的Connect默认会话超时是10秒，确保Broker的配置没有限制这个值（比如group.max.session.timeout.ms不能小于10秒）。
• offsets.topic.replication.factor：如果依赖Kafka自动创建主题，这个参数决定了偏移量主题的副本数，必须设置为>=你的集群节点数（3节点则设为3），否则自动创建的主题副本数不足，会导致协调器无法正常工作。

4. 排查网络与DNS解析的一致性 #

虽然其他组件正常，但Connect容器的网络环境可能存在差异：

• 在Connect容器内部测试Kafka Broker的可达性：

  docker exec -it <connect-container-id> ping kafka1.kafka
  docker exec -it <connect-container-id> nslookup kafka1.kafka
  

  确保能正确解析到Broker的IP，且网络连通正常。
• 检查Kafka Broker的advertised.listeners配置：确保Broker对外暴露的地址是Connect容器能访问的主机名或IP（不能是localhost，除非Connect和Broker在同一个容器网络且用localhost通信）。

5. 检查Connect的消费者配置覆盖 #

Connect的消费者配置可能被环境变量或自定义配置覆盖，导致异常：

• 查看Connect日志中是否有消费者配置的输出（因为你开启了TRACE日志），搜索consumer config相关内容，确认bootstrap.servers、session.timeout.ms等参数是否符合预期。
• 尝试显式设置消费者的bootstrap servers：添加环境变量CONNECT_CONSUMER_BOOTSTRAP_SERVERS=kafka1.kafka:9092,kafka2.kafka:9092,kafka3.kafka:9092，确保消费者使用正确的Broker地址。

6. 验证Kafka集群元数据同步 #

如果某个Broker的元数据未同步，可能导致Connect请求该Broker时无法找到协调器：

• 修改Connect的CONNECT_BOOTSTRAP_SERVERS，只指定单个Broker（比如kafka1.kafka:9092），重启Connect后观察日志是否还出现协调器不可用的错误。
• 检查所有Kafka Broker的日志，确认元数据同步是否正常（搜索metadata相关日志，看是否有同步失败的信息）。

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