三个信号
| 信号 | 回答 | 例子 |
|---|---|---|
| 指标 Metrics | 系统整体怎样 | QPS、错误率、P99 延迟 |
| 日志 Logs | 当时发生了什么 | 报错堆栈、关键事件 |
| 链路 Traces | 一次请求走过的路 | 跨服务耗时分布 |
怎么配合
指标告诉你「出问题了」，链路帮你「定位到哪一段」，日志告诉你「具体错在哪行」。
两个坑
- 只打日志不建指标：出事只能人肉翻日志，没法告警；
- 日志没关联 ID：一次请求跨多个服务，没有 traceId 根本串不起来。
实战案例：三次“查不到问题”的排障
- 只有日志、没有指标：故障持续两小时才由用户反馈发现。若有错误率与 P99 延迟指标，告警本可提前触发。
- 日志没有关联 ID：一次下单跨 5 个服务，没有
traceId只能按时间拼凑。接入链路追踪并在日志里带上traceId后，一次检索即可还原全链路。 - 指标维度失控：把
userId、orderId当标签，时间序列数量爆炸并拖垮存储。高基数字段只应出现在日志或链路的属性里。
常见问题（FAQ）
日志该打多少？打“可决策”的信息：入参摘要、关键分支、耗时与结果；避免整段报文和循环内日志。指标重点看哪些？黄金指标：延迟、流量、错误、饱和度。采样会不会漏掉故障？会，建议对错误与慢请求 100% 采样，正常请求按比例采样。告警怎么设才不吵？基于症状（错误率、延迟）而非单机资源指标，并设分级与抑制窗口。
落地顺序：别一次上全套
可观测性最容易失败的方式是“先买平台再想用途”。建议的顺序是：
- 先打通请求 ID：在入口生成
traceId，透传到所有下游与日志，这一步的收益最大、成本最低； - 再建四个黄金指标：延迟（P50/P95/P99）、流量、错误率、饱和度，先让“出问题能被发现”；
- 然后接链路追踪：只对关键入口采样，避免全量带来的存储与开销；
- 最后做日志治理：约定级别、字段与保留期，把变量写进结构化字段而不是拼进消息文本。
告警治理：把噪声压下去
- 基于症状而非原因：告警“下单错误率 > 2%”，而不是“某台机器 CPU > 80%”；
- 分级与抑制：P1 打电话、P2 群里通知、P3 只上一块看板；同一故障的派生告警要抑制；
- 为每个告警写清处置步骤：附上看板链接与排查命令，值班同学不必先找文档；
- 定期复盘告警量：连续无人处理的告警应降级或删除，否则会训练团队忽略所有告警。
成本与保留期
指标长期保留会线性增长，日志则更贵。常见做法是指标按“高精度短期 + 降采样长期”两级存储，日志保留 7–30 天，链路仅保留慢请求与错误请求的完整数据。
SLO 与错误预算入门
- SLI 要可测：选“成功请求占比”“P99 延迟”这类可直接从指标算出的量，而不是“用户体验好”；
- SLO 要留余量：把目标定在 99.9% 而不是 100%，剩余额度就是错误预算；
- 错误预算驱动决策：预算充足时可以加快发版，预算烧完则应冻结新功能先补稳定性；
- 窗口要区分：短窗口（1 小时）用于告警，长窗口（30 天）用于评估趋势，二者用途不同。
从告警到复盘的闭环
一次故障的完整闭环是：告警触发 → 定位（链路 + 日志）→ 缓解 → 记录时间线 → 补监控或测试。若缺少最后一步，同类故障会以同样方式复发；复盘产出的应是可执行的改进项，而不是一份“原因说明”。
日志级别的统一约定
- ERROR：需要人介入的问题，且应可告警；
- WARN：异常但可自愈，用于趋势观察；
- INFO：关键业务事件与状态变更，控制量级；
- DEBUG：排障细节，默认关闭，可按需临时打开。
约定清楚后，级别本身就携带了处置信息，值班同学不必逐条阅读。