【百度云原生導讀】在前一篇《基于 Prometheus 的大規(guī)模線上業(yè)務監(jiān)控實踐》中，我們?yōu)榇蠹医榻B了針對大規(guī)模業(yè)務監(jiān)控場景，百度云原生團隊基于 Prometheus 技術方案的一些探索，包括基于 Prometheus 進行指標降維、Prometheus 的自動分片采集、以及基于 Flink 流式計算構建的預計算。

本文將深入采集專題，為大家介紹如何構建采集億級別指標的高可靠Prometheus 集群。

采集億級別指標，通常會面臨三大類問題：一是網絡帶寬打滿、Prometheus大內存、Prometheus計算 CPU 利用率高等一系列資源類問題；二是如何構建高可用、高可靠的集群，如何確保監(jiān)控數據的不丟不重等高可用類問題；三是集群的自動彈性擴縮，如何進一步降低運維成本等運維類問題。只有解決好這三類核心問題才能構建出一套理想的 Prometheus 采集集群。

為此，百度云原生團隊針對 Prometheus 提出了“流計算加速”、“高可用HA”、“感知采集壓力的自動分片管理”等多項“外科手術式打擊”般的精準解決方案，最終實現了億級別指標的采集。

下文將從“資源、高可用、運維”三個方面，為大家?guī)砦覀兊膶崙?zhàn)經驗。

資源

采集開壓縮，降低網絡帶寬壓力

按照單指標100b大小、5s采集一次計算，采集億級別指標，采用千兆網卡也存在網卡被打滿現象；另外監(jiān)控作為服務的旁路系統，首先要保證的是不能影響業(yè)務的正常使用。Prometheus 自身支持帶壓縮的采集，只需將 Exporter 中 HTTP Content-Encoding 設置為 Gzip 即可開啟。經實際測試，開啟壓縮后，壓縮率通常在幾十分之一，這樣就可降低網絡帶寬壓力；如果 Exporter 吐出數據塊相同部分較多，壓縮將更加有效。

指標壓縮+加快數據落盤，避免大內存問題

Prometheus 大內存問題是被經常詬病的問題之一，隨著數據采集時長增加，Prometheus CPU 和內存都會升高，但內存會首先達到瓶頸，這會導致 Prometheus 發(fā)生OOM 造成重啟，采集發(fā)生中斷。為解決這個問題，我們可以從以下兩方面入手：

減少維度數量，縮短指標、維度長度來減少內存使用：Prometheus 將最近拉取的數據保存在內存中，提供實時數據的高效查詢；另外加載查詢歷史數據時，需要將歷史數據加載到內存中。如果維度數量多或者指標、維度字符長度過長，內存使用量就會越大。因此可以通過減少維度數量、或者縮短指標、維度字符長度來降低內存使用量。需要注意的一點是縮短指標和維度時，對于指標能夠反映出其所屬的域以及指標單位，對于維度可反映該實例的維度特征。

加快 block 數據落盤頻率來釋放內存：Prometheus 內存消耗主要是因為每隔2小時做一次 block 數據落盤，落盤之前所有數據都在內存里面，默認是2h落盤一次。因此可以通過調整 Prometheus 內存數據保存時長，加快落盤頻率來釋放內存。在生產環(huán)境可根據實際情況進行縮短，如調整到半小時級別。

引入流式計算，降低 CPU 使用

Prometheus 提供了預聚合 (Recording Rule) 可以讓我們對一些常用的指標或者計算相對復雜的指標提前計算，然后將這些數據存儲到新的數據指標中，查詢這些計算好的數據將比查詢原始的數據更快更便捷。但 Prometheus 提供的預聚合采用的是“批計算”，Prometheus 首先會緩存所有指標，在窗口將要關閉時進行實時查詢計算，這對于承擔大規(guī)模采集任務的 Prometheus 是致命的，因為在每次執(zhí)行計算時，會消耗大量的CPU，同時計算的延遲特別大，對于萬級別的指標量計算延遲將達到分鐘級別，考慮到后續(xù)報警等通路的延遲，這樣的延遲在預計算側顯然是不能接受的。

針對預計算慢的問題，通過自研 Adapter 模塊將“批計算”改為“流計算”來加速。以計算每個周期的總請求數為例，使用 PromQL 可以通過前后兩個周期的 Sum 值相減來計算，并在 PromQL 中指定需要保留的維度，但 PromQL 計算時減法、求和是發(fā)生在計算窗口關閉時；而使用 Adapter 的流計算，其具體做法是：

? ? ? ? 1. Adapter 模塊與 Prometheus 同 Pod 部署，并實時讀取 Prometheus 的 WAL 數據；

? ? ? ? 2. Adapter 模塊緩存了該 Prometheus 上個采集周期所有時序數據的值，讀取到本周期的值后減去上個周期值，作為該時序數據本周期的增量值；

? ? ? ? 3. 求得本周期增量值后，根據用戶配置的匯聚規(guī)則直接將該增量值累加為和值；

? ? ? ? 4. 當計算窗口關閉時，可直接輸出累加的和值；

可以看到 Adapter 通過以數據驅動的流處理達到了計算加速的效果。同時 Adapter 模塊同時還可執(zhí)行指標的黑白名單過濾、指標標簽的 Relabel 等操作。常規(guī)的 Prometheus數據發(fā)送是通過 Remote Write 方案，使用該方案需要對時序數據經過多次的序列化與反序列化，同時還有數據傳輸上的消耗，使用 Adapter 直接讀取 WAL 數據則避免了這些消耗，降低了 CPU 的使用。

?

高可用 HA

Prometheus 有本地存儲數據能力，但 Prometheus 之間沒有數據同步能力。所以要想在保證可用性的前提下再保持高可用，使用 HA 是最佳的方案。將采集的任務分 Shard，每個 Shard 包含兩個 Prometheus 副本。每個副本都有自己對應的 Sidecar Adapter。Adapter 做選主邏輯，只有主 Adapter 對應的 Prometheus 副本數據能推送到后續(xù)通路，這樣可以保證一個異常，另一個也能推送成功，確保數據的不丟不重。在實現 Adapter 的選主可以有多種方案，比如 Raft、依賴 Zookeeper 等。由于部署在 K8s 集群中，從時效性、可運維性等方面考慮，基于 K8s Lease 資源，實現租約機制的選主方案是最佳方案。采用該方案在 Prometheus 異常、Adapter 異常甚至兩者都異常時都可在5s內實現主備切換，確保了采集數據的不丟失。

與常見的 Prometheus 高可用方案 Federate、Cortex、Thanos 相比，使用基于Adapter 做數據去重的方案可以避免如下問題：Federate 方案需要逐層做數據聚合，將減少的后的數據傳輸到中央 Prometheus 中，故其適用于最終分析的數據量偏少的場景。Thanos 的數據去重是查詢時數據去重，這意味著 Thanos 會存儲多份的冗余數據，存儲的開銷也會相應地更大 。

采用云原生部署，降低運維成本

作為新一代的開源監(jiān)控解決方案，Prometheus 自身具有強大的采集性能，單實例采集能力可達百萬級別指標。如果采集億級別指標，粗略估算需要幾百臺服務器；再考慮采集集群的容災、冗余等問題，消耗的服務器資源甚至可達上千臺。若維護這上千臺服務器需要耗費大量的成本。為降低運維成本，在這里我們采用 容器+K8S 的云原生部署模式，將 Prometheus 部署到 K8S 集群中。

考慮到 Exporter 吐出的指標量會隨著新指標、新維度的出現發(fā)生變化，導致 Prometheus 的采集壓力發(fā)生變化。我們還自研了 PromAgent 與 PromScheduler 模塊，PromAgent實時感知 Prometheus 采集壓力的變化，并上報給 PromScheduler；PromScheduler 收到采集壓力數據后，其分片管理功能根據自動分配算法進行自動伸展。

結語

在本文中，我們聚焦于采集專題，介紹了采集億級別指標的 Prometheus 集群設計方案，包括“資源、高可用、運維“這三方面。在后續(xù)的系列文章中，我們將繼續(xù)從計算、存儲和報警等各環(huán)節(jié)出發(fā)，繼續(xù)探討如何基于 Prometheus 構建高性能、低延遲、高可用的監(jiān)控系統，敬請期待。

總結

以上是生活随笔為你收集整理的百度可观测系列 | 采集亿级别指标，Prometheus 集群方案这样设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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