可觀測性通常在三大支柱（日誌、指標和跟蹤）的上下文中定義。 現代雲原生應用程式是複雜且動態的。 為了避免意外和效能問題，您需要乙個強大的可觀測性堆疊。 但是，可觀測性是否僅限於收集日誌、指標和跟蹤？
翻譯自 signoz 部落格的 Three Pillars of Observability [and Beyond]。 由Leigh Finch撰寫。 在過去的 25 年中，監控工具一直是任何企業的關鍵組成部分，它提供有關基礎架構和應用程式問題的高階警報，以防止它們影響客戶。 隨著時間的推移，我們增加了監控系統中的指標數量，以更好地了解正在監控的系統。
然而，由於軟體系統的複雜性，僅依靠指標進行監控有其侷限性。 它通常無法識別可能導致數字體驗問題並影響終端使用者的未知變數。
最近'可觀察性'這一概念在行業中嶄露頭角，標誌著從傳統監控的轉變。 與後者不同，後者側重於預定義的指標，而可觀測性則強調了解系統在任何給定時間的狀態，包括前導和後續服務級別指標。 這種方法允許實時檢視效能問題或錯誤，而不管具體指標如何。 例如，使用像 Signoz 這樣的可觀察物件***來跟蹤 Web 請求可以顯示請求的整個過程和內部操作，從而提供比僅測量伺服器響應時間更全面的檢視。 它包括在特定請求（方法、類、資料庫查詢）上下文中完成的工作的詳細資訊。
可觀測性的三大支柱通常是指標、跟蹤和日誌。
在檢查指標時，它們通常表示特定指標在給定時刻的狀態。 這對於了解隨時間的變化至關重要，如時間序列圖所示，例如 CPU 利用率。
時間序列圖起源於最古老的監控工具之一，稱為 MRTG（多路由器流量圖器）。 MRTG 通常使用 SNMP（網路監控協議）每 5 分鐘收集一次資料，以圖形方式顯示路由器介面的利用率。 隨後，SNMP在Linux（甚至MS Windows）上流行起來，以定期輪詢間隔收集各種指標。 雖然SNMP仍然很受歡迎，但它不再是新方法的首選，包括OTEL收集器基於**的監控、REST API和流遙測。
兩種常見的指標型別與利用率和飽和度有關。 利用率指標指示資源使用率（如 CPU 和記憶體利用率）的百分比，或應用程式伺服器工作執行緒的使用率。 同時，飽和度指標反映了資源的爭用程度。 例如，磁碟佇列長度表示在給定時間間隔內超過磁碟處理能力的工作量。 在這裡，雖然利用率可能顯示為 100%，但飽和度顯示掛起的工作負載超出了系統的處理能力。
跟蹤提供了對事件隨時間推移的見解。 在 APM 和 OpenTelemetry 的上下文中，這通常涉及在探查器中嵌入庫或使用探查器來分析應用程式和執行時。 有關如何將 Spring Boot 與 OpenTelemetry 和 Signoz 整合以實現可觀測性的三大支柱的更多資訊，請檢視我的 Spring Boot 監控文章。 跟蹤的乙個典型示例是對 Web 前端的 HTTP 請求，該請求涉及多個任務來完成並返回響應。 考慮乙個 HTTP POST 請求，將新寵物新增到主人的個人資料中。 此請求包含 25 個工作跨度，每個跨度都包含有關工作單元的詳細屬性、SQL 語句、執行緒 ID 和服務詳細資訊。 
儘管可以從日誌中推斷出其中一些資訊，但跟蹤以上下文和標準化格式呈現這些工作單元。 像火焰圖和甘特圖這樣的跟蹤可以很容易地視覺化整個請求，因為它在複雜的分布式設定中遍歷不同的元件。 這種方法無需搜尋多個伺服器、容器和日誌檔案來跟蹤單個請求，從而節省了大量工作時間。
作為三個可觀測性支柱中最古老的乙個，日誌已經從基本的'print'語句演變為複雜的結構化格式。 儘管它們固有的靈活性和非結構化特性最初使分析具有挑戰性，但現代日誌記錄庫、框架和標準已顯著提高了其可用性。 Signoz 等工具提供日誌管道來轉換日誌，以滿足您的查詢和聚合需求。
Logback 和 Log4j 等框架簡化了日誌修改，因此可以輕鬆使用 OpenTelemetry 和 Signoz，無需單獨的日誌管道。 例如，Signoz 可以查詢 logback 的結構化字段、屬性和值，以過濾不相關的資料或隔離與特定跟蹤或跨度 ID 相關的日誌。
可觀測性已經從僅僅收集和分析三大支柱（日誌、指標和跟蹤）演變而來。 "上下文"它越來越被認為是除錯複雜分布式系統的關鍵元件，它補充了傳統的三大支柱：指標、日誌記錄和跟蹤。
上下文可以稱為可觀測性的第四個支柱 - 關聯不同的訊號並為可觀測性的三個支柱提供更多資訊。
在故障排除時，上下文至關重要。 它連線指標、日誌和跟蹤中的不同資訊。 這種相互聯絡有助於快速定位問題，了解其影響，並制定更有效的解決方案。
將上下文與可觀測性的三大支柱整合：
關聯的日誌和跟蹤：可以通過注入跟蹤和跨度識別符號來關聯日誌和跟蹤。 使用跟蹤來了解有問題的請求流，並確定問題在旅程中發生的位置。 然後，向下鑽取到這些特定跨度或服務的日誌，以獲取詳細的錯誤資訊。
具有上下文的指標：當指標與上下文相結合時，指標變得更有意義，而不僅僅是定量資料。 例如，當您知道哪個部署或更改觸發了資源使用量激增時，資源使用量的峰值會提供更多資訊。
可觀測性的未來趨勢是利用人工智慧根據學習模式進行快速資料解釋，以優先考慮關鍵資訊、站點可靠性工程 （SRE） 和可觀測性團隊，同時過濾掉不太重要的資料。 這種方法簡化了對最具影響力的問題的關注。 此外，AI 的作用還包括自動響應標準事件，例如收集相關除錯資訊和重啟服務。 這種自動化減少了恢復服務時對人為干預的需求，使團隊能夠專注於根本原因分析 （RCA） 和預防策略。
視覺化是可觀察性的關鍵，它將資料轉化為易於理解的故事，供各種受眾使用。 儀表板應將關鍵資訊傳達給所有技能水平和主題專業知識的使用者，而不僅僅是專家。
組織面臨的最大挑戰之一是建立儀表板，以在單個檢視中顯示所有可能的資訊。 如果您需要閱讀儀表板才能理解它，那麼它不是儀表板，而是報表。
有效的儀表板需要對目標受眾有同理心。 例如，高管可能只想知道某項服務是否可用且效能良好，因此他們可能只需要乙個紅綠燈。 相比之下，服務所有者可能會受益於更詳細的指標，例如使用者數量、平均效能以及 p95 和 p99 值，以識別異常值。
“有效儀表板的關鍵：簡單、可讀、以使用者為中心的設計。 ”
成熟度指數是我們如何應用和服務以了解可以採取哪些措施來降低數字體驗風險的有效基準。 為了評估成熟度，我們必須評估與服務相關的人員、流程和技術。
從人員方面開始，評估團隊的可觀測性技能以及組織對嵌入可觀測性實踐的承諾。
流程應減少對特定個人的依賴，並增強業務或服務的彈性。 例如，服務降級計畫可能概述了在瞬態事件期間從三個支柱收集資訊的步驟。
技術不僅僅是工具;它涉及充分利用這些工具來完全檢測服務。 本文以 Spring Boot 監視為例，討論使用三大支柱的檢測。 對於這些元素中的每乙個，我們將使用成熟度指數來應用當前狀態與期望狀態，以幫助我們將精力集中在投資哪些服務上。
我們全面介紹了現代雲原生應用程式中不斷發展的可觀測性。 它超越了傳統的監控，強調了可觀測性如何通過將上下文作為第四支柱的一部分而變得更加動態和更加互聯。 可觀測性的未來被認為越來越依賴人工智慧和有效的資料視覺化來使複雜的資料易於理解和可操作。
對於希望增強數字體驗和系統可靠性的組織來說，擁抱這些不斷發展的可觀測性方面至關重要。 關鍵是將這些實踐嵌入到他們的運營文化中，確保乙個強大、響應迅速和有彈性的技術生態系統。