求助：Kafka集群随机出现13/13 Brokers Down错误（Strimzi+Confluent .NET）

核心原因分析 #

这个错误大多是客户端连接状态误判，而非broker真的全部不可用——因为消息最终能写入成功，说明librdkafka内部的重试机制已经自动恢复了连接，只是错误日志被触发。常见触发场景是闲置期后首次发送消息时，连接被网络或broker端的超时策略断开。

具体解决方案 #

• 调整连接闲置超时配置
  在生产者配置中增大connections.max.idle.ms（默认是9分钟），避免闲置连接被Kubernetes网络策略、Strimzi或broker端的超时规则断开。比如设置为3600000（1小时）：

  ConnectionsMaxIdleMs = 3600000
  

  同时配置合理的重连退避参数，让客户端快速恢复连接：

  ReconnectBackoffMs = 100,
  ReconnectBackoffMaxMs = 1000
  

• 升级Confluent客户端版本
  Confluent 2.4.0对应的librdkafka版本存在一些连接状态检测的bug，和Kafka 3.1.0的兼容性不够完善。建议升级到3.x系列的稳定版，新版本修复了不少类似的误报问题。

• 检查Strimzi与Kubernetes网络配置

  • 确认Strimzi暴露的broker地址是客户端可正常访问的（比如外部Listener的正确域名/IP），避免客户端连接内部IP导致的网络问题。
  • 检查Kubernetes Service的会话超时设置，部分云厂商的LoadBalancer或NodePort存在闲置连接回收机制，需要调整对应超时时间。

• 开启调试日志定位细节
  在生产者配置中添加调试日志开关，获取更详细的连接状态变化：

  Debug = "broker,conn,net"
  

  通过日志可以明确是连接真的断开，还是客户端的状态误判，同时结合Strimzi的broker日志，确认broker侧是否有连接断开的记录。

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