上一篇本事在介紹 Microservice Architecture Pattern 中的 Application Infrastructure Patterns，其中我將「可觀測性 (Observability)」這個議題往後延，有一部分是篇幅的問題也有一部分是我認為這塊在這一兩年已經是一門可以深入探討的學問。在天瓏書局中也可以找到幾本專門講「可觀測性的書籍」。我自己在最近的專案中也接觸了 Gray Log, Loginsight, ELK, OpenSearch, Prometheus Grafana 以及 Jaeger 等相關工具。

在這裡，我就不細談這些工具，應該都有專書在講了！如果未來有需要，我再另外搞一系列來分享。所以，視角還是回到導入微服務這塊。在最初我開始接觸到客戶詢問「微服務」的時候，我們討論了服務拆分，然後就會一直討論到「維運」該怎麼進行。以前，程式被客戶反應有問題，我就到伺服器上看看日誌，確認有沒有什麼異常的。

接著，你就會忽然警覺，那微服務的機器上 Log 可能也是「分散」的，我該怎麼進行相關問題的判定？所以，在這裡就可以參照 Microservice Architecture Pattern 裡面的可觀測性部分。

應用程式基礎架構模式

在微服務架構裡，可觀測性不是單一工具，而是一組互補的設計模式，目的是讓你看得見系統內發生了什麼、為何發生，以及接下來可能會發生什麼。下列模式彼此協作：由日誌/度量/追蹤構成資料面，透過健康檢查與變更記錄補上情境，最後以稽核紀錄保障合規與責任追溯。

可觀測性 (Observability)

• Log Aggregation（集中化日誌）
  將每個服務的標準輸出/錯誤輸出與應用日誌彙整到集中式平台。
  目的：跨服務檢索、關聯與告警。
  實作要點：結構化（JSON）、統一欄位（traceId、spanId、service、env、version）、保留政策與遮罩敏感資訊。

  為了讓日誌擋在分散式交易環境上可以發揮效用，在實作要點中提到的「統一欄位」就是一個重要的實作，讓我們可以在日後透過關聯的方式來確認應用程式執行的脈絡。

• Application Metrics（應用程式度量指標）
  彙整「可量化」的服務健康與商務指標（如 QPS、P99 latency、錯誤率、併發數、佇列深度、資料庫連線用量、重要業務轉換率）。
  目的：即時監控與 SLO/SLA 追蹤。
  實作要點：以 pull 或 push 模式暴露 /metrics；區分基礎設施與業務度量；每版發布保留度量相容性。

在這個部分主要是針對業務相關的資訊進行量測而不是僅針對 CPU / Memory 使用率這種單純的指標。

• Distributed Tracing（分散式追蹤）
  用 traceId/spanId 把一次請求在多服務間的呼叫鏈連起來，量測每段耗時與錯誤點。
  目的：定位瓶頸與跨服務錯誤源。
  實作要點：由入口（GW/BFF）產生 traceId；透過 HTTP/gRPC header（如 W3C Trace Context）傳遞；記錄關鍵標籤（tenant、orderId…）。

  在微服務中實作的過程必須相當小心遺失這些 id，如果沒有處理好將無法有效判斷資訊的脈絡。

• Exception Tracking（例外追蹤）

Exception 是我們在程式發生問題時最重要的線索，大致上我們可以分成「已知」跟「未知」兩個選項。針對已知的部分，通常都有對應的處理程序，而未知則是我們要跟時間賽跑在營運階段想辦法用最有效率的方式來找到問題。

在原本的模式中僅有簡單的說明要註記「版本」、「行為」以及「環境變數」等，這部分我認為可以在看一下「例外處理的逆襲」這本書，你會對於 Exception 的機制有更近一步的瞭解 (我在唸書的時候也因為這樣對「例外」處理有所啟發)。

• Health Check API（健康檢查）

Health Check API 是目前很多維運團隊要求開發團隊需要實作的事項，但是我看到很多人都是寫一個 API 回覆個 HTTP 200 OK 就當作這個服務的狀態正常。

必較謹慎一點應該是該服務也需要檢視自己「相依」的服務是否正常，例如：API、Datasource 等，並依據這些情境將自己的健康狀態分成「健康」、「警告」及「示警」等不同狀態。

例如：spring 中的 actuator 就可以協助我們完成這些工作。

• Log Deployments and Changes（部署與變更記錄）

將每次部署與設定都予以紀錄，以便日後追蹤這些變更是否衍伸了後續的問題。這裡指的是需要有比較詳細的 Release Notes 的概念，而不是僅有說版號有更新。留下這些紀錄，將有助於我們更快遞透過這些內容來定位某次版本變更後所造成的問題。

• Audit Logging（稽核紀錄）

針對安全與合規的使用者/系統操作（登入、授權變更、敏感資料存取、金流動作）留下不可竄改、可回放的紀錄。
通常來說，稽核日誌不會跟一般日誌放在一起，其功能作用與保留時間都不太一樣。

沒有可觀測性，就沒有可靠性。把上述模式視為「產品能力」而非「運維附加」，在設計之初就納入你的微服務基線（baseline）。

結語

可觀測性對於建構微服務系統來說是一個相當重要的工作，特別是現在又經常採用 Kubernetes 等相關的工具來輔助線上營運的工作。

可觀測性的知識點內容會包含「日誌的搜集」、「資料的分析與判讀」、「即時監控告警」等不同應用需求，現在市面上有有許多的工具在協助我們完成這些工作。

這篇主要是針對微服務中可觀測性的概念進行交代，但是隨著你選擇的「工具」不同，你可能還需要去理解這些工具的架構，包含高可用、資料儲存等，每一項工具都需要相當的時間來學習才可以在實務上正常的規劃與應用。當你導入微服務時，除了應用程式的開發，你可能還需要很多時間花費的基礎架構的維護。