從開發到架構設計的可觀測性實踐

DevOpsDays 2025 by 鄭淳尹 (Philipz)
1. 微服務複雜性與可觀測性介紹
2. OpenTelemetry與可觀測平台架構
3. OpenTelemetry與Spring Boot整合
4. 故障查找及系統優化實際案例
5. 可觀測性挑戰與未來趨勢

Transcript

1. DevOpsDays Taipei 2025 從開發到架構設計的 可觀測性實踐 2025-06-05 鄭淳尹 Philipz
2. Observability簡介 微服務複雜性與可觀測性介紹 AGENDA 1 OpenTelemetry與可觀測平台架構 說明部署方式及優劣項目 2 可觀測性挑戰與實踐建議 系統規模與複雜性增加時的挑戰與策略 4 可觀測性未來趨勢 GenAI將是下一代可觀測性技術的必要基礎能力 5 OpenTelemetry與Spring Boot整合 以GCP可觀測平台解決方案作示範 3
3. Observability簡介 微服務複雜性與可觀測性介紹 1
4. 雲原生架構技術棧日益複雜 3 從機房的電力和網路，作業系統和容器平台，應用系統運作到使用者請求數量
5. 傳統監控與可觀測性的差異 4 農產品產銷履歷資訊就如同集中式的全鏈路追蹤平台 ⚫ 關注 我知道的問題 預先定義的問題和故障模式 ⚫ 基於 預設閾值 告警 當超過特定閾值時發出通知 ⚫ 聚焦於 系統健康狀態 主要考量系統是否正常運行 ◼ 聚焦於 我不知道的問題 能夠探索未預期的問題 ◼ 支持 高度探索性分析 靈活查詢和多維度數據關聯分析 ◼ 深入理解 系統行為原因 理解複雜系統內部運作邏輯 可觀測性 傳統監控 僅在食品終端檢測 如同超市抽檢成品，只能發現 已受污染商品 固定時間點檢查 定期檢測無法捕捉運輸中的 溫度異常 孤立的監測點 各環節數據不互通，無法追蹤 污染源頭 全鏈路追蹤 從農場到餐桌全過程監測 ，及時發現問題源頭 多維數據關聯分析 結合溫度、濕度、運輸時 間等維度交叉分析 異常模式識別 通過歷史數據學習識別未 知的異常模式 主動探索未知問題 被動回應已知問題
6. 解決系統可觀測性的基本三大訊號資訊 5 CNCF定義可觀測性規範 - 追蹤（Traces）、指標（Metrics）和日誌（Logs） 聚合指標 事件日誌 請求鏈路 低數據量 高數據量 請求範圍事件 請求範圍指標 聚合指標事件 完整資訊 標籤對應日誌 樣本 追蹤欄位或 自動日誌
7. 三大訊號資訊的對應關係 6 可依照不同角色、不同解決方案，採用適合的可觀測資訊查找方式 span_id trace_id 🅐 🅑 🅒 🅓 🅕 🅔 標籤對應日誌 樣本 追蹤欄位或 自動日誌 🅑 🅐 🅒 🅓 🅕 🅔 🅐 透過時間戳找日誌 🅑 統計次數顯示指標 🅒 以trace/span id來對應鏈路 🅓 metadata來標示日誌 🅔 透過時間戳找鏈路
8. 追蹤（Traces）、指標（Metrics）和日誌（Logs）所代表的意義 7 OpenTelemetry可支持三種監控指標以呈現不同構面的系統錯誤 log.event log.event log.event … log.event log.error log.error … log.event log.event log.event … Service1 Service2 Service3 ╳ Transation1 ╳ ╳ 4 requests Success: 4 Failure: 0 Avg. Latency: ? ms 4 requests Success: 3 Failure: 1 Avg. Latency: ? ms 4 requests Success: 2 Failure: 2 Avg. Latency: ? ms Transation2 Transation3 Transation4 Legend: Transation Success event Failure event Service/ Application ╳ Logs Traces Metrics 說明： 1. 一項交易由多個 服務所組成 2. Trace呈現每次交 易的全貌 3. Log紀錄單一服務 的邏輯錯誤 4. Metrics統計單一 服務的狀態數據
9. OpenTelemetry與可觀測平台架構 說明部署方式及優劣項目 2
10. OpenTelemetry開源可觀測性標準框架 9 統一收集和處理各種可觀測性數據的格式、技術和架構，廠商藉此規範發展各自解決方案 1. 應用層可整合 SDK或 手動安裝 Agent 2. 基礎層亦使用相同 OTel 格式，避免遺 漏平台監控數據 3. Collector 將監控方案與應 用層/基礎層解耦 4. 可自行設定監控數據的接 收、處理和匯出 5. 彙總到可觀測性解決 方案，如Elastic、 Dynatrace，或公有 雲服務
11. 可觀測性管道建置方案比較 10 從儀表資料產生到數據持久化的四種選項 直接模式 (Direct) 應用儀表 優點 缺點 ✓ 最快的實現價值 ✓ 架構簡單直觀 ✓ 最低的傳輸延遲 X 數據處理彈性低 X 需要修改程式及配置 X 維運複雜度高 X 分散的安全控制 可觀測性平台 直接傳送 混合模式 (Hybrid) 應用儀表 優點 缺點 ✓ 結合代理和閘道的優勢 ✓ 支持最多情境和需求 ✓ 最高數據靈活性和可移植性 X 配置最為複雜 X 最高管理成本 X 需要專門團隊維護 可觀測性平台 Agent 代理 Gateway 閘道叢集 本地 傳送 集中 處理 統一 匯入 代理模式 (Agent) 應用儀表 優點 缺點 ✓ 快速實現價值 ✓ 切分遙測傳輸與處理 ✓ 減輕應用負載 ✓ 支援動態配置 X 單點故障風險 X 需適當規模和監控 可觀測性平台 Agent 代理 本地傳送 集中處理 閘道模式 (Gateway) 優點 缺點 ✓ 避免單點故障 ✓ 支持進階數據處理功能 ✓ 支持尾部採樣 ✓ 適用於無伺服器等環境 X 無法減輕應用負載 X 需注意負載平衡配置 X 可能會有較高傳輸延遲 應用儀表 可觀測性平台 本地傳送 統一匯入 Gateway 閘道叢集 小團隊 & 程式支援 大團隊 & 語言支援 程式不支援 𝙓 不建議
12. 可觀測性平台選擇指南 11 建置後的Day 2擴大使用、持續改進與優化才是最大考驗 功能性需求 (What) • ⽀援的訊號類型 (Logs, Metrics, Traces) • 異常偵測能⼒ • 資料保留時間 • 即時分析能⼒ • AI/ML 整合能⼒ ⾮功能性需求 (How) • 成本與可預測性 • 擴展性與效能 • 安全性與合規 • 易用性與⽂檔 • 後續維護與社群活躍度
13. OpenTelemetry與Spring Boot整合 以GCP可觀測平台解決方案作示範 3
14. OpeneTelemetry Operator in GCP GKE 13 Cloud Traces、Cloud Logging和Google Cloud Managed Service for Prometheus https://cloud.google.com/stackdriver/docs
15. OpenTelemetry SDK與Agent的差異 14 Kubernetes OpenTelemetry Operator可透過sidecar安裝agent並由instrumentation來控制各種語言的設定 Container/VM Application Exporter Trace Backend HTTP Req. Container/VM Application Agent Trace Backend HTTP Req. Traces Agentless Using Agent Initialize exporter in app code Install the agent alongside the app https://github.com/open-telemetry/opentelemetry-java-instrumentation
16. OTEL Agent可協助將Stdout的logs傳送到可觀測平台 15 傳統方式是logs寫到檔案，透過filebeat/fluentbit分批傳到日誌服務，但讀寫檔案可能會影響效能
17. 在Trace數據中找出持續時間較久的 16 開發階段可依據Trace鏈路找出耗時最久的程式，持續優化應用系統
18. 在Trace數據中找出持續時間較久的 17 開發階段可依據Trace鏈路找出耗時最久的程式，持續優化應用系統 關聯到相對應之logs
19. Trace鏈路協助找出錯誤原因 18 OTEL Agent自動填入Metadata(屬性)協助判斷出錯的服務跟Pod
20. 配合Cloud SQL查詢洞察功能，找出SQL可優化之處 19 Cloud SQL日誌也會傳送到GCP Traces/Logs，持續優化資料庫效能 發現N+1 Selection問題 Metrics Traces
21. 配合Cloud SQL查詢洞察功能，找出SQL可優化之處 20 Cloud SQL日誌也會傳送到GCP Trace/Logs，持續優化資料庫效能 發現N+1 Selection問題
22. 可觀測性挑戰與實踐建議 系統規模與複雜性增加時的挑戰與策略 4
23. 可能面臨的挑戰和解決方案 22 大規模採用可觀測性必會面臨諸多問題，包括組織、人員和技術 整合現有系統 挑戰 🅧 已有監控⼯具與OpenTelemetry功能重疊 🅧 舊系統產⽣的歷史數據難以整合 🅧 全⾯遷移⾵險高，可能中斷業務運營 解決 策略 🅥 實施漸進式遷移，先從⾮核⼼系統開始 🅥 配置雙寫模式，同時向新舊系統發送數據 🅥 使用OpenTelemetry接收器連接⽼舊系統 資料量龐大 挑戰 🅧 高流量環境產生大量遙測數據量 🅧 完整採集可能導致網路和存儲壓⼒ 🅧 處理海量數據需要大量計算資源 解決 策略 🅥 實施智能採樣策略，區分正常與異常流量 🅥 使用分層存儲，熱數據高可用冷數據低成本 🅥 配置Collector水平擴展，負載平衡處理 成本控制 挑戰 🅧 遙測數據存儲成本隨服務規模快速增長 🅧 完整鏈路追蹤的運算與網路⽀出高昂 🅧 難以平衡資料完整性與成本效益 解決 策略 🅥 按服務重要分級設置採樣率，核⼼服務完整採集 🅥 設置⽣命周期管理自動過期清理非關鍵數據 🅥 結合聚合指標與詳細鏈路數據降低存儲密度 複雜環境部署 挑戰 🅧 多語言、多架構環境下配置管理複雜 🅧 跨環境追蹤上下文傳遞不一致 🅧 各種語言SDK成熟度不一，功能⽀持不同 解決 策略 🅥 採用集中化配置管理，統一管控語言SDK 🅥 標準化追蹤設置，確保跨服務上下文傳遞 🅥 建立統一語義約定，規範標籤與屬性命名
24. 可觀測性實踐注意事項 23 與數據分析工程一樣，需要考量資源、成本、採樣跟機敏保護 效能與資源管理 ◆ 採樣策略最佳化 ◆ 批次優化 ◆ 資源限制設置 ◆ 數據生命周期管理 架構設計考量 ◆ Collector部署模式選擇 ◆ 採樣策略設計 ◆ 多租戶隔離 ◆ 負載均衡配置 數據品質控制 ◆ 標準化命名約定 ◆ 避免冗餘數據 ◆ 屬性精簡原則 ◆ OTEL優先 安全與隱私保護 ◆ 避免敏感數據收集 ◆ 傳輸加密 ◆ 集中憑證管理 ◆ 訪問控制 實踐步驟 ❶ 需求評估 確定觀測目標和關鍵指 標，制定清晰的可觀測性 策略 ❷ 架構規劃 選擇合適的部署模式和採 樣策略，設計數據流管道 ❸ 漸進實施 先從非核⼼系統開始，驗 證效果後逐步擴展 ❹ 數據驗證 確保數據完整、準確，並 符合業務需求 ❺ 持續優化 定期審查採樣策略、數據 質量和資源使用
25. 可觀測性未來趨勢 GenAI將是下一代可觀測性技術的必要基礎能力 5
26. Grafana MCP with Claude Sonnet LLM in Cursor 25 借重 MCP + GenAI 能力，分析多構面的可觀測數據，縮短查找問題時間提高準確度
27. AI Will Be the Foundation of Next Generation IT Operations 26 Gartner IT Infrastructure, Operations and Cloud Strategies Conference 2024
28. THANK YOU – Q&A