指标监控与告警：四大黄金指标

面板很全，但没人看

监控大盘做了两百张图，CPU、内存、连接数、GC 一应俱全。故障当晚没人知道先看哪张——大家更关心的是"用户还能不能用"，而不是某台机器的 CPU。监控要从机器视角走向用户视角，这中间的桥，就是四大黄金指标。

四大黄金指标

Google SRE 给出的四件套，每个服务都要有：延迟——请求处理耗时，注意分位数（P99）比平均值诚实；流量——QPS 或业务吞吐，衡量系统压力；错误——失败请求率，5xx 与业务失败分开看；饱和度——资源余量，连接池占用、队列深度、线程池活跃度。四张图回答一个问题：用户有没有受影响，影响多大。

Prometheus：拉模型三行起步

Prometheus 定期从各服务的 /metrics 端点拉取指标，配合服务发现自动纳管新实例。业务服务先用 Micrometer 暴露框架自带指标，再逐步补业务指标（下单成功率、支付回调延迟）。常用 PromQL 两行就能覆盖核心告警场景：

# 服务 P99 延迟
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# 5xx 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  / sum(rate(http_requests_total[5m])) by (service)

告警的分级与三条纪律

告警不分级，等于没有告警：P0——核心链路不可用，电话叫醒；P1——指标异常但服务尚可，群里通知；P2——趋势劣化，日报跟进。三条纪律让告警保持可信：可行动——收到告警要有明确的下一步，否则删掉；有上下文——告警消息带上服务、指标现值、阈值、看板链接；聚合去抖——连续 N 个周期才触发，同一故障合并通知。狼来了三次之后，再真的狼也没人信了。

SLO：从机器活着到用户没受影响

在四大指标之上定义 SLO——比如"下单接口 99.9% 的请求在 500ms 内成功"。SLO 带来错误预算：一个月允许 43 分钟的额度，预算烧得快，就少发版多加固；预算充裕，可以更激进地演进——这让"要不要发版"从拍脑袋变成看数字。观测三件套（链路、日志、指标）至此凑齐，下一篇讲微服务绕不开的老话题：分布式事务在服务拆分后的落位。