【百度云原生導讀】在前一篇《基于 Prometheus 的大規模線上業務監控實踐》中，我們為大家介紹了針對大規模業務監控場景，百度云原生團隊基于 Prometheus 技術方案的一些探索，包括基于 Prometheus 進行指標降維、Prometheus 的自動分片采集、以及基于 Flink 流式計算構建的預計算。

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

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

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

下文將從“資源、高可用、運維”三個方面，為大家帶來我們的實戰經驗。

資源

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

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

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

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

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

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

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

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

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

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

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

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

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

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

?

高可用 HA

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

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

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

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

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

結語

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

總結

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

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