可觀察性一詞源于控制理論。RE Kálmán 在 1960 年將其定義為衡量您從系統外部輸出的知識推斷系統內部狀態的能力。可觀察性是一個非常強大的概念，因為它可以讓您了解系統的內部狀態，而無需內部工作的復雜性。換句話說，您只需查看輸出即可了解發生了什么。

在過去的十年中，軟件和架構已經從運行單個進程的單一應用程序發展到復雜的架構，包括分布在眾多節點上的數百甚至數千個服務。這種演變需要不同的工具和技術來推理構成現代軟件的不同組件。當您使可觀察性適應軟件時，它允許您以新的方式與您編寫的代碼進行交互和推理。可觀察的系統允許您回答開放式問題并理解：

應用程序的內部工作原理

系統的當前狀態，無論多么極端或異常

用戶當前遇到的問題

為什么系統會以某種方式運行——無需猜測

人們對可觀察性的含義有不同程度的理解。對于一些人來說，這只是偽裝成一個新流行詞的老式監控。但究竟什么是可觀察性，它與監控有何不同？

可觀察性與監控有何不同

許多公司長期以來一直使用基于指標的工具系統和監控來推理他們的系統并解決問題。這些組織中的 IT 運營部門匯總了指標，并使用懸掛在其 IT 室周圍的大屏幕顯示大量儀表板。

在分布式架構時代之前，監控是一種反應式方法，適用于傳統應用程序。但是，監控有一個缺陷：您無法完全查看或了解您的系統。監控迫使你做出反應，推測出了什么問題。

監控基于許多不再適用于現代應用程序的假設。例如，監控假設：

• 您的應用程序是單片的。
• 您有靜態數量的節點或主機要監控。
• 只有當災難發生時，你才會觀察一個系統。
• 該應用程序在虛擬機或裸機上運行，??讓您可以完全訪問系統指標。
• 您可以通過儀表板和遙測滿足運營工程師的需求。

由于以下原因，這些假設在現實中不再適用于現代架構：

• 有許多服務需要管理。
• 有許多具有不同技術的存儲可供觀察。
• 基礎設施是高度動態的，容量的出現和消失取決于需求。
• 要監控的主機或節點的數量總是在變化和不可預測的。
• 自動儀器不足以了解復雜系統中正在發生的事情。
• 許多分散且松散耦合的服務正在管理中，其中許多服務不受站點可靠性工程團隊的直接控制。

分布式系統中的故障模式是不可預測的。它們經常發生并且很少重復，以至于大多數團隊無法設置適當且相關的儀表板來監控它們。這就是可觀察性如此重要的地方。它使工程團隊能夠以各種方法收集遙測數據，從而使他們能夠診斷問題而無需先預見錯誤是如何發生的。

為什么可觀察性很重要

一個可觀察的系統比不那么顯眼的系統更容易了解（一般和非常詳細）、監控、用新代碼更新和修復。但除此之外，還有更多理由讓您的系統可觀察。可觀察性將幫助您：

• 發現并解決“未知的未知”或您不知道的問題：監控系統最重要的限制之一是它們只尋找“已知的未知”或您已經知道的異常情況。可觀察性識別您不會意識到或不會考慮搜索的情況。然后，它監控它們與特定性能問題的聯系，為根本原因識別和解決提供上下文。
• 在開發過程的早期識別和解決問題：可觀察性將使您深入了解軟件開發過程的早期階段。在新代碼中的問題損害用戶體驗或服務水平協議 (SLA) 之前，開發團隊能夠發現并修復它們。
• 節省時間：沒有可觀察性，開發人員只能瘋狂猜測 X 和 Y 發生的原因。就時間和資源而言，這是非生產性的并且成本高昂。
• 提供深刻見解：可觀察性讓您了解根本原因。

總而言之，您需要可觀察性，以便讓您的 DevOps 團隊能夠調查任何系統，無論您的系統有多復雜，而無需依靠經驗或深入的系統知識來分析根本原因。

可觀察性的支柱

可觀察性為系統狀態提供了無與倫比的可見性。但這種可見性伴隨著一些指導支柱或原則。當您正確剖析可觀察性時，它有兩個關鍵要素。首先是需要理解復雜系統的人，其次是有助于理解的數據。如果不承認人員和技術以及它們之間存在的交互，您就無法獲得適當的可觀察性。

有了這種理解，問題就來了：如何收集數據并將其組合起來進行檢查以提供所需的洞察力？處理和傳輸數據的技術要求是什么？

這就是被稱為指標、日志和跟蹤的三大可觀察性支柱發揮作用的地方。讓我們一一看看。

指標

指標（也稱為時間序列指標）是跨時間的應用程序和系統運行狀況的基本指標。一個指標可以是應用程序在特定時期內消耗了多少內存或 CPU 容量。度量將包括時間戳、名稱和表示某個值的字段。

在監控方面，指標是一個顯而易見的起點，因為它們對于描述資源狀態很有用。也就是說，您可以根據已知問題提出問題，例如“系統是活的還是死的？”度量標準旨在提供對已知問題的可見性。對于未知問題，您需要的不僅僅是指標。您需要上下文，而該上下文的一個有價值的信息來源是日志。

日志

日志是應用程序事件的詳細、不可變和帶時間戳的記錄。開發人員可以使用日志來創建每個事件的高保真、逐毫秒記錄，并附上上下文，他們可以“回放”以進行故障排除和調試等。因此，事件日志對于檢測分布式系統中的緊急和意外行為特別有用。因此，由于單個系統組件中發生單個事件，因此在復雜的分布式系統中很少發生故障。

系統應該通過日志記錄任何給定時間它正在做什么的信息。因此，日志可能是 DevOps 團隊工具箱中第二重要的項目。此外，日志提供了比指標更詳細的資源信息。如果指標表明資源不再可操作，日志可幫助您找出原因。充分利用日志的關鍵是保持合理的收集。通過限制您收集的內容來做到這一點。此外，在可能的情況下，關注常見領域，以便更快地發現大海撈針。

痕跡

跟蹤是一系列因果關聯的分布式事件的表示，這些事件對分布式系統的端到端請求流進行編碼。當請求進入應用程序時開始跟蹤。隨著用戶請求從服務轉移到服務，跟蹤使整個系統的行為和狀態更加可見和易于理解。

由于跟蹤具有豐富的上下文，因此您可以全面了解系統所有不同部分中發生的情況，因為傳統上對 DevOps 團隊隱藏的請求通過。跟蹤提供了對應用程序整體運行狀況的重要可見性。

跟蹤還可以分析和監控系統，例如容器化應用程序、無服務器架構和微服務架構。然而，它們主要關注應用層，僅提供底層基礎設施健康狀況的有限視圖。因此，即使您收集了跟蹤、指標和日志，仍然需要全面了解您的環境。

DevOps 團隊需要什么

盡管可觀察性這個術語是幾十年前創造的，但它對軟件系統的使用或適應提供了一種思考我們制作的軟件的新方法。隨著軟件和系統變得越來越復雜，人們會遇到難以預測、調試或計劃的問題。DevOps 團隊現在必須能夠以靈活的方式持續收集遙測數據，從而使他們能夠診斷問題，而無需先預見錯誤可能發生的方式，以便對問題進行故障排除并構建可靠的系統。

雖然日志、指標和跟蹤很重要，但除非您以正確的方式使用它們，否則它們不足以具有可見性。為了產生有助于故障排除和性能調整的理解，可觀察性需要將此數據與豐富的上下文相結合。簡而言之，如果僅使用來自狀態和控制向量的所有可行發展的輸出信息（物理上，這通常對應于傳感器獲得的信息），可以確定當前狀態，則系統被認為是可觀察的。