2021年初，可觀測性的概念在國內市場還鮮少有人提到，但到了2021年下半年，有關可觀測性的研討和實踐卻開始如雨後春筍般層出不窮，知名公司 Grafana 甚至直接將原來的監控工具改成了可觀測性技術棧並推了一系列服務。可觀測性真的能夠解決傳統監控體系面臨的諸多問題嗎？又該如何構建可觀測體系？本期，亞馬遜雲科技 Tech Talk 特別邀請到觀測雲 CEO 蔣爍淼帶來分享《構建端到端的可觀測體系最佳實踐》。
可觀測性為何突然“火出圈”
可觀測性看似是個新鮮詞，但其實它的起源遠比我們的認知要早得多。可觀測性最早是匈牙利裔工程師魯道夫·卡爾曼針對線性動態系統提出的概念。若以訊號流圖來看，若所有的內部狀態都可以輸出到輸出訊號，此係統即有可觀測性。1948年伯特·維納發表的著作《控制論-關於動物和機器中控制和通訊的科學》同樣提到了可觀測性。控制理論中的可觀測性是指系統可以由其外部輸出推斷其內部狀態的程度。
隨著雲端計算的發展，可觀測性的概念逐漸走入計算機軟體領域。為什麼近期可觀測性的熱度顯著提升了呢？
蔣爍淼認為，這很大程度是由於系統複雜性的增強。IT 系統的本質是一個數字化的系統，過去，系統本身結構簡單，多為單體式架構，且基礎設施相對固定，可以通過監控去檢視系統。但隨著雲原生時代的到了，管理物件從單一主機逐漸變成雲，後來又變成雲原生的分散式複雜系統，傳統的面向基礎設施的監控、簡單的日誌和簡單的 APM 沒有辦法解決問題，因此，需要構建系統完整的可觀測性。
可觀測性中使用的主要資料類是指標、日誌、鏈路。它們通常被稱為“可觀測性的三大支柱”。
- 指標（Metric）：指標是連續時間下的系統的值的記錄，基礎指標通常用於描述兩種資料型別，一種是計數（Count），一種是計量（Gauge）。
- 日誌（Log）：系統/應用輸出的時間相關的記錄，通常由系統/軟體開發人員輸出，方便定位系統的錯誤和狀態。
- 鏈路（Tracing）：基於有向無環圖構建的軟體各個模組直接地呼叫關係。
三大支柱至關重要，開發者正是通過這三個維度的資料來判定應用系統的狀況。和傳統監控相比，可觀測體系擁有諸多優勢。
傳統監控面向已知的問題，只能去發現和通知那些已知可能會發生的故障，如：CPU>90%。主要監控物件是 IT 物件，僅面向服務端的元件，解決基礎的運維問題。
而可觀測性則能夠協助發現並定位未知的問題。其核心是不斷收集系統產生的各種核心指標與資料，通過資料分析的方式來保障和優化業務，如：發現小程式客戶端在某個城市的支付失敗率非常高，從而判斷是否是程式碼層面上導致這樣一個異常。可觀測性主要監測的物件不僅僅是IT物件，還有應用和業務，面向雲、分散式系統、APP/小程式。
在分享中蔣爍淼談到，隨著基礎設施的發展，傳統監控將逐步被可觀測性所取代。
他將構建可觀測性的價值總結為以下五點：
- 讓 SLO 視覺化，清晰的目標和現狀
- 發現與定位未知問題
- 減少團隊間的澄清成本
- 降低業務異常造成的無法預知的經濟損失
- 提升終端使用者體驗和滿意度
開源 or SaaS，可觀測性構建正確的開啟方式是？
相比於傳統監控體系，構建可觀測性既然有諸多優勢和價值。那麼該如何構建可觀測性呢？
首先，需要儘可能地收集所有元件系統的所有相關⾯的基礎資料，包括雲、主機、容器、Kubernetes 叢集，應⽤和各種終端。實時收集這些資料的成本並不⾼，但如果沒有收集，⼀旦系統故障需要排查分析的時候，就⽆法有效評估當時的狀態。
其次，要明確系統可觀測性構建的責任。誰是這個元件的構建者，誰負責定義這個元件的 SLI，誰負責收集所有的相關基礎資料並構建相應的儀表盤以及誰為相關的元件的 SLO 負責，需要責任到人。
第三，開發者需要為可觀測性負責。開發者要將⾃⼰開發系統的可觀測性資料暴露作為軟體質量⼯程的⼀部分，如果說單元測試是為了保證最⼩單元程式碼的可⽤性，那麼開發者標準化暴露可觀測性基礎資料也將作為⽣產系統可靠性的必要條件。
第四，需要建⽴統⼀的指標、⽇志、鏈路規範，統⼀團隊的⼯具鏈。即採取相同的指標命名規範，相同的⽇志格式，相同的鏈路系統。如果在遵循 OpenTelemetry 標準後，仍有不同，則可定義串聯整個系統的統⼀TAG 規範，如：所有錯誤都是 state:error。
第五，要持續優化改進整體可觀測性。針對整個系統的可觀測，包括資料收集，檢視構建，TAG 體系建⽴，這些步驟均需要時間，不能因為覆蓋度或者構建的儀表盤未能在某次事故中發揮作⽤而繼續⽤過去的⽅式處理問題。每次未被觀測的故障都是進⼀步提升可觀測範圍的絕佳機會。
從可觀測性構建的路徑不難看出，其過程是非常複雜的。那麼，主流的構建方式有哪些？蔣爍淼介紹了兩種最為常見的可觀測性構建方式，分別是通過開源的方式構建和採用 SaaS 產品進行構建。
得益於開源生態的蓬勃發展，為可觀測性的構建提供了諸多選擇。採用開源的方式構建，需要構建者從前端的資料抓取到後端的資料處理，包括資料展示、告警等周邊功能的相關知識有非常詳盡的瞭解掌握。因此，這種方式適合於那些有足夠實力或者學習成本及時間成本相對充足的團隊。
相比於開源的方式，採用成熟的 SaaS 產品構建可觀測性是一種更加高效的方式。蔣爍淼以觀測雲的產品為例，介紹了這種方式的四點優勢。
- 不做縫合怪：在伺服器內僅安裝一個 agent 就可以收集這臺主機所有相關的系統資料，避免成堆的 agent 和配置項。
- 不做小白鼠：能提供端到端的完整覆蓋，並能做到開箱即用，避免良莠不齊的整合，如：觀測雲就能夠支援超過200種技術棧，實現端到端的覆蓋。
- 不封閉、高度可程式設計：可實現輕鬆構建任意的可觀測場景，甚至將業務資料引數引入到整體的觀測中，靈活性強。此外，還能夠避免死板的整合，擁有強大的二次開發能力。
- 不留隱患：觀察雲對使用者側程式碼永久開源，單向通訊，不會也不能向客戶環境下發指令。所有的資料收集預設脫敏且使用者可對整個過程進行控制。
前面提到，可觀測性的構建是應“雲”而生的，不僅如此，觀測雲本身也是完完全全的雲原生產品。觀測雲中整套產品包括資料平臺，都是部署在亞馬遜雲科技的 EKS 之上的，並基於容器進行編排。觀測雲的整體架構非常簡單，即通過一個 agent 將海量資料進行統一，進入資料平臺，然後通過平臺的能力提供完整的可觀測性。整個系統分為核心平臺層、Web 層和資料接入層，核心平臺層是完全由觀測雲進行自研的，沒有進行開源。上層的 Web 層，在核心資料處理平臺上有一套與平臺對接的 API。蔣爍淼說：“對於客戶來說，更推薦直接選擇觀測雲的 SaaS 產品，如果願意，客戶也可以在亞馬遜上完全孤立地進行部署，也是非常方便的，只不過整體費用要比直接採用 SaaS 產品高得多。
為什麼會選擇亞馬遜雲科技？主要是基於以下考量：
- 觀測系統本身要有高一個數量級的可靠性和更高的 SLA：觀測雲是幫助客戶構建可觀測性系統的平臺，因此需要自身擁有很高的可靠性，如果不能提供足夠高的可靠性，一旦觀測系統出現故障，便無法及時提醒客戶，提供詳細的分析更無從談起。此外，選擇雲服務本身也能夠讓一部分觀測雲平臺的 SLA 由亞馬遜來提供。
- 更成熟的 Marketplace：使用者可通過中國的團隊直接在亞馬遜上進行產品購買，亞馬遜雲科技會把產品消費直接在 Marketplace 上記賬。需要說明的是，觀測雲的產品是根據資料規模來付費的，當使用者沒有資料量的時候幾乎是免費的。
- 全球性：亞馬遜雲科技能夠提供比海外產品更好的相容性，尤其對於中國的技術棧整體成本更低。蔣爍淼在分享中透露：“在春節過後，觀測雲將會在海外亞馬遜雲科技節點部署我們的觀測平臺。觀測雲希望用中國力量為中國的出海客戶提供比海外產品更好的、成本更低的選擇。”
- 借力 APN 融入亞馬遜雲科技全球網路：觀測雲希望藉助亞馬遜雲科技強大的生態，將可觀測性作為最終對客戶提供服務的手段，並希望能夠借力APN，幫助更多使用者瞭解可觀測性的效果，這個也是觀測雲選擇亞馬遜科技非常重要的原因之一。
除了是完完整整的雲原生產品，在觀測雲的系統中，還包含幾個非常有趣的設計。首先，在採集側：
- 觀測雲把第三方指標,日誌,鏈路採集協議統一轉為觀測雲協議
- 外掛式採集棧設計, 各外掛之間採用 go 協程隔離,互不影響
- 主動式資源消耗控制防止 agent 端資源壓力過大(cgroup 控制採集資源佔用)
- 被動式資源消耗控制防止 server 端壓力過大(背壓機制)
- 潮汐機制的分散式日誌解析 (pipeline)
其次，在儲存查詢側，觀測雲統一了查詢語法，使用者無需關心底層資料儲存，簡單易上手。
第三，在分析側，觀測雲實現了全部資料串聯，並構建了統一的檢視器，將原始資料以類似多維分析和列表的方式進行分析，使用者可以去構建自己的檢視器。此外，由於資料量大，為避免前端造成使用者瀏覽器壓力過大，觀測雲可以按照指定百分比來採集資料，並提供 SLO/SLI 的皮膚，幫助客戶構建自己應用系統整體可靠性的度量方式。
構建端到端的可觀測體系實踐案例
在對概念層和技術層面進行詳細的介紹後，蔣爍淼以某電商客戶作為案例，就具體該如何構建端到端的可觀測體系進行了講解。
案例中電商客戶面臨的問題是：交易流程從客戶下單到倉庫到最後財務記賬，一個訂單需要將近10次介面呼叫，其中任何環節都有可能出現問題，例如程式問題，網路異常，庫存卡住等。目前沒有有效的監控工具能夠把對訂單流程進行監控，出問題一般都是門店員工反饋過來，然後運維人員根據訂單去參照流程去查詢問題出在哪裡，非常被動，且工作量較大，每天需要運維人員去查詢業務介面是否走完。
針對該客戶構建端到端的可觀測體系的過程大致分為四步：第一步，梳理觀測物件整合接入。採用觀測雲的產品，整個接入過程僅需要30分鐘左右就可以完成。
第二步，統一檢視與分析。具體步驟為，首先，對使用者體驗進行監測，然後檢視該行為下的和後端打通的鏈路，並點選具體的鏈路進入鏈路檢視器，最後檢視相應鏈路的日誌。
第三，通過檢視器實現業務的可觀測。
第四，通過 SLO 監控器預警。
通過觀測雲完成端到端的可觀測性構建後，該電商客戶將訂單流程節點狀態視覺化，可實現以訂單號檢索訂單流程節點狀態，流程卡在哪個環節，報錯資訊是怎樣一目瞭然。從使用者操作介面、網路、後端服務到依賴的中介軟體、作業系統，任意故障都能夠提供清晰的溯源與分析。不僅如此，觀測雲還提供實時異常監控告警，確保問題能夠被及時發現並及時處理。
除電商領域的應用外，觀測雲的 SaaS 產品還適用於非常多應用場景。在觀測雲的官網有完整的系統可觀測性構建的最佳實踐，感興趣的小夥伴可直接去觀測雲官網檢視相應文件。
戳閱讀原文直達官網
https://www.guance.com/#home