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

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

應用程序的內(nèi)部工作原理

系統(tǒng)的當前狀態(tài)，無論多么極端或異常

用戶當前遇到的問題

為什么系統(tǒng)會以某種方式運行——無需猜測

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

可觀察性與監(jiān)控有何不同

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

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

監(jiān)控基于許多不再適用于現(xiàn)代應用程序的假設。例如，監(jiān)控假設：

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

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

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

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

為什么可觀察性很重要

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

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

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

可觀察性的支柱

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

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

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

指標

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

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

日志

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

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

痕跡

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

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

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

DevOps 團隊需要什么

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

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