Observability Signal Correlation#
Metrics 告訴你「系統出問題了」，Logs 告訴你「發生了什麼事」，Traces 告訴你「問題出在哪個環節」。三大信號各自強大，但單獨使用時都有盲點。Signal Correlation 的核心價值在於：將它們串連起來，讓你能夠順暢地從「發現異常」走到「定位根因」，不需要在不同工具之間來回切換、手動比對時間戳。
一個典型的除錯流程是：
- 什麼壞了？ — Metrics Dashboard 上看到錯誤率飆升
- 為什麼壞了？ — 跳轉到對應時段的 Logs，找到錯誤訊息
- 壞在哪裡？ — 從 Logs 中的 Trace ID 跳轉到完整的 Trace，看到是哪個下游服務逾時
這個流程要順暢運作，需要三大信號之間有明確的關聯機制。
Metrics and Logs#
Metrics → Logs 是最常見的關聯路徑。當你在 Grafana Dashboard 上發現某個服務的延遲突然飆高，下一步自然是想看「那段時間到底發生了什麼事」。
實現這個關聯的關鍵是統一的 Label 體系。如果你的 Metrics 用 service_name=order-service 標記，Logs 也用相同的 Label，那麼 Grafana 就能自動帶入篩選條件，讓你從 Metrics Panel 一鍵跳轉到 Loki 中對應時間段、對應服務的日誌。
Label 的一致性是所有 Signal Correlation 的基礎。如果 Metrics 用
service、Logs 用app、Traces 用service.name，關聯就會斷裂。在設計初期就統一命名規範，比事後修補容易得多。
這個方向的價值在於：Metrics 擅長「快速發現異常」但不包含細節，Logs 包含豐富細節但不適合用來做即時監控。兩者結合，先用 Metrics 縮小時間範圍和目標服務，再用 Logs 深入調查。
Metrics to Traces#
Metrics → Traces 讓你從指標的異常尖峰，直接找到導致該異常的具體請求。
這個關聯的關鍵技術是 Exemplar。Exemplar 是嵌入在 Metrics 資料點中的 Trace ID——當 Prometheus 記錄一個 Histogram 的觀測值時，可以同時附上產生這個值的請求的 Trace ID。在 Grafana 的圖表上，Exemplar 顯示為 Metrics 曲線上的小點；點擊它，就能直接跳轉到對應的 Trace。
Exemplar 特別適合用來調查延遲異常。當你看到 P99 延遲突然從 200ms 飆到 2s，Exemplar 讓你直接找到那些「慢請求」的 Trace，而不是在海量 Trace 中大海撈針。
沒有 Exemplar 的話，你只能靠時間範圍和 Label 去 Tempo 中搜尋，這在高流量的系統中幾乎不可能精確命中。
Traces and Logs#
Traces → Logs 是定位根因的最後一哩路。當你從 Trace 中發現某個 Span 耗時異常或回傳錯誤，下一步就是查看該請求在那個服務中的詳細日誌。
實現的方式是將 Trace ID 注入日誌。應用程式在處理每個請求時，把當前的 Trace ID 和 Span ID 寫入日誌的結構化欄位。這樣，在 Grafana 中查看某個 Trace 時，就能用 Trace ID 在 Loki 中精確查詢到該請求的所有日誌。
這個方向解決的痛點是：Trace 的 Span 通常只記錄操作名稱、耗時和狀態碼，不包含業務邏輯的細節。例如 Span 告訴你「資料庫查詢花了 3 秒」，但日誌告訴你「查詢的 SQL 是什麼、回傳了多少筆資料、為什麼慢」。
OpenTelemetry SDK 通常會自動將 Trace ID 注入到日誌框架的 MDC（Mapped Diagnostic Context）中。確認你的 Log Appender 有把 MDC 欄位輸出到日誌格式裡，這個關聯就自然建立了。
Traces to Metrics#
Traces → Metrics 是一個比較特別的方向：從 Trace 的 Span 資料中衍生出 Metrics。這就是下一章會深入討論的 Span Metrics。
核心概念是：每個 Span 天然包含了服務名稱、操作名稱、耗時、狀態碼等資訊。將大量 Span 聚合起來，就能計算出每個服務/操作的 RED Metrics：
- Rate：每秒請求數
- Error：錯誤率
- Duration：延遲分佈
這意味著如果你已經做了 Tracing Instrumentation，不需要額外埋 Metrics 程式碼，就能獲得服務層級的效能指標。OTel Collector 的 Span Metrics Processor 可以在收集管線中自動完成這個轉換。
實現 Signal Correlation 的三大前提#
要讓以上所有關聯路徑順暢運作，需要三個基礎建設：
- 統一的 Label / Attribute 體系：所有信號使用相同的服務名稱、環境標籤、版本標籤。OpenTelemetry 的 Resource Attributes 和 Semantic Conventions 提供了標準化的起點
- Trace ID 注入日誌：應用程式的日誌必須包含 Trace ID 欄位，這是 Traces ↔ Logs 關聯的橋樑
- Exemplar 支援：Metrics 中嵌入 Trace ID，這是 Metrics → Traces 關聯的橋樑。需要 Instrumentation Library、Prometheus、Grafana 三方都支援
Signal Correlation 不是「裝了工具就自動有的」功能。它需要在 Instrumentation 階段就有意識地設計：統一 Label、注入 Trace ID、啟用 Exemplar。如果事後才想加，改動成本會非常高。
Grafana 作為統一介面#
Grafana 在 Signal Correlation 中扮演的角色，不只是「好看的 Dashboard」，而是信號之間的導航中心。透過 Data Source 之間的 Link 設定，你可以在同一個介面中：
- 從 Prometheus 的 Metrics Panel 跳轉到 Loki 的 Logs
- 從 Metrics 上的 Exemplar 跳轉到 Tempo 的 Trace
- 從 Tempo 的 Trace 跳轉到 Loki 的 Logs
這種「一個平台、多個信號」的體驗，大幅降低了上下文切換的成本。不需要在三個不同的工具之間複製貼上時間戳和 Service Name，所有的交叉查詢都在 Grafana 中一氣呵成。