引言
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 執行個體的水位等等。
全局架構師
全局觀測者當然關注核心名額，在了解 SRE 穩定性方案的同時，關注全部 MOSN 服務帶來的性能提升，例如業務轉發成功率，MOSN rt 等名額。
除了上述的這些基本産品能力以外，我們還嘗試着從資料、功能、體驗這些角度繼續提升産品。
未來的思考
螞蟻金服監控産品将緻力于成為雲原生時代的全棧監控，從應用到基礎設施，從雲、邊到端，将技術風險領域的監控資料全部透明化，均具備一站式可觀測能力。對内将支撐技術風險各個領域的業務場景，包括應急、容量、限流、安全、變更、大促等，對外将支撐科技輸出、雲産品、國際賦能和商業化。
後續重點方向有 Monitoring as a Service，旨在讓業務研發和 SRE 同學通過 Code 方式完成從監控資料采集、資料聚合、預警規則配置、大盤 CMS 報表展現等功能，提升監控業務場景的便利性、靈活性和創造性，為監控領域豐富多彩的玩法帶來更多可能。
最後，也歡迎志同道合的夥伴加入我們，一起參與金融級監控系統架構設計和創新。
關于我們
歡迎來到「螞蟻智能運維」的世界。本号由螞蟻智能監控團隊出品，面向關注智能運維技術的同學，将不定期與大家分享雲原生時代下螞蟻金服在智能監控的架構設計與創新方面的思考與實踐。
螞蟻智能監控團隊，負責螞蟻金服的基礎設施和業務應用的監控需求，正在努力建設一個支撐百萬級機器叢集、億萬規模服務調用場景下的，覆寫名額、日志、性能和鍊路等監控資料，囊括采集、清洗、計算、存儲乃至大盤展現、離線分析、告警覆寫和根因定位等功能，同時具備智能化 AIOps 能力的一站式、一體化的監控産品，并服務螞蟻金服衆多業務和場景。
關于「智能運維」有任何想要交流、讨論的話題，歡迎留言告訴我們。
PS：螞蟻智能監控正在招聘 AIOps 專家，歡迎加入我們，有興趣聯系 [email protected]