OpenTelemetry 是什麼？#

OpenTelemetry（簡稱 OTel）是 CNCF 的可觀測性統一標準，提供一套廠商中立的 API、SDK 和工具，用來產生、收集和匯出 Traces、Metrics、Logs 三種可觀測性信號。

它的核心承諾很簡單：你只需要埋點一次，資料可以送往任何後端。不管你今天用 Jaeger、明天換 Tempo、後天上 Datadog，應用程式的 Instrumentation 程式碼完全不需要改。

OTel 是 OpenTracing 和 OpenCensus 兩個專案合併的產物，是 CNCF 中活躍度僅次於 Kubernetes 的專案。這不只是技術優勢，更代表了生態系的保證——幾乎所有主流的可觀測性後端都已原生支援 OTLP（OpenTelemetry Protocol）。

三種 Instrumentation 層級#

OpenTelemetry 提供三種不同深度的埋點方式，它們不是互斥的，而是可以組合使用：

Zero-code Instrumentation（自動埋點）#

不改任何程式碼，透過 Agent 或自動注入機制，攔截框架層級的操作並自動產生 Span。

  • Java：使用 Java Agent（-javaagent:opentelemetry-javaagent.jar），在 JVM 層級攔截 HTTP、gRPC、JDBC 等呼叫
  • Python：使用 opentelemetry-instrument 命令包裝應用程式啟動，自動注入常見框架的 Hook
  • .NET：透過 .NET Instrumentation 套件自動注入
  • Node.js：透過 @opentelemetry/auto-instrumentations-node 在 require 層級攔截

Library-level Instrumentation（框架整合）#

框架或函式庫自帶的 OTel 整合。例如 Spring Boot 的 Micrometer Tracing、Express.js 的 OTel Middleware。你需要加入相依套件，但不需要手動建立 Span。

Manual Instrumentation（手動埋點）#

開發者自行建立 Span，記錄業務邏輯中的關鍵操作。例如追蹤「計算折扣」或「產生推薦結果」這類不會被自動埋點涵蓋的邏輯。

實務上最常見的做法是 Zero-code 打底 + Manual 補強。先用 Zero-code 取得框架層級的完整追蹤（HTTP、資料庫、快取），再針對核心業務邏輯手動加上 Span。這樣能以最小的成本取得最大的可觀測性。

Zero-code Instrumentation 為什麼如此重要？#

Zero-code 的價值不只是技術上的便利，更是組織層面的突破：

  • 導入門檻趨近於零：不需要每個開發者都理解 Tracing 的概念，運維團隊就能替整個系統開啟追蹤
  • 涵蓋面廣：自動攔截 HTTP Client/Server、資料庫驅動、訊息佇列 Client 等常見操作，第一天就能看到完整的服務調用鏈
  • 一致性：所有服務用同樣的方式產生 Span，命名規範和屬性格式統一
  • 安全感：因為不改程式碼，回滾也很簡單——拿掉 Agent 就回到原本的狀態

對於已經在線上跑了多年的既有系統，Zero-code 可能是唯一現實的導入路徑。你不可能要求團隊停下功能開發，花幾個 Sprint 在每個服務裡手動埋點。

OpenTelemetry 與 Logging 的整合#

OpenTelemetry 不只處理 Trace，它還能把 Trace 和 Log 打通。

核心做法是 Trace ID 注入：當應用程式寫 Log 時，OTel SDK 自動將當前的 Trace ID 和 Span ID 注入日誌的上下文欄位。這樣一來：

  • 在 Trace UI 看到一個有問題的 Span，可以一鍵跳到對應的 Log
  • 在 Log 查詢結果中，可以按 Trace ID 關聯到完整的追蹤鏈
  • 同一條 Trace 中所有服務的 Log 都能串起來看

要實現 Trace-Log 關聯，你的 Logging 框架需要支援 OTel 的 Context。Java 的 Logback/Log4j2、Python 的 logging 模組都有對應的 OTel 整合。結構化日誌（JSON 格式）會讓這個關聯更容易實現。

適用情境與限制#

什麼時候用 OpenTelemetry SDK？#

  • 新專案：直接從第一天就內建可觀測性，未來不需要重工
  • 既有專案想快速導入：用 Zero-code 在一天內讓整個系統產生 Trace
  • 多語言環境：OTel 支援 Java、Python、Go、.NET、JavaScript、Rust 等主流語言，一套標準通吃
  • 想保持後端靈活性：今天用開源方案，明天可能要上商業 APM，OTel 讓這個切換無痛

Zero-code 的限制#

Zero-code 不是萬能的，了解它的邊界才能做出正確的決策：

  • 只涵蓋框架層級：HTTP 呼叫、資料庫查詢會被追蹤，但你的「計算運費邏輯花了 500ms」不會出現在 Trace 中——這需要手動埋點
  • 效能開銷：自動埋點會攔截大量操作，在極端高效能場景下可能有可測量的延遲增加（通常在個位數毫秒等級）
  • 客製化受限：自動產生的 Span 名稱和屬性是固定的，如果你需要特定的命名或額外的業務屬性，仍需手動處理
  • 語言支援不均：Java 和 Python 的 Zero-code 支援最成熟，其他語言可能需要更多的 Library-level 整合

OpenTelemetry 的 SDK 和 API 是分開的。API 是穩定的介面，SDK 是具體的實作。這意味著框架可以安全地依賴 OTel API 而不引入沉重的 SDK——如果使用者沒有啟用 OTel，API 呼叫就是 No-op，零開銷。