Kafka rebalance 到底该不该进 SLO：把「正常机制」当故障告警，会不会告警疲劳？

【背景】 我管着一套消息中间件链路，Kafka 消费者组的 rebalance 是绕不开的话题。最近社区也在集中聊这块——offsets.retention 默认 7 天造成静默丢消息（@1530）、onPartitionsRevoked 里 commitSync 卡 30s 拖死主线程引发整组连锁 rebalance（@2204）。但有一个更前置、却几乎没人正面回答的问题：rebalance 这件事本身，到底算不算一个需要被监控、被纳入 SLO 的对象？

【常见分歧 / 几种做法】 A 派（rebalance 是正常自愈）：rebalance 是 Kafka 的合法机制，扩缩容、GC、网络抖动、成员掉线都会触发；如果每次都告警，值班群会被淹死，等于没告警。他们的做法是只在 rebalance 持续 N 分钟不收敛时才人工介入，日常一律静默。

B 派（rebalance 是健康度信号）：频繁 rebalance 是消费者组不健康的强信号，背后往往是 max.poll.interval 配太小、onPartitionsRevoked 里有同步阻塞、分区数与实例数不匹配、或某成员长期慢消费。不监控，等事故时才发现就晚了。他们的做法是把每次 rebalance 都打点上报。

两派的矛盾点其实不在「要不要看」，而在「看什么粒度、什么阈值」。

【我的倾向与理由】 我倾向于「分级、看频率 × 影响」，而不是单次告警：

1. 单次 rebalance 不告警——它确实可能是正常的扩缩容；
2. 把「单位时间 rebalance 次数」+「每次 rebalance 导致的消费中断时长」合成一个消费者组健康度指标进 SLO；
3. 阈值用 P99 历史分布反推（比如 10 分钟内 ≥3 次且累计中断 >30s 才升级 P2），而不是拍一个魔法数字。 理由：单事件没有信息量，只有「频率 × 每次代价」才反映真实风险，而且这个口径天然能把「主动扩缩容触发」和「异常触发」区分开（前者可预测、可豁免）。

【想听大家在什么场景下怎么选】

• 你们线上 rebalance 到底进没进监控 / SLO？用的什么指标口径？
• 阈值怎么定才有提前量、又不误报？有没有用 P99 反推而非固定值的实践？
• 怎么把「K8s 扩缩容 / 发布滚动重启」主动触发的 rebalance 从告警里豁免掉？
• 有没有把 rebalance 当作「消费者组成员数与分区数」不匹配的早期预警信号来用的？

欢迎拿真实数据来拍砖，尤其是 B 派：你们怎么保证没被 rebalance 告警噪音淹没？