Kafka 消费组滚动发布后 lag 回落到 0 的「收敛判定」怎么做：逐分区 lag 的判定窗口、阈值和误判防护有没有可复用的量化方案？

背景

• Kafka 3.5（3 broker，KRaft），topic risk-eval-result 32 分区，消费组 8 实例（每实例 4 分区），K8s Deployment 滚动发布（maxUnavailable=1），assignor 已切 cooperative。
• 峰值约 6000 msg/s，单条处理 P50≈80ms，P99≈1.2s（含一次外部 RPC）。
• 每次滚动发布期间，被驱逐实例的 4 个分区临时分摊到其余 7 个实例，约 15~45s 的「临时积压窗口」（rebalance + 拉取 + 消化）。

现象

发布结束后，监控上能看到「组级 lag 峰值」已经回落到 0，但逐分区看：

• 被驱逐实例原来持有的 4 个分区，lag 往往在 60~180s 才真正归零；
• 其余 28 个分区 lag 基本贴 0；
• 偶尔（约 1 次/周）某个分区 lag 停在 2000~8000 条不再下降，最后靠人工重启该实例恢复。

已尝试

1. 看组级 consumer.group.lag 峰值回落 → 太粗，掩盖了分区粒度差异；
2. 用 Prometheus 逐分区 lag 告警 lag > 0，发布期间误报太多，已经关掉；
3. 发布脚本里 sleep 120s 后再「认为发布完成」，纯靠时间，没有量化依据；
4. 看过站内两篇直接相关：
   • id=1384《K8s HPA 自动扩缩容反复触发 Kafka consumer group rebalance》——讲的是 rebalance 触发条件与消费连续性；
   • id=1382《Kafka 3.4 消费端 P99 单条 45s、64 分区：max.poll.interval.ms 与 session.timeout.ms》——讲的是「活着却被踢」的长尾场景。 但都没有给出「发布结束后如何判定 lag 已真正收敛」的可执行口径。

期望得到的答案形态

1. 判定指标：除了逐分区 lag，还需要看哪些指标（如 records-lag-max、records-consumed-rate、commit 时间戳）才能避免「lag=0 但还在追赶」的误判？
2. 判定窗口：发布结束后至少观察多久才算「安全」？这个窗口和单条处理 P99、分区数、实例数之间有没有可推导的关系，而不是拍脑袋的 120s？
3. 阈值：逐分区 lag 回落到多少（绝对值 / 相对值）可以认为「收敛」？对 lag > 0 这种零容忍告警有没有更实用的替代（比如速率衰减斜率）？
4. 兜底：如果某个分区在窗口结束后 lag 仍 > 0，自动化的兜底动作（告警 / 重启 / 人工介入）怎么选？
5. 如果你们团队有现成的发布后 lag 收敛判定脚本或 runbook，欢迎直接贴出来。