日志、指标、链路三合一：从一次慢查询看可观测数据如何联动

三类数据为什么要放一起

传统排障是"三板斧"分开打：先在监控里看 CPU、内存、QPS，再到日志平台搜关键字，最后手动抓链路。三套系统时间线对不齐，字段命名不统一，一次线上事故经常要开三个后台来回切，光是把时间点对上就要十几分钟。

炬鲸 OBSERVE 的做法是把日志、指标、链路收进同一套数据模型，用 trace_id、span_id、service、host 这些公共字段做关联。好处很直接：你在任意一屏，都能一键跳到另外两类数据，不用再猜"这条日志到底对应哪个请求"。

这种关联不是把三个页面拼到一个入口那么简单。底层要做两件事：一是采集端统一把 trace_id 注入日志和指标标签，二是查询侧按公共字段做关联检索，保证跨数据源的查询在同一个时间窗口内是准的。

从一个慢查询告警开始

假设凌晨 2 点收到告警：订单库的 SELECT * FROM orders WHERE status = ? 平均耗时从 120ms 涨到 3.2s，P99 更夸张，到了 8s。传统流程是先连数据库看慢查询，再翻应用日志，最后才想起要看链路。我们的做法是直接从告警卡片点进去。

告警卡片自带一个 trace_id 样本，点开就是链路视图：网关 → 订单服务 → 订单 DAO → MySQL。火焰图显示 97% 的时间耗在 MySQL 的 ExecQuery 上，说明问题不在应用层，省掉了翻应用日志这一步。

日志、指标、链路怎么串起来

链路定位到"数据库慢"，下一步是搞清楚为什么慢。在 span 详情页点"关联日志"，系统按 trace_id 拉出订单服务在那段时间的日志，里面有一条慢查询日志，记录了完整 SQL 和它命中的执行计划。

再切指标：同一时间窗口下看 MySQL 实例，QPS 没涨，但 Innodb_row_lock_waits 从 0 涨到每秒 200 多次。三类信息拼起来，结论就清楚了：查询本身没变慢，是昨晚发的版本改了事务隔离级别，行锁等待把这条 SQL 拖住了。回滚配置，耗时恢复。

落地建议

1. trace_id 要在网关、服务、数据库中间件全链路透传，缺一段就断链。
2. 日志里强制打 trace_id 和 span_id，否则"关联"只是摆设。
3. 指标的 label 按 service + host 打，和链路、日志的维度对齐。
4. 采样率别一刀切，核心链路高采样，避免关联时样本缺失。

这套关联不是锦上添花。排障时间能不能从"小时"降到"分钟"，往往就差在数据能不能串起来。