Explore 与关联 · 桥在 UI 上落地

看板和 Explore 是互补的，对应第 0 部分那对概念：

Explore 就是第 0 部分那个“按任意维度追问下去”的 UI 化身：

看板告诉你:P99 涨了
     ↓ 点进 Explore
改查询:按 instance 切一下 → 只有 3 个 pod 慢
     ↓ 再改
这 3 个有什么共同点?→ 都在 node-7
     ↓ 换个数据源
node-7 的磁盘 IO → 饱和了

每一步都是“临时想到的”，没有任何看板预先准备了它们。 这就是为什么光有看板不够——看板是地图，Explore 是你的腿。

① 指标 → 追踪（exemplar）

Prometheus 数据源配置里：

jsonData:
  exemplarTraceIdDestinations:
    - name: trace_id          # exemplar 里的哪个字段
      datasourceUid: tempo    # 跳到哪个数据源

配好后，曲线旁边会出现小菱形点，点它 → 直接打开那条 trace。这就是“用聚合的便宜换个案入口”在 UI 上的样子。

② 追踪 → 日志

Tempo 数据源配置 tracesToLogs（现在叫 tracesToLogsV2）：

jsonData:
  tracesToLogsV2:
    datasourceUid: loki
    tags: [{ key: 'service.name', value: 'service' }]   # span 属性 → 日志标签的映射
    filterByTraceID: true      # ← 关键:只看这条 trace 的日志

在 trace 的火焰图上，每个 span 旁边有个“Logs”按钮 → 点开就是那一跳、那个时刻、那条 trace 的日志。

filterByTraceID: true 是精髓——它把“在几万条日志里翻”变成“就看这一个请求的几条”。前提是你的日志里真的有 trace_id。

③ 日志 → 追踪

Loki 数据源配置 derivedFields：

derivedFields:
  - name: TraceID
    matcherRegex: 'trace_id=(\w+)'    # 从日志里提取
    datasourceUid: tempo
    url: '$${__value.raw}'

于是日志里的 trace_id 变成一个可点的链接。

④ 追踪 → 指标 —— 靠 spanmetrics connector 生成的指标，在 Tempo 里配 tracesToMetrics。

一个残酷的现实：这些桥都要手工配置**，而且配置分散在各个数据源里。**

“我配了 exemplar 但点不了”的排查顺序：

1. 应用真的吐 exemplar 了吗？ → curl /metrics 看有没有 # {trace_id=...}。
2. 格式协商到 OpenMetrics 了吗？ → 最常见的失败点，经典文本格式会静默丢弃 exemplar。
3. Prometheus 开了 --enable-feature=exemplar-storage 吗？
4. Grafana 数据源配了 exemplarTraceIdDestinations 吗？
5. 那条 trace 真的存在吗？ → 被采样丢了？

五个环节，少一个就没有，而且大多是静默失败。 这是可观测性工程的真实写照：理念优雅，落地琐碎。

现在把这个专栏的所有东西串成一个画面——第 0 部分那个 P99 变慢的例子，完整的点击路径：

数一数这条路径用到了这个专栏的多少东西：

这就是整个专栏的意义：让这条路径从 10 分钟压缩到 5 分钟，并且不依赖“恰好有个老师傅知道该看哪”。

而如果缺了任何一环——没有 SLO 告警（不知道出事）、没有分层看板（不知道看哪）、没有 exemplar（跳不过去）、没有 trace_id（日志捞不着）、基数爆了（查询超时）——这条路径就断了，你就回到了“猜”。