作者：曾慶國
作者簡介：
曾慶國，來自阿里雲智能-雲原生可觀測團隊。過去多年一直從事雲原生相關領域工作。從運營開源產品到商業產品研發；從應用交付、平臺工程到深入雲原生可觀測。多次通過 KubeCon、ArchSummit、A2M、雲原生峯會等平臺分享雲原生實踐經驗。
今天給大家帶來一個非常讓人興奮的話題，雲原生全棧可觀測。
業務系統具備良好的可觀測性，是最容易讓開發者、運營者和管理者興奮的。爲什麼這樣講？當開發者做了非常棒的業務功能，把它發佈上線，此時如果它是黑盒的，或許大家都感受不到更多的成就感。當研發同學能從一個觀測大盤上看到業務功能有多少 PB 流量引入，業務系統穩定運行，資源消耗平穩且符合預期；業務運營同學可以看到目前有多少用戶訪問，用戶的行爲軌跡，產生了多少業務訂單。這個時候纔是讓大家真正的安心和興奮。
迴歸本質，這就是全棧觀測最基本的訴求。
回首過去幾年，可觀測伴隨着整個雲原生技術發展。Gartner 將 Applied Observability 列爲 2023 年戰略技術趨勢，並預計，2026 年 70% 成功應用可觀察性的組織將實現更短的決策延遲，爲目標業務或 IT 流程帶來競爭優勢。
基於多年的實踐經驗和技術積累，阿里雲發佈 ARMS 全棧可觀測產品體系，幫助企業更快、更低成本的完成全棧可觀測技術棧的構建。
*阿里云云原生 ARMS 全棧可觀測方案
雲上需要什麼樣的可觀測體系？
多年之前，更多講日誌、監控、運維。近幾年，隨着雲原生技術的發展，“可觀測”一詞變成大家必談的點。圍繞着現有云上需求，出現了一個更熱的專業詞 -- 全棧可觀測。
我們認爲目前及未來很長時間，全棧可觀測將應用到各行各業及不同企業中去。所以，今天想跟大家聊聊，什麼是全棧可觀測及我們爲什麼需要它。
雲上業務在可觀測維度的挑戰
（一）雲上觀測的痛點
首先，我們來看服務上雲及上雲以後，企業會遇到的可觀測領域挑戰。
1）第一大挑戰：數據孤島
這個問題由來已久，且非常突出。舉幾個簡單例子，企業用 ECS、容器、消息隊列等不同產品都會提供可觀測的數據，對於企業來講，這些數據怎麼關聯起來，怎麼有機形成關聯整體並輔助後續決策？但通常這是割裂的。
另外，在市場上、社區裏有大量可觀測相關項目、工具、產品，怎麼去選擇？當運維同學進行選擇時候，面向運維的需求去選擇某個工具集去更好做穩定性。當業務和產品同學進行選擇時候，希望看到更多業務級數據輔助業務決策。不同需求出發，會選擇不同觀測集，這是很長時間出現的問題。
今天我們講全棧可觀測的時候，核心就是解決這樣的問題，在可觀測領域裏邊如何解決數據孤島問題。
2）第二大挑戰：成本
我們認爲可觀測是大數據的生意，意味着各方面成本非常高，最基本的就是數據存儲、數據分析、全鏈路計算成本。
其次，還包括怎麼獲取這些數據的技術、人力成本及業務上可能要更多消耗資源方面的成本。這些成本的膨脹會阻礙不同企業獲得不一樣的觀測效果，大家看到可觀測很理想、很美好，但當企業遇到成本問題時常常會退縮。
3）第三大挑戰：不同技術架構下如何保障穩定
第三個點也是我們做全棧可觀測的初衷。大量行業業務特別是現在很多跨國企業及規模較大的企業，業務在雲原生領域中快速擴展，變成多元化和分佈式，不同的架構和技術棧層出不窮。對於這些業務如何確保他們的穩定性？如何拿到更好業務數據的觀測？如何衡量更優的業務成本？這些都是需要我們去把這些數據從各種各樣的維度，各種各樣基礎設施上或者不同業務服務上收集回來，形成最終可利用的數據集。
換句話說，這些都需要兩個字 -- 統一。雲原生很關鍵的點叫做標準化統一，在雲原生可觀測領域裏邊，統一更加重要，需要我們更好地採集數據。
4）第四大挑戰：無法兌現的價值
不同的團隊、不同業務方對可觀測的需求是不一樣的。如剛纔所提到的，SRE 團隊、穩定性團隊更多的是要關注業務穩定性、業務運行狀態等；研發同學關注資源消耗、架構狀態等。業務或者運營的同學關注當前的業務數據，當前有多少 PV 進來了，多少 UV 進來了，然後形成了多少訂單或者處理多少消息。這些需求形成了一系列的觀測維度。針對不同團隊、不同業務線需求時，觀測怎麼選擇？怎麼兌現觀測數據的價值，顯得更加的艱難。
（二）可觀測的十年，我們做了什麼
從這四個維度講，我們看到了目前雲原生可觀測方面四大核心挑戰，如何解決這些挑戰？阿里雲最近十年怎麼做的？我們簡單做一個回顧。
阿里云云原生可觀測產品歷程
2013年-2023年，十年間我所在的團隊就是阿里云云原生可觀測團隊，從最初的淘寶時代到現在的阿里雲公有云商業服務。
最開始的就是內部 EagleEye （鷹眼）產品，它的目的就是做分佈式應用的追蹤和分析，這種產品應對淘寶大量的流量和分佈式業務架構非常關鍵。這個產品其實在對標到開源社區，也有類似當時提出來的概念——APM。
隨後的幾年，從內部的工具孵化，變成了阿里雲上公有云的服務，最開始還是圍繞着 APM、Java 領域的應用監控這些維度來出發和深耕。隨着雲原生整個技術的發展以及可觀測技術棧開源領域的發展，阿里雲可觀測產品逐步走向開放，圍繞着開源領域已經形成的標準來制定整個的產品架構和體驗。
因此，我們逐步引入了全棧可觀測能力，包括通常理解的前端到服務到 APP，以及後端運維以及基礎設施、中間件產品等。
從2022年開始，阿里雲更多把整個全棧可觀測的能力，端到端提供給的客戶。全棧對於大多數客戶來說去落地還是非常複雜，如何利用阿里雲提供可觀測的統一平臺，快速達到比較理想的全棧可觀測的狀態，這是重點解決的問題。
圍繞標準化，完全以 Prometheus，OpenTelemetry 的體系構建了後續的可觀測數據，採、存、用全套機制。面向未來，更多的肯定就是把這種端到端全棧可觀測的經驗、平臺能力和產品能力直接快速賦能給我們的每一個客戶。
企業落地全棧可觀測的重要步驟
（一）做決策
不管是我們的業務團隊做決策還是相關的平臺團隊做決策，亦或者站在更高的企業維度做決策，首先是瞭解可觀測的優勢。
1）提供更好的業務運行的能見度，更好解決問題
企業上雲和依賴大量 PaaS 產品成爲主流，企業會用到大量的雲產品。這個時候對於整個業務運行的能見度來說，不僅是自己寫的代碼，可能會涉及到當前使用到的所有云產品的成本情況、運行情況、資源消耗等，從而構建出整個業務運行的能見度。
所以，當我們能夠統一進行觀測、統一進行查看的時候，可以更快地定位問題。今天某一個業務出現問題，是什麼原因導致的？是因爲代碼寫的問題還是某個基礎設施有問題？這就需要儘快進行定位。
全面實施可觀測技術的優勢和挑戰
2）用這些可觀測的數據幫助我們做業務的決策
特別是我們做一些 ToC 或者在線的業務，隨時關注當前線上運行狀態的觀測數據，例如當前提供了一個推理服務，這個推理服務目前有多少用戶進行調用，整個的響應是什麼樣的。如果發現我們用戶的調用降低了，有沒有可能是因爲延遲太高，定位即可推動接下來加大運行資源的投入。這裏只是舉了一個小點，更多的其實是幫助我們從技術上，架構上，業務上做決策，必然會提供更多的數據支撐。
3）省資源或者降成本的維度考量
我們知道業務運行狀態包括了當前消耗資源的情況，整體的資源利用率的情況，當我們掌握它的變化趨勢，會更明確做出判斷，這個資源是不是分配太多了？可以降一降成本。降了成本以後，它的可靠性能否保障？這些都是可以從我們的趨勢數據，整體觀測的數據來衡量和決策。
4）組織協作的維度上，由於可觀測性的出現變得不一樣
我們接觸很多的團隊，利用可觀測的數據在不同的層級進行協作。讓整個的業務運行，讓業務整體數據更加透明以後，技術同學以及架構的同學各種維度觀測的數據在同個數據池進行溝通的時候，就有溝通的橋樑。這是四個關鍵的優勢。
但任何事物不可能只有優勢，沒有劣勢，哪有那麼多銀彈。
1）複雜性
可觀測系統是複雜系統，當你不知道怎麼選擇一個好的方案或者適合自己方案的時候，發現各方提供可觀測數據，整體進行收集、處理、使用，選了很多的工具，這裏邊的技術門檻非常高，導致整個團隊投入的成本也會變高。
2）額外的資源消耗和性能開銷
因爲引入可觀測性，業務應用旁邊裝了侵入式的探針。這個時候或多或少會給業務帶來一些壓力，以及整個系統性能的開銷。當然，可觀測技術在儘可能把這些侵入性或者把附加的資源消耗降低，但是避不了。採集大量數據的同時，必然消耗大量的資源。也會從另外一個維度帶來成本的上升。
3）組織文化成爲變革阻力
如果說我們的組織文化沒有形成數據驅動模式，落地全面可觀測就會有阻礙和挑戰，投入這麼大的成本，帶來的收益是什麼？因爲收益沒有人用。
4）數據安全和數據的可解釋
這也是比較高的門檻。我們從基礎設施到業務到上層自研的系統，都會產生不同的數據，每個數據代表什麼含義，對於不同的人有不同的理解。如何讓這些數據被不同有需求的人理解到找到，也是有很大的挑戰。如何獲得這些優勢的同時，降低這些挑戰，這是我們作爲可觀測廠商需要重點考慮的，也是爲了幫助大家更好利用可觀測的能力，是需要做的。
（二）尋方案
阿里云云原生 ARMS 全棧可觀測方案
今天就以這樣的比較完整的方式呈現整個雲原生可觀測，給大家帶來完整的方案思考。這裏的標題有兩個關健詞， “場景化”和“數據” 。什麼是場景？場景其實就是應對不同的用戶需求，所沉澱的不同的經驗或者方案。比如現在應對我們 SRE 穩定性的需求，可能有具體的場景，給你對應的視圖、告警配置等等。這套經驗可以直接應用到業務體系裏邊去，確保穩定性觀測落地。我們圍繞着業務的需求的時候，要看到當前的用戶量，用戶訪問的狀態，以及轉化的程度，對應用戶觀測維度相關的經驗給到用戶。最上層是場景的沉澱，場景的沉澱的話，目前對於公用的場景沉澱，還是分幾個方面：
第一方面，基礎設施的層面，是大家公用的，不同的用戶上來都會應用到的維度。
第二方面，在業務應用領域，從前端到後端應用，形成全棧的應用可觀測場景。
第三方面，基於自身業務特徵的自定義化。有了完整且標準化的數據集，用戶通過相關的平臺能力，能夠自定義出自己一套觀測的實踐。
簡單來看一下，基礎設施的維度，目前雲原生領域基礎設施核心就是容器以及傳統的主機，雲上各種各樣的數據庫服務，人工智能相關的服務，大數據服務。這些數據，雲原生可觀測平臺已經支持這些維度的觀測數據採集、富化和聚合。舉個例子，某個業務團隊複用企業雲賬號，在他們使用的各種雲資源和雲服務商，統一打上了團隊標籤。這個時候從可觀測的數據視角可以基於這樣的標籤開始計算，當前這個業務團隊的服務的消費是怎樣的，資源消耗是怎樣的，成本是怎樣的，業務穩定性是怎樣的，可以以不同的維度視角進行數據聚合，呈現出整個不同維度的觀測力度。
從應用的可觀測的維度來看，通過各種各樣的非侵入的和有侵入的、部分侵入的產品能力，比如 Java 應用的 APM，或者不同語言的基於 eBPF 應用的黃金三指標的分析。或者在前端的應用，APP 端都可以通過相關的數據採集的鏈路以及信息沉澱出這樣的場景。
支撐這樣的場景當然需要有對應的平臺的能力，這裏的平臺能力核心其實對於我們來講幾個重要的環節。一是數據接入能力，雲上各種各樣形態的數據呈現出來，大量的數據庫實例，或者網關層面的實例，它是端到端的解決方案，不僅把數據採進來，這個數據會怎麼樣用，怎麼畫一個大盤，怎麼構建告警規則。目前已經積累了大量的可觀測生態能力。
阿里云云原生 ARMS 全棧可觀測生態能力圍繞着“數據”方向，在平臺能力側提供可觀測數據管理。觀測數據逐步偏向於標準化，所以我們可以像數據庫一樣管理可觀測數據。數據熱點分佈，維度分佈，查詢熱點（慢查詢）分佈等等。細化的數據管理和加工有利於用戶創造更多的觀測場景，有的放矢的優化成本。平臺能力的第三個維度就是告警平臺和可視化、以及 AI 技術相關的數據聚合和數據解釋能力。
數據的背後有一個非常重要的模塊，就是生成和採集數據的探針。ARMS 雲原生可觀測形成了從基礎設施、雲服務到後端應用、前端應用全棧的數據探針能力。在雲上，用戶可以透明化的利用這些探針採集全棧的數據。同時兼容 Prometheus，OpenTelemetry 等社區標準數據協議。根據 Metric、Trace 等不同的數據類型提供差異化的數據處理能力。最關鍵的是，雲上數據採集的最佳實踐已經原生落地。
落地全棧可觀測的重要技術要點
（一）數據選型
可觀測數據形態
數據在可觀測領域裏邊具體有哪些形態？上面這個圖非常的流行，目前可觀測數據的四大數據類別：指標（Metrics）、日誌（Logs）、應用鏈路追蹤（Traces）和應用運行時分析（Profiles） ，它們適用於在不同的層面，可以一定層面的轉化和交叉的關係。先來看指標的數據，最標準化的數據載體，體現的信息非常直接。當前有多少用戶的訪問，通過指標來表達的時候非常直接，有幾個維度加幾個標籤，然後給一個確定的數值。Traces 處理複雜場景，長鏈路處理的時候，用到這種數據形態。它的核心點就是關聯性很強，但是成本比較高，它更加趨向於日誌，它的有效信息密度稍低。Profiles 數據，被開發者使用到，也就是軟件的內部運行狀態時候核心的利器，找到關鍵性的技術問題，內存的問題，CPU 消耗的問題。
日誌是使用面最廣闊的可觀測數據，也是成本非常高的，大量的日誌不出問題的時候，或者不分析的時候是沒有用的，更多的實踐會把這種低密度數據往信息高密度進行轉化。
（二）數據採集
阿里云云原生可觀測平臺探針能力
有了數據選型以後，考慮數據的採集，我把它分爲 4 類採集的面，考慮的技術要點不一樣。
1）容器
容器是雲原生最重要的平臺。對於 Kubernetes 這一套體系以及生態能力、平臺服務，供給了大量的觀測數據。包括：集羣自身運行狀態數據，集羣工作負載數據以及運行應用自身的業務觀測黃金三指標數據。對於Kubernetes 容器數據的採集，核心的點就是探針具備大規模的目標服務發現的能力。
用戶的單個集羣可能存在大規模的採集目標，也可能有很高的變化頻率，例如 AI 訓練的任務 Pod，生命週期相對短，但是頻繁進行更新。採集這些業務指標的時候就會面臨高擾動的情況。基於大量的採集目標，不同的探針實例採不同數據的時候，涉及 Target 的調度和熱遷移，這是爲了數據的準確和穩定的關鍵點。在功能性方面，在容器集羣採集的數據，一般會進行端側處理，考慮哪些數據是重要的，或者哪些數據在端側直接進行轉化或聚合。具備數據處理 Pipeline 和默認規則是處理容器集羣觀測數據的關鍵。
2）ECS 雲服務器
雲上面臨大規模的 ESC 主機，我們的探針如何高效安裝過去以及穩定的工作。和 K8s 不一樣，ESC 沒有標準的服務發現的能力，沒有工作負載的控制能力。它的體系相對於容器顯得不那麼雲原生。我們採集數據更多是無侵略的技術，分析主機自身物理資源狀態，運行業務相關聯的黃金三指標，同時識別他們的進程，進行數據關聯以及打上相應的標籤。比如機器上打了標籤屬於某個業務線，機器跑的進程服務相關聯的數據同時打上對應的標籤，以便於後續進行統計和聚合。
3）Serverless 化的雲服務
雲服務 Serverless 對於用戶來說更加簡單和低成本，同時也更加黑盒。但對於可觀測來說，我們需要採集內部 Serverless 環境採集下各種各樣的雲服務的指標，以及關聯相關的觀測數據。這裏也會涉及到有特色的點，雲服務的自動發現，某個用戶創立了 Serverless 的數據庫，觀測平臺將開始在內部採集這個實例對應相關聯觀測的數據，最後把數據呈現給用戶，這是用戶不可見的部分。
4）業務應用
業務應用關聯的採集，和業務要綁定在一塊，這種技術形態目前有這麼幾類。一是 Java 類的 JVM 的探針；eBPF 無侵入的探針和針對某一類業務應用更加具體進行數據的採集和生成的 Exporter。伴隨業務的探針需要更低的資源消耗，更高的穩定性。
（三）數據統一化處理
有了這些無處不在的探針能力以後，我們拿到了豐富的雲上可觀測數據。這些數據的存儲怎麼處理？過去的幾年，不同的場景裏面有不同的數據存儲都是分離的，不統一。這種情況帶來什麼問題？用戶選用這些工具的時候，沒有辦法把數據打通，同時它的使用、成本計算、規模計算都是分離的。
在今年 ARMS 做了一個大升級，針對不同的可觀測場景的數據的背後，都通過 Prometheus 的 Metrics 統一存儲。這些場景，想觀測的目標產生多少數據，統一按照數據量（GB）統一進行收費。在 ARMS 整體產品體系中你可以隨意選擇產品能力和場景能力，只需要爲產生的數據量進行付費。
這個的數據管理模式背後是大量的數據處理工作，針對應用監控、鏈路追蹤、前端監控、雲撥測等等業務領域，將核心數據處理統一轉換爲標準的指標格式。從數據形態上看即大量利用 Trace2Metric，Log2Metric 和自動化指標封裝技術。
阿里云云原生可觀測平臺統一範式
當然，統一數據的背後也會有一些原始數據的存儲，比如跟蹤的鏈路，在大多數情況下，熱數據都是指標。因爲它會把大量的鏈路追蹤整個的計算結果變成指標存儲起來。當然，也有少量的查詢，背後會有冷數據，存儲在原始的存儲裏邊。這種存儲相對成本更低，讓整個存儲的規範更加統一，以指標作爲我們的核心存儲。
（四）降成本
有了這樣的採集存儲以後，很關鍵的一個挑戰就是成本。所以，從平臺能力這一側，千方百計要降低成本，舉三個例子。
三類降成本技術方案
1）指標數據
大家使用面最廣的觀測數據形態，指標發散是高成本的攔路虎。例如現在要去統計我們的請求積累，如果在指標中直接存儲請求的 Path 路徑，這種數據大量的產生，而且沒有多大的意義，成本累計上升。
針對這些問題，有很多處理方式，有自動化的服務端直接處理的方式，採集側最佳實踐的處理方式，也有根據不同的數據類型，在端側無損進行相關的聚合，核心的是降低成本。
2）鏈路數據
鏈路追蹤更多查詢調用鏈裏邊的服務狀態，熱數據查詢核心都是指標，整個鏈路數據的追蹤查詢相對低頻。把整個調用鏈進行了冷熱分離，整個熱的數據都是先彙算成指標存起來以後，少量的查詢纔會到整個後面的冷數據，也是整個調用鏈。第二個維度是採樣的考慮，錯慢數據採樣是目前實際應用最廣的能力。
3）日誌數據
對於網關類服務的格式化的日誌非常突出的形態，直接在端側進行轉化，不需要存儲大量的日誌，直接變成有效的指標進行存儲起來，以供後續的計算和查詢，平臺具有一套開箱即用的產品能力。
（五）端到端實施
有了上面的一些核心的能力以後，另外非常重要的就是需要把這些平臺的能力，以及數據採集、數據處理和可視化的經驗有效歸類起來，能夠端到端提供給我們的用戶。觀測某一個已經存在的雲服務、基礎設施或業務應用，數據應該如何進行採集，哪些數據重要，如何進行數據關聯可視化，如何配置告警最佳實踐。這是有很高的門檻。對於大多數業務的公司或者團隊來說，都是要考慮很久的問題。
我們認爲這些必然是經驗的積累。我們面對大量的用戶，總結各方實踐經驗並沉澱爲可再次複用的能力集合。我們創造了一個 Observability As Code 的模式。在統一的平臺能力之上，將數據採集、處理、數據存儲、數據可視化和告警進行標準化的描述，形成可觀測生態插件。目前雲上可觀測插件越來越豐富，已經覆蓋了全棧領域，整體構建整個可觀測的生態。
經典案例
目前應用全棧可觀測體系的客戶基本上都比較類似，從需求、現狀和痛點來看都是具有很多的共同性。如上文中提到的一些點。
傳音控股全棧可觀測案例
對於傳音控股的痛點是什麼？雲原生化整個上雲改造，形成的觀測對象非常多，因爲使用大量的雲服務、中間件、基礎設施服務，還有業務分佈在全球不同的區域。需要一個觀測平臺能夠將整個業務體系覆蓋到。
第二，內部來說核心解決的問題就是業務的問題排查，問題的診斷作爲第一需求，內部推廣、應對團隊的合作，如何利用可觀測數據作爲紐帶，最後就是數據的集合，使用到不同服務的時候，他們產生的數據如何通過業務的需求聚合起來，這就是必然遇到的問題。從他們的方案來講，利用 ARMS 可觀測平臺能力，構建全球的觀測體系，數據整體都會構造到統一數據池子裏，形成統一的數據追蹤，最終形成了統一的視圖。
有幾個關鍵的點：在無侵入方面，APM 的 Java 體系沒有侵入的代碼，相對無侵入。指標採集採用了大量內置的經驗數據採集器，對於他們來說是完全透明的，其實都不需要感知採集器的存在，可以把他們的相關觀測數據納入到整個數據池。
第二個維度，提供統一觀測的能力。統一整個指標的體系觀測告警，能夠幫助用戶更好地按照業務進行聚合，從而構建全球觀測的體系。
結語
全棧可觀測的實踐對於整個行業來看還處於比較早期的狀態。當不同的企業在遇到某些契機的時候，纔會開始引入這樣的技術棧改造。從我們遇到的衆多成功團隊的經驗看，內部的決策體系、內部的團隊合作會帶來顯而易見的改變。