2021 大促 AntMonitor 總結 - 雲原生 Prometheus 監控實踐

語言: CN / TW / HK
時間 2022-01-26 15:01:30

文｜陳岸琦（花名：敖清 )

螞蟻集團高階開發工程師

負責螞蟻 Prometheus 監控原生功能，在螞蟻集團的落地與產品化建設。

本文 6566 字 閱讀 15 分鐘

前 言

日誌和指標是監控不可或缺的兩種資料來源，為應用系統提供完整的可觀測性。

AntMonitor 作為螞蟻的統一監控平臺，是一款主要以日誌方式採集監控資料的監控產品。在社群，開源的雲原生監控，主要以 Metrics （指標）的方式實現監控，其中以 Prometheus 為代表。

並且 Prometheus 監控因其強大的使用者功能、結合 PromQL 的資料後分析能力，在業界有廣泛的使用者群體。實際上已成為開源標準，廣泛用於開源 Kubernetes 的叢集監控。

Prometheus 本身是一款單機監控產品，在螞蟻龐大的高可用叢集場景落地，具有一定的侷限性和困難，包括但不限於：

  1. Prometheus 沒有提供穩定的、長期的資料儲存功能，無法滿足螞蟻場景下對歷史資料的查詢；

  2. Prometheus 是有損監控，不保證資料的完整性，無法滿足螞蟻場景下對交易筆數等資料的精確性要求；

  3. Prometheus 不支援日誌監控。

但是為了滿足使用者對 Metrics 監控的需求，經過近兩年的努力，我們成功地將 Prometheus 的主要功能融合進了 AntMonitor 的現有架構，提供了一套具有螞蟻場景特色的叢集化解決方案。

今年大促，我們成功地將 Sigma 叢集監控（螞蟻原生的叢集管理和資源排程平臺）完整遷移至 AntMonitor。配合告警和大盤，實現了 Sigma 監控的覆蓋。AntMonitor 憑藉 Sigma 監控的遷移，成功孵化了完善的的雲原生 Prometheus 監控能力。

本文簡要介紹了AntMonitor 對 Prometheus 監控功能的支援，以及 Sigma 監控的落地實踐。

PART. 1 海量資料下的採集架構

以下是一段 Prometheus metrics 資料的樣例：

$ curl localhost:8080/metrics #HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles. #TYPE go_gc_duration_seconds summary go_gc_duration_seconds{quantile="0"} 7.2124e-05 go_gc_duration_seconds{quantile="0.25"} 0.000105153 go_gc_duration_seconds{quantile="0.5"} 0.000129333 go_gc_duration_seconds{quantile="0.75"} 0.000159649 go_gc_duration_seconds{quantile="1"} 0.070438398 go_gc_duration_seconds_sum 11.413964775 go_gc_duration_seconds_count 20020 #HELP go_goroutines Number of goroutines that currently exist. #TYPE go_goroutines gauge go_goroutines 47 #HELP go_info Information about the Go environment. #TYPE go_info gauge go_info{version="go1.15.2"} 1 #HELP go_memstats_alloc_bytes Number of bytes allocated and still in use. #TYPE go_memstats_alloc_bytes gauge go_memstats_alloc_bytes 5.955488e+06

Metrics（指標）資料和日誌資料擁有較大差別，包括但不限於：

第一、日誌資料寫在磁碟上，每條日誌都有標準時間戳，而 Prometheus metrics 是存在記憶體裡，採集時間以拉取的時間為準，因此資料的準確性對排程的準確性有較高要求。

第二、日誌的每次採集均採集增量即可，每次採集的資料量有限，但是 Metrics 資料每次採集均要採集全量，資料的文字大小動輒上百 MB，因此 Metrics 資料量巨大，很容易超限。

第三、日誌資料均需要按照某些固定 schema（資料表結構）作切分清洗、計算聚合，但是原生 Metrics 通常儲存單機原始資料。

AntMonitor 現有的資料鏈路大致為由 agent 採集日誌資料緩存於記憶體，由 Spark 計算叢集從 agent 記憶體中拉取資料，進行聚合，儲存於 CeresDB。

然而 Metrics 資料不同於日誌資料，單機明細資料通常具備可觀測性，具備完整的資訊。因此通常 Metrics 資料，可以跳過計算步驟，直接進行儲存。因此，Metrics 資料在保留單機明細資料的情況下，由 agent 記憶體和 Spark 拉取的方式已經不合時宜，不僅浪費了計算資源，agent 記憶體也無法支撐住龐大的 Metrics 資料量。

因此，我們根據使用者的業務需求，提供了兩條資料鏈路：

  • 在需要保留單機明細資料的情況下，走基於閘道器的明細資料採集鏈路；

  • 在需要資料聚合的情況下，走基於 Spark 的聚合資料採集。

1.1 基於閘道器的明細資料採集

為了使保留明細資料跳過計算叢集直接儲存，我們研發上線了一套專門服務 Metrics 資料的中心化採集 + push 儲存的鏈路。

中心化採集相對於傳統的 agent 採集，不再需要依賴於部署在每臺物理機，而是隻通過 HTTP 請求的方式採集 Metrics 資料。中心化採集對 Metrics 的採集配置進行結構化的下發和排程，以此滿足了 Metrics 採集對時間戳排程精確性的要求。並且，中心採集對採集到的資料不存記憶體，而是直接以 push 的方式推送給 PushGateway，由 gateway 直接儲存至底層 CeresDB。

圖片

這套採集方案，滿足了 Metrics 對時間精度和儲存單機資料的要求。並且將 Metrics 資料採集與現有的日誌採集接耦，使二者互不干擾，解放了對 agent 記憶體和計算資源的高消耗。

該套方案已經成功用於螞蟻 Sigma 等多個技術棧和基礎設施的 Prometheus 採集，目前每分鐘處理上億條指標資料。

1.2 基於 Spark 的聚合資料採集

以 Sigma 為代表的基礎設施監控，對單機明細資料有較大需求。但是保留明細資料也有較大的缺點，例如：資料量龐大，對儲存消耗較高；資料查詢時，耗時和資料讀取量巨大。

但是對於一些業務應用使用者，對單機明細資料並不關注，只關注於一些維度的聚合資料。例如，以機房維度、叢集維度等。因此在這種場景下，儲存明細資料，會造成較大的儲存浪費，並且在資料查詢時，會帶來很差的使用者體驗。因此在這種場景下，我們保留了目前 AntMonitor 傳統的日誌鏈路，對採集的 Metrics 單機明細資料進行了聚合進行儲存。在業務不關注單機明細資料的場景下，這條鏈路擁有明顯的好處，節省了儲存空間，提升了使用者查詢的速度。

圖片

但是不同於日誌監控的資料聚合，必須由使用者配置聚合規則，由於 Metrics 資料本身就包含 schema 資訊，我們通過自動化的配置項，自動對 Gauge、Counter、Histogram 等 metric type 自動為使用者生成了聚合配置，免去了使用者手動配置聚合的繁瑣：

圖片

下圖總結對比了資料聚合與不聚合的區別和優劣：

圖片

PART. 2 維表體系下的元資料統一

原生 Prometheus 提供多種服務發現機制，如 K8s 服務發現通過 apiserver 可以自動獲取發現採集的 targets。但是，AntMonitor 作為一個螞蟻統一監控系統，顯然是不能通過 apiserver 自動發現監控目標。

AntMonitor 在日誌監控的現有基礎上，建設有一套較為完善的元資料維表體系，包含了 SOFA、Spanner、OB 等多個螞蟻技術棧元資料。元資料告訴我們去哪裡採集監控資料，對應原生的服務發現機制。為了拉齊原生功能，我們對部分維表進行了必要改造，此處我們以 Sigma 監控的落地實踐為例，簡要介紹下我們的元資料同步流程。

2.1 Sigma 元資料同步

AntMonitor 進行 Sigma 監控的前提是要獲取元資料，元資料告訴我們去哪裡採集監控資料。

為此，我們設計了基於 RMC（螞蟻的統一元資料平臺） 的 “全量同步+增量同步” 元資料同步方案。前者保證元資料齊全可靠，後者基於 AntQ 實現，保證了元資料的實時性。

圖片

圖片

從圖中可以看到，為了對齊原生的 staleness 功能，Sigma pod 元資料統一添加了下線 (offline) 這個中間狀態。

原生 Prometheus 通過 relabeling 功能實現採集目標過濾等，還可以通過 metric relabeling 對拉取到的資料進行編輯。Sigma 元資料同步還記錄了一些必要的 Sigma pod labels，並支援在採集配置時，通過這些 label 設定黑白名單；支援附加 label，實現了類 Prometheus relabling 及 metric relabeling 的功能。迎合雲原生監控配置體驗。

圖片

圖片

PART. 3 分散式架構下的儲存叢集

我們以 Sigma 業務為例，因為 Sigma 的 Metrics 資料需要儲存單機明細資料，並且很多主要元件均是 15s 級，因此資料寫入量巨大，目前資料量寫入量每秒數百萬資料點。因此導致資料查詢時，經常超出限制，無法產出資料結果。因此 CeresDB 針對這種資料量巨大的情景，按 label 標籤進行了分割槽。例如 Sigma 的 Metrics 資料，通常帶有 cluster 叢集標籤，CeresDB 按 cluster 維度對 Sigma 資料進行了分割槽。在通過 PromQL 查詢資料時，會將查詢按 cluster 維度拆分下推至所在 data 節點進行執行，再由每個 data 節點產出的結果，在 proxy 節點產出最終查詢結果，返回至使用者。

不同於單機版本的 Prometheus ，CeresDB 是採用 share-nothing 的分散式架構，叢集中有主要有三個角色：

  • datanode：儲存具體 Metric 資料，一般會被分配若干分片(sharding)，有狀態

  • proxy：寫入/查詢路由，無狀態

  • meta：儲存分片、租戶等資訊，有狀態。

一個 PromQL 查詢的大概執行流程：

  1. proxy 首先把一個 PromQL 查詢語句解析成語法樹，同時根據 meta 中的分片資訊查出涉及到的 datanode

  2. 通過 RPC 把語法樹中可以下推執行的節點發送給 datanode

  3. proxy 接受所有 datanode 的返回值，執行語法樹中不可下推的計算節點，最終結果返回給客戶端

我們以這個 PromQL 查詢為例，執行示意圖如下：

java sum(rate(write_duration_sum[5m])) / sum(rate(write_duration_count[5m]))

圖片

這樣的分片演算法，加上 CeresDB 做的其他計算優化，使得 Sigma 的查詢資料效率有極大提升。現對於原生 prometheus + thanos 架構，大部分高耗時查詢，效率提升了 2-5 倍。

PART. 4 Grafana Component

AntMonitor 的視覺化主要為日誌監控設計，而社群普遍使用 Grafana 來解決雲原生監控的視覺化問題。我們對比之後發現，AntMonitor 原有的視覺化無法承載以 PromQL 為主的視覺化能力。為此，我們需要尋找到既能嵌入原有架構，又能滿足雲原生視覺化需求的方案。

Grafana 的前端程式碼主要由 AngularJS 1.x + React 寫成，AngularJS 主要承擔 bootstrap 的功能。並且，部分公共的 service 類也由 AngularJS 承擔，React 主要承擔渲染層以及新功能的編寫。

早期接觸過 SPA 應用的朋友應該知道，AngularJS 1.x 作為第一代全功能的前端框架，存在程式碼耦合嚴重，無法靈活嵌入其他框架的問題。我們通過魔改 AngularJS 的原始碼，使其具備重複 bootstrap 的能力，以方便嵌入其他框架來解決這個問題。並且，我們為 Grafana 編寫了一套新的 React Component 庫，方便與其他業務整合。目前，我們已經成功將此功能輸出到多個場景使用。

在有了前端之後，我們便不需要整套的 Grafana 元件也不需要整套的 Grafana 後端 API，我們用 SOFABoot 實現了 Grafana 部分必要的 API 例如 dashboard、query、annotation，結合我們元件化的 component 提供給使用者使用。

PART. 5 分散式架構下的 Rule 執行引擎

原生 Prometheus 提供了 Recording Rules (RR) 和 Alerting Rules (AR) 功能，將一些指標預計算並存儲，方便日常查詢。這是一個 Prometheus metrics 獨有的功能，可以解決上文提到的實時查詢耗時較長的問題。

基於此，我們定製開發了與 Antmonitor Prometheus 監控配套的 Rule 執行引擎，相容了原生的 YAML 編輯、匯入、下發 RR/AR 的操作體驗，並通過 alertmanager 接入各類告警閘道器進行告警分發。這套 RR/AR Rule 執行引擎已經成功應用於 Sigma 監控、Antmonitor SLO 服務、系統監控等業務。

5.1 Antmonitor SLO 服務接入實踐

Antmonitor SLO 服務需要計算服務各項指標不同時間段內的表現，如：一天、一週、一個月成功率和耗時等。這些可以作為 RR 交給我們的 Rule 執行引擎預計算並存儲，供使用者查詢，同時還可以將 "SLO+閾值" 作為 AR 計算告警，並交給告警閘道器傳送出去。

SLO 的 RR 具有一定規律，大部分是 sum_over_time() 形式。針對這一特點，Rule 執行引擎實現了基於滑動視窗的計算方式，並克服了由此因為滑動引發的各種計算誤差問題，有效降低了下游計算壓力。

5.2 可回放的 Recording Rules

Rule 執行引擎除了支援實時的 RR 計算外，還支援歷史 RR 重計算，可以自動檢測歷史計算結果並重計算覆蓋。主要應對以下場景：

1）異常資料修復：Rule 執行引擎在執行過程中，難免會因為各種原因（如：源資料異常、底層依賴服務 pontus、CeresDB 偶發故障等）導致 RR 計算異常，而出現異常資料。異常資料可能會造成哭笑不得的體驗（成功率>100%）、錯誤傳遞（SLO 場景下，一個時間點的資料異常會通過 sum_over_time 函式持續傳遞下去）、持續誤警等。由此可見，需要一種機制能快速恢復異常資料。

2）當一個新的 RR 集合接入 Rule 執行引擎，一般而言使用者只能得到接入時刻開始的 RR 計算結果，使用者需要等待一段時間才能得到一個趨勢圖，如果使用者想看的趨勢圖時間跨度很大，這個等待的時間成本太高了。歷史 RR 重計算可以很好的解決這一痛點，可以直接重計算接入時刻前任意區間的 RR 計算結果。

PART. 6 功能展望

今年我們成功地將 Sigma 監控在 AntMonitor 落地，建設了基礎設施能力，積累了業務實踐經驗。明年我們將將工作重點轉移到服務 C 端使用者，為 C 端使用者提供極致順暢的監控體驗。目前 C 端使用者（業務使用者）在 AntMonitor 的 Metrics 監控能力還較為零散，我們明年將致力於 Prometheus 能力的整合，提供順暢的一站式體驗。

【特別緻謝】

特別緻謝專案業務方，Sigma SRE 團隊提出的寶貴建議和意見，和對開發過程中所遇到困難的包容和理解。

特別緻謝專案元資料合作方 RMC 團隊，對專案的友情支援。

也特別緻謝每一位 AntMonitor 雲原生監控專案組的每一位成員對本專案的鼎力相助。

【參考連結】

-【Prometheus 官方文件】

http://prometheus.io/

-【Prometheus on CeresDB 演進之路】

http://mp.weixin.qq.com/s/zrxDgBjutbdvROQRYa3zrQ

本週推薦閱讀

Prometheus on CeresDB 演進之路

深入 HTTP/3（一）｜從 QUIC 連結的建立與關閉看協議的演進

降本提效！註冊中心在螞蟻集團的蛻變之路

螞蟻大規模 Sigma 叢集 Etcd 拆分實踐

img

「」
「」