背景：一次排查花了三个小时
六月一次线上下单失败，从接到告警到定位根因花了三个小时。不是问题复杂，是信息散——日志在 ELK、指标在 Prometheus、链路在 SkyWalking，三套系统各看各的，人肉拼不出完整画面。那周我推动了可观测性体系重构，把三大支柱真正串起来。
三大支柱：日志、指标、链路
可观测性的经典三分法：
- Metrics（指标）：聚合后的数值，回答「系统现在健不健康」。适合告警。
- Logging（日志）：离散事件，回答「具体发生了什么」。
- Tracing（链路）：单次请求的跨服务路径，回答「慢在哪个环节」。
三者不是替代关系，缺一个定位就断一层。过去我们只有日志和指标，链路缺失，分布式调用里卡点只能靠猜。
指标体系设计：从 RED 到 USE
服务侧用 RED 方法（Rate、Errors、Duration）定义黄金指标：
# 请求速率
sum(rate(http_server_requests_seconds_count{uri="/order"}[5m]))
# 错误率
sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m]))
/ sum(rate(http_server_requests_seconds_count[5m]))
# P99 耗时
histogram_quantile(0.99,
sum(rate(http_server_requests_seconds_bucket{uri="/order"}[5m])) by (le))
资源侧用 USE 方法（Utilization、Saturation、Errors）盯 CPU、内存、线程池。告警只挂在 RED 上，避免指标噪声。
链路打通：TraceId 串起三支柱
关键是同一个 traceId 要同时出现在指标标签、日志 MDCC 和链路上下文里。SkyWalking 9 的 Java agent 自动注入，我们在日志 pattern 里加上 %X{traceId}：
# logback-spring.xml
<pattern>%d{ISO8601} [%X{traceId}] %-5level %logger - %msg%n</pattern>
这样在 Grafana 看到某条 P99 飙升，点开就能拿到 traceId，去日志系统按它检索，再进 SkyWalking 看完整调用树，三步闭环。
故障定位效率提升
体系落地一个月后统计：同类问题平均定位时间从 180 分钟降到 22 分钟。提升来自两处——一是链路补全让卡点一眼可见（一次慢查询藏在第三个 RPC 后面，之前根本想不到），二是指标和日志用 traceId 关联后，不用在多个系统间反复切换上下文。
先到这
《可观测性建设：从日志到链路追踪的演进》这块我前前后后踩了不止一次。今天先写这些，后面想到新的再补。