螞蟻集團的業務種類繁多，兼具金融級的“穩” 和互聯網的 “快”，支撐又快又穩的業務發展需要完善的穩定性保障體系，?這個體系的基石就是可觀測性平臺-AntMonitor?。

早在2011年前，監控平臺就已經完成初代建設，在2012到2017年這五年間，螞蟻監控技術團隊抽象出了業務視角監控牽引的模式，大大提升了核心業務的故障發現能力，同期研發了可視化引擎與易用的配置系統。為了支撐雙11等大規模海量計算場景，在底層數據技術上做到了實時穩定的大規模日志和指標處理能力。隨著這些能力的完成，可觀測平臺的產品也逐漸成熟。

2017年后，整個螞蟻集團?可觀測性能力逐步走向了全息化、數據化和智能化?。這一代整個團隊除了繼承前幾年的平臺建設優點之外，還著力解決了幾個方面的問題，包括：

• 完成從客戶端到服務端，從業務應用到基礎設施的?一站式全場景監控
• 基于監控的海量數據，?實時數據探查和分析
• AIOps?智能場景化?落地

#1 特色產品能力

1. 全息可觀測

所謂的全息觀測能力，?能力上?融合各項可觀測能力（如指標、trace、日志、性能分析）；?覆蓋面上?可以做到一站式解決端到端的各類組件。這兩點共同解決了數據孤島的問題。以前觀測類平臺往往是四分五裂的狀態，所有平臺都嘗試從自身的角度出發，去解決業務系統的觀測問題。但是這樣最終帶來的是“斷頭路”的效果，數據只有真正能相互流通關聯的時候，才能真正發揮其作用。Google也在其論文中披露，其內部監控平臺也是從各個團隊自行運維的borgmon逐漸收攏到統一的平臺Monarch上，以解決在應急和數據分析過程中跨組件，跨部門的隔閡。

就觀測能力而言，?每類觀測能力均有其優勢與不足?。比如，指標類數據是可以方便地展現一個實體（或大或小）隨時間變化的趨勢。而日志能獲取明細數據，在排查具體問題的時候非常有用。trace的話往往是站在業務請求的角度，可以串聯這一次請求中的上下文。螞蟻在統一的觀測平臺上，逐步建立了以指標和日志為主，trace為輔助的各種能力。并且更為關鍵的是，平臺很好地融合了這三方面的能力，使之能夠各取所長。除了業界強調的可觀測能力三大支柱外，螞蟻的可觀測平臺還深度建設了性能分析能力和線上單機程序診斷能力。

1）日志、指標和trace的融合產品

下圖上，我們可以看到底層的表格上均是關于錯誤量級的指標監控，同時點開也能看到錯誤的具體日志詳情，這里對日志做了大量的模式歸類、運維維度的聚合。這極大提升了業務排障的效率。

2）一體化的性能分析產品

螞蟻的一線研發運維，可以在平臺上直接或間接（通過告警自動觸發）做CPU的細粒度分析。基本上，用戶可以從宏觀的指標到精確的代碼行，都能得到定量分析。圖示為on cpu的火焰圖分析。

3）客戶端監控能力 ，以某個小程序為例，端到端的實現全面可觀測性覆蓋：

4）高效的觀測能力接入

在長期的發展中，螞蟻監控技術團隊也發現需要被監控的技術產品多種多樣，每次都單獨適配成本非常之高，因此通過定義一套通用的模型體系，滿足不同用戶需要，不僅能解決效能的提升，還可以建立統一的監控數據模型體系。技術上來講，主要是通過標準化、實體化和拓撲化來解決這個問題的。

首先是標準化 。技術棧模型方案，通過讓用戶自主的，標準的接入一個新產品，將所有能力開放給用戶，化被動為主動，一方面為用戶提供豐富的開放性能力，另一方面也以一定的標準規范約束用戶。

第二是實體化 。平臺有能力讓了解每一個組件結構模型的人，為每一個實體建立所需要的實體采集模板、展現模版和告警模版。下圖以內部的分布式數據庫 oceanbase 舉例，通過定義不同的實體模型就可以很清晰的了解它的拓撲模型（如下圖），然后根據用戶的需要對不同的實體采集指標數據，并匯聚成不同維度的數據源，然后根據數據源定義不同的展現模版。

第三是拓撲關聯的處理 。不同的產品都有一定的依賴關系，我們在構建實體模型的時候就已經有能力做到這一點了。

有了前面幾點能力，具體操作層面用戶在接入一個新類型異構的觀測實體的時候，?僅僅需要做三件事?：包括定義被觀測實體與它們之間的關系、定義實體之上的采集與計算規則、基于實體與其關系定義展現與告警模板。

2. 內置數據智能

監控的實時數據是實現AIOps的基礎，在有了實時、全面、精準的監控數據后，就可以在傳統監控的基礎上構建AIOps的數據平臺，實現智能化應用。

1）靈活的數據探索分析

數據分析視角中，最直觀的其實就是?查詢語言?。可觀測平臺內部，對所有的結構化數據分成了兩大類表：?時序表和維度表?。針對時序表，螞蟻監控技術團隊兼容了業界在指標監控領域比較流行的promQL，用戶可以直接提交進行查詢。對于需要更豐富表達能力的分析訴求，平臺上針對維度表和時序表都可以執行SQL查詢，包括復雜的互相join操作等均支持。

技術實現上，平臺對SQL和promQL的執行在架構上實現了“?多模輸入、統一執行?”的結構。首先在api層面，用戶對一個表（或者稱之為指標）既可以提交SQL 查詢和promQL查詢。兩者在語法解析層有各自獨立的實現，但是在執行層，都統一共享底層的spark、flink以及團隊自研的時序數據庫CeresDB等基礎設施。

2）算法工程平臺

有了強大的數據能力后，監控團隊針對性地建設了重點的業務場景，同時也在領域內落地了算法實驗室，完成了整個數據算法智能化的內部閉環，包括算法的部署、訓練、回歸，外部場景的管理和樣本數據的管理，以及用戶打標數據的回流等。

3）技術風險場景智能化

在Antmonitor的提供的實時數據和AI工程能力之上，螞蟻監控團隊深度構建了技術風險的各種場景智能化防控能力，為提升支付寶全局系統穩定性做出了重要貢獻。

a.智能變更防御場景

經過對螞蟻多年的故障分析，可以發現60%以上的故障都是人為變更導致的，因此沉淀了 智能分批監控、錯誤碼檢測、跨鏈路檢測、變更資損檢測、變更窗口檢測 等多種防御微服務，包含6000多個防御規則，每天256萬次自動化的防御風險校驗，自從有了這套架構，每年變更故障下降50%左右。

b. 智能應急定位場景

由于支付寶分布式系統規模龐大，一筆業務可能經過數十個系統，依賴的基礎設施也非常復雜，涉及相關人員很多，當出現業務失敗時，如何快速定位到具體的問題節點并協調相關人員助力 解決問題 ，就成為重要命題。因此產品基于監控指標和異常檢測算法，在檢測故障后在釘釘群自動提示、展示故障信息、展示輔助定位信息、組織相關人員進行相應的應急處理及善后，在部分場景實現了故障自愈。

c. 智能彈性容量場景

在螞蟻金融屬性業務高穩定性和互聯網的業務復雜性要求下，往往造成經典在線應用利用率長期低下，資源成本浪費嚴重。但是?經典的彈性伸縮無法滿足螞蟻的業務要求?，主要原因之一是經典彈性在線資源使用和利用率是無法通過簡單的線性折算出來，之二是彈性伸縮變更風險高，無技術風險控制手段，特別是縮容無風控手段，異常會直接引發故障，之三是經典在線的擴縮容速度是需要十分鐘以上，擴縮容無法滿足快速彈性的訴求。

經過多年的摸索和落地實踐，螞蟻彈性容量?基于技術風險防控體系+云原生統一資源調度+數據智能?，三者組充分結合，實現在穩定性和成本優化中取最大值?；诒O控大數據和機器學習算法、K8S、erviceMesh和技術風險防控技術，建設了適合螞蟻的全局在線資源利用率無風險精確管理和全局容量異常自適應體系。主要的核心技術有多階段伸縮、預測式伸縮、云原生分時調度技術，這也是螞蟻綠色計算的核心技術，目前?已經將7件 “綠色計算” 相關專利無償開放。

3. Monitoring as a Service 能力開放

AntMonitor在針對可觀測性這個領域，在解決一些已知的、有共性的需求的時候，都產出了對應產品能力。但是如何承載一些和外部系統（通常是SRE團隊）聯動型的需求、偏領域定制需求等“未知”的需求，如何協同平臺生態仍然是巨大的問題。

為此，在產品層面提出了建議 MaaS 的設想（Monitoring as a Service), 監控能力服務化，開放、融合監控能力到SRE各個領域，快速完成 SRE 場景建設，沉淀可復用能力，主要包含以下 3 個業務目標：

• 開放服務把監控的計算、存儲、算法、視圖等等能力開放出來。
• 促進分析服務的標準化沉淀，讓更多的場景可以復用、共同建設這部分的能力。
• 解決“監”與“控”之間的鏈接問題。

技術實現層面，螞蟻監控技術團隊主要基于serverless能力，做了一個領域性的研發與運行平臺，讓用戶的定制化訴求能直接在這個平臺通過寫一段代碼的方式得到滿足。這里可以直觀地看到一個檢查變更的服務函數的產品效果：

螞蟻技術內部的SRE、研發、質量都可以在這樣的開放技術體系下，基于監控的數據和智能化能力快速實現自己的個性化需求，目前平臺已經有3萬個API持續為各種應用場景持續提供服務。

#2 平臺核心技術

1. 融合的時序數據平臺

前面敘述的整個螞蟻可觀測性平臺AntMonitor的所有產品功能均是基于團隊研發的底層時序數據平臺pontus。這里的時序數據平臺是一個廣義的時序數據的綜合解決方案，可以看做是傳統的CMDB和時序數據的融合平臺。這個解決方案中，包括了對結構化時序數據的統一建模，數據的采集、計算、存儲能力，以及數據的管理能力。具體可以參考如下大圖：

1）數據管理能力

在整個平臺僅面對指標監控的固定需求時，對數據的管控訴求并沒有這么大。但是隨著上層觀測產品的日益豐富、數據冗余、數據口徑定義不清、數據的來源和存儲引擎的多樣化等現實情況，僅僅引擎層面提供的服務是不夠的。

AntMonitor底層的時序數據平臺 pontus 經過迭代，其數據管理能力也得到了不斷地增強，從而形成了獨立的底層技術平臺。平臺的管理能力包括了對數據整個流轉過程的全方面管理，包括采集、計算、存儲、消費等，是一個綜合性的解決方案能力。放眼業界，知名的云廠商也都演化出了其時序數據平臺或服務，比如AWS的timestream和Azure的time series insight，它們都提供給了非常強的數據管理能力。

當前，時序數據平臺管理的表數量已經達到接近百萬個，支撐了螞蟻集團所有時序類數據和元數據。

2）多維時序模型

如何用一個統一模型去組織這些數據呢？經過考慮，團隊決定讓平臺中的數據在技術上通過“表”來承載。業務上，考慮到數倉領域已經較為成熟，因此借鑒了其中一些理論，?多維時序模型其實就是數倉中雪花模型的應用?。

前面提到，時序數據平臺是一個傳統CMDB和時序數據的融合平臺，其中就有兩類相輔相成的數據，分別是元數據和時序指標數據。?元數據?是業務、應用、基礎設施自身的結構描述，而?時序數據?是他們隨時間變化的狀態描述。因此，所有表又分為時序表和維度表。維度表用來承載元數據，時序表用來存儲被監控對象的時序觀測數據，同時兩者之間可以進行關聯。

最終，所有的數據都組成了一張大網，同時做好了對任何系統的結構描述與狀態描述。

有了這樣一個模型，平臺和上層的可觀測業務就能真正的解耦，底層平臺中不會再有任何與特定的、異構的運維實體或者公司的技術業務架構綁定的概念。這也是前述技術棧產品接入能力的理論基礎。

3）海量數據處理架構

整體上，可觀測平臺是一個需要實時處理巨量數據的（每分鐘40T 輸入數據，200億個時序數據點寫入）垂直領域實時數據平臺。 而且，本身螞蟻監控技術團隊服務的上層業務就是公司的SRE與穩定性團隊，因此可以 說是線上穩定性的最后一道保障，需要在各種極端情況下保證這個實時系統自身的穩定。 要在一套解決方案中同時做好實時性、穩定性、低成本這三個點，其基礎技術挑戰非常大。

整體運行時架構可以用下圖表達：

在這套架構中，我們使用了 regional的多活架構。具體來說，regional 架構是指，所有的日志采集和指標采集的收集與解析層， 都是在機房內完成的，流量不出機房以減少對骨干網和專線的網絡壓力?；诖思軜?#xff0c;螞蟻監控技術團隊保障了在極端環境下的機房級甚至城市級的容災能力。同時常態化的使用多種手段（比如單節點的資源負載調度，多集群的負載分發管理等），確保整體數據流量的持續穩定使用。

在提升整體架構的性能水平上，重點的工作是做了算子下推。這個操作的核心思想都是就近計算，通過調度計算邏輯，減少數據的搬運。算子下推這個能力，經過自動化分析之后，甚至可能直接查詢agent的數據；或者中心數據大規模聚合可以做到盡量分級提取，能在單機完成的聚合直接聚合給出部分結果再由中心聚合。

2. 高性能時序數據庫

隨著平臺對時序數據存儲能力的訴求不斷提高，AntMonitor團隊在調研了各種開源的時序存儲之后，發現或多或少存在不滿足當前業務訴求。在時序數據場景中，螞蟻集團需要同時解決這個幾個問題：

1）讀寫高吞吐與低成本

螞蟻的觀測平臺平時每分鐘都在產生200億個時序點上。如何提升極致的讀寫性能，甚至在雙十一這樣的業務峰值的時候，也能達到比較好的性能是一個重要的命題。而且，由于業務體量巨大，在解決吞吐問題的時候，也需要考慮資源成本（機器）。

2）高可用能力

觀測系統是線上穩定性的最后保障。時序數據庫作為觀測系統的存儲。必須保證在任何極端情況下都能持續穩定提供服務，典型場景比如單機不可用、機房斷網等。

3）多租戶與管控能力

這一點，對于大型互聯網公司來說也是很關鍵的。螞蟻的觀測數據也是分等級的，不同的租戶內的管理需求，比如TTL、資源水位等都是不一樣的。

4）時序與分析能力融合

業界的時序產品，往往僅強調時序分析性能。但是我們在螞蟻的觀測平臺實踐中，除了要支持時序分析之外，還需要做大量大規模數據分析，基本等同于大數據中的AP場景。兩者的業務目標不同，如何在同一套時序數據庫中同時完成，是一個業界暫時探索不多的命題。

最終，團隊決定自研一款高性能的時序數據庫，也就是Ceresdb。而上面說的這些技術問題，均在自研產品上得到了解決，Ceresdb目前已經完整商業化，近期我們會將其核心代碼開源，貢獻給社區開放共建，希望能幫助到更多的業務場景。

3. 新硬件探索 - AEP

AEP是新型內存介質產品（數據可以持久化）。CeresDB 已經有了純內存時序數據庫 MTSDB 用于緩存最新時間段的數據以提升查詢性能，但內存是昂貴的，MTSDB 保存的數據時長也受到了內存的極大限制，很難保存超過 12 小時以上的數據，而用戶的查詢需求越來越高，這部分數據必須從更下層的分布式存儲讀取，時延相對較大，如果能將這部分數據存儲在和內存讀寫速度在一個量級的 AEP 中，那么無疑會給查詢體驗帶來很大的提升。

實踐中，我們采用了 App Direct 模式，直接使用文件系統 API 訪問 AEP，將 AEP 作為內存之下的二級存儲，從 MTSDB 淘汰的數據直接寫入 AEP，第三級為 OBKV。

目前 ceresdb 已經在線上完成了部分集群的 AEP 試點，從線上查詢觀察，查詢 RT 接近內存，下一步將繼續努力優化在 AEP 中的數據結構，提高壓縮比，降低存儲成本。

#3 總結和展望

業務訴求是技術發展的核心驅動力 ，在螞蟻業務復雜多元、極高穩定性、超大規模處理的要求下，多年持續的投入和打磨核心監控系統，逐漸演進到了今天的技術架構。同時，我們也在不斷探索技術開放，通過技術開源、產品化等方式為更多的行業數字化轉型提供穩定的底盤支撐。

在開源領域，我們的方向是兼容、提升與共享。在平臺發展的過程中兼容了大量業界的優秀實現，同時在公司超大規模的場景下，做出了大量的創新工作，比如多維時序模型、時序與分析融合的高性能時序數據庫等，形成一套領先的技術體系。后續，我們在可觀測領域的這些平臺與能力組件，都會逐步開源，首先將開源的是時序數據庫CeresDB，希望能不斷吸收業界同行的意見，也可以被更多業務場景所集成。

除了服務內部，我們的可觀測平臺產品也在逐漸開展商業化探索。監控平臺作為螞蟻技術風險商業化產品 TRaas 的關鍵產品，已經輸出到數十家銀行、機構。未來，更多在螞蟻內部監控廣泛使用的技術能力，比如數據分析、智能檢測、AIOps應用等，也將會通過各種產品形態進行技術開放，對外賦能。

?

總結

以上是生活随笔為你收集整理的十年磨一剑：蚂蚁集团可观测性平台 AntMonitor 揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。