运维进阶：构建可观测性体系

从「监控」到「可观测性」

传统监控回答的是「已知的问题发生了吗」——你预先想到了指标，配了阈值。

可观测性回答的是「我不知道的问题，能不能被解释」——面对任意异常，能否通过已有数据推断出根因。

维度	传统监控	可观测性
关注点	已知故障	未知异常
数据	指标阈值	指标 + 日志 + 链路
提问方式	是不是超阈值了	为什么会这样
面向	运维	研发 + 运维

三大支柱

1. Metrics —— 告诉你「出问题了」

指标是聚合的、低成本的、长期存储的。适合做趋势与告警。

必须覆盖的四类（Google SRE 黄金指标）：

指标	含义	典型实现
Latency	请求延迟（区分成功/失败）	`histogram_quantile`
Traffic	请求量	QPS 计数器
Errors	错误率	5xx 计数 / 总请求数
Saturation	饱和度	CPU、内存、队列深度

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

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

经验：告警要基于「用户可感知的症状」（错误率、延迟），而不是「机器指标」（CPU 80%）。CPU 高但服务正常，不该半夜叫醒人。

2. Logging —— 告诉你「为什么」

日志是事件级别的、高成本的。关键是结构化。

{"ts":"2026-10-15T10:23:01Z","level":"error","trace_id":"abc123",
 "service":"order","msg":"payment timeout","order_id":"9527","latency_ms":3002}

结构化日志的三个好处：

可被机器解析，能按字段聚合（例如「按 order_id 统计失败次数」）；
trace_id 打通与链路的关联；
便于做日志采样与成本控制。

成本控制：日志量往往是指标的上百倍。分级存储 + 采样是必须的。

级别	保留策略
DEBUG	生产默认关闭，需要时按需开启
INFO	采样存储，保留 7 天
WARN / ERROR	全量存储，保留 30 天

3. Tracing —— 告诉你「慢在哪」

一条请求跨越多个服务时，只有链路能告诉你时间花在了哪一跳。

# OpenTelemetry 采样策略
processors:
  probabilistic_sampler:
    sampling_percentage: 10   # 正常流量采样 10%
  tail_sampling:              # 尾部采样：错误请求 100% 保留
    policies:
      - name: errors
        type: status_code
        status_code: {status_codes: [ERROR]}

尾部采样（tail sampling） 是关键技巧：正常请求只留 10%，但错误和慢请求全留。这样既有代表性，又不会淹没在数据里。

落地顺序（重要）

不要一上来就上全套。推荐顺序：

先做 Metrics（1-2 周）——投入产出比最高，立刻能发现明显问题。
再做结构化日志 + 关键字告警（2-3 周）。
最后做 Tracing（1 个月以上）——需要全链路改造，成本最高。

理由：Metrics 能独立生效；Tracing 需要每个服务都埋点，改造周期长。顺序错了会导致长期投入却看不到收益。

告警治理：避免「狼来了」

告警疲劳是监控体系最大的敌人。三条纪律：

只有需要人立刻行动的事才告警，其余进日报。
每条告警必须有 Runbook（处理手册），否则就是噪音。
定期复盘告警：连续两周未被处理的告警，要么降级，要么删除。

# Alertmanager 分组与抑制
route:
  group_by: [alertname, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h        # 避免重复轰炸
inhibit_rules:
  - source_matchers: [severity="critical"]
    target_matchers: [severity="warning"]
    equal: [service]         # 严重告警存在时抑制同服务的警告

成熟的标志

故障发生前，监控已经告警；
收到告警时，看板能直接指出大致范围；
事后复盘，能通过数据还原完整时间线；
团队不再说「用户反馈后我们才知道」。

小结

可观测性 ≠ 更多监控，而是能用数据回答任意问题。
落地要按 Metrics → Logging → Tracing 的顺序，别贪快。
告警的目标是「精准」，不是「全面」。