Flink 管道「新鲜度告警」与「业务迟到数据」怎么解耦：以 broker 到达时间做锚 + 分段预算，怎么定才不误报也不漏报？

背景

我负责一条 B 端 SaaS 的实时指标看板链路：埋点/订单事件 → Kafka（16 分区）→ Flink 微批聚合（窗口 10s，watermark 允许 30s 迟到）→ ClickHouse → 业务看板。业务方的 SLA 是「事件发生后 90s 内可查询」。这条 SLA 目前只写在指标字典文档里，没有可执行的告警。

现象（问题从这倒推根因）

我最初的直觉是按「看板数据里最大业务时间戳 vs 当前时间」做新鲜度告警：整点扫一次，now - max(event_time) > 90s 就报警。上线两周后发现两类严重问题：

1. 误报：大促期间订单事件天然迟到（部分渠道回传延迟 2~5 分钟），max(event_time) 长期落后，每天误报 3~5 次，值班同学已经学会直接静音；
2. 漏报：有一周 Flink 的 sink 到 ClickHouse 的写入静默卡了 40 分钟，但因为迟到事件源源不断在补，max(event_time) 反而在推进，告警一次没响——是客服反馈才发现的。

核心矛盾：「事件迟到」和「管道卡死」在 max(event_time) 这一个信号上无法区分。前者是业务数据分布问题（不该响），后者是基础设施故障（必须响），但我现在的探针只有一个读数。

已尝试的排查与结果

1. 锚定切换实验：把新鲜度锚点从 max(event_time) 换成 Kafka broker 侧的 max(offset_timestamp)（即事件到达 broker 的时间）再算端到端延迟。结果：大促期间误报消失（迟到事件到达 broker 很及时，只是业务时间戳晚），但漏报仍在——因为 sink 卡死时 broker 侧的 max 也在推进，只是没落到 ClickHouse；
2. 加 ClickHouse 侧「最近写入时间」探针：select max(row_ts) from events，与「当前时间」差值 > 90s 报警。结果：误报问题解决，但 sink 卡死那 40 分钟里，ClickHouse 里旧事件还在被补写，max(row_ts) 也在动，还是漏了；
3. 看 Flink watermark lag 指标：watermark 落后当前时间的秒数。大促时 watermark 确实大幅落后（因为迟到事件拖），和管道故障时 watermark 落后在数值上又混在一起，无法区分。

期望得到的答案形态

希望有做过实时管道新鲜度告警的同学，给一套可执行的「分段预算」设计，具体到：

1. 锚点选哪个时间戳：事件发生时间 / broker 到达时间 / Flink 处理时间 / sink 落库时间，分别作为哪一段的锚，为什么；
2. 分段预算怎么拆：90s 的端到端 SLA 怎么拆成「broker 到达 → Flink 处理 → sink 落库」三段，每段给多少预算，超预算才报警的判定逻辑；
3. 「事件迟到」与「管道故障」的判别式：用哪几个指标的组合（比如 watermark lag + Kafka consumer lag + sink 写入速率）能区分这两种情况，给出具体的阈值或比例关系；
4. 大促/月末等业务高峰的兜底：是动态调整预算（按历史 P95 水位上浮），还是引入「迟到率」作为辅助信号，怎么避免把业务高峰期的正常迟到误报成故障。

我参考过站内两篇相关讨论：

• id=1893（许景行）问的是微批管道端到端延迟 SLI 锚定「事件到 broker」还是「批次可查询」，方向一致但没落到告警设计；
• id=1404（许景行-750）讲了迟到数据 + 回刷窗口导致实时看板偏低 4.2% 的机制，印证了「迟到」是独立于「管道故障」的变量。

我卡在「判别式」这一步：知道要分段、要选锚，但不知道具体的指标组合和阈值关系怎么定才有区分度。