让花费告警真的在余额见底前响：一把聚合站 key 上的阈值怎么设

花费告警失效，通常不是告警工具不好，而是阈值拍脑袋定的。要么设得太松，余额见底才响；要么设得太紧，天天误报最后被静音。这篇讲一个可落地的做法：从真实调用量反推每日阈值，再接一个自动轮询用量的探针。

先理解聚合站的计费口径

在这类聚合站上，你用一把 key 调多个模型，扣费口径是「官方价 × 1.3」。这意味着同一份 token 量，落到不同模型上花费差别很大，单纯按请求数设阈值没有意义。

所以阈值的基本单位应该是「金额」，而不是「次数」。你要盯的是这把 key 当天已经扣掉多少钱、还剩多少余额。

从真实调用量反推每日阈值

不要先定阈值再看用量，顺序反过来：

1. 取一段有代表性的历史窗口，覆盖你的日常波动，比如最近两周的正常工作日。
2. 统计这把 key 每天的实际扣费，得到日花费的分布，而不是只看平均值。
3. 找出高分位的那一天（比如最忙的那天），把它当作「正常上限」。阈值应该落在这个上限之上一点，而不是平均值附近。
4. 用余额反算安全天数：当前余额 ÷ 日均花费 = 还能撑几天。如果这个天数小于你补余额所需的时间（充值到账、审批、换 key 等），说明阈值要更早触发。

一个实用的双层阈值：

• 预警线：日花费接近历史高分位时触发，提醒你「今天用量异常」或「该看余额了」。
• 硬线：余额低于 N 天日均花费时触发，这个 N 取决于你补余额的周转时间。

两层分开，是因为它们回答的是不同问题：一层管用量异常，一层管余额风险。

把阈值接到自动探针上

人工盯面板的问题是，你不会一直盯。探针要做的是定时拉取用量，自己比对阈值。

探针的结构很简单：

• 定时触发：用 cron、定时任务或你现有 CI 的 schedule，按固定间隔跑一次。频率不用太高，能覆盖你的补余额周转时间即可。
• 拉取用量：调用聚合站提供的用量或余额查询接口，拿到这把 key 的当日花费和剩余余额。
• 比对阈值：把当日花费和余额分别对照预警线、硬线。
• 发出告警：命中就推送到你实际会看的地方（IM、邮件、工单），并带上当前数值和阈值，方便判断。

关键点：探针只读用量数据，不做写操作，也不需要把 key 暴露在告警消息里。

几个容易踩的坑

• 按 UTC 还是本地时区切日：接口返回的「当日」口径要和你的阈值口径一致，否则跨时区会误判。
• 告警去重：硬线触发后，如果探针每轮都发，很快就会被忽略。同一天同一类告警只发一次，或按状态变化发。
• 阈值随用量漂移：业务量变了，历史高分位就过时了。每隔一段时间用新的真实数据重算一次，别让阈值固定死。
• 多把 key 分开算：如果你有多把 key，阈值和余额要分开监控，别混在一起算平均。

一句话总结

阈值从真实扣费分布里来，不从感觉里来；探针定时拉用量、比对、推送，把「盯面板」换成「面板来找你」。在官方价 × 1.3 的扣费口径下，盯金额比盯次数可靠得多。