Hands-On OpenTelemetry Prometheus, Jaeger, Grafana and the OTel Demo

Cover Image

原始來源與檔名：2026-06-23T094541+0800-Hands-On OpenTelemetry Prometheus, Jaeger, Grafana and the OTel Demo.md

NAPKIN | 餐巾纸

公式：可觀測性 (Observability) = Metrics (發現異常) + Traces (定位瓶頸) + Logs (根因分析) 一句話：透過 OpenTelemetry 官方 Demo 實戰演練，展示如何利用 OTel Collector 將遙測數據解耦，並統一分發至 Prometheus、Jaeger 與 OpenSearch 進行全鏈路關聯與 Grafana 視覺化。 餐巾纸草图：

[ Microservices (OTLP) ] 
         │ 
         ▼ 
[ OTel Collector ]  -- (Receivers -> Processors -> Exporters)
         │
  ┌──────┼──────┐
  ▼      ▼      ▼
[Prometheus] [Jaeger] [OpenSearch]
(Metrics)    (Traces)    (Logs)
  │      │      │
  └──────┼──────┘
         ▼
     [ Grafana ] (統一視覺化/RED指標)

ROUND 1: SKELETON | 骨架掃描

核心問題：在分散式系統中，可觀測性（Observability）的三大支柱在實戰中究竟長什麼樣子？如何整合並打通這些開源工具？
核心答案：透過部署 OpenTelemetry Collector 作為數據中繼站，應用程式只需發送 OTLP 格式數據，Collector 負責將其轉換並分發給專職的後端引擎：Prometheus 處理量化的時間序列指標，Jaeger 處理服務呼叫鏈拓撲，OpenSearch 處理結構化日誌。最後以 Grafana 建立統一監控儀表板。
論證結構與章節骨架：
1. 架構啟動與配置：剖析 OTel Demo 的 Docker Compose 結構與 OTel Collector 的 Pipeline (Receivers, Processors, Exporters, Connectors)。
2. Prometheus (Metrics)：觀察系統宏觀健康度，介紹 PromQL 計算速率 (rate)、長尾延遲 (histogram_quantile)，以及從 Trace 派生 Metric 的 span_metrics 機制。
3. Jaeger (Traces)：解決「系統哪裡慢」的問題。解析 Trace 與 Span 的階層關係、跨度類型 (SPAN_KIND)，將服務依賴具象化為時間軸。
4. OpenSearch (Logs)：解決「到底發生什麼事」的問題。利用 traceId 與 spanId 實現日誌與追蹤的精準關聯。
5. Grafana (Dashboards)：統整三大支柱，展示包含 RED 指標的 APM 儀表板，作為維運的第一道防線。

ROUND 2: DISSECTION | 血肉解剖

隱形假設與邊界條件：
- 本文假設讀者具備微服務架構的基礎認知，且已意識到傳統單機日誌無法進行跨服務追蹤的痛點。
- 此為「運維與資料探索」視角的實戰，邊界條件在於它不涉及代碼層面的埋點教學 (Instrumentation)，而是聚焦在基礎設施搭建好後，如何有效地使用這些工具進行問題排查。
- 本案例採用全開源軟體作為儲存後端，但在企業級應用中，這些後端極可能會被替換為 Datadog、Dynatrace 等商業 SaaS，而這正是 OTel 標準化的最大價值—解耦。

ROUND 3: SOUL | 靈魂提取

知識連結：
- RED Metrics：Rate (速率), Errors (錯誤), Duration (耗時)，微服務服務水準監控的黃金三指標。
- Trace-Log Correlation (鏈路日誌關聯)：分散式除錯的聖杯。透過在日誌中自動注入 trace_id，打通了「從宏觀報警到微觀異常棧」的高速公路。
- Span Metrics Connector：過去需要開發者手動編寫 metric 與 trace 兩套邏輯，現在可以透過 OTel Collector 在底層直接從 Span 資料中聚合出 Prometheus Metric，大幅降低應用層的效能開銷與程式碼侵入性。
深層洞見：
- 可觀測性的本質並不是搜集更多的數據，而是建立一套由面到線再到點的排障 SOP：Metrics 報警（面：發生什麼問題？） -> Traces 定位瓶頸（線：問題出在哪個環節？） -> Logs 查明根因（點：具體的程式碼錯誤是什麼？）。
- OpenTelemetry 的革命性在於「遙測數據生產與消費的解耦」。架構師終於可以掌控統一的資料 Pipeline，不再被特定的監控廠商綁架。
行動呼籲：
- 在新系統架構設計時，全面放棄私有協議的監控 SDK，將 OTLP 設為遙測數據唯一標準。
- 引入 OTel Collector 作為 Sidecar 或 DaemonSet，統一接管系統的 Observability 數據流，為未來的基礎設施演進保留最大的彈性。

Hands-On OpenTelemetry Prometheus, Jaeger, Grafana and the OTel Demo (Architectural Deep Dive)

前言/背景

在雲原生與微服務架構中，系統的複雜度呈指數級上升，傳統基於單點日誌與機器的監控模式已完全無法應對跨服務的除錯需求。本文透過剖析官方的 OpenTelemetry Demo，具象化了 OTel 收集器如何與現代三大開源監控巨頭 (Prometheus, Jaeger, OpenSearch) 協同運作，建立一套完整的、無廠商鎖定的可觀測性標準堆疊。

章節詳細總結

1. 遙測數據樞紐：OpenTelemetry Collector

解耦設計：Collector 扮演數據中介者的角色，內部包含 Receivers (接收 OTLP 等協定)、Processors (過濾、批次處理、標籤修飾)、Exporters (發送到各種後端)。
Span Metrics 機制：透過 span_metrics connector，Collector 能夠直接攔截並分析流經的 Traces，即時聚合出 Prometheus 可用的 Metrics（如 traces_span_metrics_calls_total）。這意味著應用程式只需專心發送 Trace，指標聚合交由基礎設施層處理，是極具效率的架構模式。

2. 宏觀指標監控：Prometheus

指標維度化：透過 OTel Collector 傳入的 Resource Attributes 自動轉換為 Prometheus 的 Labels（如 service_name, span_kind），使多維度查詢成為可能。
實戰查詢 (PromQL)：
- 使用 rate() 將不斷遞增的 Counter 轉換為即時的 QPS (Operations Per Second)。
- 使用 histogram_quantile(0.95, ...) 計算 p95 長尾延遲，精準抓出拖累系統效能的關鍵服務。
價值：幫助架構師與 SRE 快速回答：「系統現在有問題嗎？」、「哪幾個服務錯誤率飆高？」。

3. 分散式鏈路追蹤：Jaeger

層級架構：Trace 代表一次完整的外部請求，Span 代表其中的單一操作。兩者透過 Trace ID 與 Span ID 建構出具有 Parent-Child 關係的樹狀結構。
Span Kind 語義：
- SERVER：接收請求的一端。
- CLIENT：發起外部依賴呼叫的一端。
- 透過成對的 Client/Server Span，Jaeger 能精確畫出服務間的依賴拓撲圖與網路耗時。
價值：當 Metrics 發出警告時，Jaeger 能用視覺化時間軸精確回答：「這個請求到底塞在哪個下游環節？」。

4. 結構化日誌分析：OpenSearch

日誌結構化：傳統日誌只是單純的字串，而透過 OTel 收集的日誌是帶有豐富元數據 (Metadata) 的 JSON 文件，包含 severity, body, 以及最重要的 traceId 與 spanId。
Trace-Log 關聯 (Correlation)：這是一級架構師必須落實的功能。當在 Jaeger 中發現一個異常的 Span 時，只需複製其 traceId，即可在 OpenSearch 中精準拉出該次請求涉及的所有跨服務日誌，迅速看到導致錯誤的 Exception Stacktrace。
價值：作為排障的最後一哩路，精確回答：「程式碼底層到底發生了什麼錯誤？」。

5. 統一視覺化與營運視角：Grafana

資料聚合：Grafana 本身不儲存資料，而是作為 Visualization Layer，將 Prometheus, Jaeger, OpenSearch 同時掛載為 Data Sources。
RED 指標儀表板：展示以 Rate, Errors, Duration 為核心的 APM Dashboard，將三大遙測數據無縫融合在單一視窗，這是 SRE 團隊日常營運的最佳切入點。

總結與結論

現代系統架構師必須將「可觀測性」視為與高可用性、安全性同等重要的非功能性需求 (NFR)。OpenTelemetry Demo 不僅是一組開源工具的火力展示，更是現代 Troubleshooting 工作流的最佳實踐。它徹底將遙測數據的「生產端」與「消費端」解耦，我們應當在所有新的架構設計中，全面擁抱 OTLP 標準與 Collector 架構，以確保基礎設施的長期演進彈性。