日志分级与可观测性三支柱

「系统出问题了」之后的第一个动作永远是看数据。可观测性三大支柱各自回答一个不同的问题。

三支柱的分工

日志（Logs）：离散事件的详细记录。回答「发生了什么」。 指标（Metrics）：数值时间序列（QPS、延迟、错误率）。回答「系统健康吗」，存储便宜、适合告警。 链路追踪（Tracing）：一个请求跨服务的完整路径。回答「慢在哪、错在哪一跳」。

三者不是替代关系。告警靠指标，定位靠追踪，取证靠日志。

日志分级的使用纪律

• ERROR：需要人介入的异常。用了它就要有告警接住，否则降级为 WARN；
• WARN：可自动恢复但值得注意（重试成功、降级触发）；
• INFO：关键业务动作（下单、支付、登录），一条事件一行；
• DEBUG：排障细节，生产默认关闭，按需动态开启。

最常见的反模式：用 ERROR 打印普通业务失败（「用户密码错误」），告警群被淹没后，真错误反而没人看。

结构化日志

{"ts":"2026-09-01T10:00:00+08:00","level":"info","event":"order.created",
 "order_id":"20260901...","user_id":42,"amount":99.00,"trace_id":"a1b2c3"}

• 一行一事件、JSON 格式，机器可查询；
• trace_id 贯穿：入口生成，跨服务、跨线程透传，是串起日志与追踪的钥匙；
• 事件名用稳定标识（order.created），不写自由文本句子。

打日志的三个判断

1. 这条日志在什么场景下会被查？ 答不出来就别打；
2. 出问题时，靠现有日志能否还原现场？ 关键分支（权限拒绝、外部调用失败）必须有；
3. 敏感信息进日志了吗？ 密码、令牌、身份证号脱敏，日志库的权限通常更松。

从哪里开始

没有全套 APM 也能起步：先把「指标」（哪怕只是访问日志聚合出的 QPS/错误率）和「结构化日志 + trace_id」做好，这两样覆盖 80% 的排障场景。链路追踪等微服务数量真正多起来再上。