作者介紹
王坤，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 進行了解和使用，後面也會貼出我們的使用架構和效果展示。
1、VictoriaMetrics 介紹
VictoriaMetrics （後續簡稱 VM ）是一種快速、經濟高效且可擴充的監控解決方案和時間序列資料庫，它可以僅作為 Prometheus 的遠端寫入做長期存儲，也可以用于完全替換 Prometheus 使用。
Prometheus 的 Config、API、PromQL，Exporter、Service discovery 等 VM 基本都能夠相容支援，如果作為替換方案，替換成本會非常低。
在 DB-Engines - TSDB 的排行中，VM 目前排名為 Top 15，并呈上升趨勢，可見下圖：
2、VictoriaMetrics特點
可以作為 Prometheus 的長期資料存儲庫：
- 相容 PromQL 并提供改進增強的 MetricsQL ；
- 可以直接使用 Grafana 的 Prometheus DataSource 進行配置，因為相容 Prometheus API ；
- 高性能 - 查詢效率優于 Prometheus ；
- 低記憶體 - 相較 Prometheus 低 5 倍，相較 Promscale 低 28 倍；
- 高壓縮 - 磁盤空間相較 Prometheus 低 7 倍，相較 Promscale 低 92 倍，詳情可參見 Promscale VS VictoriaMetrics ；
- 叢集版可水準擴充、可資料多副本、支援多租戶。
3、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 架構
按照官網建議資料量低于 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 完成部署和管理的。
替換後其中某叢集的資料表現如下：
| Active time series | ~28 Million |
| Datapoints | ~17 Trillion |
| Ingestion rate | ~1.6 Million/s |
| Disk usage | ~8 TB |
| Average query rate | ~450/s |
| Query duration | median is ~300ms, p99 ~200ms |
後續準備做的幾個優化
- VM 開源版本不支援 downsampling ，僅企業版中有。對于時間範圍較大的查詢，時序結果會特别多處理較慢，後續計劃嘗試使用 vmalert 通過 recordRule 來進行稀釋，達到 downsampling 的效果；
- 其實很多應用如 Etcd、Node-exporter 暴露出來的名額裡有些是我們并不關注的，後續也計劃進行名額治理，排除無用名額來降低監控資源開銷。
總結
本文介紹了 Victoriametrics 的優勢以及 Prometheus 不足之處，在 Qunar 替換掉的原因以及替換後的效果展示。也分享了 Qunar 對 VM 的使用方式和架構。
使用 VM 替代 Prometheus 是個很好的選擇，其它有類似需求的場景或組織也可以嘗試 VM 。如果要用最直接的話來形容 VM ，可以稱其為 Prometheus 企業版，Prometheus Plus 。
最後，任何系統、架構都并非一勞永逸，都要随着場景、需求變化而變化；也并沒有哪種系統、架構可以完全契合所有場景需求，都需要根據自身場景實際情況，本着實用至上的原則進行設計規劃。
作者丨王坤
來源丨公衆号：Qunar技術沙龍 （ID：QunarTL）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]
活動推薦
第八屆DAMS-中國資料智能管理峰會将于2023年3月31日在上海舉辦，與大家一起探索大資料與雲原生強強聯合的方式、挖掘由此激發的軟體發展和技術進步。
報名連結：2023年DAMS中國資料智能管理峰會-上海站 �-�百格活動
演講嘉賓所在機關：阿裡、騰訊、京東、美團、華為雲、位元組、螞蟻、網易、新浪、攜程、哔哩哔哩、小紅書、vivo、快狗打車、貨拉拉、工商銀行、建設銀行、中國銀行、平安銀行、光大銀行、彙豐銀行、微衆銀行、複旦大學等産學研界技術領跑機關。
演講議題聚焦：
- 大資料&資料資産管理：資料治理丨存算分離丨雲原生OLAP丨湖倉一體丨智能分析
- 資料庫：雲原生分布式丨時間序列丨服務自治丨中間件丨跨雲多活
- 運維：AIOps丨故障分析丨性能優化丨離線上混部丨高可用建設
- 金融科技：規模化監控丨實時數倉丨分布式改造丨國産化替代丨數字化轉型丨混沌工程