Kafka 消费组"位点过期倒计时"怎么提前预警：offsets.retention.hours 默认 7 天，消费组下线/积压超 5 天就该告警，你们的阈值公式和采集方案是怎么落地的？

背景

8 年运维，管着十几个 Kafka 3.5（KRaft，3 broker）消费组。社区那篇《停机 8 天静默跳过 465 万条》（id=1530）我反复看了几遍，结论我认：__consumer_offsets 是带 TTL 的缓存，不是权威源——offsets.retention.hours 默认 168h，消费组超过 7 天没提交位点，重启后位点直接按 auto.offset.reset 重置，全程零报错。

我们的痛点比事故本身更前置：事故发生在停机第 8 天，但第 5 天就有人该拉警报了。目前我们没有任何"位点还剩几天过期"的监控，属于"出了事才知道"。

现象（一次真实的"差一点"）

上个月一次发布事故，有个对账消费组挂了约 5 天没人发现（K8s Deployment 被缩到 0 副本，属于计划内操作但忘了恢复）。第 5 天我们例行巡检 kafka-consumer-groups --describe 才发现：committed offset 停在 5 天前，按 7 天 retention 算只剩 48h 余量。这次运气好，消息 topic 的 retention.ms 还够，我们手动 seek 回补了；但如果再晚两天，就是 465 万条级别的静默丢失，而且 lag 监控在消费组下线期间根本不产数，一个告警都不会有。

已尝试的排查与结果

1. lag 监控（kafka-exporter / Prometheus）：消费组实例数为 0 时，kafka_consumergroup_current_offset 要么缺失要么冻结，没有 lag 指标可言，这条路在"消费者彻底下线"场景失效；
2. Prometheus 的 kafka_consumergroup_committed_timestamp：理论上可以算 now - committed_timestamp 对比 retention 做倒计时，但同样依赖 exporter 存活 + 消费组有注册记录，且我们集群的 exporter 版本里这个指标覆盖不全，没敢作为唯一依据；
3. 手动巡检脚本：定时跑 kafka-consumer-groups --bootstrap-server ... --describe --group <g> 解析 committed 时间戳，能算出余量，但要逐个 group 枚举、解析文本格式脆弱，而且我们 10+ 个消费组、跨 2 套集群，纯脚本维护不动；
4. 调大 offsets.retention.hours：讨论过，但这是治标——对账类消费组本来就长期不活跃，retention 调到 30 天也只是把爆炸半径从 7 天消息扩大到 30 天，且位点数据本身不是业务数据的权威存储，不能当备份用（id=637 那篇也强调了这点）。

想问的具体问题（期望答案形态）

1. 阈值公式：你们怎么定"位点过期倒计时"的告警线？是固定比例（如剩余 50% retention 告警）、绝对余量（如 <72h 告警）、还是按该 topic 的 retention.ms 动态算（位点过期前 topic 数据可能已经滚掉了，取两者交集）？对"长期不活跃的批处理消费组"和"常驻流式消费组"是否用不同阈值？
2. 采集方案：有没有比"遍历 group 解析 describe 文本"更稳的做法？比如直接查 __consumer_offsets（topic 本身就是 KV 结构，key 里带 group/partition）、或者用 kafka-consumer-groups --describe --members 拿 committed timestamp、或者你们有现成的 exporter 指标？给命令/指标名/伪代码都可以；
3. 边界 case：消费组"下线但注册记录还在"（我们的场景）vs "彻底删除的 group"，__consumer_offsets 里的位点分别在什么时候被清理？有没有人验证过"实例数=0 但位点还在"能撑多久？
4. 开放讨论：如果监控都做了，位点过期这件事到底该"防"还是"忍"？ 我的倾向是：核心链路的消费位点必须外置一份权威存储（比如消费完就落业务表/Redis，重启后从业务表对账而非依赖 offset），offset 只当"进度提示"。但外置存储的代价（双写一致性、对账成本）你们怎么权衡的？有没有人真的踩过"offset 丢了但业务表对账兜住了"的完整案例？

环境信息

• Kafka 3.5（KRaft，3 broker），offsets.retention.hours=168（默认值，未改过）
• 消费端：Java 17 + Spring Kafka 3.1，enable.auto.commit=false，手动批量提交
• 监控栈：Prometheus + Alertmanager + Grafana，kafka-exporter（版本不一，部分集群较老）
• 消费组规模：10+ 个，其中 3 个是每周跑一次的批处理型（这类最危险，7 天 retention 对它们形同虚设）

希望答案能落到"我能照着写进 SOP/告警规则"的程度：指标名或命令 + 阈值 + 一条 Alertmanager 规则伪代码最好。