4、指标监控体系：四大黄金信号

说实话，做SRE这么多年，我踩过最大的坑就是——指标太多，重点全丢。你想想看，一个订单系统几百个指标，CPU、内存、线程数、GC次数……全堆在Grafana上，出了事根本不知道看哪张图。

后来我学乖了。Google的SRE圣经里提过四个黄金信号，我把它当成监控的「宪法」。说白了，你只要盯住这四个维度，90%的根因都能在30秒内圈定范围。今天我就把这套打法拆开揉碎讲给你。

4.1 四大黄金信号：到底盯什么？

这四个信号不是拍脑袋定的。我经历过一次线上事故，订单延迟从50ms飙到3s，第一反应是看CPU——结果CPU才30%。后来发现是数据库连接池被打满了，这就是典型的「饱和度」问题。所以四个信号必须一起看。

信号	核心含义	订单场景举例	我常用的指标
延迟	请求处理耗时	下单接口P99延迟	http_request_duration_seconds
流量	系统负载压力	每秒订单创建数	http_requests_total
错误	失败请求比例	下单失败率 > 1%	http_requests_errors_total
饱和度	资源耗尽程度	数据库连接池使用率	db_connections_used / max

4.2 Prometheus指标采集：怎么收？

Prometheus是我最顺手的工具。它拉取指标的方式，说白了就是「定时去你家门口拿快递」。你只需要在服务里暴露一个/metrics端点，Prometheus每15秒来取一次。

我习惯把指标分成三类：

• Counter：只增不减，比如请求总数、错误总数。适合看速率。
• Gauge：可增可减，比如内存使用量、连接数。适合看当前值。
• Histogram：分布统计，比如请求延迟的P50/P90/P99。这个最有用。

给你看一段我实际在订单服务里用的采集配置：

# 订单服务 metrics 端点暴露示例 (Go + Prometheus client)
http.Handle("/metrics", promhttp.Handler())

// 自定义指标：订单创建延迟直方图
orderCreateDuration := prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name:    "order_create_duration_seconds",
        Help:    "订单创建耗时分布",
        Buckets: []float64{0.01, 0.05, 0.1, 0.5, 1, 2, 5},
    },
    []string{"status", "payment_method"},
)
prometheus.MustRegister(orderCreateDuration)

4.3 Grafana看板设计：一眼看出问题

Grafana看板不是堆图表。我见过最烂的看板——一个页面放了40张图，滚动三屏都看不到底。出了事，运维小哥得拿放大镜找。

我的设计原则只有三条：

1. 从上到下，按黄金信号分层。第一行放延迟和错误，第二行放流量和饱和度。
2. 红色警报放左边。人眼习惯从左往右扫，最重要的错误率、P99延迟放左上角。
3. 每个面板只放一个指标。别把CPU和内存画在一张图上，混在一起谁也看不清。

下面是我为订单延迟做的看板JSON片段（核心部分）：

{
  "title": "订单执行延迟 · 黄金信号看板",
  "panels": [
    {
      "title": "P99 延迟 (最近1小时)",
      "type": "graph",
      "targets": [{
        "expr": "histogram_quantile(0.99, 
          rate(order_create_duration_seconds_bucket[5m]))",
        "legendFormat": "P99"
      }],
      "yaxis": {"unit": "s"}
    },
    {
      "title": "错误率",
      "type": "graph",
      "targets": [{
        "expr": "rate(order_create_errors_total[5m]) 
          / rate(order_create_total[5m]) * 100",
        "legendFormat": "错误率%"
      }]
    }
  ]
}

4.4 实战：订单延迟根因定位的监控组合拳

假设你现在看到Grafana上订单P99延迟从100ms涨到了800ms。别慌，按这个顺序查：

• 第一步：看错误率。如果错误率也涨了，大概率是下游服务挂了（比如支付网关超时）。
• 第二步：看流量。如果QPS翻倍了，那就是促销流量导致延迟增加，加机器就行。
• 第三步：看饱和度。如果数据库连接池使用率到了95%，那就是连接不够，要么扩连接池，要么优化SQL。
• 第四步：看延迟分布。用Histogram看是P50涨了还是P99涨了。P50涨说明普遍慢，P99涨说明有长尾请求。

我记得有一次，P99涨到1.2s，但P50只有80ms。我一看Histogram，发现有个别请求耗时超过5s。顺着trace一查，是某个订单触发了库存锁重试。这就是长尾问题的典型特征。