淺談彈性計算管控可觀測性體系建設

一年前寫過一篇介紹彈性計算管控監控告警體系的文章《彈性計算管控監控預警體系建設之路》 介紹的是彈性計算管控監控告警體系的發展和設計思路。監控告警本質只是故障發現的手段之一，當前主要聚焦在穩定性的故障/問題發現領域（當然告警是一種業界共識的故障發現媒介，一定程度會傳遞故障定位資訊）。可觀測性是貫穿整個軟體生命週期的，從穩定性視角看，可觀測性覆蓋了從故障預防->故障發現->故障定位->故障恢復->故障改進驗收的完整週期。

首先，從組織、業務、技術等幾個視角來定義 ECS 管控在客觀性上遇到的問題：

• 整合複雜性，當前能力非標，資料割裂，難以輸出標準化的API用於業務整合

• 業務體感差，可觀測性大盤，預警整體體感對研發不夠友好，仍然是運維思維

• 基建能力弱，研發構建業務自定義的能力沒有完整的方法或者平臺支援

• 問題定位難，metric和trace能力不足，故障定位大部分場景依託於專家經驗

• 應用視角，全軟體生命週期（SDLC）觀測，包括研發、測試、交付、運維等

• 穩定性視角，多場景觀測能力、監控發現、告警通知、根因定位

• 容量視角，建設產品與組織視角的容量觀測能力

• 定義現狀，構建產品視角的容量觀測能力

• 評估未來，為後續資源降本提供決策支援

• 建立標準化機制與 SOP，透過遵循行業標準協議和最佳實踐，確保資料模型、指標定義、日誌格式等關鍵元件的一致性和互操作性。這將簡化跨團隊協作，降低技術壁壘，並提高整體運維效率，使得從不同維度獲取的系統狀態資訊得以精準對映並整合到一個通用檢視中，為故障快速響應奠定基礎。

• 提供可整合效能力，支援與開源、阿里雲產品工具、服務無縫對接，如日誌收集平臺、APM（Application Performance Management）、 tracing工具等。這樣，在滿足多樣化需求的同時，也能保證所有相關資料來源能夠高效地融入觀測平臺，形成完整的端到端可觀測鏈條，助力團隊在面對複雜故障場景時迅速定位根源。

• 預留可擴充套件性，隨著業務和技術的快速發展，可觀測框架需要靈活適應不斷增長的資料規模和新型應用場景。設計之初就要充分考慮模組化和水平擴充套件能力，以確保在系統擴容、新功能接入的情況下，仍能保持穩定高效的效能表現，滿足未來可能出現的各種運維需求。

• 提供卓越的使用者體驗，直觀易用的介面設計，實時準確的資料反饋，以及智慧化的問題診斷輔助，都將大幅提升SRE和研發團隊的工作效能。例如，透過對海量資料進行智慧分析，結合 AIOps/LLMOps 技術提前預測潛在風險，甚至能夠在故障發生之前即採取預防措施，顯著降低系統的MTTR（Mean Time To Repair）。

• Service，依賴服務層，當前 ECS 管控可觀測性構建於阿里雲公共云云產品以及部分內部服務之上，核心原則：Cloud First。

• Data Center，資料中心，資料質量與覆蓋度是決定上層業務是否可以標準化運維與實現智慧化運維的關鍵，當前觀測資料層主要包括 log、metric、trace、event、cmdb 以及業務資料與運維知識等。

• Process Layer，透過 ETL 等工具對資料進行加工並統一儲存，包括時序資料庫、關聯式資料庫、知識圖譜、數倉等多種形態，核心在於統一建模、標準化與業務適配。

• Operation Brain，運維大腦，專家經驗與 AIOps/LLMOPs 的能力組合，核心解決業務運維領域最複雜“思考”能力落地問題，比如故障領域經典的根因定位、容量預測等。

• Automation Center，運維編排與工具管理，直接支撐典型的業務運維場景，比如告警事件通知、變更事件廣播、自動化擴容、限流自愈、自動化 profile 等，核心在於解決標準化、與業務覆蓋問題。

1. Cloud Frist，吃狗糧，優先考慮基於雲產品（尤其是公共雲）的開放整合能力構建可觀測性，比如 ECS 管控可觀測性核心依賴了 SLS、ARMS、雲監控、DAS 等多個雲產品的 OpenAPI 與 InnerAPI。
2. SDLC，建立覆蓋軟體開發生命週期的觀測能力，觀測不僅僅用來在運維階段發現故障，同樣可以用於業務規劃、容量規劃、研發質量、交付效能、成本最佳化等領域。
3. Platform，平臺產品思維，我們不做解決單點區域性問題的方案，要做可以解決一系列問題的平臺解決方案，同時要儘可能推動實現 研發自助->自動化->智慧化 的演進。

在ECS管控可觀測效能力建設的漫長演進歷程中，從內部monitor、sunfire，再到sls與prometheus生態結合並融入自主研發階段，目前ECS管控觀測已實現全鏈路“上雲”，這一過程蘊含了幾個關鍵性的洞察與思考，與大家分享一下：

1. 觀測資料構築之重猶如基石（再次強調），組織視角下需洞見“恆定”與“變化”。在業務圖譜中，業務核心資料可視作不變的“常量”，而觀測技術則是持續迭代的“變數”。無論是昔日的Nagios、ELK，還是現今流行的prometheus生態系統，未來無疑會出現更為卓越的解決方案。然而，相對而言，業務的資料與核心關注點相對穩定， 比如在 ECS 團隊，我們對保障 ECS及相關配件資源的有效交付與穩定執行（涵蓋成功率、效率、規模承載力等關鍵指標）不會改變。

2. 深度挖掘並充分利用雲端產品潛能，旨在減少運維邊際成本，達成高效運作。不論是SLS、ARMS，抑或是雲監控服務中託管的prometheus、grafana等雲原生工具集，它們所提供的強大功能足以支撐日常業務場景所需。獨立運維乃至自主研發此類工具，其收益往往並不顯著，尤其是在業務規模逐步擴大的背景下，獨立運維的成本和風險將會呈現出上升趨勢。

3. 踐行面向失效的設計哲學，以使用者為中心，深知在不確定的世界中，“所有云產品皆有潛在不可靠性”。不妨提出一個挑戰性的問題：倘若依賴的XXX雲產品突發故障，我們將如何應對？近期AK故障引發的大量雲產品異常事件，大量依賴雲產品構建的觀測能力在該場景也全部異常，這為我們提供了一個亟待深思的例項。當前我們團隊正積極內省，並與雲內監控團隊密切溝通，共同探討如何在雲產品可能出現故障的情境下，仍能確保核心的觀測能力和監控告警機制的有效性和可靠性，實現對未知風險的有效抵禦。

• Log，ECS 管控所有服務以及業務日誌，國內與海外雙中心部署，統一儲存在 SLS logstore。

• Metric，ECS 管控度量指標資料， Prometheus 資料協議，儲存在 SLS metric store，國內海外雙中心儲存。

• Trace，基於 ARMS 與 SLS logstore 自研可編排、可擴充套件的全鏈路日誌追蹤服務。

• Meta，基於 ECS 業務以及管控應用、架構、組織等資訊建設統一的業務 meta 資料，基於 meta 資料與 Trace 構建知識圖譜服務。

• Event，事件中心覆蓋了包括資源主動運維、變更、告警、資料庫、異常檢測、壓測演練等多維的異動資料。

• Business Data 與 knowledge 目前思路是提供標準化 meta 外的補充，可以作為大模型的語料輸入。

• 日誌查詢託管，解決研發最高頻的多賬號日誌查詢需求，透過RAM 角色扮演方式在嫦娥運維平臺內嵌 SLS 控制檯，解決單瀏覽器多阿里雲賬號日誌查詢需求，同時支援 全域性 logstore 搜尋、收藏與分享功能，可以將 SLS 查詢條件持久化，實現快速訪問以及分享給他人，以上所述所有操作使用者都無需感知阿里雲賬號。

• 日誌資源管控，透過持久化 SLS meta 以及 SLS 的 OpenAPI 結合業務形態實現 SLS 機器組分發、Dashboard 跨地域同步、資料投遞數倉等高階運維能力，簡化研發運維操作與成本。

技術建設

• 異構多資料來源支援，統一 Prometheus 資料協議寫入，支援 logstore 轉 metric store、ECS自研metrics框架寫入、以及同步第三方 metric 資料等多種異構資料來源接入，透過統一的 prometheus 資料協議標準，資料來源與資料儲存皆具備擴充套件性。

• 自定義 HTTP API 用於業務被整合，透過自定義 HTTP API 方式統一封裝業務模型，提供適配 ECS 業務的使用方式，天然支援 region、應用等模型引數。同時，透過 prometheus 原生協議提供  的查詢能力，這部分能力透過 SLS metric store 提供。

• 業務 labels 注入非常關鍵，如果說 ECS 管控 metrics 最核心的兩個價值，其一是資料標準化，第二就是我們透過結合業務 Meta，針對每個 metric 都加入了業務視角的 labels，這個對於上層運維能力構建至關重要。

標準規範

資料儲存規範

• 國內海外雙中心儲存，安全合規設計，ECS 管控 metric 資料不涉及使用者面合規風險，權衡安全合規與運維成本考慮透過國內+海外雙中心儲存（當前透過資料同步鏈路彙總到上海，後續需要拆分）。

• 冷熱資料分離，SLS 儲存實時 metric 資料，最長儲存一年，透過定時同步鏈路將資料迴流到 MaxCompute，並經過 ETL 加工為業務需要的資料提供給 AIOps 與大模型使用。

指標分級規範

指標體系在實際建設過程中會有兩個階段，第一階段，指標覆蓋不全，體現在觀測維度不夠豐富、告警覆蓋不全；為了解決第一階段問題，業務側通常會從多個維度層次進行指標補齊，進而指標的數量會膨脹，系統會遇到第二個問題，指標太多了，我們該怎麼用？實際經驗來看，系統需要重點關注的指標占總指標的比例不應該超過 30%，過多的重點指標意味著業務/問題題的定義不夠清晰。所以在 ECS 管控我們定義了重點指標（核心指標、關鍵指標）佔比控制在 30%以內。你可能會問，哪些指標可以定義為重點指標呢？我們的實踐建議是從客戶/業務視角出發，可以表徵客戶業務受損的指標。

指標分層規範

metric格式規範

完全遵循 prometheus metric format，time-series 儲存，sample如下：

• 指標(metric)：metric name和描述當前樣本特徵的labelsets;

• 時間戳(timestamp)：一個精確到毫秒的時間戳，當前指標預設一分鐘生成一次；

• 樣本值(value)：一個float64的浮點型資料表示當前樣本的值。

metic命名規範

labels 使用規範

labels 可以方便業務聚合，比如統計應用 A 在地域 cn-hangzhou 下所有 check health 異常的機器總量，就可以透過 labels 快速過濾。為了簡化業務使用成本，對 metric labels 進行統一使用規範，針對通用的 labels 進行命名統一。

Event：事件驅動運維架構

• 異構資料來源擴充套件支援，Event Center 本身不生產資料，只是資料搬運工。這裡我們設計了統一的事件閘道器，多協議支援彙總多資料來源的事件資訊，並提供統一的過濾加工能力，統一標準化為 CloudEvents 協議。

• CloudEvents協議標準，統一標準化事件協議，整合視角，可以將多源資料進行統一整合儲存；被整合視角，CloudEvents 協議作為開源標準，可以更好的被內部甚至是生態其它產品進行整合，比如阿里雲的 EventBridge 等。

• 高可用儲存方案，使用 SLS+mongodb 雙寫方式，保障單資料來源異常情況，服務整體高可用。

• 事件驅動運維架構，可以簡單理解成  event-driven architecture 在運維領域的應用，但這並不只是一種技術實現或者架構模式的改變，更是 DevOps 工作方式的改變。

Trace：全鏈路追蹤能力

當前 Trace 系統仍然在演進中，Trace 系統在實現上有以下幾個關鍵設計：

• Trace 埋點打通，如何解決一個 Request ID 可以打通全鏈路包括業務、中介軟體、執行緒池、資料庫全鏈路，整個過程極具挑戰。對內，要解決上述如執行緒池、資料庫串聯問題，當前我們透過 ARMS、DAS、自研能力進行串聯，目前串聯了部分，仍然覆蓋中；對外，如何打通依賴方，這個不是一個單純的技術問題，這裡不做討論。

• 編排排程能力，在全鏈路 Trace 埋點都標準化輸出到日誌的情況下，編排能力和排程能力將會非常關鍵。前者解決業務自定義擴充套件能力，簡單來說，除了支援 ECS 的業務，同樣可以支援其它雲產品接入；後者，在呼叫鏈路很長情況下，權衡查詢的體驗與準確性，這裡需要在並行排程能力上不斷提升。

Dashboard：分層觀測大盤建設

Dashboard 分層定義

觀測大盤是為了快速準確輔助人工發現觀測鏈路異常局點，所以核心是回到產品和業務本身，回到使用者視角來定義。ECS 管控為例，業務特徵是多地域單元化部署、業務形態複雜、依賴鏈路多。在觀測大盤分層上，我們也從解決上述問題思考：

• status 大盤，雲產品維度的全地域健康狀態，輔助人工發現當前異常地域。

• 核心指標大盤，覆蓋地域維度核心指標，在定位到異常地域情況，輔助快速定位異常核心指標。

• 應用大盤，應用維度從核心指標、黃金指標、中介軟體、依賴服務等幾個維度定義應用核心觀測資料，用於在定位應用異常局點。

• 業務大盤，從業務視角出發，服務正常未必等同業務正常，核心在於從使用者視角定義業務的健康狀態，以及識別異常業務。

• 場景大盤，覆蓋研發生命週期以及日常研發活動，比如 CI Dashboard、釋出可觀測性、重保（雙十一大促）觀測、容量大盤、以及垂直領域如資料、中介軟體整體的觀測大盤。

技術建設

• 核心是 Data Center，當前包括 Log 與 Metrics，ECS 管控當前所有的 log 以及 metrics 都統一託管在 sls 的 logstore 與 metric store，同時基於 SLS 開放 API 實現了一定管控能力比如多地域同步。

• 充分利用雲產品優勢，回到最初架構設計 Cloud First 原則，ECS 管控在 Dashboard 建設上也充分利用了雲產品優勢。

• 透過 SLS 與雲監控託管的 prometheus 與 grafana 能力，免去獨立運維成本

• 透過 SLS 開放 API 實現了多地域 Dashboard 同步能力，簡化多地域運維成本。

Alert： 智慧告警平臺

成熟度模型

筆者認為告警成熟度最高的級別 L4 是告警自愈，而 實現告警自愈需要一套高度體系化、高度整合化的平臺工具鏈支撐，包括業務運維領域的 CMDB、全覆蓋且準確的監控告警、可靠運維任務編排排程能力、以及對應 ITIL系統的支援，這也就是ECS管控SRE在整體運維架構裡我們堅持要定義管控的運維知識圖譜以及前期大量標準化體系和流程建設的原因。筆者認為，決定智慧（無論是 AIOps 還是當下火熱的 LLM Ops）運維能否最終場景化落地的必要條件是這些最基礎的資料和能力。

技術建設

當前彈性計算的告警整體實現了標準化、統一化的管控，其中部分核心告警實現了一定的根因定位能力，當前整體正在向告警自愈方向演進，下面是我們統一告警平臺整體的技術設計。

從產品設計角度看，有以下幾個關鍵設計分享：

1. 開箱即用，支援主流告警包括雲監控、SLS、ARMS、POP、DAS 在內的七種資料來源預設整合（大部分基於公共雲開放能力整合），通用監控告警預設整合（比如雲監控、資料庫等），業務告警在SLS配置後預設自動消費生成配置。業務只需要按照自定義需求簡單配置即可完成使用。

2. 多源支援，支援雲監控、SLS、ARMS、DAS、Grafana等多源異構告警整合，透過統一的閘道器模式進行整合，支援橫向擴充套件。

3. 豐富功能，支援告警抑制、關鍵關聯、告警診斷、關聯變更、ChatOps整合、移動端使用等豐富功能。

4. 診斷支援，支援可插拔擴充套件的診斷架構，使用者可以透過自定義告警診斷模版實現告警後的根因定位、工單路由等高階能力；同時系統也提供了通用的公共元件，如熱點日誌分析、重保客戶驗證、多地域管控等。

5. 業務打通，與彈性計算業務天然整合，配合嫦娥平臺現有的meta資料可以實現告警精準投送，值班體系打通，以及業務診斷擴充套件，團隊釘群定向投送，團隊告警度量等業務視角高階能力。

應用可觀測性

ECS 管控整個穩定性保障以及運維自動化體系都是圍繞“應用”來建設的，對於可觀測性視角來說，應用維度的可觀測效能力至關重要。前面提到的無論是 Data Center、Event、Trace、Dashboard、Alert 都會從有一個重要維度是應用。而應用可觀測性建設部分我們完全依託於 ARMS 應用可觀測效能力，透過應用接入 ARMS 以及配合 ECS 應用 Meta 嵌入了 ARMS 控制檯簡化使用成本。

status：雲產品健康大盤

而從阿里雲內部組織研發視角來看我們同樣需要能力可以感知到關注產品的全域性健康狀態，對於 ECS 管控來說這裡的全域性核心是指：全地域、全服務，全應用。雲內監控團隊建設了內部的雲產品 status 大盤，ECS 管控作為首批整合的雲產品，將 ECS 管控的觀測能力透過標準化 prometheus metric 的方式輸出。同時基於雲內監控的開放能力在 ECS 運維平臺嫦娥進行了系統整合。

AIOps 與 LLMOps

在可觀測性領域，標準化、體系化、平臺化更多解決的是規模化帶來的運維成本，而隨之而來的複雜性問題，難以透過傳統的手段解決。比如規模性或者故障反饋鏈路很長情況，如何快速定位故障根因。

智慧運維這個方向以及對於大型研發團隊的價值，個人堅定不移地相信。當然 AIOps 甚至最近火熱的 LLMOps 只是手段，一切要回到解決業務問題的命題才有價值。而前文提到的 Data Center 裡包括 metric、log、trace、meta、知識圖譜、業務知識等資料是構建智慧運維的基石，也是 AIOps、LLMOps 等可以在業務團隊落地的關鍵。