别等系统“凉了”才响铃：聊聊延迟敏感系统的监控与报警设计

大家好，我是 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，而是为了：

• 让问题早点暴露
• 让人更从容地处理
• 让系统别把锅甩给值班的人

八、写在最后

如果你现在正在做、或者即将做延迟敏感系统，我送你三句话：

1. 别信平均值，多看分位数
2. 别只看结果，要拆链路
3. 别只会报警，要能自救