2026年3月7日 星期六

可觀測性 OpenTelemetry：建立雲原生服務的標準化觀測

於 沒有留言:
標籤：
 

隨著微服務架構普及，可觀測性已從選配變成標配。不同語言、不同平台觀測標準不一，是很多團隊導入時最先碰到的問題。OpenTelemetry 是目前解決這件事最好的工具，讓你的團隊從「不知道」到「修復完成」的時間縮到最短。

那我們就開始吧！




一、Background：雲原生維運的可觀測性


在現代 K8S 雲原生系統中，即時看到問題，並修復問題是一項艱鉅的任務。由於微服務架構，一個請求可能通過 10 幾個服務節點與不同的 API Gateway。當流量暴增、面板出現紅燈告警時，工程師往往只能憑經驗與直覺逐步排查。

OpenTelemetry（簡稱 OTel） 就是在這樣的背景下誕生。它由雲原生計算基金會（CNCF）主導，目標是推動雲端觀測標準化。

推動 OTel 建置主要有幾項好處：

  • 觀測 SDK 寫法不同 → ✅ 提供一致的觀測 SDK 標準

  • 觀測資料格式不一致 → ✅ 觀測資料對齊統一格式

  • 難以跨語言或跨平台整合 → ✅ 減少供應商鎖定成本

目前各家雲廠商（AWS、Azure、GCP）與觀測平台（Grafana、Datadog）皆已原生支援 OTel 格式，讓使用者能自由切換後端，不再被單一供應商鎖定。

💡 小知識：OpenTelemetry 在 CNCF 的貢獻者數量僅次於 Kubernetes，已成為多雲環境下的預設標準。

 


二、OTel 架構：它是如何運作的？



OpenTelemetry 旨在 統一收集、處理與導出觀測資料。透過整合「觀測三大支柱（The Three Pillars of Observability）」，讓工程師能以單一視角掌握微服務拓樸、請求延遲與事件脈絡。


2.1 三大資料型態總覽

類型說明常見用途常見收集來源 / 提供商
Traces追蹤請求在服務間的路徑分析延遲瓶頸、呼叫鏈路Grafana Tempo, Jaeger, AWS X-Ray
Metrics數值度量（CPU、QPS）監控趨勢、設定警報Prometheus, Datadog, CloudWatch
Logs事件紀錄與上下文重現錯誤診斷、事件還原Loki, Elasticsearch, Splunk

2.2 資料傳遞架構


OTel 的強大在於分層設計，主要分為三個階段：Instrumentation → OTLP Protocol → Exporter

  • Instrumentation (儀表化)：從應用中收集資料。支援「Zero Code」自動掛載，不需改動業務程式碼即可達成觀測。

  • OTLP (傳輸協定)：定義統一格式，讓不同語言、平台的資料能溝通。

  • Exporter (輸出)：將資料轉發至後端系統（如 Prometheus、Tempo 等）。

OTel Collector 是關鍵中介層，負責接收、過濾、轉換與轉發資料。透過 Grafana 將三者整合，實現「點擊 Trace 即可回看當時 Log」的聯動分析。


2.3 實戰配置與範例


以下是 OpenTelemetry Collector 的基本 YAML 配置，展示如何接收資料並分流輸出：

receivers:
  otlp:
    protocols:
      grpc: {}  # Port 4317，應用程式推送 Traces/Metrics 的入口
      http: {}  # Port 4318，同上，支援 HTTP/JSON 格式

processors:
  batch:
    timeout: 2s            # 每 2 秒批次送出，降低後端寫入壓力
    send_batch_size: 1024  # 單批最多 1024 筆
  attributes/common:
    actions:
      - {key: environment, value: "production",   action: upsert}  # ← 改成你的環境名
      - {key: cluster,     value: "k8s-prod-tw",  action: upsert}  # ← 改成你的叢集名
  probabilistic_sampler:
    sampling_percentage: 10  # 生產環境建議 5~20%，開發環境可設 100

exporters:
  prometheus:
    endpoint: "0.0.0.0:9464"  # Prometheus 來此 Port scrape Metrics
  otlp/tempo:
    endpoint: "tempo.monitoring.svc.cluster.local:4317"  # ← 改成你的 Tempo 位址
    tls:
      insecure: true  # 叢集內部通訊可關閉 TLS

service:
  pipelines:
    traces:
      receivers:  [otlp]
      processors: [attributes/common, probabilistic_sampler, batch]
      exporters:  [otlp/tempo]
    metrics:
      receivers:  [otlp]
      processors: [batch]
      exporters:  [prometheus]

  • receivers：定義資料接收端，支援 gRPC（Port 4317）與 HTTP（Port 4318）兩種 OTLP 協定。

  • processors：三層處理管線——batch 批次緩衝降低後端壓力；attributes/common 為所有資料統一注入環境標籤（如 environment: prod）；probabilistic_sampler 在生產環境做 10% 取樣，避免海量 Traces 打爆後端。

  • exporters：雙軌輸出——Metrics 送 Prometheus（Port 9464）；Traces 送 Grafana Tempo（透過 OTLP gRPC）。

  • service.pipelines：將 receivers → processors → exporters 串接成兩條獨立 Pipeline，traces 與 metrics 各走各的路。

實作可另外參考：



三、推進策略：Code-based vs Zero-code


許多團隊最擔心「要改多少程式碼」。OTel 提供了 Zero-code Instrumentation (自動插樁) 方案：

  • Java：啟動參數加上 -javaagent:opentelemetry-javaagent.jar。

  • Python/Node.js：使用 wrapper 命令啟動即可攔截常用框架（FastAPI, Express）。

模式優點缺點適用場景
Zero-code快速部署、適合舊系統資料粒度受限POC、快速上線
Code-based自訂精細邏輯、記錄業務事件成本高、需改程式核心專案、高精度觀測


Zero-code Instrumentation 不改任何業務邏輯，就能自動攔截 Spring Boot、gRPC、JDBC、Kafka 等框架的呼叫，生成完整的 Traces。.NET、Python、Node.js、Go 等語言也有對應的 Auto-Instrumentation 支援。這表示不重構即可讓舊系統具備可觀測性。

實務建議先用 Zero-code 鋪基礎觀測，再於關鍵商業邏輯加入 Code-based 自訂標籤。幾個需要注意的面向：

  • 先輸出至現有平台，降低團隊學習曲線與導入阻力。
  • 逐步擴展服務，實現跨系統的 Trace ID 追蹤。
  • 將觀測數據轉化為運營指標（SLI/SLO）。

可觀測性的導入是累積的過程，基礎打得扎實，後續每一層擴展的成本才會持續下降。



四、結語：Observability 的下一步


好的可觀測性不只是事後救火，而是在問題還沒爆發前就看到異常的輪廓，並在出事時縮短從「不知道」到「知道原因」的時間。所有的架構選擇、工具投資，最終都在這裡被檢驗。

當前趨勢正朝兩個方向發展：

  • 第一是寬事件的根因分析。其核心在於將所有上下文（UserID、TraceID、執行時間）整合進 Data Lake，透過 OTel 作為統一收集層，讓 Prometheus + Loki 負責即時告警，ClickHouse/S3 承載長期分析與根因挖掘 RCA 時具備回溯任何細節的能力。

  • 第二是 LLM Observability 的標準化。Token 消耗、模型幻覺、RAG 鏈路中向量資料庫的延遲，這些指標目前仍缺乏統一框架，是 SRE 與 AI 工程接下來最值得投入的交匯點。

兩條路線的共同基礎是 OpenTelemetry。Structured Logging 與 Trace Context 格式標準化後，換後端或接 AI 分析，都只是更換一個 Exporter 的問題。

工具會換，架構會變。真正的競爭優勢，是一個能持續看清自己系統狀態的團隊。而這件事，讓我們從 OTel 的地基打紮實開始：）



📚 延伸閱讀




沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)
技術提供：Blogger.
 
© 2025 Mr. Opengate