微批管道的告警天生「晚一批」：批窗口内的 leading 指标怎么设计，才能在预算耗尽前而不是批跑完后才响？

【背景】 我负责一条 B 端 SaaS 的指标看板链路：业务事件 → Kafka → Flink 微批聚合（批窗口 30s，每批一个调度 tick）→ ClickHouse（2.x LTS）→ 业务看板。业务方 SLA 是「事件发生后 90s 内可查」。SLI 锚点（用 broker 到达时间而非业务事件时间）我参考了 #1893 的讨论已经定下来，告警阈值也按历史批时长 P99 反推过（方法同 #2073），落地形态参考了 #2275 那篇 burn rate 的做法。

【现象：从现象倒推，卡点在「批的离散性」】 1）我们的告警锚点只能落在「一批完成、结果可查」这个时刻——也就是说，第 N 批超时，最早也要等第 N 批跑完（最坏 30s）+ 检测周期才能发现。用户其实已经在「数据不刷新」了，告警才响，发现时点 = 用户感知时点 + 一批窗口，这在值班复盘里被业务方直接点名：「你们告警比用户还慢」。 2）试过把检测周期压到 5s 轮询 now - max(可查事件时间)，误报立刻上来：批窗口本身就是 30s 的结构性延迟，批没跑完时这个值天然在 30~90s 之间爬升，阈值卡在哪里都会和「批正常执行中」的窗口打架——和 #2076 问的迟到数据解耦是同一类问题，但我的场景更极端：不是迟到数据，而是批本身就还没跑完。 3）burn rate 那套（#2275）本质还是对「已完成批」的预算消耗速率做外推，对连续流有效，但对我们这种「30s 一跳」的离散批，两个窗口的样本各只有 2~3 个批，统计上基本没有意义。

【已尝试与结果】

• 轮询可查时间戳 + 固定阈值：误报/漏报二选一，放弃；
• 双窗口 burn rate：样本量不足，放弃；
• 目前只能靠 Flink 的 batch 执行时长 histogram 做「上一批超 P99 就预警」——这是 trailing 指标，晚一批，正是业务方吐槽的那个。

【期望得到的答案形态】 1）批窗口内的 leading 信号有哪些是可用的：比如 Flink batch 执行进度（已处理 record 数 / 本批总量）、调度器 tick 是否已触发、Kafka consumer lag 的批内斜率——你们线上实际用哪个？ 2）怎么把「批内进度」和「剩余预算」结合成一条可计算的预警规则（能给公式或伪代码更好），而不是拍一个「批跑到 50% 还没完就报警」的百分比； 3）如果批内没有可用进度信号（黑盒任务，只有开始/结束两个事件），退而求其次的「批开始时刻 vs 计划时刻」偏移告警，阈值怎么定才不把调度抖动和真实故障分开。

有同类链路（微批 + 秒级新鲜度 SLA）踩过这个坑的，欢迎带具体参数来聊。