可觀測性是什么？ 入門指南
如果您之前對可觀測性重要性，益處，以及組成不甚了解，本文是一個合適的指南手冊。
什么是可觀測性？
可觀測性被定義為根據(jù)系統(tǒng)產(chǎn)生的輸出數(shù)據(jù)（如日志，指標和鏈路追蹤）來衡量當前系統(tǒng)運行狀態(tài)的能力。
可觀測性目前被廣泛的用于提升分布式 IT 系統(tǒng)的穩(wěn)定性（系統(tǒng)復雜度成倍提升，在故障或者異常時很難快速定位和解決），它利用指標、日志和鏈路追蹤三種類型數(shù)據(jù)，為分布式系統(tǒng)內(nèi)部運行狀態(tài)提供了深度透視能力，協(xié)助 DevOps 工程師解決各種問題并提升系統(tǒng)性能。
如果您還不明白什么是可觀測性，那么讓我們這樣說吧: 可觀測性是可以幫助團隊高效調(diào)試其系統(tǒng)的工具或技術解決方案?？捎^測性基于探索事先未定義的屬性和模式（幫助我們主動地探索事先未定義的屬性和規(guī)律，類似于解謎過程中的探索和揭示隱藏信息的能力）。
為什么可觀測性很重要？
在大規(guī)模分布式系統(tǒng)上開展工作的跨職能團隊，具備可觀測性能力，特別是在生產(chǎn)環(huán)境中，可以精確的識別異常，做出更快速有效的反應。
通過可觀測性系統(tǒng)，一旦確定導致應用程序性能下降的原因，就可以在它影響整體系統(tǒng)的性能或導致系統(tǒng)停擺之前來修復它。
可觀測性帶來的收益不僅限于 IT 場景，當您收集和洞察可觀測性數(shù)據(jù)時，您還可以看到數(shù)字服務對您所在組織產(chǎn)生的影響。
通過透視系統(tǒng)運行狀況的視角能夠讓您從監(jiān)測用戶體驗 SLO （服務水平目標）的結果，來確保軟件發(fā)布達到業(yè)務目標，并且根據(jù)業(yè)務影響選擇各事項的優(yōu)先次序。
可觀測性與監(jiān)控之間的區(qū)別
對于初級 DevOps 或剛剛開始 SRE（站點可靠性工程師）的人來說，徹底理解可觀測性與監(jiān)控之間的區(qū)別非常重要。
以下是?DORA（ DevOps 研究和評估）（https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability?hl=zh-cn）團隊研究關于可觀測性和監(jiān)控的內(nèi)容。
監(jiān)控是可以幫助團隊觀察和了解其系統(tǒng)狀態(tài)的工具或技術解決方案。監(jiān)控基于收集一組預定義的指標或日志。
可觀測性是可以幫助團隊高效調(diào)試其系統(tǒng)的工具或技術解決方案。可觀測性基于探索未預先定義的屬性和模式。
利用系統(tǒng)輸出到外部數(shù)據(jù)來識別系統(tǒng)內(nèi)部狀態(tài)的能力被定義為可觀測性。
在 IT 領域，我們可以把可觀測性理解為利用日志、指標和鏈路追蹤來理解軟件內(nèi)部狀態(tài)的能力。
同時，監(jiān)控是指從系統(tǒng)中獲取數(shù)據(jù)（日志、指標和鏈路追蹤）的過程。
大多數(shù)監(jiān)控工具都提供了一個拖拽交互的儀表盤來顯示您所選擇的數(shù)據(jù)和它們各自的指標。然而，這種方法存在一個重要的缺點，因為通常團隊根據(jù)個人偏好來構建此類儀表板，可能會導致重要指標的遺漏、性能異常和數(shù)據(jù)缺失的問題。
其次，大多數(shù)監(jiān)控工具要么可能是是因為安全問題，要么可能是由于代理程序采集數(shù)據(jù)的能力不足，在復雜的云原生應用和容器化環(huán)境不能很好兼容。
相比之下，可觀測性工具在兼容性方面表現(xiàn)更好，因為它們專注于收集整個基礎設施中的日志、鏈路追蹤和指標數(shù)據(jù)，還能夠及時通知 DevOps 工程師，使他們能夠在問題變成實際問題之前就能察覺到并采取行動。
簡而言之，監(jiān)控告訴您系統(tǒng)發(fā)生了故障，而可觀測性可以幫助您找出系統(tǒng)故障的原因。
可觀測性有什么好處
可觀測性對于終端用戶、企業(yè)和 IT 團隊都帶來了顯著的優(yōu)勢。下面列舉了可觀測性的主要好處以及可觀測性的重要性：
應用程序性能監(jiān)控：全面的端到端可觀測性幫助企業(yè)更快地識別性能問題，甚至能夠捕捉由于采用云原生和微服務架構而引起的問題。借助先進的可觀測性解決方案，可以自動化更多的任務，提高運維和開發(fā)團隊的生產(chǎn)力和創(chuàng)造力。
DevSecOps 和 SRE ：可觀測性應該是應用程序及其底層基礎設施的基本特征，而非單純使用新工具的結果。軟件設計團隊和開發(fā)團隊需確保其所開發(fā)的程序易于觀測。在軟件交付的整個生命周期中，DevSecOps 和 SRE 團隊能夠利用和理解可觀測數(shù)據(jù)，以創(chuàng)建更強大、更安全、更具彈性的應用程序。
基礎設施、云和 Kubernetes 的監(jiān)控：可觀測性的一個好處是它有助于基礎設施監(jiān)控?；A設施和運維（ I&O ）團隊可以利用可觀測性解決方案提供更好的異常事件上下文環(huán)境，從而更快地識別和解決問題，優(yōu)化資源利用率，并提高對基礎設施和應用程序的管理能力。
終端用戶體驗：舒適的用戶體驗可以提升企業(yè)的聲譽和收入，為其帶來競爭優(yōu)勢。通過可觀測性解決方案，企業(yè)能夠在終端用戶察覺問題之前發(fā)現(xiàn)并解決這些問題，并在用戶提出之前實施改進措施，從而提高客戶滿意度和留存率。
可觀測性的主要組成部分是什么？
指標、日志和分布式鏈路追蹤是可觀測性的三個主要方面，也被稱為“可觀測性的三大支柱”。將這三個支柱相結合，而不是單獨使用它們，可以顯著提高微服務架構中應用的監(jiān)控和管理能力。由于微服務架構的復雜性，傳統(tǒng)的監(jiān)控方法可能無法滿足對系統(tǒng)的全面觀測和調(diào)試需求。
事件日志、指標和鏈路追蹤是可觀測性的三大支柱，它們不僅可以單獨使用，還可以通過綜合利用它們的數(shù)據(jù)來提供更全面的觀測。通過綜合使用三支柱的數(shù)據(jù)，我們可以更好地理解和優(yōu)化系統(tǒng)的性能和行為。這對于 DevOps 團隊來說，將顯著提升其生產(chǎn)力，并為用戶提供更好的體驗。
日志
事件日志記錄包含時間戳，并且是三個支柱中信息提供最詳細信息的一個。通常情況下，開發(fā)人員負責在代碼中進行日志記錄。
而且由于大多數(shù)軟件包和編程語言已經(jīng)內(nèi)置了日志記錄功能，因此實現(xiàn)事件日志記錄非常簡單。
事件日志在面對非典型或極端事件的場景下表現(xiàn)出色，它能夠提供更詳細的信息和上下文，這是通過平均值和百分位數(shù)指標無法涵蓋或揭示的。
因此，事件日志能夠幫助我們更好地了解分布式系統(tǒng)中較少發(fā)生但對系統(tǒng)性能和穩(wěn)定性具有重要影響的意外行為。
指標
在一段時間內(nèi)收集的數(shù)據(jù)可以通過數(shù)值指標的形式進行表示。這些指標利用數(shù)學建模和預測能力，可以更加全面地了解系統(tǒng)在當前和未來時期內(nèi)的行為方式。
通過對指標的存儲、處理、壓縮和檢索進行優(yōu)化，我們能夠實現(xiàn)更長時間范圍內(nèi)的數(shù)據(jù)保留，并且簡化查詢操作。因此，指標數(shù)據(jù)非常適合用于創(chuàng)建展示歷史模式的儀表板。
同時，使用指標還可以逐漸降低數(shù)據(jù)的分辨率。在一定的時間段后，我們可以將數(shù)據(jù)聚合成每日或每周的頻率指標。這樣做可以有效減少數(shù)據(jù)的復雜性，同時方便分析和理解數(shù)據(jù)。
鏈路追蹤
分布式系統(tǒng)中的端到端請求流程可以被編碼成一條完整的調(diào)用鏈，這個調(diào)用鏈代表了一系列分散事件的具體請求路徑。
鏈路追蹤數(shù)據(jù)的結構類似于事件日志，它們記錄了請求的不同階段。每個獨立的請求鏈路可以深入了解請求的結構，并且展示了請求在不同組件或服務上經(jīng)過的路徑。了解請求的結構有助于理解不同組件或服務之間的異步交互方式，以及這種異步交互對請求的執(zhí)行時間、順序和并發(fā)性等方面的影響。整個請求路徑可以幫助軟件工程師和 SRE 清晰地了解涉及的各個組件或服務。
通過理解請求的完整生命周期，我們可以調(diào)試多個服務的請求，以確定延遲增加或資源使用量增加的原因。這使得我們能夠更好地分析和優(yōu)化系統(tǒng)性能。
可觀測性如何運作？
可觀測性平臺是一個集成現(xiàn)有指標數(shù)據(jù)的工具，它能夠為應用程序和基礎設施組件添加新的監(jiān)測數(shù)據(jù)。該平臺的主要功能是持續(xù)地識別和收集性能數(shù)據(jù)，并提取關鍵信息。
一般而言，可觀測性平臺會收集指標、鏈路追蹤和日志數(shù)據(jù)，并且實時地將它們串聯(lián)起來。通過將這些數(shù)據(jù)整合到一起，該平臺為 DevOps 團隊、SRE 團隊和 IT 人員提供了詳盡的上下文信息，包括每個事件的具體細節(jié)、發(fā)生位置和原因。這樣的上下文信息對于識別、分析和解決應用程序性能問題非常有價值。
可觀測性實現(xiàn)面臨哪些挑戰(zhàn)？
雖然實現(xiàn)可觀測性一直以來都是一個具有挑戰(zhàn)性的難題，但是隨著云服務的復雜性日益增加并且企業(yè)加速采用云服務的趨勢，解決這個問題變得至關重要。特別是在微服務和容器化應用的環(huán)境下，云服務所產(chǎn)生的監(jiān)控數(shù)據(jù)變得更加廣泛和復雜。與過去相比，它們不僅數(shù)量更多，而且種類和規(guī)模也更大，超出了傳統(tǒng)監(jiān)控系統(tǒng)所能提供的數(shù)據(jù)范疇。
關于可觀測性實現(xiàn)，通常會面臨以下困難：
數(shù)據(jù)孤島：由于存在眾多采集代理程序、用不同的數(shù)據(jù)源和獨立的監(jiān)控工具，各工具之間沒有很好的集成或協(xié)同工作，很難全面理解應用程序、各種云服務和數(shù)字渠道（包括 Web 、移動網(wǎng)絡和物聯(lián)網(wǎng)）之間的相互依賴關系。
大規(guī)模、高速度、多樣性和復雜性挑戰(zhàn)：在使用 AWS、Azure 和 GCP ( Google Cloud Platform )等現(xiàn)代云服務基礎設施的架構中，各服務和組件產(chǎn)生的原始指標數(shù)據(jù)量非常龐大，選擇之前的監(jiān)控方案，幾乎不可能找到答案（很難有效地處理和分析這些數(shù)據(jù)，從中獲取有用的信息和答案）。使用 Kubernetes 和容器進行快速擴縮容的能力，導致了更頻繁的數(shù)據(jù)生成和變動，增加了對數(shù)據(jù)管理和分析的挑戰(zhàn)。
缺乏預生產(chǎn)環(huán)境：盡管進行了預生產(chǎn)模擬高負載的測試，但開發(fā)人員依然缺少準確觀測或理解實際情況的方法，代碼發(fā)布前無法在生產(chǎn)環(huán)境中，了解到真實用戶的操作（真實行為、網(wǎng)絡延遲、不同地理位置的訪問等因素）如何影響應用程序和基礎設施。
排查故障耗費大量時間：為了解決問題并試圖確定問題源頭，實施團隊，運維團隊，基數(shù)設施團隊，開發(fā)團隊和數(shù)字體驗團隊（ DX ，客戶與企業(yè)所有數(shù)字渠道互動的方式，是您整體客戶體驗的重要組成部分）都被納入故障排除工作。但是結果是，寶貴的時間被浪費在猜測和理解指標數(shù)據(jù)上。
可觀測性與 DevOps 有何關系？
在 DevOps 中，可觀測性是必不可少的。如果您想充分利用 DevOps 所提供的所有優(yōu)勢，可觀測性是一個關鍵要素。因為 DevOps 方法論的一個關鍵目標之一就是項目交付的一致性（consistent project delivery）。
DevOps 的概念要求實施 CI/CD（持續(xù)集成和持續(xù)交付）。了解變更對應用程序可能會產(chǎn)生的影響是及其重要的！此外， 它使開發(fā)者在產(chǎn)品分發(fā)給用戶時能夠控制活動，確保用戶獲得更好體驗。
通過實施可觀測性的方法和工具，您可以處理復雜性問題。首先，它通過觀測應用程序的輸出來幫助您能夠深入了解應用程序和系統(tǒng)的運行情況，從而更好地識別和解決潛在的問題。此外，它可以幫助我們精確定位問題，并確定問題發(fā)生的具體時間和位置。
如何實踐可觀測性？
要實現(xiàn)可觀測性，您的系統(tǒng)和應用程序必須提供指標收集必要的指標數(shù)據(jù)。您可以通過自己創(chuàng)造的工具、利用開源軟件或購買商業(yè)的可觀測性解決方案來創(chuàng)建一個可觀測的系統(tǒng)。
以下是開始實踐可觀測性的幾個步驟：
確定業(yè)務目標：通過優(yōu)化系統(tǒng)資源來減少基礎設施支出、并且通過支持容量規(guī)劃以促進業(yè)務增長，以及提高關鍵業(yè)務指標的表現(xiàn)（如平均恢復時間），強大的可觀測性配置可以幫助提高利潤或凈收入。 通過向支持人員提供額外的上下文數(shù)據(jù)，可以促進問題的透明度，甚至創(chuàng)造積極的客戶體驗。然而，針對不同的業(yè)務目標，所需的可觀測性配置可能會有很大的差異。一旦您確定了主要的業(yè)務目標，您需要制定一個可觀測性策略，以確保您擁有適當?shù)氖侄魏凸ぞ邅碇С诌@些目標的實現(xiàn)。
關注正確的指標：精心設計的可觀測性方法，您可以在問題出現(xiàn)之前就預測到潛在的錯誤或故障，并準確定位根本原因。 為了追求透明度，需要進行多種數(shù)據(jù)收集、分析以及其他監(jiān)控和測試技術，以便全面了解和評估所涉及的內(nèi)容。
事件日志：對于架構和開發(fā)團隊來說，事件日志是分布式系統(tǒng)中可觀測性的重要數(shù)據(jù)源。有很多專為捕獲和存儲事件日志設計的工具，如Prometheus、Middleware和Splunk。 這些事件信息可能包括系統(tǒng)的各種過程的成功信息、重大系統(tǒng)故障、意外停機或導致系統(tǒng)過載的流量變化。 因為它為開發(fā)人員提供了關鍵的取證信息，用來發(fā)現(xiàn)有缺陷的組件或有交互有問題的部分，所以這對于調(diào)試和定位錯誤處理尤為重要。
訪問可視化數(shù)據(jù)：當成功采集到可觀測性數(shù)據(jù)時，這些原始數(shù)據(jù)必須被壓縮成通用的格式。通常再使用各種可視化工具對這些數(shù)據(jù)進行可視化渲染。 通過這樣方式，團隊成員就可以高效的將該信息傳遞或分享給其他相關的團隊。
選擇合適的可觀測性平臺：在選擇合適的可觀測性平臺時，請考慮以下因素：
工具是否免費？
是否使用開源采集代理工具？
工具是否易用？
是否具備發(fā)揮該工具最大潛力所需的技術知識儲備？
工具的處理能力可以適應何種數(shù)據(jù)規(guī)模？
通過回答這些問題和其他與業(yè)務相關的問題，將幫助您做出明智的決策。
結論
一個可觀測性系統(tǒng)需要與業(yè)務平臺進行適配和兼容，否則可能會帶來一些問題。這些問題包括：
系統(tǒng)變得笨重：如果系統(tǒng)無法適應不兼容的平臺，可能導致系統(tǒng)變得復雜、難以管理和使用。
增加運營成本：為了維護和支持系統(tǒng)，在不兼容的平臺上可能需要額外的資源和投入，從而增加了運營成本。
缺乏效果和可見性：如果系統(tǒng)無法提供令人滿意的功能和足夠的可見性，就無法有效監(jiān)控和了解系統(tǒng)的運行情況。
因此，在實施過程中，我們需要明確希望通過可觀測性系統(tǒng)解決的關鍵問題，以確保系統(tǒng)能夠提供精準且有用的數(shù)據(jù)和可靠的見解。這些數(shù)據(jù)和見解可以幫助我們深入了解運營情況、問題和趨勢，從而支持企業(yè)的決策和運營。
如果沒有明確的指導方向，在構建可觀測性系統(tǒng)時可能會出現(xiàn)混亂的網(wǎng)絡，其中存在著相互沖突的問題，無法提供一致性的用戶體驗和支持。因此，需要有明確的目標和計劃，以確保系統(tǒng)的穩(wěn)定性和有效性。
本文翻譯自：https://devopscube.com/what-is-observability/，譯者王梓禾，更多可觀測性體系建設思路，請參考《面向故障處理的可觀測性體系建設》（?https://mp.weixin.qq.com/s/erX7Nl3IhmTihXpeBvmzHQ?）
