05 · 可观测性基础设施：日志/指标/告警
发布只是开始，线上到底怎么样靠可观测性回答。本篇讲日志、指标、告警三件套怎么搭、怎么定告警规则、怎么控制成本。先给结论：可观测性不是"多上几个监控系统"，而是三个信号（日志/指标/追踪）各有分工，加上"会叫的告警"。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 把"线上发生了什么"变成可查询、可告警、可追溯的基础设施 |
| 核心内容 | 三信号分工、日志采集、指标与 SLO、告警规则、成本与演进 |
| 读完能回答 | 日志、指标、追踪各解决什么？告警怎么定才不吵又不漏？ |
| 相关板块 | C08 · 可观测性 ｜ D04 · Linux 入门 ｜ A12 · 前端可观测性 |
一、先给结论：三个信号，各管一段
| 信号 | 回答 | 类比前端 |
|---|---|---|
| 日志 | 具体某次发生了什么 | console.log + 上报 |
| 指标 | 现在整体什么水位 | 性能面板的曲线 |
| 追踪 | 一次请求经过了哪些服务 | 接口调用链 |
一句话：指标告诉你"变慢了"，日志告诉你"为什么慢"，追踪告诉你"慢在哪一环"。三者配合才是可观测。
二、日志：采集、结构化、检索
2.1 采集路径
text
应用打 stdout → 采集器（如 Vector/Fluent Bit）→ 存储（Loki/ES）→ 查询面板2.2 结构化日志
json
{"ts":"2026-10-13T10:00:00Z","level":"ERROR","service":"order-api","trace_id":"abc","msg":"order failed"}| 要点 | 说明 |
|---|---|
| JSON 结构化 | 方便按字段检索，别纯文本拼字符串 |
带 trace_id | 关联请求与追踪，跨服务串起来 |
| 级别收敛 | ERROR 才告警，DEBUG 别进生产 |
| 不落敏感信息 | 手机号/密码脱敏（见 S05） |
成本意识：日志存量大、检索慢、贵。给日志设保留期（如 30 天）和采样策略（如 DEBUG 不存），别把全量日志当指标用。
三、指标与 SLO：把"健康"定义出来
3.1 黄金四信号
| 信号 | 含义 |
|---|---|
| 延迟 | 请求多快返回（分位如 p95） |
| 流量 | 每秒多少请求 |
| 错误 | 5xx/4xx 比例 |
| 饱和度 | CPU/内存/连接是否快满 |
3.2 SLO 是把体验变成数字
text
目标：99.9% 的请求 p95 延迟 < 500ms| 概念 | 说明 |
|---|---|
| SLI | 实际测到的指标（p95 延迟） |
| SLO | 目标承诺（99.9% 达标） |
| 错误预算 | 允许出错的额度，用完了要收敛发布 |
为什么 SLO 有用：它把"我们要多稳定"量化，让团队能回答"这周能不能发版"。
四、告警：会叫但不吵
4.1 告警原则
text
告警 = 需要人行动的异常，不是"信息"| 坏告警 | 好告警 |
|---|---|
| 磁盘 > 50% 就报警 | 磁盘 > 85% 且持续 15 分钟才报 |
| 每台机都单独报 | 服务维度聚合，去重 |
| 只有触发没有说明 | 附 runbook：先看什么、找谁、怎么缓解 |
4.2 告警四问
- 这个信号变化代表用户体验受损吗？
- 触发后人有明确动作吗？
- 有对应的排查文档/runbook 吗？
- 会误报还是漏报？怎么调阈值？
告警疲劳是真实风险：报警太多，人会选择性无视。宁可少而准，配 runbook。
五、追踪：跨服务定位慢请求
text
一次下单 → API 网关 → 订单服务 → 支付服务 → 数据库
每段都记录 trace_id 与耗时| 术语 | 含义 |
|---|---|
| Trace | 一次完整请求 |
| Span | 其中一段（一个服务/一次 DB 调用） |
| Trace ID | 贯穿全链路的标识 |
前端对照：像 DevTools 的 Performance 面板，只是跨了进程。后端排障"接口慢"时，先看追踪找最慢的 span，而不是猜。
六、落地与成本：从最小可行开始
| 阶段 | 做什么 | 工具示例 |
|---|---|---|
| 1 | 结构化日志 + 查询 | Loki + Grafana |
| 2 | 关键指标 + 基础告警 | Prometheus + Alertmanager |
| 3 | 请求追踪 | OpenTelemetry + Jaeger/Tempo |
| 4 | SLO 与错误预算 | 指标 + 告警联动 |
演进原则：先解决"出事了能查到"，再谈 SLO。别一上来就上全家桶，成本和维护会压垮小团队。
七、自检清单
- [ ] 日志结构化、带 trace_id、不落敏感信息
- [ ] 有保留期与采样策略，成本可控
- [ ] 定义了黄金四信号与至少一个 SLO
- [ ] 告警少而准，每条带 runbook
- [ ] 慢请求能靠追踪定位到具体服务/调用
八、常见误区
| 误区 | 事实 |
|---|---|
| "监控系统多就是可观测" | 三信号配合 + 会叫的告警才是 |
| "日志能当指标用" | 日志量大且不聚合，做指标成本高且慢 |
| "告警越多越安全" | 告警疲劳会让真告警被忽略 |
| "SLO 是运维的 KPI" | 它是让团队统一"稳定"定义的契约 |
| "追踪是微服务才需要" | 单体里的慢 SQL/慢调用同样值得追踪 |
九、动手练习
练习 A：日志结构化改造
把自己服务的日志输出改成 JSON 格式，加 trace_id 与级别字段，用查询面板按字段过滤。
练习 B：定一条告警
选一个关键指标（如 5xx 比例），设计阈值、持续时间、runbook 三项，说清为什么这样定。
练习 C：接一次追踪
给一个二服务调用的 demo 接 OpenTelemetry，模拟慢请求，用追踪图指出最慢的 span。
相关文档
本区
- 04 · Linux 服务器入门 —— 单机日志与系统排障
- 02 · 部署与 CI/CD —— 发布后的健康检查与监控确认
- D 域 README
其他域
- C08 · 可观测性 —— 后端观测三件套
- C12 · 错误处理日志与配置 —— 日志规范与配置
- A12 · 前端可观测性与线上排障 —— 前端侧观测对照
- S05 · 数据与隐私合规 —— 日志脱敏与留存