Kafka Streams部分任务停止消费排查求助（v3.1.1，K8s部署）

以下是针对该问题的根因分析及排查步骤：

1. 网络连接异常（匹配Node -1断开日志） #

• Node -1是Kafka客户端在未获取完整Broker元数据时使用的虚拟节点，这条日志表明AdminClient在与集群交互时出现了元数据获取失败或Broker连接中断。
• 即使Streams主日志无错误，部分分区的消费者可能因与对应Broker的连接静默断开，无法拉取消息。K8s环境下常见诱因：网络波动、Service路由异常、Broker主动清理空闲连接。
• 排查动作：
  • 在Streams Pod内执行ping <broker-ip>或nc -zv <broker-ip> <port>验证网络连通性
  • 核对Broker侧connections.max.idle.ms配置，若Broker侧超时时间小于Streams的540000ms（9分钟），Broker会主动断开空闲连接，而客户端未及时感知

2. 任务静默阻塞（无错误但停止消费） #

• 当前max.task.idle.ms=0，意味着任务空闲时不会触发任何告警。若某个任务的处理逻辑出现阻塞（如State Store IO卡住、同步调用外部服务无响应但未抛异常），会导致该任务停止拉取消息，但StreamThread整体仍在运行（从日志可见StreamThread仍在统计处理记录）。
• 排查动作：
  • 查看Pod的CPU、内存、磁盘IO指标，是否存在持续高负载或IO等待
  • 梳理Processors中的业务逻辑，排查是否有潜在阻塞点（如大流量下的State Store范围查询、未设置超时的外部调用）
  • 开启Streams的DEBUG日志，重点监控org.apache.kafka.streams.processor.internals.Task类的日志，确认异常任务是否还在执行poll/commit操作

3. 位移提交异常 #

• 日志显示有commit记录，但部分分区可能出现位移提交失败且未重试（当前retries=0）。位移提交失败时，Streams可能停止拉取该分区消息以避免重复处理，但这类异常不在default.deserialization.exception.handler的处理范围内，因此无错误日志。
• 排查动作：
  • 检查Broker侧__consumer_offsets主题的状态，是否存在分区不可用或消息堆积
  • 通过Kafka命令行工具查询该Streams应用的位移记录，确认异常分区的位移是否有更新：

    kafka-consumer-groups.sh --bootstrap-server <broker-list> --describe --group <application-id>
    

4. 配置隐性问题 #

• session.timeout.ms=10000ms：K8s环境下，Pod短暂网络抖动或GC停顿可能触发Session超时，但你提到未触发Rebalance，不过部分分区的消费者可能已被Broker标记为死亡，元数据未及时同步到客户端。
• poll.ms=50ms：若任务处理耗时过长，可能导致实际poll间隔超过max.poll.interval.ms（默认300000ms），引发隐性的任务停滞。
• 优化建议：
  • 将max.task.idle.ms调整为30000ms，当任务空闲超过该时间时，Streams会打印告警日志，便于快速定位异常任务
  • 增大retries配置至3，允许位移提交、生产操作重试，避免单次失败导致任务停滞

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