概述

在 Kubernetes 的生態系中，我們獲得了前所未有的容器彈性，這大大助益於微服務的建構與複雜的容器編排。它為我們提供了一個強大且靈活的平台，使我們能夠快速響應並適應變動多端的需求。

然而，隨著服務越來越複雜，背後所需要的技術也變得更為精密和進階。僅僅有一個完善的容器化架構是不夠的，我們還需要更深入的技術來確保整個產品能夠安全無虞地在線上運行。這也是為什麼「可視化的三本柱」— 日誌 (Logging)、追踪 (Tracing) 以及指標 (Metrics) — 變得至關重要。它們不僅提供了系統的透明度，還使我們能夠迅速地定位、解決問題，確保提供最佳的使用體驗。

可觀測性三本柱 Three Pillars of Observability

可觀測性三本柱定義為指日誌（logs）、指標（metrics）、追蹤（traces），都依賴於「事件（event）」的概念，也可以想成人們透過對事件的觀察，逐漸歸納出現代可觀測性的各種性質。

事件本質上是監控與遙測的基石，不論是已被定義的事件或是離散又獨特的事件，每個事件能有一些蛛絲馬跡來確認它曾經發生。通常我們會透過這些事件的上下文，來拼湊出事務的全貌，特別像在用戶之間的操作中，我們可以來回審視是否事件產生出來的上下文如同我們的預期，例如，一個用戶在瀏覽器中點擊「立即支付」的按鈕，那這按下「立即支付」按鈕的事件，是否如同我們的預期在理想中的 ２ 秒內，就跳轉到結帳成功的頁面。

可觀測性解決方案首先是追蹤在某個時間點發生的個體操作事件，在監控工具搜集的資訊下，系統管理員需要知道關於重大事件，包括潛在的風險以及系統當前狀況..等，這通常代表著：

• 自動觸發警報通知維運人員某個特定事件的發生
• 診斷以及定位出為什麼某個事件為何發生

像是當硬碟空間使用率已到達 90% 肯定是每個系統管理者腎上腺素激增的事件，但除了清除舊資料或加大空間的緊急應變之外，我們更多的是需要關於這些激增的資料量是來自哪一個應用服務，且是否為正常使用。

什麼是日誌（Logs）

日誌是紀錄系統環境中發生的事件、警告、錯誤的文件，大多數的日誌都包含上下文訊息，例如事件發生的時間以及與之關聯的用戶或端點，他們很容易生成，並為我們提供有關我們關心的事件的詳細訊息，包括：

• 記錄著所有請求訊息的 HTTP Access Logs
• 應用服務中包含 Info、Debug、Warning、Error 等級的訊息，幫助我們了解內部狀況的 App Logs
• 可以追溯敏感操作的 Audit Logs

就讓我們觀察在一個實際情況下，用戶與系統交互溝通的行為：

有家咖啡店有個由各種組件組成的系統，其中一個就是收銀機，這時我們可以讓收銀機在每次進行金融交易時產生日誌。對於這些每筆交易的日誌，我們可以捕獲：

• 消費者訊息
• 購買時間
• 購買項目
• 結帳金額

在這裡的收銀機就像是系統中的一個服務，運作的同時也產生出交易日誌，以便記錄紀錄已發生事件的詳細訊息，以便之後排查問題時參考。

優點：

• 日誌是一種非常容易生成的格式，通常是由時間戳加上相關訊息文字，在系統中都已有成熟功能開箱及用。
• 大多數的平台都提供了標準化的日誌記錄和機制，幫助我們統一格式。
• 不但是純文字，且不同於其他事件，日誌是人類可以直接閱讀的形式。

缺點：

• 日誌很容易不小心產生大量數據，在雲端上的儲存、流量、寫入都可能產生大量成本。
• 發送或寫入過多的日誌可能會影響應用服務效能，甚至在某些服務中寫入日誌是一種會堵塞的同步操作。
• 關於日誌持久性沒有特別處理，可能導致在微服務、VM、容器頻繁的生成消滅的過程中遺失。

什麼是指標（Metrics）

指標是很具有實際量化意義的數值，可表示系統某一方面的健康狀況。在許多場景中，指標很直觀地收集 CPU、Memory 和硬碟使用率指標，都是直接與系統運行狀況相關的明顯自然指標。面對系統中成千上萬的指標事件，我們需要非常謹慎小心的去分析他們，這是一個專業領域，通常我們會使用許多工具來輔助我們判斷並且期望他適當發出告警，替我們爭取處理時間。

再回到咖啡店的比喻，假設每當成交時系統也同時發送了記錄著消費金額的指標，那現在我們想要計算我們在過去十分鐘內賺進的總金額。我們可以藉由此指標達成此操作。

指標不只是能簡單的幫我們相加數值，還可以從多種維度讓我們了解系統在一個時間內的趨勢，像是每小時的客戶數量或者是每筆訂單所需要的平均時間。

優點：

• 高度定量且通常可以直觀的與告警閥值關聯。
• 輕量且儲存和檢索成本低廉。
• 指標非常擅長呈現一段時間內的趨勢，以便了解系統的變化過程。
• 指標的傳輸與儲存通常穩定，不會隨著流量或系統負載而增加。

缺點：

• 指標只能明確告訴你某個事實已經發生，但無法讓你知道其背後的原因。
• 指標通常以固定時間間隔收集，這意味著他們在其中的空窗期有可能丟失重要的細節。

什麼是追蹤（Traces）

追蹤資料是一個相對較新的概念，有鑒於近年來微服務的興起，使人們不得不尋找可以串連分佈式系統互動的解決方案。它有助於我們追蹤流轉在不同服務元件中的相關訊息，並且統一拼湊出完整的整個事件的過程，從而找到瓶頸所在，雖然他可能沒辦法告訴你系統異常的原因，但它可以幫助你縮小無數中個組件的故障範圍。

對於追蹤，我們可以從製作咖啡的咖啡師以及使用咖啡機的角度捕捉資訊。

系統中的每個組件被捕捉的資訊稱為 Span（跨度），當我們組合出同一個追蹤的 Span 時，我們就得到了完整的分布式追蹤事件。其中有個串連起相關 Span 的關鍵辨識點，像是 trace id 或 parent id 等等。

優點：

• 非常適合識別分佈式系統發生問題的組件或步驟。
• 可以提供跨多個服務的請求和響應流程的端到端可見性，使我們能夠了解整個系統的行為。
• 擅長識別可能影響最終用戶整體體驗的性能瓶頸以及優化將產生最大影響的地方。
• 通過提供請求和響應流的詳細記錄，可以用來排查分佈式系統中的問題。

缺點：

• 如果沒有使用 Service Mesh 等預設全局拓樸方案，可能會需要對每個元件或服務各自埋入相關程式碼。
• 沒有進一步聚合和處理，它無法呈現一段時間內的趨勢或模式。
• 無法點出失敗的原因，需要另外透過日誌或者是指標來定位問題。
• 可能會增加系統開銷亦或者是降低效能增加延遲。

結論

在我們深入探討可觀測性的三本柱之後，我們可以清楚地看到它們各自的優缺點。每一柱都為我們提供了對系統運作的獨特視角，但也帶來了自己的挑戰。

這就是為什麼工具選擇如此關鍵。接下來要介紹的服務 Grafana 不僅僅是一個可視化工具，它也是一個綜合性的可觀測性平台。它的設計考慮到了這三本柱的獨特性質和挑戰，並嘗試通過一個統一的界面來解決它們。特別是，Grafana 在整合、分析和視覺呈現來自不同來源的數據時，從而幫助使用者輕鬆地跨越界限。

相關程式碼同步收錄在：

https://github.com/MikeHsu0618/grafana-stack-in-kubernetes/tree/main/day4

References

Metrics vs. Logs vs. Traces (vs. Profiles) - SquaredUp

The Three Pillars of Observability: Metrics, Logs and Traces

The 3 pillars of observability: Logs, metrics and traces | TechTarget