背景與遷移動機
Delivery Hero 是一家食品配送公司，透過收購整合了 13 個實體，每個實體原有不同的平臺與觀測工具。歷史問題包括：各實體使用不同供應商與 SDK，導致無法整合分佈式追蹤；資料存儲於不同後端，無法實現統一觀測；CTO 要求每年節省 600 萬美元，推動平臺與觀測工具整合。遷移目標為成為供應商中立（vendor agnostic），標準化語義約定，實現 democratized observability，以追蹤（tracing）為核心整合所有 telemetry 資料。
遷移策略與架構設計
理想架構
中央管理的 OpenTelemetry Collector Agent，所有應用程式使用 OpenTelemetry SDK，資料經由 Agent 進入單一供應商。
實際架構
- Central Datadog Collector：整合 Datadog 格式資料至新供應商。
- Central OTP Collector：處理 OTP 格式資料。
- Federated Collectors：支援多種格式（如 OTLP、Prometheus、JSON）並整合至新供應商。
- 子公司自建 Collector：如 Glovo、Logistics 等業務單位仍維護獨立 Collector。
遷移步驟
先完成基礎設施遷移，後處理應用程式重儀表化（reinstrumentation）。
遇到的挑戰與問題
3.1 自訂組件與上游貢獻
- Forking 組件：例如 DataDog Collector 的 forked 接收器，因需支援所有 telemetry 類型（traces、metrics、logs）。現有自訂邏輯與 OpenTelemetry 上游版本不兼容，無法回退。其他自訂組件包括 Span Metrics Connector、Prometheus Exporter、Delta to Cumulative Processor、Load Balancing Exporter。
- 貢獻上游困難：上游組件更新週期慢，無法及時整合需求。自訂組件導致 OpenTelemetry Collector 版本更新需額外打補丁，增加維護成本。
3.2 數據序列化/反序列化開銷
- 問題描述：資料在 Collector 內部轉換時需進行多次序列化與反序列化（marshalling/unmarshalling），類比搬家過程需拆解所有物品至不同盒子，導致效率低下。
- 性能影響：CPU 使用率高，垃圾回收（GC）開銷大。內存消耗高，火焰圖顯示大部分 CPU 週期用於資料轉換。
3.3 有狀態組件的額外需求
- Span Metrics Connector：需確保同個 Trace 的 spans 進入同一 Collector Pod，需部署 Load Balancing Exporter。
- Delta to Cumulative Processor：需根據 DataDog 主機標頭路由資料，需自建 Proxy 應用與路由邏輯。
- 維護成本：需持續監控與調試自建組件，增加運維負擔。例如某 Proxy 應用曾導致重大事故。
結論與反思
繼續挑戰
- 自訂組件與上游貢獻的平衡。
- 有狀態組件的額外基礎設施需求。
- 數據轉換的性能開銷。
長期價值
OpenTelemetry 是實現 vendor agnostic 與消除供應商鎖定的唯一途徑。雖需額外成本，但符合長期戰略目標。
總結
雖然遷移過程困難重重，但 OpenTelemetry 的靈活性與標準化仍具備重要價值。需持續優化自訂組件與上游貢獻流程，以降低維護成本。
技術實現細節
- Prometheus Remote Write Exporter 的修改：原始 exporter 無日誌記錄，導致問題難以追蹤。新增日誌功能以協助調試。
- OpenTelemetry Collector 的自訂邏輯：允許 Fork 並加入公司特定邏輯，但需與 OpenTelemetry 標準兼容。透過自訂邏輯驗證標準的適用性與效率。
挑戰與解決方案
- 標準化與企業需求的衝突：現有 OpenTelemetry 標準需適配企業架構，導致額外開發成本。企業需在標準化與快速交付之間取得平衡。
- 貢獻回饋的長期信心：確認 OpenTelemetry 社群能接受企業的修改，但需先完成內部整合。透過實際應用驗證組件穩定性，再推動回饋至 OpenTelemetry 社群。
其他技術觀察
- OpenTelemetry Collector 的角色：作為數據收集與轉換的核心組件，需處理多種數據源與導出目標（如 Prometheus Remote Write）。自訂邏輯需確保與 OpenTelemetry 的生態系兼容。
- CNCF 的定位：OpenTelemetry 為 CNCF 設計的標準，企業需在 CNCF 生態中尋求長期技術路線圖。
貢獻流程優化
- OpenTelemetry Collector Contrib 的貢獻經驗：團隊已提交多個 Pull Request（PR）至 contrib components，部分仍在審核中（如某 PR 已掛起四個月）。建議加快審核週期以提升貢獻友好度。
- 貢獻與整合的平衡：為達成公司目標（如截止日期、對 CTO 的承諾），需先整合至內部系統再回饋 OpenTelemetry 社群。透過實際數據測試組件效能（如處理大數據量），作為「戰場測試」（battle test）的手段。
技術或工具的定義與基本概念
OpenTelemetry 是一個開放源碼的 observability 標準，提供 telemetry（追蹤、指標、日誌）的收集、處理與導出功能。其核心組件包括 Collector、SDK 與 Exporter，支援多種格式（如 OTLP、Prometheus、JSON）與供應商（如 Datadog、Prometheus）。OpenTelemetry 的 vendor agnostic 特性使其能避免供應商鎖定，實現統一的 observability 視圖。
重要的特性或功能
- 性能優化：透過 Collector 的資料轉換與導出功能，減少應用層的負擔。
- 可擴展性：支援多種格式與供應商，適應不同企業架構需求。
- 標準化語義約定：確保不同系統的 telemetry 資料可被統一解析與分析。
- 靈活性：允許自訂組件與邏輯，適應企業特定需求。
實際的應用案例或實作步驟
- 基礎設施遷移：部署 Central Datadog Collector 與 Central OTP Collector，整合至新供應商。
- 應用程式重儀表化：使用 OpenTelemetry SDK 重寫應用程式，支援 traces、metrics、logs。
- 自訂組件開發：針對特定需求（如 Load Balancing Exporter）開發自訂邏輯，並與 OpenTelemetry 標準兼容。
- 性能優化：透過減少資料序列化/反序列化次數，優化 Collector 的 CPU 使用率與內存消耗。
- 監控與調試：新增日誌功能至 Prometheus Remote Write Exporter，協助問題追蹤與調試。
該技術的優勢與挑戰
優勢
- vendor agnostic：避免供應商鎖定，實現統一的 observability 視圖。
- 標準化語義約定：確保不同系統的 telemetry 資料可被統一解析與分析。
- 靈活性：支援多種格式與供應商，適應不同企業架構需求。
- 長期戰略價值：符合 CNCF 生態的技術路線圖，提升技術可持續性。
挑戰
- 自訂組件維護成本：需持續監控與調試自建組件，增加運維負擔。
- 上游貢獻週期慢：無法及時整合需求，導致版本更新需額外打補丁。
- 數據轉換性能開銷：多次序列化/反序列化導致 CPU 使用率高與內存消耗大。
- 有狀態組件需求：需部署額外基礎設施（如 Load Balancing Exporter）以確保資料一致性。
總結
OpenTelemetry 的靈活性與標準化使其成為實現 vendor agnostic 與消除供應商鎖定的關鍵工具。儘管遷移過程面臨自訂組件維護、上游貢獻週期與數據轉換性能等挑戰，但其長期戰略價值不容忽視。企業需在標準化與快速交付之間取得平衡，並持續優化自訂組件與上游貢獻流程，以降低維護成本。