在前一篇中，我們提到可觀測性的三大核心面向：Logs、Metrics、Tracing，並延伸了 Health Check、Audit Logging、Exception Tracking 等模式。到了 Day 15，我們要更深入探討幾個與「狀態追蹤」及「變更可視化」高度相關的模式：

• Log Aggregation：集中化日誌管理，解決分散式環境下的可視性問題。
• Exception Tracking：系統化管理例外，避免錯誤訊息被淹沒。
• Log Deployments & Changes：把部署與環境變更納入觀測，強化因果關聯性分析。

這三個模式不僅是微服務可觀測性的延伸，也是持續交付與運維團隊的重要工具。

Log Aggregation

情境

在微服務架構中，每個 Service 會獨立部署，甚至同一服務也可能有多個實例。這些實例會分布在不同機器、節點或雲端資源上，產生的日誌也因此散落各處。當一個請求需要經過多個服務協作時，要追蹤一條完整的 Request Flow 幾乎不可能。

問題

• 如何有效整合多個服務與實例的日誌？
• 如何針對某個請求，快速定位異常的環節？
• 如何在龐大的日誌中過濾有意義的訊號？

動機

• 微服務規模越大，日誌量指數成長。
• 分散式環境下，單一檔案查詢變得低效。
• 解決方案必須對 Runtime 效能影響最小。

解決方案

導入集中式日誌服務，將所有服務實例的日誌匯入統一的系統，並提供：

1. 搜尋與分析能力（例如 Elasticsearch/Kibana）。
2. 即時警示：當日誌中出現特定關鍵字或模式時觸發通知。
3. 上下文整合：利用 Request ID / Trace ID，將跨服務的請求串接成一條完整流程。

效益

1. 優點：集中化觀測、快速定位問題
2. 缺點：需額外基礎設施，且處理高流量日誌需大量儲存與計算資源

相關模式

1. Distributed Tracing：將 Request ID 寫入 Log，以便跨服務串接。
2. Exception Tracking：錯誤訊息除了寫入 Log，也同步至錯誤追蹤系統。

Exception Traking

情境

當系統出現錯誤時，通常會拋出 Exception。Exception 中往往包含 錯誤訊息、堆疊追蹤、請求上下文。在傳統單體應用中，這些 Exception 很容易集中在同一台伺服器上觀察。但在微服務架構中，錯誤可能分散在不同節點，甚至出現在跨服務的交互過程。

問題

• 如何避免同一錯誤被多次記錄？
• 如何快速歸納錯誤類型並派發給負責的開發團隊？
• 如何將 Exception 與使用者操作、業務事件關聯起來？

動機

• 大量例外可能造成訊息「雪崩」，開發者難以判斷優先處理順序。
• 需要最小化對效能的影響，避免因觀測而導致額外故障。

解決方案

建立 集中式 Exception Tracking Service，例如：

• Sentry
• Rollbar
• Azure Application Insights

上述工具可以協助我們：

1. 自動去除重複錯誤。
2. 將錯誤與 Git/Issue Tracking 工具整合（例如 JIRA）。
3. 提供錯誤趨勢報表，幫助判斷新版本是否引入新錯誤。

效益

透過良好的 Exception Tracking 機制，協助維運人員更容易查看錯誤，並追蹤修復進度。但是，好的 Exception 處理機制本來就不容易撰寫，分散式的 Exception 更將增加設計的複雜度。再者，錯誤的堆疊可能洩漏內部細節，造成安全性的疑慮。

相關模式

1. Log Aggregation：錯誤不僅要被追蹤，還要在 Log 中有完整記錄。
2. Audit Logging：若錯誤與使用者操作相關，應與審計日誌結合。

Log Deployments and Changes

情境

微服務架構的部署頻率遠高於傳統單體系統，可能每天多次釋出版本。事實上，許多故障往往發生在 部署後或配置變更後。若沒有追蹤部署歷史，排查問題時容易誤判根本原因。

問題

• 如何快速判斷故障是否與部署/變更有關？
• 如何將 Metrics、Logs 與 Change Event 結合？

動機

• 部署流程頻繁，人工追蹤幾乎不可能。(在微服務的系統中，每天可能有許多次的部署，間接造成系統的異常)
• 問題常在變更後立即出現，需能自動建立「前後對照」。

解決方案

將《部署與環境變更紀》錄納入觀測系統：

1. 版本標記：在 Metrics 或 Logs 上加註版本號。
2. 自動發布紀錄：CI/CD Pipeline 發布時，將紀錄寫入 Logging/Monitoring 系統。
3. 環境事件追蹤：例如配置檔變更、資料庫 Schema 調整。

效益

當因為部署引發異常的時候可以加速排查的程序，但必須跟 CI/CD 流程緊密整合，做到自動化整合。

相關模式

1. Application Metrics：與部署時間軸對照，找出效能下降的關鍵版本。
2. Audit Logging：將變更紀錄納入審計，確保合規性。

結語

本篇章模仿 Design Pattern 中描述一個 Pattern 的模式來說明「Log Aggregation」、「Exception Tracking」及「Log Deployment & Change」三個模式，說明這三個模式應用在「分散式」運算環境的施作方式。

針對這些議題，其實已經有很多的工具可以協助我們去做對應的實現：

• 集中式日誌：ELK Stack、Grafana Loki
• 分散式追蹤：Jaeger、Zipkin、OpenTelemetry
• Exception Tracking:Sentry、Rollbar
• 部署追蹤：ArgoCD、Spinnaker

目前也有人在討論這些工具的整合平台正式著將 Logs/Metrics/Tracing 三種可觀測性的功能結合為一。