可觀測性通常在三個支柱的背景下定義 - 日志，指標和跟蹤?，F代云原生應用程序復雜而動態。為了避免意外和性能問題，您需要一個強大的可觀測性堆棧。但是，可觀測性是否僅限于收集日志，指標和跟蹤呢？

譯自 SigNoz 博客的Three Pillars of Observability [And Beyond]。作者 Leigh Finch。

監控工具在過去 25 年一直是任何企業的關鍵組成部分，提供對基礎設施和應用程序問題的高級警報，以防止它們影響客戶。隨著時光的推移，我們在監控系統中增加了指標的數量，以更好地了解正在監控的系統。

然而，隨著軟件系統的復雜化，僅僅依賴指標進行監控存在其局限性。它通常無法識別可能導致數字體驗問題、影響最終用戶的未知變量。

最近，'可觀測性'的概念在行業中嶄露頭角，標志著從傳統監控的轉變。與后者專注于預定義的指標不同，可觀測性強調理解系統在任何給定時間的狀態，包括前導和后續的服務水平指標。這種方法允許實時了解性能問題或錯誤，而不受特定指標的限制。例如，使用像 SigNoz 這樣的可觀測性工具來跟蹤 Web 請求會展示請求的整個過程和內部操作，提供比僅測量服務器響應時間更全面的視角。它包括在特定請求的上下文中正在完成的工作的詳細信息（方法、類、數據庫查詢）。

可觀測性的三大支柱通常是指標、跟蹤和日志。

指標

在檢查指標時，它們通常代表在給定時刻的特定指標的狀態。這對于理解隨時間變化的情況至關重要，如在時間序列圖中所見，例如 CPU 利用率。

SigNoz 儀表板顯示的 K8s Pod CPU 利用率

時間序列圖起源于最古老的監控工具之一，名為 MRTG（Multi-Router Traffic Grapher）。MRTG 通常每 5 分鐘使用 SNMP（Simple Network Monitoring Protocol）收集數據，以圖形方式顯示路由器接口的利用率。隨后，SNMP 在 Linux（甚至是 MS Windows）上變得流行，以在定期輪詢間隔內收集各種指標。盡管 SNMP 仍然流行，但相較于新方法（包括 OTEL 收集器的基于代理的監控、REST API 和流式遙測），它不再是首選。

兩種常見的指標類型與利用率和飽和度相關。利用率指標指示資源使用的百分比，例如 CPU 和內存利用率，或應用服務器工作線程的使用情況。與此同時，飽和度指標反映了對資源爭用的程度。例如，磁盤隊列長度指示在給定間隔內超出磁盤處理能力的過多工作量。在這里，雖然利用率可能顯示為 100%，但飽和度揭示了超出系統處理能力的待處理工作負荷。

跟蹤

跟蹤提供了隨時間發生事件的洞察。在 APM 和 OpenTelemetry 的背景下，這通常涉及將庫嵌入代碼中，或使用分析器/代理對應用程序和運行時進行分析。關于如何將 Spring Boot 與 OpenTelemetry 和 SigNoz 集成以實現可觀測性的三大支柱，請參考我的《Spring Boot 監控》文章。

典型的跟蹤示例是對 Web 前端的 HTTP 請求，涉及多個任務以完成并返回響應?？紤]一個 HTTP POST 請求，用于向所有者的個人資料中添加新寵物。這個請求包含 25 個工作單元（Spans），每個單元包含有關工作單元的詳細屬性、SQL 語句、線程 ID 和服務詳細信息。

示例 HTTP 跟蹤

盡管可以從日志中推導出其中一些信息，但跟蹤以一種上下文和標準化的格式呈現這些工作單元。類似 Flamegraphs 和 Gantt 圖的跟蹤可輕松可視化整個請求，因為它在復雜的分布式設置中穿越不同組件。這種方法消除了需要搜索多個服務器、容器和日志文件以跟蹤單個請求的需求，從而節省大量工作時間。

日志

作為三大可觀測性支柱中最古老的一支，日志已從基本的 'print' 語句演變為復雜的結構化格式。盡管它們固有的靈活性和非結構化的性質最初使分析變得具有挑戰性，但現代日志庫、框架和標準顯著提高了它們的可用性。像 SigNoz 這樣的工具提供了日志流水線，以轉換日志以適應您的查詢和聚合需求。

按跟蹤 ID 聚合的示例日志

通過上下文增強日志

類似 Logback 和 Log4J 這樣的框架已經簡化了日志的修改，以便 OpenTelemetry 和 SigNoz 輕松消費，消除了需要單獨的日志流水線。例如，Logback 的結構化字段、屬性和值可以由 SigNoz 查詢，以過濾不相關的數據或隔離與特定跟蹤或跨度 ID 相關的日志。

示例日志顯示跟蹤和跨度 ID

超越三大支柱之外 - 上下文

可觀測性已經從僅僅收集和分析三大支柱（日志、指標和跟蹤）發展出來。"上下文（Context）" 被越來越認識為在調試復雜的分布式系統中的關鍵組成部分，它補充了傳統的三大支柱：指標、日志和跟蹤。

上下文可以被稱為可觀測性的第四支柱 - 關聯不同的信號，并為可觀測性的三大支柱提供更多信息。

上下文在可觀測性中的作用

在故障排除中，上下文至關重要。它連接了指標、日志和跟蹤中的不同信息片段。這種相互關聯有助于快速定位問題、理解它們的影響并制定更有效的解決方案。

將上下文與可觀測性的三大支柱集成：

• 關聯的日志和跟蹤：通過注入跟蹤和跨度標識符，可以將日志和跟蹤相關聯。使用跟蹤了解有問題請求的流程，并確定問題發生在旅程的哪個階段。然后，深入了解這些特定跨度或服務的日志，以獲取詳細的錯誤信息。
• 具有上下文的指標：與僅有數量數據相比，指標在與上下文相結合時變得更有意義。例如，當您知道哪個部署或更改觸發了資源使用率的激增時，資源使用率的激增就更具信息性。

可觀測性的未來趨勢是利用人工智能進行基于學習模式的快速數據解釋，以優先處理關鍵信息，站點可靠性工程（SRE）和可觀測性團隊，同時過濾掉不太重要的數據。這種方法簡化了對最具影響力問題的關注。此外，人工智能的作用還包括自動化對標準事件的例行響應，例如收集相關的調試信息和重新啟動服務。這種自動化減少了在恢復服務方面人為干預的需求，使團隊能夠集中精力進行根本原因分析（RCA）和預防性策略。

數據可視化 - 可觀測性的關鍵組成部分

在可觀測性中，可視化是關鍵，它將數據轉化為對各種受眾都易于理解的故事。儀表板應該向各個技術水平和主題專業知識的用戶傳達關鍵信息，而不僅僅是專家。

組織面臨的最大挑戰之一是創建能夠在單個視圖中顯示所有可能信息的儀表板。如果需要閱讀儀表板才能理解它，那么它不是儀表板，而是報告。

使儀表板易于消化

有效的儀表板需要對目標受眾有同理心。例如，高管可能只想知道服務是否可用和性能良好，因此可能只需要一個交通燈。相比之下，服務所有者可能從更詳細的指標中受益，例如用戶數量、平均性能以及 p95 和 p99 值，以識別異常值。

“有效儀表板的關鍵：簡單、可讀性強、以用戶為中心的設計?！?/p>

SigNoz 中的簡單 CPU 和線程儀表板

在組織中導航可觀測性成熟度

成熟度指數是一種有效的基準我們應用和服務的方式，了解可以采取哪些措施來降低數字體驗的風險。為了評估成熟度，我們必須評估與服務相關的人員、流程和技術。

首先從人員方面著手，評估團隊的可觀測性技能以及組織嵌入可觀測性實踐的承諾。

流程應該減少對特定個體的依賴，增強業務或服務的彈性。例如，服務降級計劃可能會概述在瞬態事件期間從三大支柱收集信息的步驟。

技術不僅涉及工具；它涉及充分利用這些工具來充分儀表化服務。以Spring Boot 監控為例，該文章討論了使用三大支柱進行儀表化的情況。

對于這些要素的每一個，我們將使用成熟度指數應用當前狀態與期望狀態的對比，以幫助我們集中精力投資于哪些服務。

結論

我們呈現了現代云原生應用中可觀測性不斷發展的全面視圖。它超越了傳統監控的范圍，突顯了可觀測性如何變得更加動態，并通過將上下文作為第四支柱的一部分而更加相互連接?？捎^測性的未來被視為越來越依賴人工智能和有效的數據可視化，以使復雜的數據變得可理解且可操作。

對于希望增強數字體驗和系統可靠性的組織來說，擁抱可觀測性的這些不斷發展的方面至關重要。關鍵是將這些實踐融入其運營文化，確保一個強大、響應迅速且具有彈性的技術生態系統。