Qunar 容器集羣監控系統架構實踐

作者介紹：

王坤，2020 年加入去哪兒網，高級系統運維工程師、去哪兒雲原生 SIG、基礎設施 SIG 成員，目前主要負責 Kubernetes、容器指標監控等系統的運維和雲原生相關工作。

一、概述

在雲原生的體系下，面對高彈性、拆分微服務以及應用動態生命週期等特點，傳統監控體系如 cacti 、nagios 、Zabbix 等已經逐漸喪失了優勢，難以適用和支撐，對應的新一代雲原生監控體系應運而生，Prometheus 爲核心的監控系統已成爲雲原生監控領域的事實標準。

之前公司有文章介紹過，Qunar 內部的一站式監控平臺，後端存儲是基於 Graphite+Whisper 做的二次開發，前端控制面是基於 Grafana 做的二次開發。而 Grafana 是支持多數據源的，其中就包含 Prometheus 數據源。所以在容器化落地期間最初計劃採用的監控方案也是 Prometheus ，其本身是個 All in One 的系統，擁有強大的 PromQL ，集採集、處理、存儲、查詢、rule 檢測於一身，非常易於部署和運維。但每個系統都不是完全能夠契合使用需求的，Prometheus 也一樣不是完美的。

該文章將以 Qunar 容器監控實踐過程和經驗爲基礎，講述我們監控體系構建、遇到的挑戰和相應對策，以及對 VictoriaMetrics 的簡單介紹與 Qunar 在過渡至 VictoriaMetrics 後的效果。

二、使用 Prometheus 的相關問題

Prometheus 是個 All in One 的系統，集採集、處理、存儲、查詢、rule 檢測於一身，這樣做易於部署和運維，但也意味着喪失了拆分組件所具備的獨立性和可擴展性。實踐測試摘錄的幾個問題如下：

• 數據採集量大存在瓶頸，目前 Qunar 單集羣容器指標量級每分鐘將近 1 億；

• 不支持水平擴容；

• 只支持 All in One 單機部署，不支持集羣拆分部署；

• 其本身不適用於作爲長期數據存儲；

• 佔用資源高；

• 查詢效率低，Prometheus 加載數據是從磁盤到內存的，不合理查詢或大範圍查詢都會加劇內存佔用問題，範圍較大的數據查詢尤其明顯，甚至觸發 OOM 。

如上例舉的幾項問題點，其實對於大多數公司來講都不是問題，因爲沒有那麼大的數據量和需求。但是對於我們或一些數據規模較大的公司來講，每一項都在對我們的使用環境說 No...  我們也對這些問題嘗試了以下解決方案：

使用分片，對 Prometheus 進行按服務維度分片進行分別採集存儲。默認告警策略條件是針對所有 Targets 的，分片後因每實例處理的 Targets 不同，數據不統一，告警規則也需要隨着拆分修改。

使用 HA ，也就是跑兩個 Prometheus 採集同樣的數據，外層通過負載均衡器進行代理對其實行高可用

使用 Promscale 作爲其遠程存儲，保留長期數據注：Promscale 是 TimescaleDB 近兩年發佈的一個基於 TimescaleDB 之上的 Prometheus 長期存儲。

但做了這些處理後，其實還是留存問題，也有侷限性和較大隱患：

例如 2 個實例，1、2 同時運行採集相同數據，他們之間是各自採集各自的沒有數據同步機制，如果某臺宕機一段時間恢復後，數據就是缺失的，那麼負載均衡器輪訓到宕機的這臺數據就會有問題，這意味着使用類似 Nginx 負載均衡是不能夠滿足使用的。

各集羣 2w+ Targets，拆分 Prometheus 後可以提升性能，但依然有限，對資源佔用問題並未改善。

遠程存儲 Promscale 資源佔用極大，40k samples/s，一天 30 億，就用掉了將近 16 cores/40G 內存 / 150GB 磁盤。而我們單集羣 1.50 Mil samples/s，一天就產生 1300 億左右，而且需求數據雙副本，這樣的資源需求下如果上了線，僅磁盤單集羣 1 天就要耗費 12TB 左右，這樣的代價我們是表示有些抗拒的。。

三、接觸 VictoriaMetrics

在爲調整後面臨到的這些難點，進行進一步調研，結合 Qunar 自身經驗和需求參考各類相關文檔以及各大廠商的架構分享時，我們注意到了 VictoriaMetrics ，並在其官網列出的諸多用戶案例中，發現知乎使用 VictoriaMetrics 的數據分享與我們的數據規模量級幾乎一致，而且性能與資源表現都相當優異，非常符合我們期望需求，便開始了 VictoriaMetrics 的嚐鮮旅程，也歸結出適合我們生產場景的雲原生監控體系架構，並在後續工作中通過使用測試完全滿足我們需求，進行了全面替換使用。

在此，先對 VictoriaMetrics 進行介紹，也推薦給大家對 VictoriaMetrics 進行了解和使用，後面也會貼出我們的使用架構和效果展示。

（一）VictoriaMetrics 介紹

VictoriaMetrics （後續簡稱 VM ）是一種快速、經濟高效且可擴展的監控解決方案和時間序列數據庫，它可以僅作爲 Prometheus 的遠程寫入做長期存儲，也可以用於完全替換 Prometheus 使用。

Prometheus 的 Config、API、PromQL，Exporter、Service discovery 等 VM 基本都能夠兼容支持，如果作爲替換方案，替換成本會非常低。

在 DB-Engines - TSDB 的排行中，VM 當前排名爲 Top 15，並呈上升趨勢，可見下圖：

（二）VictoriaMetrics 特點

可以作爲 Prometheus 的長期數據存儲庫

1. 兼容 PromQL 並提供改進增強的 MetricsQL ；

2. 可以直接使用 Grafana 的 Prometheus DataSource 進行配置，因爲兼容 Prometheus API ；

3. 高性能 - 查詢效率優於 Prometheus ；

4. 低內存 - 相較 Prometheus 低 5 倍，相較 Promscale 低 28 倍；

5. 高壓縮 - 磁盤空間相較 Prometheus 低 7 倍，相較 Promscale 低 92 倍，詳情可參見 Promscale VS VictoriaMetrics ；

6. 集羣版可水平擴展、可數據多副本、支持多租戶

（三）VictoriaMetrics 架構

VM 有兩類部署方式，都非常簡單，如果對 Prometheus 有一定基礎，整個替換過程會非常順滑，這裏就不對安裝進行細述了。

• VM - Single server - All in One 單點方式，提供 Docker image ，單點 VM 可以支撐 100 萬 Data Points/s。

• VM - Cluster - 集羣版，拆分爲了 vmselect、vminsert、vmstorage 3 個服務，提供 Operate ，支持水平擴展；低於百萬指標 / s 建議用單點方式，更易於安裝使用和維護。

Qunar 單集羣 Total Data points 17萬億，採用的是 VMCluster 方案。

另外對於指標採集和告警，需要單獨以下組件

可選，可按自身需求選擇是否使用如下組件替代現有方案。
如果只是將 VM 作爲 Prometheus 的遠程存儲來使用的話，這兩個組件可忽略，僅部署 VM - Single 或 VM - Cluster ，並在 Prometheus 配置 remoteWrite 指向 VM 地址即可。

• VMagent

• VMalert

vmcluster 架構圖

vm-single 特別簡單不做贅述，這裏說下 vm-cluster，vmcluster 由以下 3 個服務組成：

• vmstorage 負責提供數據存儲服務;

• vminsert 是數據存儲 vmstorage 的代理，使用一致性 hash 算法將數據寫入分片；

• vmselect 負責數據查詢，根據輸入的查詢條件從 vmstorage 中查詢數據。vmselece、vminsert 爲無狀態服務，vmstorage 是有狀態的，每個服務都可以獨立擴展。

vmstorage 使用的是 shared nothing 架構，節點之間各自獨立互無感知、不需要通信和共享數據，由此也提升了集羣的可用性，降低運維、擴容難度。

如下爲官網提供的 vmcluster 的架構圖

vmagent

vmagent 是一個輕量的指標收集器，可以收集不同來源處的指標，並將指標存儲在 vm 或者其他支持 remote_write 協議的 Prometheus 兼容的存儲系統。

建議通過 VM Operate 進行管理，它可以識別原 Prometheus 創建的  ServiceMonitor、PodMonitor 等資源對象，不需要做任何改動直接使用。

vmagent 具備如下特點（摘要）：

• 可以直接替代 prometheus 從各種 exporter 進行指標抓取

• 相較 prometheus 更少的資源佔用

• 當抓目標數量較大時，可以分佈到多個 vmagent 實例中並設置多份抓取提供採集高可用性

• 支持不可靠遠端存儲，數據恢復方面相比 Prometheus 的 Wal ，VM 通過可配置 -remoteWrite.tmpDataPath 參數在遠程存儲不可用時將數據寫入到磁盤，在遠程存儲恢復後，再將寫入磁盤的指標發送到遠程存儲，在大規模指標採集場景下，該方式更友好。

• 支持基於 prometheus relabeling 的模式添加、移除、修改 labels，可以在數據發送到遠端存儲之前進行數據的過濾

• 支持從 Kafka 讀寫數據

vmalert

前面說到 vmagent 可用於替代 Prometheus 進行數據採集，那麼 vmalert 即爲用於替代 Prometheus 規則運算，之前我們都是在 prometheus 中配置報警規則評估後發送到 alertmanager，在 VM 中即可使用 vmalert 來處理報警。

vmalert 會針對 -datasource.url 地址執行配置的報警或記錄規則，然後可以將報警發送給 -notifier.url 配置的 Alertmanager 地址，記錄規則結果會通過遠程寫入的協議進行保存，所以需要配置 -remoteWrite.url 。

建議通過 VM Operate 進行管理，它可以識別原 Prometheus 創建的 PrometheusRule、Probe 資源對象，不需要做任何改動直接使用。

vmalert 具備如下特點：

• 與 VictoriaMetrics TSDB 集成

• VictoriaMetrics MetricsQL 支持和表達式驗證

• Prometheus 告警規則格式支持

• 自 Alertmanager v0.16.0 開始與 Alertmanager 集成

• 在重啓時可以保持報警狀態

• 支持記錄和報警規則重放

• 輕量級，且沒有額外的依賴

• Qunar 的 VictoriaMetrics 架構

Qunar 的 VictoriaMetrics 架構

按照官網建議數據量低於 100w/s 採用 VM 單機版， 數據量高於 100w/s 採用 VM 集羣版，根據 Qunar 的指標數據量級，以及對可擴展性的需求等，選擇使用了 VM 集羣版。

• 採集方面使用 vmagent 並按照服務維度劃分採集目標分爲多組，且每組雙副本部署以保障高可用。各集羣互不相關和影響，通過添加 env、Cluster labels 進行環境和集羣標識

• 數據存儲使用 VMcluster，每個集羣部署一套，並通過 label 和 tolerations 與 podAntiAffinity 控制 VMcluster 的節點獨立、vmstorage 同節點互斥。同一集羣的 vmagent 均將數據 remoteWrite 到同集羣 VM 中，並將 VM 配置爲多副本存儲，保障存儲高可用。

• 部署 Promxy 添加所有集羣，查詢入口均通過 Promxy 進行查詢

• Watcher 中的 Prometheus 數據源配置爲 Promxy 地址，將 Promxy 作爲數據源

• 告警方面使用了 vmalert，並在 Qunar 告警中心架構上，Watcher 團隊自研添加了 Rule Manager、Prometheus Manager 兩個模塊。

· Rule Manager 表示的是 rule 同步模塊，將規則同步至我們 Watcher Dashboard ，用於用戶查看和自定義修改，便於一站式管理。同時也繼續沿用原有告警實例信息同步 icinga daemon 邏輯。

· Prometheus Manager 模塊主要是實現了 reciever 接口，接收 alertmanager 的 hook ，然後更改 icinga 的報警狀態。

· 最後對於 vmalert 本身狀態，則是採用撥測監控實現。於此以最小改動代價融入至 Qunar 現有告警中心。

建議使用 vm-operate 進行部署和管理，它實現瞭如下幾項 CRD 

• VMCluster：定義 VM 集羣

• VMAgent：定義 vmagent 實例

• VMServiceScrape：定義從 Service 支持的 Pod 中抓取指標配置

• VMPodScrape：定義從 Pod 中抓取指標配置

• VMRule：定義報警和記錄規則

• VMProbe：使用 blackbox exporter 爲目標定義探測配置

同時默認也可以識別 prometheus-perate 實現的 Servicemonitor 、 PodMonitor 、PrometheusRule 、Probe 這些 CRD ，開箱即用平滑接替 Prometheus 

完全替換後的表現

Qunar 容器化已將全環境集羣的原 Prometheus 方案全部使用 VM 解決方案進行替換，所有的應用都是使用 VM-Operate 完成部署和管理的。

替換後其中某集羣的數據表現如下：

dkzigx

後續準備做的幾個優化

• VM 開源版本不支持 downsampling ，僅企業版中有。對於時間範圍較大的查詢，時序結果會特別多處理較慢，後續計劃嘗試使用 vmalert 通過 recordRule 來進行稀釋，達到 downsampling 的效果。

• 其實很多應用如 Etcd、Node-exporter 暴露出來的指標裏有些是我們並不關注的，後續也計劃進行指標治理，排除無用指標來降低監控資源開銷

總結

本文介紹了 Victoriametrics 的優勢以及 Prometheus 不足之處，在 Qunar 替換掉的原因以及替換後的效果展示。也分享了 Qunar 對 VM 的使用方式和架構。

使用 VM 替代 Prometheus 是個很好的選擇，其它有類似需求的場景或組織也可以嘗試 VM 。如果要用最直接的話來形容 VM ，可以稱其爲 Prometheus 企業版，Prometheus Plus 。

最後，任何系統、架構都並非一勞永逸，都要隨着場景、需求變化而變化；也並沒有哪種系統、架構可以完全契合所有場景需求，都需要根據自身場景實際情況，本着實用至上的原則進行設計規劃。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qaJuLhsGQrtiNlymBiHZxA