# 一分鐘精華速覽 #
全棧可觀測是一種更全面、更綜合和更深入的觀測能力，能協助全面瞭解和監測系統的各個層面和組件，它不僅僅是一個技術上的概念，更多地是技術與業務的結合。在“以業務爲導向”的大前提下，全棧可觀測正在成爲趨勢。
本文分享了阿里雲可觀測平臺服務作爲全球分佈的超大業務系統，同時也作爲服務全球企業用戶的可觀測平臺提供方，在故障洞察提效中遇到的業務挑戰，以及 6 個關鍵技術點和 2 個應用案例。
背景
全棧可觀測是一個技術和業務相結合的領域，單從技術維度理解，可觀測包含了基礎設施、應用服務、客戶端等等，而是更廣義的維度則關注這項技術如何支撐企業的業務，提供跨越各個層面的數據收集、分析和可視化，幫助企業更好地理解和管理其系統和應用。從技術開源到各類頭部廠商的產品，再到國內外多個業務組織的落地，都可以看出全棧可觀測已經成爲一種技術趨勢。
Gartner 報告顯示，落地可觀測性具有相當高的戰略價值
這一觀點也在 Gartner 的報告中得到印證，根據 Gartner 的預測，到 2026 年，成功應用可觀測性的 70% 組織將能夠實現更短的決策響應時間，從而爲目標業務或 IT 流程帶來競爭優勢，這說明可觀測技術已經突破了技術層面，進入業務層面。
所以從業務視角來看，業務的變化（規模，複雜性，穩定性要求）必然驅動企業對可觀測技術提出更高的要求。阿里雲可觀測平臺服務作爲一個全球分佈的超大業務系統，同時也作爲服務全球企業用戶的可觀測平臺提供方，由於其支撐的業務架構的不斷變化，驅動了可觀測技術棧的不斷演進。
今天我將結合阿里雲的可觀測業務挑戰，重點從幾項關鍵性技術和場景，與大家交流我對可觀測技術的思考。
01 業務如何推動阿里雲觀測技術演進？
阿里雲可觀測性技術發展時間線
2012 年鷹眼系統打通應用和中間件：阿里雲可觀測性技術起點可以追溯到 11 年前，當時淘寶開始逐步實施微服務架構，這導致了大量服務之間相互調用非常複雜。因此，在這個時期我們構建了鷹眼監控系統（EagleEye），來解決不同業務之間的調用問題。可以說，正是淘寶業務的快速發展和微服務架構的演進，才促成了這一技術的產生，也爲後期的可觀測體系打下了基礎。
2013-2015 年引入指標和日誌：這個階段，從社區的角度來看，容器技術和開源項目開始出現。同時，類似於 Service Mesh 這樣的項目也應運而生。由於底層基礎設施的改變，即容器化的普及，監控領域出現了新的需求和要求。我們的監控技術方向也逐步從打通應用和中間件之間的調用鏈，演進到引入觀測指標和日誌等。
2017 年 ARMS 雲服務：“可觀測性”這個詞正式出現並明確了其定義，即關注的數據維度，如指標等。阿里雲隨即基於原有的鷹眼監控系統，推出了產品化的服務 ARMS。
2022 年全棧可觀測套件：在上雲容器化、平臺化的前提下，開源社區的發展帶來了相對規範的可觀測技術棧，所以阿里雲在 2022 年發佈了全棧的可觀測相關技術，基於開源的規範實現相關的雲服務。
從阿里近 10 年的監控技術發展可以看出，技術並不是自發演進的，更多是由於業務架構和基礎設施架構的變化推動了可觀測性技術的架構改變。
02 阿里雲的可觀測遇到了哪些挑戰？
2.1 作爲平臺方：服務全球企業用戶
2.2 作爲業務系統：全球分佈
2.2.1 確保較高的業務能見度
我們經常面臨用戶無法找到其觀測數據的問題。這是一個常見的挑戰，需要我們思考，從數據採集到存儲和消費如何確保高度的業務可見性。
2.2.2 如何確保SLA達標
上述的問題只是一個表面現象，我們需要深入瞭解問題的根本原因。可觀測性數據鏈路非常長，涵蓋了從數據採集、端側處理、服務端處理、存儲到查詢等全鏈路的業務系統。因此，我們需要快速診斷故障，確定是哪個環節出現了問題，或者是否是由於用戶配置問題導致的等等。我們需要在最短的時間內診斷用戶數據鏈路故障並可視化故障，將平均定位時間從 10 分鐘降低到 5 分鐘或更低。我將在後面分享具體的實踐方式。
2.2.3 如何支撐業務決策
同時，我們自身也需要做出許多決策，無論是關於服務和產品的模式、架構，還是產品運營的形態等等。我們要知道用戶需要哪些可觀測生態能力，並建立觀測數據模型進行精確評估。
03 有哪些關鍵性技術需要突破？
3.1 我們需要什麼樣的觀測數據？
對於關注可觀測性技術的同學來說，這個圖應該很熟悉。開源社區對可觀測性的定義是指標、日誌、調用鏈和 Profiles，這四類數據實際上存在很多交叉，而不是完全分離的。這個交叉意味着這幾種數據本質上是相似的，它們都用於反映業務運行的技術狀態和業務數據狀態，只是捕獲數據的渠道和形式不同。如果要比較這幾種數據，可以從以下維度考慮。
指標(Metrics）：
相對而言，指標數據是成本最低的，因爲它們是提前計算好的數據。通常情況下，我們可以通過分析日誌等方式來計算得到這些數據。例如，每天的請求數（QPS）等指標可以直接反映我們想要了解的數據。當然，如果要從日誌中計算這些指標，就需要大量的數據才能得出結果。可以說指標數據是相對有效和直接的數據形式，通常以數字形式呈現。但對於開發者來說，如果可觀測平臺的建設者和開發者是分離的，開發者可能不太願意進行較多的改動，因爲這些改動會有一定代碼侵入性。
日誌（Logging)：
日誌數據的有效信息密度相對較低，因此完全存儲和檢索它的成本較高。不過，在不同的業務系統中，日誌通常被細分爲訪問日誌、業務日誌、錯誤日誌等等。因此，使用日誌來快速定位系統故障是最方便的方法，打印一條日誌或編寫一行代碼是相對容易的操作。對於事件類的日誌通常作爲審計的原始數據，低成本存儲也是大多數業務希望的。
調用鏈(Tracing）：
調用鏈是在日誌基礎上增加關聯性的一種衍生數據。它將一次請求的前後調用關聯起來，從而產生增強效果。調用鏈具有較強的數據關聯性，但也伴隨較高的成本。因此，我們需要考慮採樣問題。
調用鏈的好處是能夠快速定位複雜系統故障，特別是涉及多個服務的情況。通過調用鏈，我們可以準確定位 API 請求故障的具體位置。相比之下，僅從日誌出發可能需要進行回溯並對業務有一定了解。而指標數據可能只是一種側面的統計模式。在這些不同數據類型之間有很多轉化點，我們將在後面具體介紹。
Profiles：
這是近年來受到更多關注的數據類型。它深入到了我們應用程序的細節，當然不同的開發語言可能有所不同。一般情況下，我們會在需要提升性能或者發現內存泄漏、CPU 佔用過高等疑難雜症時使用這種觀測數據模式。它能夠快速定位到代碼中出現問題的具體位置。
在全棧可觀測體系中，以上幾種數據類型通常會被統一使用。同時，考慮到成本問題，我們會進行轉換和選擇性存儲，最終綜合利用這些數據。如果只能選擇一種數據類型的話，指標是最直接的一種觀測數據。
3.2 關鍵點 1：多種部署形態下的數據採集架構
在現代的部署環境中，特別是雲上的環境，我們可以將其分爲容器集羣、ECS 主機和雲服務。在考慮全棧時，我們的業務系統可能是自研的，以容器的形式運行在雲上或自建機房中；也可能是相對傳統的結構，在虛擬機上運行。雲服務中間件也是大多數企業的選擇。因此，在建立全棧的數據採集時，我們必須考慮這些不同的維度。
再說說探針核心要考慮的維度——
3.2.1 不丟數據
這是最基礎的要求，但實際上也是最難的要求。有經驗的探針開發人員都知道，在面對超大規模集羣時，日誌採集、應用 Tracing 數據採集和指標採集，數據量都是海量的。因此，如何確保不丟失數據是探針開發中必要的設計因素。
根據部署形態或架構形態，探針可以分爲運行在集羣、節點、應用這樣三個維度。
應用維度的探針，它採集的數據主要以調用鏈爲主，因爲只有調用鏈才必須侵入應用。而無侵入的調用鍊形態，目前還在發展過程中，不同的開發語言還沒有太好的方法能夠實現。因此，在 APM 形態下，都以應用探針爲主。
節點維度的探針，它面對的是在同一內核的業務，即容器化部署後，同一個節點上會有多個容器，可能幾十到幾百個不等。同理，在 ECS 上也是節點級別的，它可以藉助 eBPF 相關技術實現無侵入採集指標、業務日誌等等。無侵入 Tracing 採集也是在節點探針這個維度考量。
集羣維度的探針，它的核心是作爲數據中轉，將前置數據採集的邏輯在單集羣側先進行計算，比如日誌本身的轉化、Relable 等等。同時，也需要實現服務發現去採集一些指標的數據，比如常見的業務暴露指標，錯誤數、請求數等等。
通過多級的 Agent 模式，幫助我們在大集羣中分類採集不同的數據，然後上傳到服務端。上傳數據時會採用分包原則，確保每一個數據包都上傳到網關。網關僅接受數據壓縮包立即轉到背後的消息中間件，不拆包。繼而可以保障高性能接受數據包，確保在 Agent 側不阻塞。
3.2.2 實時採集
另一個維度是實時採集，即需要降低延遲，避免數據在幾分鐘甚至更長時間後才被存儲到服務端並供用戶查詢到。因此，我們需要儘快採集數據，讓 Agnet 在處理大量數據時的並行能力需要足夠強大。
所以集羣探針的多副本採集是關鍵技術之一。當我們面對多個採集 Target 採集目標時，需要創建多個採集工作副本，自動均衡採集不同 Target 的指標，並在短時間內將其發送到後端。Tracing 等應用端數據天然分散式採集。
3.2.3 就近處理
當考慮全鏈路的實時性時，除了採集外，存儲處理的邏輯也是必須要考慮的。這裏引出了另外一個重要問題是就近處理，其目的是爲了降低成本。因爲一旦將數據發送到服務端，就會帶來計算和存儲的成本。面向日誌和特定 Tracing 數據，我們可以降採樣或做轉化，通過在端側提前處理，最終產出的指標數據成本會相對較低。
3.2.4 智能關聯/打標籤
在進行全棧數據查詢時，智能關聯和打標籤是關鍵。在採集不同的應用時，它可能會有多種標籤，例如某個 APP ID、訪問域名。通過對原始數據進行處理，我們可以統一打上標籤，並在查詢時將它們關聯起來。
3.2.5 無侵入採集
目前在可觀測領域，無侵入的採集方式被視爲關鍵技術，因爲它能夠降低對業務代碼的侵入，使技術棧更容易落地。下面我將重點講解。
3.3 關鍵點 2：基於 eBPF 的無侵入數據採集能力
eBPF 作爲一種無侵入的數據採集能力，被認爲是非常重要的技術手段。無侵入的採集方式能夠減少對研發的影響，使得技術棧的部署更加順利。目前，這種採集方式在社區和實踐中得到廣泛應用。
無侵入採集方式不會對業務代碼產生干擾，它是在運行的內核中工作，例如 Linux 內核可以採集 IO 數據，其中包括網絡 IO、文本文件 IO 等。目前最常用的是網絡 IO，也就是請求的黃金三指標數據。通過從內核直接捕獲這些數據，則能快速計算出黃金三指標。我們可以從圖中簡單瞭解它的工作模式。
我們通過節點探針向內核下發相關的 eBPF 腳本，內核會自動加載並捕獲當前節點下的所有網絡調用。然後，它會自動解碼應用的協議，並計算出黃金三指標。這種模式適用於不同的通信協議，可以計算出具體的黃金三指標。這些指標以及一些分段的 Tracing 數據會被髮送到集羣探針側進行處理，或者直接存儲。
在這個過程中，我們可以從這個大圖中看到一個完整的業務系統可能使用不同的開發語言，如 Node.js、Java、PHP 等。對於 Java 來說，由於其侵入性（侵入 Jvm 運行時）探針的發展相對成熟，它的探針功能更豐富。而對於其他語言，業界更多地使用無侵入的 eBPF 技術來分析指標和調用鏈，建立整個鏈路。因此，我們可以從不同的技術棧採集相關的指標數據，從而得到整體架構。
網絡通信版本的全棧可觀測架構圖
這個圖展示了通信、進程和協議等更詳細的信息，還可以標識每個請求之間的關聯 Span ID 等。這些信息分析後可以方便我們進行整體的可觀測性。
然而，這些技術也面臨一些挑戰，比如會佔用較高的資源。由於需要分析網絡協議，解碼通信包，就會消耗大量的 CPU 資源，相比於直接注入 Java 探針或者業務方編寫代碼來體現指標，無侵入方式的資源佔用更高。如果我們要選擇的話，更好的方式是讓業務開發者以一種標準的方式生成指標，以提升業務自身的可觀測性。
另外一個挑戰是智能識別通信鏈路中的每個節點。我們可以通過域名、IP 地址等維度來識別通信的目標，例如 RDS 是否基於某個雲服務或自建服務，需要進行識別並進行關聯。
所以，這個技術的門檻相對較高，但好在開源社區和阿里雲上都有相關的技術和產品可供使用。
3.4 關鍵點 3：存儲成本控制的技術要點
在討論採集和存儲的過程中，我想重點談一談降低成本的問題。因爲可觀測的核心是需要處理大量的數據，而數據處理會產生成本，這也是很多團隊決策更快引入可觀測性的一個重要因素。在這個過程中，有很多技術性的因素需要考慮，我舉幾個例子來說明。
3.4.1 Metrics 成本陡增的真相
問題背景：
舉一個例子來說明，在指標處理這個方面，假設我們通過一種旁路的方式捕獲到了一個指標，比如請求的狀態。這種指標很簡單，它可以用來標記每天的請求數量。然而，如果我們在設計中沒有很好地把握，比如在標籤中引入了一個變化量很大的變量，例如 User ID，而業務系統有 1000 萬活躍用戶，那麼就會同時產生 1000 萬條時間線。這樣的數據量相對其價值通常是不成正比的。這是我們在爲大多數用戶提供服務的過程中經常遇到的成本爆炸場景之一。
解決思路：
那麼，如何解決這個問題呢？其實解決思路還是相對簡單明瞭的。首先，我們在生成指標時要避免出現這樣的模式。如果我們不需要如此詳細的數據（一般情況下是不需要的），就不要設計這樣的指標標籤。這是最根本的解決思路。然而，作爲平臺方，很難要求所有用戶都遵循這個規則。因此，我們需要考慮從服務端提供一些機制來處理這個問題。
具體方案：
第一個是 Prometheus 社區的方案，即在採集數據時對標籤進行重寫，將變化較大的數字轉換爲通配符，從而降低整個指標。然而，這種方法依賴於用戶具備相關經驗，並能配置相關策略。
那麼，是否有更簡單、更智能的方式？我們在服務端採用了一種自動處理的方式。當數據流進入處理流程後，系統會自動判斷指標是否開始發散。如果發現這樣的事件發生，服務會觸發生成相應的規則，並將規則注入到處理的鏈路過程中。這樣，1000 萬條數據就自動轉化，最終存儲中可能只有一條數據。這種自動轉化的邏輯依賴於發散數據。整個過程背後需要有經驗的積累，才能生成相應規則來自動處理這樣的事件。
另外，一些廠商還會使用存儲降成本的邏輯，即數據是否可以取消更多索引，但這會增加成本並可能對存儲的非通用性要求更多。
我個人認爲，最簡單的方式還是在產生指標時就考慮這個問題。將指標的合理的設計納入到技術設計中。
3.4.2 如何有效降低 Traces 成本
問題背景：
以圖爲例，我們通常認爲 90% 以上的測試數據和日誌一樣，大多數情況下是沒有用的。除非出現問題或者想了解某個調用鏈的背後調用，否則一般不會去查看它的調用鏈是否正確。因此，存儲全量數據後再使用全量數據，則會帶來很高的成本。但如果只是簡單按比例採樣，數據失真也是非常可怕的，可能會錯過一些錯誤，也失去了觀測的意義。有什麼方法可以解決這個問題呢？
解決思路：
在實踐中，我們嘗試了幾種方法，這裏分享一種按業務語義來處理數據的方式。
我們分析數據時，通常用戶在調用產生後的短期內（例如 30 分鐘）會去查詢調用鏈的狀態。隨着時間的推移，查詢比例通常會非常低，這是基於業務分析的結果。因此，我們提出了熱數據和冷數據的分類方式。
熱數據用於實時查詢，冷數據則用於排查問題或進行最終統計。在熱數據轉化爲冷數據的過程中，我們需要存儲有錯誤的調用鏈，而其他數據則按一定比例進行採樣存儲。通過這樣的存儲模式，我們不能用冷數據產生的統計指標來評估業務的性能，它只是作爲從調用鏈維度進行分析的參考數據。因此，我們非常關注錯誤的，或較慢的調用鏈的數據，必須將其保存下來。總體而言，這種處理思路降低了冷數據存儲的成本，同時也降低了最終用戶查詢的成本。
3.5 關鍵點 4：預先提取關鍵數據
3.5.1 Trace2Metric
以調用鏈爲例，通常我們關注的場景是單條調用鏈的上下游追溯。但更多的情況是基於 Trace 數據進行統計分析，統計業務的請求量、錯誤和耗時等黃金指標。
在構建追蹤系統時，我們將其分爲兩類查詢：一類是查詢調用鏈，另一類是基於調用鏈生成的統計數據，我們稱之爲指標。對於這些指標的計算，我們可以將其前移以降低成本。具體而言，我們引入了 Trace2Metric 的模式，將追蹤數據進入處理鏈路後先進行處理，生成統計指標，比如某兩個服務之間調用的數量、錯誤數和耗時等指標，然後將其存儲到指標存儲系統中。至於其他原始 Trace 數據，可以通過之前提到的冷熱數據方式進行處理，或以低成本的方式全量存儲，例如去掉所有索引，只存儲原始文本數據。
通過這樣的方式分流數據，我們在用戶端通過可視化系統進行查詢時，更頻繁地查詢的是指標，而較低頻的查詢則是原始 Trace 數據。因此，在整體上降低了低頻查詢的存儲成本，而高頻查詢的指標是聚合的，所以指標量也較小。通過這樣的處理模式，我們可以逐步演進數據處理鏈路。
3.5.2 Log2Metric
在處理日誌的指標時，思考模式與 Tracing 類似。實際上，日誌更容易產生指標，特別是訪問日誌，如網關日誌或業務的訪問日誌。這類日誌通常需要統計整體業務或基於業務維度的數據，而單點查詢很少。例如，統計哪些用戶訪問了哪個業務系統。因此，在採集日誌數據後，我們可以直接進行產生指標的處理。
在開源社區中已有相關的方案，如 Vector 模式，它對日誌進行前置處理並生成指標。後續的存儲方式與前面的 Trace 類似。
綜上所述，我們主要從以上幾個維度考慮來降低存儲成本。
3.6 關鍵點 5：觀測數據全局聚合查詢
3.6.1 應用場景
數據的使用取決於存儲形態。以指標爲例，業務指標的數據可能存在幾種場景。
跨賬號的數據聚合查詢：在雲上可能存在不同賬號的數據，每個賬號對應不同的業務團隊。但是在整體視角下進行可觀測時，需要將相關數據聚合在一起進行可視化、告警等操作。
跨 Region 的數據聚合查詢：從技術角度來看，可能存在跨地域、甚至跨國的數據查詢需求。例如，北京可能有相關業務，杭州也有相關業務，北美也有相關業務。在觀測整個業務系統時，需要從這些不同地域甚至跨國 Region 查詢相應的數據。
跨實例(數據域)的數據聚合查詢：這個場景顆粒度更小，是數據的多租存儲，即分不同的實例存儲。此時最基礎的粒度則是跨實例（數據域）。比如，某個實例存儲後端服務的觀測數據，另一個實例存儲前端和 APP 的觀測數據，還有一個實例存儲雲服務的觀測數據。在做全棧觀測時，需要將不同場景的數據進行聚合查詢。
3.6.2 解決思路
爲了實現這一目標，我們需要選擇合適的技術來進行聚合查詢。那麼聚合查詢是這麼做的？
這裏得益於開源規範，在指標處理的鏈路中，以 Prometheus 規範爲主。該規範定義了豐富的算子和查詢語法。所有 PromQL 的查詢語法進入到聚合查詢實例後，就會拆解裏面的每個算子，並將其發送到目標數據存儲實例進行計算。然後將這些數據重新流回聚合實例進行聚合，並響應給用戶。對於用戶來說，這種計算和彙總的邏輯是透明的，因爲他們只需要提供一個查詢語法即可。同時，通過指標加標籤的機制，我們可以很好地分辨出數據的共同標籤、差異化標籤，從而瞭解這些數據的來源。這種模式能夠幫助我們構建不同場景的可觀測性視圖。
3.7 關鍵點 6：構建無處不在的可觀測基礎設施
有了採集、存儲、查詢等基礎設施後，構建全棧的可觀測能力就必然需要面向場景。
在場景方面，通常可以分爲基礎設施的觀測、應用的實時觀測、前端的觀測、APP 的觀測以及主動的雲撥測等。這些觀測點都能從可觀測平臺進行分類。
在具體的業務場景中，則不需要考慮這些，直接根據業務形態選擇適合的觀測方式。在提供這些能力時，我們要考慮開源的兼容性。因此，以開箱即用的方式提供開源和雲服務的觀測方案是非常重要的。開箱即用意味着每個場景的告警、大盤數據源、數據採集和處理規則等都以獨立的聚合方案的形式直接可用。這對於構建可觀測平臺是一個重要參考。我們提供給開發者和業務團隊的，不能僅僅是技術的基礎設施，而是應該是基於開源視角、業務視角和公共服務視角的最佳實踐，以包裝好的方式提供給平臺用戶使用。同時這種包裝需要是標準化，可擴展的，我們的研發甚至是用戶可以根據需求隨時定義新的插件，利用平臺已有的能力，形成可複用的解決方案。
04 可觀測平臺的實踐和落地效果
4.1 自身實踐：阿里雲構建全域 SLA 可觀測
作爲一個全球分佈的業務系統，阿里云云原生可觀測團隊需要關注自身的觀測和降低用戶故障發現的時間。爲此，我們需要構建一個全面的可觀測團隊視圖。涵蓋幾個關鍵維度的數據：SLA 可用性、成本和穩定性、用戶運營（用戶規模、新增用戶數量等）。
從這些需求中可以看到，我們的觀測需求是廣義上的全棧可觀測。從 SRE、穩定性、業務運營等多個維度建立觀測視圖。
再細分 SLA 的可觀測性需求，它涉及到了全球不同地域的數據採集、存儲和使用側的聚合查詢。再根據不同的業務形態選擇不同的觀測手段。在數據層面，我們統一進行用戶、地域和業務域等維度打標和數據查詢。
對於我們的業務分佈，一個是控制面，一個是數據面，我們需要針對不同的維度進行面向用戶的聚合。在控制面中，我們關注用戶的操作，例如開通哪些實例等。在數據鏈路中，我們關注每個用戶在特定環境中的數據採集、存儲和查詢情況。應用各種觀測技術手段，我們可以從下往上進行聚合，最終形成完整的觀測視圖。我們可以通過兩個截圖來說明。
第一個截圖展示了 Agent 採集側的 SLA 觀測大盤，支持從用戶維度、地域維度和用戶環境維度觀測數據採集狀態，發現故障域，以及通過指標、日誌等手段直接定位採集細節狀態，達到洞察故障的效果。
第二個截圖展示了存儲側的聚合數據，可以讓我們直接看到 SLA 的情況。支持從用戶維度、地域維度和用戶實例維度觀測數據寫入 SLA，先於用戶發現寫入環節故障。
即使我們支持用戶工單的同學具有不同的技術背景，也可以通過全棧觀測大盤快速發現用戶問題，解決效率大大提高。我們內部數據統計，通過建立多維度的觀測大盤，整體故障洞察效率提升了 50%。
4.2 用戶實踐：傳音的全棧可觀測實踐
作爲“非洲手機之王”，傳音從事以手機爲核心的智能終端的設計、研發、生產、銷售和品牌運營，是新興市場消費者喜愛的智能終端產品和移動互聯服務提供商。據 IDC 報告顯示 2021 年佔據非洲智能手機出貨量的 47.9%。傳音移動互聯廣告平臺是傳音控股的重要業務之一，是非洲最爲主流的營銷平臺之一。
客戶痛點：
在技術架構方面，傳音控股採用 Spring Cloud 進行全面微服務化， 應用運行在阿里雲容器服務 ACK 之上，並分佈在歐洲、亞洲等多個地區，真正實現了多地區服務體系。對於該體系而言，要構建完整的可觀測體系，挑戰非常大。
需求概述：
- 可觀測性應覆蓋從研發到生產的全週期。
- 同時需要監控全球多個容器集羣，雲服務基礎設施。
- 打通應用和基礎設施觀測，統一觀測調用鏈和性能、可用性指標。
方案概述：
- 自建流水線數據採集系統，通過 Grafana 展示應用構建數據
- 採用 ARMS Prometheus 產品監控容器集羣和應用性能及調用鏈，集成 Grafana 完成多集羣統一監控
- SLS 產品完成業務日誌、應用日誌、容器日誌的採集/存儲/展示，並通過查詢語句生成指標，在 Grafana 中展示
- 統一採集雲服務觀測數據，結合基礎應用數據統一觀測。
落地成效：
傳音在建立全新的可觀測技術能力後，不僅提升了問題診斷效率，還提升了用戶體驗。在此基礎上，結合其他雲原生新技術方案，業務上線效率提高了 60%，對於高效業務創新起到了至關重要的作用。
05 總結與展望
開源技術和開源社區的發展帶來了標準化，覆蓋了全棧技術和全棧業務方向的數據收集、存儲和可視化等方面。而可觀測性的廠商推出了全棧可觀測的綜合方案，引領用戶實踐，使得全棧狀態更易實現。在此基礎上，全棧可觀測的實踐案例得以在更多業務組織中落地。
當然應用可觀測性技術帶來了業務能見度、決策支持、成本優化和組織合作改進等收益，但同時，大多數業務組織也面臨着技術複雜性、成本控制、組織文化變革、數據管理等方面的挑戰。
我們可以看到，越來越多的企業正在克服這些難題，讓可觀測技術突破技術層面，進入業務層面，並得到更加廣泛的落地。可觀測，無處不在！
作者介紹
阿里雲智能技術專家——曾慶國（悅達）
TakinTalks 社區專家團成員。KubeVela 社區 Maintainer。長期從事雲原生可觀測、應用持續交付、基礎設施管理等雲原生領域，積累大量基於 Kubernetes 的雲原生應用管理平臺建設經驗和可觀測領域實踐經驗。曾幫助工業互聯網、金融和企業辦公等多個行業頭部用戶完成雲原生 DevOps 轉型。ArchSummit、Gopher、SDCon、A2M 等大會講師。
本文根據作者在「TakinTalks 穩定性社區 」公開分享整理而成
點擊立即免費試用雲產品 開啓雲上實踐之旅！
本文爲阿里雲原創內容，未經允許不得轉載