基于Prometheus Counters设计SLI/SLO的技术疑问及方案咨询

关于1 - sum(rate(confirmedCounter)) / sum(rate(requestedCounter))的合理性 #

这个表达式用来建模未收到确认的请求占总发送请求的比例（即坏事件/总事件）是合理的，但有几个关键前提和注意事项：

• 前提：requestedCounter和confirmedCounter的生命周期必须对齐——每个发送的请求最终要么收到确认（confirmedCounter递增），要么永久丢失（不会后续再触发confirmedCounter）。如果存在“延迟确认”的情况（比如发送后10秒才收到确认），你需要确保rate()的时间窗口足够覆盖最大确认延迟，否则短窗口内计算会出现临时的高坏率（因为部分confirmedCounter还没上报）。
• 注意维度一致性：sum()聚合时要确保两个计数器的标签维度完全匹配（比如都带有downstream_service、endpoint等标签），避免把不相关的请求/确认数据混在一起计算，导致比例失真。

rate vs count_over_time：怎么选？ #

两者适用场景不同，没有绝对的“更合适”，得看你的SLO定义：

• 用rate()：适合长期监控请求确认的速率比例，比如实时查看当前每秒的未确认请求占比。但要注意时间窗口的选择——窗口太小会受瞬时波动影响，太大则无法反映近期的变化，建议选比最大确认延迟大1-2倍的窗口（比如确认最长延迟10秒，选[30s]窗口）。
• 用count_over_time()：适合按固定时间窗口（比如SLO的统计周期，如1小时、1天）计算总事件和坏事件的比例。比如你的SLO是“每小时内至少99.9%的请求收到确认”，那用count_over_time(requestedCounter[1h])作为总事件数，count_over_time(confirmedCounter[1h])作为成功事件数，计算1 - sum(confirmed_count) / sum(requested_count)更直接，因为它统计的是整个窗口内的总数，不会受速率波动的干扰。

给SLI/SLO新手的额外建议 #

• 先明确SLI的定义：不要上来就写PromQL，先搞清楚你的SLI是什么——比如是“成功收到下游确认的请求比例”，还是“在X秒内收到确认的请求比例”？如果是后者，仅靠这两个计数器不够，你需要补充记录请求发送到确认的延迟时间（比如用Prometheus直方图request_confirm_duration_seconds_bucket），才能计算符合延迟要求的成功比例。
• 处理计数器重置：Prometheus计数器会在实例重启时重置为0，rate()和count_over_time()都能自动处理这个，但如果实例频繁重启，建议用increase()（比如increase(requestedCounter[1h])代替count_over_time(requestedCounter[1h])），两者效果一致，但increase()更直观体现窗口内的增量。
• 拆分维度监控：不要只看全局的sum，按下游服务、业务线等维度拆分计算SLI，这样能快速定位哪个环节出了问题（比如某个下游服务的确认率特别低）。
• 验证指标准确性：手动模拟几个异常场景（比如停止下游服务，让几个请求无法收到确认），检查你的PromQL是否能正确计算出预期的坏率，避免上线后才发现指标逻辑错误。
• 设置合理的SLO阈值：不要盲目追求99.99%，先统计历史数据，看看正常情况下的确认率是多少，再设置一个比正常水平稍高的阈值（比如历史平均99.96%，SLO设为99.95%），确保SLO既有挑战性又能实现。

内容的提问来源于stack exchange，提问作者Mustang