别等系统“凉了”才响铃：聊聊延迟敏感系统的监控与报警设计
大家好，我是 Echo_Wish。
如果你做的是离线数仓，昨天的任务今天修，问题不大；
但如果你碰的是延迟敏感系统——实时风控、实时推荐、在线交易、实时画像、广告竞价、流计算……
一句话总结就是：
慢 100ms，业务可能没感觉；
慢 1 秒，老板开始问；
慢 5 秒，监控还没报警，你已经开始背锅了。
所以今天我想聊的不是“监控怎么搭 Prometheus”，也不是“报警规则怎么写 YAML”，而是延迟敏感系统，到底应该怎么“盯”才算盯对了。
一、先泼一盆冷水：大多数系统不是挂死的，是“慢死的”
我见过太多线上事故，都是这种剧本：
- CPU 没爆
- 内存没满
- QPS 看着也还行
- 服务没 500
- 但是用户开始骂了
为啥？
👉 延迟在悄悄变大
而很多系统的监控是这样设计的：
“只要服务没挂，我就当它活着。”
这在延迟敏感系统里，是致命认知错误。
二、什么叫延迟敏感系统？别只盯“平均值”
一句话定义：
用户或下游系统，对响应时间极其敏感的系统
但这里有一个巨坑：
平均延迟（avg latency）几乎没啥用
举个真实又残酷的例子：
- 90% 请求：20ms
- 9% 请求：200ms
- 1% 请求：5 秒
平均值算下来可能才 80ms，监控面板一片绿。
但你猜那 1% 是谁？
👉 高价值用户 / 大客户 / 核心风控请求
所以延迟敏感系统，第一条铁律：
别用平均值骗自己
三、监控设计的第一原则：分位数，比均值值钱
真正有用的延迟监控，至少要盯这几个：
- P50：系统“日常体感”
- P90 / P95：开始影响用户体验
- P99 / P999：事故的前兆
举个 Prometheus 里常见的 Histogram 用法（示意）：
histogram_quantile(
0.99,
sum(rate(http_request_duration_seconds_bucket[1m])) by (le)
)
我自己的习惯是：
- P50：看趋势
- P95：设一级报警
- P99：设强报警 + 自动降级
记住一句话：
P99 是系统良心指标，P999 是系统底线。
四、延迟不是一个点，是一条“链”
很多人一提监控，就只盯接口延迟。
但在延迟敏感系统里，这远远不够。
一次请求的延迟，往往长这样：
入口 → 网关 → 服务A → MQ → 服务B → 存储 → 返回
你只盯“总耗时”，等报警了你只会懵：
“慢了，但慢在哪？”
所以监控设计要拆链路。
我强烈建议至少拆成三层：
1️⃣ 接口级延迟（用户视角）
- API / RPC / HTTP
- P95、P99
2️⃣ 关键中间件延迟
- MQ 堆积时间
- Kafka consumer lag
- Redis / HBase / ES 响应时间
3️⃣ 内部处理阶段延迟（埋点）
简单示意一下代码里的做法（伪代码）：
long t1 = System.currentTimeMillis();
fetchFromCache();
metric.record("stage.cache", System.currentTimeMillis() - t1);
long t2 = System.currentTimeMillis();
queryDB();
metric.record("stage.db", System.currentTimeMillis() - t2);
别嫌麻烦，这种埋点事故时能救命。
五、报警不是越多越好，是“该响才响”
说句得罪人的话：
80% 的报警系统，最后都会被静音
为什么？
- 半夜响
- 白天响
- 周末响
- 啥都响
- 还经常是误报
最后的结局就是：
真正出事的时候，大家已经对报警免疫了
我自己总结的报警三原则：
原则一：报警要“贴业务”
不要只报：
“P99 延迟 > 2s”
而是：
“支付接口 P99 延迟 > 2s，影响订单成功率”
人是对业务损失敏感的，不是对指标敏感。
原则二：报警要有“持续性”
瞬时抖动，没必要把人叫醒。
推荐逻辑：
- 连续 3 分钟
- 或 5 分钟内 4 次超阈值
示意规则：
P99_latency > 2000ms
持续 3 分钟
原则三：报警要分级
我一般这样分：
- P95 超阈值：钉钉 / 飞书提醒
- P99 超阈值：电话 / 短信
- P999 + QPS 下降：自动降级 + 全员拉群
不是每个问题，都值得把人从床上叫起来
六、延迟报警，必须配“自救机制”
这是我非常强调的一点：
没有自愈能力的报警，只是在宣布你要加班了
延迟敏感系统，至少要准备：
- 自动熔断
- 自动降级
- 超时快速失败
- 兜底结果
比如：
if (latencyP99 > threshold) {
enableFallback();
}
哪怕兜底结果不完美，也比一直卡着强。
七、我自己的一个真实感受
说点不那么“技术”的。
刚开始做实时系统那几年，我也迷信“机器指标”，CPU、内存、磁盘一把抓。
后来被线上事故教做人后才明白：
用户感受到的慢，才是真正的慢。
监控和报警不是为了好看，不是为了 KPI，而是为了：
- 让问题早点暴露
- 让人更从容地处理
- 让系统别把锅甩给值班的人
八、写在最后
如果你现在正在做、或者即将做延迟敏感系统，我送你三句话：
- 别信平均值，多看分位数
- 别只看结果，要拆链路
- 别只会报警，要能自救
