說到雲原生監控方案，第一時間基本上都會想到 Prometheus+AlertManager+Grafana 的一套成熟解決方案。Prometheus 作為監控核心，具備強大的資料模型、高效率運作、豐富的監控能力、強大的查詢語言 PromQL、簡單易用、管理友善等特點。但是 Prometheus 目前在高可用層面上做得還并不完美。為此，在開源社群中，孕育出了許多替代、增強方案，VictoriaMetrics 屬于其中較為優異的一個，是一個快速、經濟高效且可擴充的監控解決方案和時間序列資料庫。
01 七大特點
1. 它可以作為 Prometheus 的長期儲存，且支援 Prometheus 查詢 API，可以在 Grafana 中用作 Prometheus 的代替品；
2. 部署簡單，無論是單節點版本還是叢集版本，都隻需要運作所需的元件可執行檔案（每個元件都是一個可執行檔案），運作前不需要安裝任何依賴，易于設定和操作；
3. 使用 vmbackup/vmrestore 工具可以輕松快速地将即時快照備份到 S3 或 GCS；
4. 基于 PromQL 的查詢語言實作 MetricsQL，對 PromSQL 進行改造；
5. 讀寫性能比 InfluxDB 和 TimescaleDB 高達 20 倍；百萬時間序列資料下，記憶體使用比 InfluxDB 少 10 倍，比 Prometheus、Thanos 或 Cortex 少 7 倍；資料高壓縮，與 Prometheus、Thanos 或 Cortex 相比，所需的存儲空間最多可減少 7 倍；
6. 具有高延遲 IO 和低 IOPS；
7. 支援從第三方時序資料庫擷取資料源。
1.1. 快速接入 Prometheus 擷取資料源
資料源接入層面，VictoriaMetrics 支援通過 Prometheus 的遠端寫入方式直接相容 Prometheus 的資料寫入，同時也支援搜集多個 Prometheus 資料彙總。
remote_write:
- url: http://<victoriametrics-addr>:8428/api/v1/write
# 多個proemtheus的話，需要配置每個Prometheus的辨別符
global:
external_labels:
datacenter: dc-123
VictoriaMetrics 還支援直接取代 Prometheus 進行 exporter 搜集。
使用-promscrape.config配置Prometheus的prometheus.yml
針對 Prometheus，VictoriaMetrics 進行了一些優化：
1. 增加了 “extra_label=<label_name>=<label_value>” 可選的查詢支援，可用于基于額外标簽進行查詢過濾。例如“/api/v1/query_range?extra_label=user_id=123&extra_label=group_id=456&query=<query>”，會傳回額外标簽中包含“{user_id="123",group_id="456"}”的結果；
2. 增加了 “extra_filters[]=series_selector“ 可選的查詢支援，可用于基于拓展标簽進行規則比對的查詢過濾。例如 “/api/v1/query_range?extra_filters[]={env=~"prod|staging",user="xyz"}&query=<query>“，會傳回額外标簽中包含“{env=~"prod|staging",user="xyz"}“ 的結果；
3. 支援 “start“ 和 “end“，使用多種時間格式，如 1562529662.678、2022-03-29T01:02:03Z、2022-03、1h5m 等；
4. 在 “/api/v1/query“和“/api/v1/query_range“ 中增加了 round_digits 參數，它可用于将響應值四舍五入到小數點後給定的位數；
5. 在 “/api/v1/labels and /api/v1/label/<labelName>/values“ 中增加了 limit 參數，用于限制傳回條目的數量；
6. 在 “/api/v1/series“ 中增加了 limit 參數，用于限制傳回條目的數量；
7. 新增 “/api/v1/series/count“，傳回資料庫中時間序列的總數；
8. 新增 “/api/v1/status/active_queries“，傳回目前正在運作的查詢清單；
9. 新增 “/api/v1/status/top_queries“，傳回“topByCount“最常執行的查詢；傳回“topByAvgDuration“平均執行持續時間最長的查詢；傳回“topBySumDuration“執行時間最長的查詢。
除了支援 Prometheus 作為資料源外，VictoriaMetrics 還支援其他資料源：
1. DataDog agent
2. InfluxDB-compatible agents such as Telegraf
3. Graphite-compatible agents such as StatsD
4. OpenTSDB-compatible agents
02 架構
面對擷取速率低于每秒一百萬個資料點的場景下，官方建議使用單節點版本而不是群集版本。單節點版本可以根據 CPU 核心、RAM 和可用存儲空間的數量完美擴充。與群集版本相比，單節點版本更易于配置和操作，是以在選擇群集版本之前要三思。
圖源：https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html
VictoriaMetrics 叢集由以下服務組成：
1. vmstorage，存儲原始資料并傳回給定标簽過濾器的給定時間範圍内的查詢資料；
2. vminsert，接受接收的資料，并根據 “度量名稱及其所有标簽” 計算出的哈希值，在 vmstorage 節點之間傳播資料；
3. vmselect，通過從所有配置的 vmstorage 節點擷取所需資料來執行傳入查詢。
每個服務可以獨立擴充，并且可以在最合适的硬體上運作。Vmstorage 節點不了解彼此，不互相通信，也不共享任何資料。這是一個無共享架構，它提高了群集可用性，簡化了群集維護和群集擴充。
VictoriaMetrics 在開源層面，提供以下元件：
1. vmui：負責 vm 頁面展示，提供資料查詢、名額與基數查詢、查詢分析、鍊路分析、job 分析面闆等功能；
2. vmagent：負責資料采集、重新标記和過濾收集，并通過 Prometheus 協定将資料存儲到 VictoriaMetrics 或其他支援 Prometheus 協定的存儲系統中。支援按時間和标簽聚合樣本後同時複制多個遠端存儲系統，且能在傳輸故障時緩存資料，等待恢複後繼續傳輸；支援抓取暴露數百萬時間序列的目标與寫入多個租戶中；支援 kafka 讀寫；
3. vminsert：負責資料插入，支援不同格式、不同租戶的資料；
4. vmstorage：負責資料存儲，具有高壓縮率、低資源消耗、高性能的特點；
5. vmselect：負責資料查詢，支援資料統一查詢與多租戶資料隔離查詢；
6. vmalert：負責告警，和 Prometheus 一樣支援紀錄、告警兩種規則配置與發送告警通知，允許在注解中使用 Go 模闆來格式化資料、疊代或執行表達式，支援跨租戶發送警報和記錄規則
7. vmbackup：負責資料備份，支援增量備份和全量備份，可以做到每小時、每天、每周和每月備份，支援本地存儲、GCS、Azure Blob 存儲、S3 存儲、任何與 S3 相容的存儲；
8. vmrestore：負責資料還原，支援随時中斷與自動從斷點恢複。
03 能力
3.1. 儲存
VictoriaMetrics 使用 “-retentionPeriod”指令行标志進行配置，該标志采用一個數字，後跟一個時間機關字元 “-h（ours）、d（ays）、w（eeks）、y（ears）”。如果未指定時間機關，則假定為月。例如，“-retentionPeriod=3” 表示資料将存儲 3 個月，然後删除。預設保留期為一個月。
3.2. 資料删除
VictoriaMetrics 除了支援配置定時過期外，還支援手動進行資料删除操作，使用 “http://<victoriametrics-addr>:8428/api/v1/admin/tsdb/delete_series?match[]=<timeseries_selector_for_delete>”。删除的時間序列的存儲空間不會立即釋放，而是在随後的資料檔案背景合并過程中釋放。請注意，對于前幾個月的資料，背景合并可能永遠不會發生，是以不會為曆史資料釋放存儲空間。在這種情況下，強制合并可能有助于釋放存儲空間。
3.3. 強制合并
VictoriaMetrics 會在背景以每個月為一個分區的形式進行資料壓縮，以保持良好的性能。可以使用 “http://victoriametrics:8428/internal/force_merge?partition_prefix=YYYY_MM” 進行強制資料壓縮，會以異步的形式，立馬傳回請求結果，并在背景執行資料壓縮任務。當需要立即删除資料的時候，可以使用強制合并觸發資料删除。
3.4. 資料導入、導出
VictoriaMetrics 支援使用專屬 Agent 接口導入資料：
1.Prometheus remote_write API
2.DataDog submit metrics API
3.Graphite plaintext protocol
4.OpenTSDB telnet put protocol
5.OpenTSDB http api/put protocol
支援使用 VictoriaMetrics 統一接口導入資料：
1./api/v1/import，導出 json 格式；
2./api/v1/import/csv，導出 csv 格式；
3./api/v1/import/native，導出二進制格式。
相對的，也可以使用導出接口導出資料：
1./api/v1/export，導出 json 格式；
2./api/v1/export/csv，導出 csv 格式；
3./api/v1/export/native，導出二進制格式。
VictoriaMetrics 接口側，在導入、導出接口中，資料格式保持一緻，可以直接使用導出的資料進行資料導入。
3.5. 消除重複資料
VictoriaMetrics 會根據 “-dedup.minScrapeInterval” 配置的值進行去重，隻留下一個原始樣本，保留配置周期中時間戳最大的資料。比如 “-dedup.minScrapeInterval=60s”，将會保留 60s 間隔中最大時間戳的單個原始樣本。如果時間戳一緻的情況下，随機保留資料。
多個相同配置的 vmagent 或 Prometheus 執行個體将資料寫入同一 VictoriaMetrics 執行個體，則消除重複資料可減少磁盤空間的使用。
3.6. 存儲
VictoriaMetrics 将以類似 MergeTree 的資料結構存儲時間序列資料。插入時，VictoriaMetrics 累積最多 1s 的資料，并将其轉儲到磁盤上的 “←storageDataPath>/data/small/YYYY_MM/” 子目錄，形成具有以下名稱模式的 part：“rowsCount_blocksCount_minTimestamp_maxTimestamp”。每個 part 由兩個 “列” 組成：值和時間戳。這些是經過排序和壓縮的原始時間序列值。此外，part 包含索引檔案，用于在值和時間戳檔案中搜尋特定 series。
part 會定期合并為較大的 part，生成的部分在 “<-storageDataPath>/data/{small，big}/YYYY_MM/tmp” 子目錄下構造。當生成的 part 完成後，它将自動從 tmp 移動到自己的子目錄，而源部分将自動删除。最終結果是，源部分被 ”<-storageDataPath>/data/{small，big}/YYYY_MM/“ 目錄中的單個較大部分替換。
如果 part 的摘要大小超過可用磁盤空間，VictoriaMetrics 不會合并部件。這可以防止合并過程中出現潛在的磁盤空間不足錯誤。在可用磁盤空間不足的情況下，part 的數量可能會随着時間的推移而顯著增加。這增加了資料查詢期間的開銷，因為 VictoriaMetrics 每次請求都需要從更多的部分讀取資料。這就是為什麼建議在 “-storageDataPath” 指令行标志訓示的目錄下至少有 20% 的可用磁盤空間。
有關合并過程的資訊支援在 Grafana 儀表闆中檢視。
合并過程提高了壓縮率，并使磁盤上的部件數量保持相對較低。執行合并過程的好處如下：
1. 它提高了查詢性能，因為每次查詢都會檢查較少的部分；
2. 它減少了資料檔案的數量，因為每個部分都包含固定數量的檔案。
存儲或是合并，都不會隻儲存部分 part，part 會以資料整體的形式，要麼被全部儲存成功，要麼全部失敗。part 是不可變的。
3.7. 監控
VictoriaMetrics 在 “/metrics” 頁面以 Prometheus exposion 格式導出内部度量。這些名額可以通過 vmagent 或 Prometheus 擷取。或者，當 “-selfScrapeInterval” 指令行标志設定為持續時間大于 0 時，單節點 VictoriaMetrics 可以自抓取度量。
VictoriaMetrics 在 “/api/v1/status/active_queries“ 頁面上公開目前正在運作的查詢及其執行時間。
VictoriaMetrics 在 ”/api/v1/status/top_queries” 頁面上公開了執行時間最長的查詢。
3.8. TSDB 狀态
VictoriaMetrics 以類似于 Prometheus 的方式在 “/api/v1/status/TSDB“ 頁面傳回 TSDB 統計資訊：
1. topN=N，其中 N 是響應數量。預設情況下，傳回前 10 個；
2. date=YYYY-MM-DD，其中 YYYY-MM-DD 是收集統計資料的日期。預設情況下，收集當天的統計資料；
3. focusLabel=LABEL_NAME，傳回 seriesCountByFocusLabelValue 清單中給定 LABEL_NAME 的時間序列數最多的标簽值；
4. match[]=SELECTOR，其中 SELECTOR 是一個任意時間序列選擇器，用于在統計計算期間考慮序列。預設情況下，将考慮所有系列；
5. extra_label=LABEL=VALUE，拓展标簽篩選。
3.9. 推名額
當出現無法拉取名額的場景下，VictoriaMetrics 支援以 Prometheus 資料格式的方式，通過 push 模式進行名額推送：
1. -pushmetrics.url，推送位址，比如”-pushmetrics.url=http://victoria-metrics:8428/api/v1/import/prometheus“；
2. -pushmetrics.extraLabel，拓展标簽，支援以 label="value" 的形式給 push 資料增加标簽；
3. -pushmetrics.interval，push 周期，預設 10s。
3.10. 緩存
VictoriaMetrics 使用各種内部緩存。在正常關機期間（例如，當 VictoriaMetrics 通過發送 SIGINT 信号停止時），這些緩存存儲到 “<-storageDataPath>/cache” 目錄中。緩存将在下次 VictoriaMetrics 啟動時讀取。有時需要在下次啟動時删除這些緩存。這可以通過在重新開機 VictoriaMetrics 之前将 reset_cache_on_startup 檔案放置在“<-storageDataPath>/cache” 目錄中來執行。
VictoriaMetrics 使用各種記憶體緩存來加快資料攝取和查詢性能。每種類型緩存名額可以在 “/metrics” 頁面導出：
1. vm_cache_size_bytes，實際緩存大小；
2. vm_cache_size_max_bytes，緩存大小限制；
3. vm_cache_requests_total，對緩存的請求數；
4. vm_cache_misses_total，緩存未命中數；
5. vm_cache_entries，緩存中的條目數。
支援在 Grafana 儀表闆上檢視緩存名額，面闆顯示了每種類型緩存的目前記憶體使用情況，以及緩存命中率。如果命中率接近 100%，則緩存效率已經很高，不需要任何調整。
3.11. 其他
支援衆多 Prometheus 具備的功能，比如 Prometheus 的标簽重寫、聯邦等功能。
04 與 Prometheus 對比
優勢：
1. 性能優勢。在相同配置、采集壓力的情況下，相比使用 Prometheus，存儲空間最多可減少 7 倍，磁盤讀寫峰值最多可減少 3-4 倍，記憶體使用最多減少 7 倍；
2. 更優秀的橫向拓展、高可用方案。VictoriaMetrics 叢集模式，通過元件化各個能力，進行功能層面的架構解耦。由于負責讀寫的 vmselect、vminsert 元件都是無狀态元件，可以靈活根據讀寫壓力，進行元件的橫向擴縮容；負責存儲的 vmstorage 元件雖然是有狀态元件，但是當存儲壓力增加時，同樣支援橫向擴容，擴容後隻需要更新上下遊的 vmselect、vminsert 元件配置并重新開機，即可提升 VictoriaMetrics 叢集存儲能力；采集壓力的時候，可以利用擴容 vmagent 與 vmagent 的采集分組能力，進行分散壓力采集；
3. 資料多租戶能力。VictoriaMetrics 支援把不同類型的資料分别放到不同的租戶裡，每個租戶通過 accountID 或 accountID:projectID 的形式，在請求的 url 裡做區分。租戶的數量不影響性能，主要取決于所有租戶的活躍總時間序列，每個租戶的資料都均勻分布在後端 vmstorage 存儲，但是不支援跨租戶進行資料查詢。
缺點：
1. 沒有類似 Prometheus 的 WAL 日志，突然故障可能會丢失部分資料。Prometheus 在接收到資料的時候，會先把資料寫入記憶體，定期再寫入磁盤。為了防止寫入磁盤前資料丢失，還會再寫入記憶體的同時簡單的寫入 WAL 檔案裡，當出現故障時，就可以通過 WAL 快速恢複目前狀态。而 VictoriaMetrics 則在寫入過程中，使用 Go 的 chan 作為資料緩存隊列，多協程實作資料處理、壓縮、存儲等操作，故障下存在緩存資料丢失的情況；
2. 為了更大程度優化存儲，會選擇丢失部分資料精度。Vmstorage 元件支援配置精度儲存範圍（1-64，64 表示不丢失），以此在資料讀寫過程中，提升速度。
05 安裝
使用 helm 進行 VictoriaMetrics 叢集模式的部署。
安裝 helm，添加 chart helm 倉庫：
helm repo add vm https://victoriametrics.github.io/helm-charts/
helm repo update
導出配置檔案，并進行部署配置：
helm show values vm/victoria-metrics-cluster > values.yaml
可以使用以下指令進行配置檢查：
helm install victoria-metrics vm/victoria-metrics-cluster -f values.yaml -n victoria-metrics --debug --dry-run
根據配置檔案部署 victoria-metrics-cluster：
helm install victoria-metrics vm/victoria-metrics-cluster -f values.yaml -n victoria-metrics
稍等片刻 Helm 則會機提示安裝成功，查詢資源可以看到都已經部署起來了。
06 使用
調整 victoria-metrics-victoria-metrics-cluster-vminsert 的 service 與 victoria-metrics-victoria-metrics-cluster-vmselect 的 service，從 ClusterIP 模式改成 NodePort 模式，提供對外通路能力。修改現有 Prometheus 的配置，增加：
remote_write:
- url: http://IP:NodePort/insert/0/prometheus
把 Prometheus 的資料，寫入 VictoriaMetrics，通過 VictoriaMetrics 的 UI 位址 ”http://IP:NodePort/select/0/vmui“，即可檢視 Prometheus 采集到的資料了。
可以看出，兩者資料基本一緻。
參考資料：https://docs.victoriametrics.com/
本文作者：陳子榕
現任「DaoCloud 道客」後端開發工程師