系统出故障时，最怕的不是报错，而是“看不见发生了什么”。
很多服务上线后只有零散日志，出了问题只能猜，这会大幅拉长恢复时间。
三件基础能力要同时具备
- 日志：还原具体请求上下文
- 指标：观察整体趋势与容量变化
- 链路：定位跨服务调用瓶颈
三者缺一不可。
日志该怎么写
建议从第一天就采用结构化日志：
- 必带
traceId、requestId、userId（有则带） - 错误日志带业务上下文，不只打印异常堆栈
- 统一字段命名，避免后续检索困难
日志如果不结构化，后续排查会非常痛苦。
指标要有层级
至少覆盖三层：
- 业务指标：下单成功率、支付成功率
- 服务指标：QPS、延迟、错误率
- 资源指标：CPU、内存、连接池、线程池
层级齐全后，才能区分“业务异常”还是“基础设施瓶颈”。
链路追踪的价值
当一个请求经过多个微服务时，链路追踪能直接告诉你：
- 慢在第几跳
- 慢在数据库、外部依赖还是业务逻辑
- 错误是在哪里首次出现
这比逐个服务翻日志高效得多。
小结
可观测性本质上是系统“自解释能力”。
当系统规模上来后，这套能力会直接决定故障恢复速度和团队信心。