如果您之前對可觀測性重要性，益處，以及組成不甚了解，本文是一個合適的指南手冊。

(資料圖片)

什么是可觀測性？

可觀測性被定義為根據系統產生的輸出數據（如日志，指標和鏈路追蹤）來衡量當前系統運行狀態的能力。

可觀測性目前被廣泛的用于提升分布式 IT 系統的穩定性（系統復雜度成倍提升，在故障或者異常時很難快速定位和解決），它利用指標、日志和鏈路追蹤三種類型數據，為分布式系統內部運行狀態提供了深度透視能力，協助 DevOps 工程師解決各種問題并提升系統性能。

如果您還不明白什么是可觀測性，那么讓我們這樣說吧: 可觀測性是可以幫助團隊高效調試其系統的工具或技術解決方案。可觀測性基于探索事先未定義的屬性和模式（幫助我們主動地探索事先未定義的屬性和規律，類似于解謎過程中的探索和揭示隱藏信息的能力）。

為什么可觀測性很重要？

在大規模分布式系統上開展工作的跨職能團隊，具備可觀測性能力，特別是在生產環境中，可以精確的識別異常，做出更快速有效的反應。

通過可觀測性系統，一旦確定導致應用程序性能下降的原因，就可以在它影響整體系統的性能或導致系統停擺之前來修復它。

可觀測性帶來的收益不僅限于 IT 場景，當您收集和洞察可觀測性數據時，您還可以看到數字服務對您所在組織產生的影響。

通過透視系統運行狀況的視角能夠讓您從監測用戶體驗 SLO （服務水平目標）的結果，來確保軟件發布達到業務目標，并且根據業務影響選擇各事項的優先次序。

可觀測性與監控之間的區別

對于初級 DevOps 或剛剛開始 SRE（站點可靠性工程師）的人來說，徹底理解可觀測性與監控之間的區別非常重要。

以下是?DORA（ DevOps 研究和評估）（/architecture/devops/devops-measurement-monitoring-and-observability?hl=zh-cn）團隊研究關于可觀測性和監控的內容。

監控是可以幫助團隊觀察和了解其系統狀態的工具或技術解決方案。監控基于收集一組預定義的指標或日志。

可觀測性是可以幫助團隊高效調試其系統的工具或技術解決方案。可觀測性基于探索未預先定義的屬性和模式。

利用系統輸出到外部數據來識別系統內部狀態的能力被定義為可觀測性。

在 IT 領域，我們可以把可觀測性理解為利用日志、指標和鏈路追蹤來理解軟件內部狀態的能力。

同時，監控是指從系統中獲取數據（日志、指標和鏈路追蹤）的過程。

大多數監控工具都提供了一個拖拽交互的儀表盤來顯示您所選擇的數據和它們各自的指標。然而，這種方法存在一個重要的缺點，因為通常團隊根據個人偏好來構建此類儀表板，可能會導致重要指標的遺漏、性能異常和數據缺失的問題。

其次，大多數監控工具要么可能是是因為安全問題，要么可能是由于代理程序采集數據的能力不足，在復雜的云原生應用和容器化環境不能很好兼容。

相比之下，可觀測性工具在兼容性方面表現更好，因為它們專注于收集整個基礎設施中的日志、鏈路追蹤和指標數據，還能夠及時通知 DevOps 工程師，使他們能夠在問題變成實際問題之前就能察覺到并采取行動。

簡而言之，監控告訴您系統發生了故障，而可觀測性可以幫助您找出系統故障的原因。

可觀測性有什么好處

可觀測性對于終端用戶、企業和 IT 團隊都帶來了顯著的優勢。下面列舉了可觀測性的主要好處以及可觀測性的重要性：

應用程序性能監控：全面的端到端可觀測性幫助企業更快地識別性能問題，甚至能夠捕捉由于采用云原生和微服務架構而引起的問題。借助先進的可觀測性解決方案，可以自動化更多的任務，提高運維和開發團隊的生產力和創造力。

DevSecOps 和 SRE ：可觀測性應該是應用程序及其底層基礎設施的基本特征，而非單純使用新工具的結果。軟件設計團隊和開發團隊需確保其所開發的程序易于觀測。在軟件交付的整個生命周期中，DevSecOps 和 SRE 團隊能夠利用和理解可觀測數據，以創建更強大、更安全、更具彈性的應用程序。

基礎設施、云和 Kubernetes 的監控：可觀測性的一個好處是它有助于基礎設施監控。基礎設施和運維（ I&O ）團隊可以利用可觀測性解決方案提供更好的異常事件上下文環境，從而更快地識別和解決問題，優化資源利用率，并提高對基礎設施和應用程序的管理能力。

終端用戶體驗：舒適的用戶體驗可以提升企業的聲譽和收入，為其帶來競爭優勢。通過可觀測性解決方案，企業能夠在終端用戶察覺問題之前發現并解決這些問題，并在用戶提出之前實施改進措施，從而提高客戶滿意度和留存率。

可觀測性的主要組成部分是什么？

指標、日志和分布式鏈路追蹤是可觀測性的三個主要方面，也被稱為“可觀測性的三大支柱”。將這三個支柱相結合，而不是單獨使用它們，可以顯著提高微服務架構中應用的監控和管理能力。由于微服務架構的復雜性，傳統的監控方法可能無法滿足對系統的全面觀測和調試需求。

事件日志、指標和鏈路追蹤是可觀測性的三大支柱，它們不僅可以單獨使用，還可以通過綜合利用它們的數據來提供更全面的觀測。通過綜合使用三支柱的數據，我們可以更好地理解和優化系統的性能和行為。這對于 DevOps 團隊來說，將顯著提升其生產力，并為用戶提供更好的體驗。

日志

事件日志記錄包含時間戳，并且是三個支柱中信息提供最詳細信息的一個。通常情況下，開發人員負責在代碼中進行日志記錄。

而且由于大多數軟件包和編程語言已經內置了日志記錄功能，因此實現事件日志記錄非常簡單。

事件日志在面對非典型或極端事件的場景下表現出色，它能夠提供更詳細的信息和上下文，這是通過平均值和百分位數指標無法涵蓋或揭示的。

因此，事件日志能夠幫助我們更好地了解分布式系統中較少發生但對系統性能和穩定性具有重要影響的意外行為。

指標

在一段時間內收集的數據可以通過數值指標的形式進行表示。這些指標利用數學建模和預測能力，可以更加全面地了解系統在當前和未來時期內的行為方式。

通過對指標的存儲、處理、壓縮和檢索進行優化，我們能夠實現更長時間范圍內的數據保留，并且簡化查詢操作。因此，指標數據非常適合用于創建展示歷史模式的儀表板。

同時，使用指標還可以逐漸降低數據的分辨率。在一定的時間段后，我們可以將數據聚合成每日或每周的頻率指標。這樣做可以有效減少數據的復雜性，同時方便分析和理解數據。

鏈路追蹤

分布式系統中的端到端請求流程可以被編碼成一條完整的調用鏈，這個調用鏈代表了一系列分散事件的具體請求路徑。

鏈路追蹤數據的結構類似于事件日志，它們記錄了請求的不同階段。每個獨立的請求鏈路可以深入了解請求的結構，并且展示了請求在不同組件或服務上經過的路徑。了解請求的結構有助于理解不同組件或服務之間的異步交互方式，以及這種異步交互對請求的執行時間、順序和并發性等方面的影響。整個請求路徑可以幫助軟件工程師和 SRE 清晰地了解涉及的各個組件或服務。

通過理解請求的完整生命周期，我們可以調試多個服務的請求，以確定延遲增加或資源使用量增加的原因。這使得我們能夠更好地分析和優化系統性能。

可觀測性如何運作？

可觀測性平臺是一個集成現有指標數據的工具，它能夠為應用程序和基礎設施組件添加新的監測數據。該平臺的主要功能是持續地識別和收集性能數據，并提取關鍵信息。

一般而言，可觀測性平臺會收集指標、鏈路追蹤和日志數據，并且實時地將它們串聯起來。通過將這些數據整合到一起，該平臺為 DevOps 團隊、SRE 團隊和 IT 人員提供了詳盡的上下文信息，包括每個事件的具體細節、發生位置和原因。這樣的上下文信息對于識別、分析和解決應用程序性能問題非常有價值。

可觀測性實現面臨哪些挑戰？

雖然實現可觀測性一直以來都是一個具有挑戰性的難題，但是隨著云服務的復雜性日益增加并且企業加速采用云服務的趨勢，解決這個問題變得至關重要。特別是在微服務和容器化應用的環境下，云服務所產生的監控數據變得更加廣泛和復雜。與過去相比，它們不僅數量更多，而且種類和規模也更大，超出了傳統監控系統所能提供的數據范疇。

關于可觀測性實現，通常會面臨以下困難：

數據孤島：由于存在眾多采集代理程序、用不同的數據源和獨立的監控工具，各工具之間沒有很好的集成或協同工作，很難全面理解應用程序、各種云服務和數字渠道（包括 Web 、移動網絡和物聯網）之間的相互依賴關系。

大規模、高速度、多樣性和復雜性挑戰：在使用 AWS、Azure 和 GCP ( Google Cloud Platform )等現代云服務基礎設施的架構中，各服務和組件產生的原始指標數據量非常龐大，選擇之前的監控方案，幾乎不可能找到答案（很難有效地處理和分析這些數據，從中獲取有用的信息和答案）。使用 Kubernetes 和容器進行快速擴縮容的能力，導致了更頻繁的數據生成和變動，增加了對數據管理和分析的挑戰。

缺乏預生產環境：盡管進行了預生產模擬高負載的測試，但開發人員依然缺少準確觀測或理解實際情況的方法，代碼發布前無法在生產環境中，了解到真實用戶的操作（真實行為、網絡延遲、不同地理位置的訪問等因素）如何影響應用程序和基礎設施。

排查故障耗費大量時間：為了解決問題并試圖確定問題源頭，實施團隊，運維團隊，基數設施團隊，開發團隊和數字體驗團隊（ DX ，客戶與企業所有數字渠道互動的方式，是您整體客戶體驗的重要組成部分）都被納入故障排除工作。但是結果是，寶貴的時間被浪費在猜測和理解指標數據上。

可觀測性與 DevOps 有何關系？

在 DevOps 中，可觀測性是必不可少的。如果您想充分利用 DevOps 所提供的所有優勢，可觀測性是一個關鍵要素。因為 DevOps 方法論的一個關鍵目標之一就是項目交付的一致性（consistent project delivery）。

DevOps 的概念要求實施 CI/CD（持續集成和持續交付）。了解變更對應用程序可能會產生的影響是及其重要的！此外， 它使開發者在產品分發給用戶時能夠控制活動，確保用戶獲得更好體驗。

通過實施可觀測性的方法和工具，您可以處理復雜性問題。首先，它通過觀測應用程序的輸出來幫助您能夠深入了解應用程序和系統的運行情況，從而更好地識別和解決潛在的問題。此外，它可以幫助我們精確定位問題，并確定問題發生的具體時間和位置。

如何實踐可觀測性？

要實現可觀測性，您的系統和應用程序必須提供指標收集必要的指標數據。您可以通過自己創造的工具、利用開源軟件或購買商業的可觀測性解決方案來創建一個可觀測的系統。

以下是開始實踐可觀測性的幾個步驟：

確定業務目標：通過優化系統資源來減少基礎設施支出、并且通過支持容量規劃以促進業務增長，以及提高關鍵業務指標的表現（如平均恢復時間），強大的可觀測性配置可以幫助提高利潤或凈收入。 通過向支持人員提供額外的上下文數據，可以促進問題的透明度，甚至創造積極的客戶體驗。然而，針對不同的業務目標，所需的可觀測性配置可能會有很大的差異。一旦您確定了主要的業務目標，您需要制定一個可觀測性策略，以確保您擁有適當的手段和工具來支持這些目標的實現。

關注正確的指標：精心設計的可觀測性方法，您可以在問題出現之前就預測到潛在的錯誤或故障，并準確定位根本原因。 為了追求透明度，需要進行多種數據收集、分析以及其他監控和測試技術，以便全面了解和評估所涉及的內容。

事件日志：對于架構和開發團隊來說，事件日志是分布式系統中可觀測性的重要數據源。有很多專為捕獲和存儲事件日志設計的工具，如Prometheus、Middleware和Splunk。 這些事件信息可能包括系統的各種過程的成功信息、重大系統故障、意外停機或導致系統過載的流量變化。 因為它為開發人員提供了關鍵的取證信息，用來發現有缺陷的組件或有交互有問題的部分，所以這對于調試和定位錯誤處理尤為重要。

訪問可視化數據：當成功采集到可觀測性數據時，這些原始數據必須被壓縮成通用的格式。通常再使用各種可視化工具對這些數據進行可視化渲染。 通過這樣方式，團隊成員就可以高效的將該信息傳遞或分享給其他相關的團隊。

選擇合適的可觀測性平臺：在選擇合適的可觀測性平臺時，請考慮以下因素：

工具是否免費？

是否使用開源采集代理工具？

工具是否易用？

是否具備發揮該工具最大潛力所需的技術知識儲備？

工具的處理能力可以適應何種數據規模？

通過回答這些問題和其他與業務相關的問題，將幫助您做出明智的決策。

結論

一個可觀測性系統需要與業務平臺進行適配和兼容，否則可能會帶來一些問題。這些問題包括：

系統變得笨重：如果系統無法適應不兼容的平臺，可能導致系統變得復雜、難以管理和使用。

增加運營成本：為了維護和支持系統，在不兼容的平臺上可能需要額外的資源和投入，從而增加了運營成本。

缺乏效果和可見性：如果系統無法提供令人滿意的功能和足夠的可見性，就無法有效監控和了解系統的運行情況。

因此，在實施過程中，我們需要明確希望通過可觀測性系統解決的關鍵問題，以確保系統能夠提供精準且有用的數據和可靠的見解。這些數據和見解可以幫助我們深入了解運營情況、問題和趨勢，從而支持企業的決策和運營。

如果沒有明確的指導方向，在構建可觀測性系統時可能會出現混亂的網絡，其中存在著相互沖突的問題，無法提供一致性的用戶體驗和支持。因此，需要有明確的目標和計劃，以確保系統的穩定性和有效性。

本文翻譯自：/what-is-observability/，譯者王梓禾，更多可觀測性體系建設思路，請參考《面向故障處理的可觀測性體系建設》（?/s/erX7Nl3IhmTihXpeBvmzHQ?）

標簽：