Service Mesh 是目前社區最為炙手可熱的技術方向，去年雙11在螞蟻金服得到全面的應用，並平穩順滑的支撐了大促服務。作為目前規模最大的 Service Mesh 集群，本文從監控的領域對 Service Mesh 落地進行經驗總結，主要從以下幾方面進行介紹：雲原生監控，介紹螞蟻金服 Me... ...

引言

Service Mesh 是目前社區最為炙手可熱的技術方向，去年雙11在螞蟻金服得到全面的應用，並平穩順滑的支撐了大促服務。作為目前規模最大的 Service Mesh 集群，本文從監控的領域對 Service Mesh 落地進行經驗總結，主要從以下幾方面進行介紹：

雲原生監控，介紹螞蟻金服 Metrics 監控的落地；
用戶視角分析，介紹從應用 owner 的角度對這一基礎服務設施的體驗以及 SRE 從全站服務的穩定性對監控提出的要求；
未來的思考，介紹後續發展方向；

雲原生監控

雲原生應用的設計理念已經被越來越多的開發者接受與認可，今年螞蟻金服應用服務全面雲原生化，對我們監控服務提出更高的要求。目前 Metrics 指標監控服務也逐漸形成體系，如下圖所示基於社區原生 Prometheus 採集方案在螞蟻金服監控場景下落地。

怎麼採集

螞蟻金服監控採集 AGENT 是部署在物理機上，支持多個採集插件，如下圖，包括執行命令、日誌、HTTP 請求、動態 SQL 採集、系統指標採集、JVM 採集以及進程監控等，同時支持多個解析插件自定義解析、單行文本解析、Lua 腳本解析、JSON 解析以及 Prometheus 解析等。

在Service Mesh 監控落地中，業務方參考業界標準輸出 Metrics 指標數據，監控採集該物理機不同 Pod、App 和 Sidecar 的各項指標，包含 Metrics 指標和系統服務指標（CPU、MEM、DISK、JVM、IO 等），然後計算清洗集群節點通過拉取最近周期數據進行數據彙總、groupby 等，數據採集周期又分為：5秒級數據和分鐘級數據。對於 Service Mesh 來說，主要關註的指標有系統指標和 Metrics 指標：

系統指標（包括 Pod、App 和 MOSN 等 Sidecar 多個維度的系統指標）：系統指標, 包含 CPU、LOAD、MEM、BYTES、TCP、UCP 等信息；磁碟，包含分區可用空間、使用率等信息； IO，包含 IOPS 等信息；
Metrics 指標： PROCESSOR，包含 MOSN 進程打開的 fd 數量、申請的虛擬記憶體大小等進程資源信息； GO，包含 MOSN 進程 goroutine 數量(G)、thread 數量(M)以及 memstats 等 go runtime 信息； Downstream，包含全局下游累計建鏈數、總讀取位元組數、累計請求數、請求耗時等； Upstream，包含上游請求失敗次數、集群累計建鏈數、累計斷鏈數、異常斷鏈次數、上游請求平均耗時等； MQ Mesh，包含發送消息總數、耗時、失敗數等以及消費消息總數、耗時、失敗數等； Gateway Mesh，包含 qps、rt、限流以及多維度的成功數和失敗數等；

數據計算

對於 Agent 採集的數據需要從不同維度向上匯聚，滿足不同用戶對不同視角（LDC、IDC、APP、架構域、站點等視角）的數據需求，以適配螞蟻金服運維架構體系。

此時對於這麼大規模的數據體系，我們團隊建設螞蟻金服統一的監控數據計算平臺。

使用統一的監控數據標準、插件化的數據採集接入、通用的數據服務 API 服務來幫助不同的監控產品的快速迭代；
建立一套健全的數據質量體系、高可用計算集群來保障監控數據質量；
通過類 SQL 任務定義、自定義計算任務、插件化來提供豐富、開放的數據分析能力，來滿足技術風險業務領域下各種複雜數據分析的需求；

其中計算任務調度（spark）執行的關鍵組件包括 GS(Global-Scheduler 全局圖調度)和 CS (Compute-Space 計算空間)。

GS 是平臺的任務調度中心，如下圖所示，它收集了所有業務的數據源配置，根據數據源之間的計算關係，構建出全局計算任務拓撲模型(GlobalGraph)。再根據不同的任務執行策略，將全局任務拓撲圖切割成小範圍的任務拓撲(Graph)。主要特性有：

GS 根據任務優先順序、資源質量、負載情況等策略，將 Graph 分發到不同的計算空間進行計算(Cspace)；
同一個 Graph 內部的數據依賴是計算過程中直接依賴的；
不同的 Graph 之間的數據依賴會通過存儲進行數據解耦；
GS 會管理所有 Graph 及計算節點的任務狀態，根據 Graph 的依賴關係和依賴 Graph 的執行狀態，控制 Graph 的執行時間；

CS 是計算平臺抽象的計算任務執行空間，如下圖所示，主要負責 Graph 的解析和具體計算任務的提交執行，適用於不同的計算引擎，如 Spark/Flink。以 Spark 為例，CS 接收到 GS 發出的 GraphTask，根據 GraphTask 中的 Node(Transform) 解析成 Spark 的 Transfomation 運算元和 Action 運算元，組成計算 DAG 並提交到 Spark 集群執行。

在任務執行過程中，CS 會向 GS 同步各任務的執行狀態，用於任務跟蹤監控。

多個 CSpace 組成一個 CSpaceGroup，CSpace 之間可以根據負載均衡、資源等級、藍綠發佈等具體場景劃分不同的計算分組，多個 CSpace 之間的任務切流可以滿足負載均衡、資源隔離、藍綠發佈、灰度等高可用的要求。

規模化問題

對於螞蟻金服這麼大規模的 Service Mesh 集群數據，產品請求無法都通過 PromQL 方式實時查詢結果，以及報警及時通知。此時我們對於監控數據進行分類，其中應用、機房、站點等維度數據進行預計算聚合，例如不同機房的 QPS、RPC 轉發成功量、Error 錯誤等等，前端通過自定義配置出自己關註的大盤視圖。

其中今年大促 MOSN 容器達到幾十萬，在頻繁的發佈部署，上線下線過程中，對監控查看的實時性提出更高的要求。其中 Meta 元數據模塊對接 K8s 集群，部署監控 operator 監控容器狀態變化，達到秒級將最新採集配置通過 Agent registry 更新到 Agent 模塊。

大促保障

我們一方面對監控高可用進行保障，做到採集計算水平擴縮容，另一方面對容量進行評估，通過對不同任務進行分級處理，在大促的時候對高優先順序任務進行重點保障，對低優先順序任務和業務方進行溝通做降級處理。這樣在監控計算資源緊張的情況下，保障核心數據穩定。

產品視角

Service Mesh 是螞蟻金服內部應用服務所使用的基礎服務設施，對不同的用戶看的視角不一樣。在監控產品上，用戶對產品的使用主要集中在“配、看、用”數據這三個層面。我們早期也做過類似的用戶分析。在螞蟻金服按使用方式將用戶分為全局關註者，產品 owner、SRE、領域專家和普通用戶等，這裡監控產品對於 Service Mesh 也提供不同的視角滿足不同的用戶需求，舉例來說：

產品 Owner 視角：特指 MOSN 產品的開發們，他們重點負責 MOSN 的監控指標數據覆蓋、數據準確性以及重點調優目標；
普通用戶視角：特指應用 Owner，應用 Owner 主要看 MOSN 服務對應用 RPC 調用的影響以及該應用使用 MOSN 服務帶來的效率提升；
SRE 視角：他們關註全局視角，需要知道全部 MOSN 服務的穩定性，更註重預警、分析；
領域專家視角：特指對深度監控數據的使用者，比如深度的 JVM、CPU，Go 等指標，以及更深入的 perf、jfr 分析；
全局視角：特指架構師層次或全站維度關註者，關註全站應用服務領域；

應用 Owner

應用 Owner 對於這一新服務，期待又緊張，既期待這個 MOSN 服務可以給自己帶來什麼新的特性和服務，又擔憂新服務給我又帶來一層依賴和穩定性問題。此時對於產品上，在滿足數據可觀測性的同時，重點突出 MOSN 核心指標觀測，以及 MOSN Error 的數據歸檔，同時告警能力及時適配，讓開發 Owner 第一時間知道問題出在哪。

由於 MOSN 的部署模式是和應用容器是在同一個 Pod 裡面，那麼應用 Owner 這時會擔心資源搶占問題，當然最終還是靠數據來驗證，此時水位數據平鋪對比必不可少。

MOSN 產品專家

MOSN 產品技術專家對自己新的服務充滿信心，但是他們需要檢驗自己產品總體的性能指標以及性能調優，以達到最優化。所以一開始監控產品配合 MOSN 服務從線下到線上完成數據的覆蓋和準確性校驗，後來到核心指標的全局觀測與對比。

在 MOSN 服務上線的過程中，打交道最多就是 MOSN 技術專家，類似 MOSN 大盤已經有應用維度匯聚的大盤展示，但是對於錯誤排查來說，全局的單機維度系統指標(cpu、mem、load) top n 更有意義，可以協助快速發現 CPU、MEM 異常的實例。

SRE 專家

SRE 專家們總是對新產品上線產生莫名的擔憂，特別是今年螞蟻金服 MOSN 服務這麼大規模，所以此時需要充分數據做驗證來達到上線的標準。此這時候又需要監控提供數據，特別是全站維度的數據，為此我們專門提供核心應用服務盯盤，在壓測過程中觀測核心應用 MOSN 的 rt、報錯量以及 top 實例的水位等等。