云联信息：云监控的指标体系，先定 SLO 再谈告警

云监控上线之后，最常见的状态是：指标一大堆，告警一天几十条，运维看不过来，最后全部设成免打扰。这不是工具的问题，是缺少一个前提：先定义清楚服务的健康标准。有了这个标准，才知道该看什么指标、什么时候该告警、告警了谁负责。

SLO 是什么

服务等级目标，用一句话说清“在多长时间内、多少比例的用户能正常使用”。比如百分之九十九的请求在一秒内返回。有了它，监控才有参照。

从用户体验倒推指标

用户关心的是能不能打开、快不快、对不对。对应的指标是可用性、延迟、错误率。服务器 CPU 高不高，用户并不关心。

分清黄金四指标

延迟、流量、错误、饱和度，这四项能覆盖大部分服务的健康状况。指标不必多，这四项看住了，问题基本跑不掉。

告警要分级

影响面大的立即通知，影响面小的进日报。全部即时推送，等于没有优先级。分级的依据就是 SLO 的偏差程度。

用错误预算管理节奏

SLO 允许的失败额度就是错误预算。预算充足时可以多上线新功能，预算用完就该停下来修稳定性。这把技术和业务的语言统一了。

告警要能定位

一条告警只告诉“出问题了”，等于没告警。附上指标曲线、影响范围、最近变更，处理速度会快很多。

避免告警风暴

一个底层故障触发上百条告警，运维根本看不过来。做告警收敛和依赖抑制，把根因告警顶到最前面。

监控覆盖要补齐

只监控服务器，不监控业务链路，出了问题只能猜。关键路径的每一步都要有指标，包括第三方接口。

日志和指标要能关联

看到指标异常，能一键跳到对应时段的日志和调用链。分开查，排查时间会翻倍。

定期复盘告警质量

统计一个月内有多少告警是真的、多少是误报、平均响应多久。误报率高的规则，要么改阈值要么删掉。

把 SLO 写进复盘

每次故障复盘都对着 SLO 看：影响了多少预算、下次怎么避免。没有这个参照，复盘容易变成追责会。

从最重要的一个服务开始

不要一次给所有服务定 SLO。先选用户感知最强的那一个，跑三个月，再推广。

指标口径要写清楚

成功率算不算客户端断开、延迟算不算网络时间，口径不同结论就不同。写在文档里，避免各自解读。

和业务方一起定

技术定的 SLO 业务未必认可。拉着业务一起讨论可接受的失败比例，后面才好推动资源投入。

定期校准

业务变化后，原来的 SLO 可能过严或者过松。每季度看一次实际达成率，及时调整。

监控的价值不在指标数量，而在能不能快速回答“现在服务正常吗”。先定 SLO，再选指标，最后配告警，顺序对了才不白折腾。云联信息【资深云服务专家微信：cloud7591】，我们做可观测性梳理时，第一件事是让客户用一句话描述服务正常的样子。