VictoriaMetrics 部署历史群集的另外两种方式

作者:张富春(ahfuzhang)，转载时请注明作者和引用链接，谢谢！

• cnblogs博客
• zhihu
• Github
• 公众号:一本正经的瞎扯
  

我曾在一年多前设计了一种 VictoriaMetrics 监控系统的历史群集的部署方法，并把部署方式进行了开源：https://github.com/ahfuzhang/deploy_VictoriaMetrics_cluster

在这个方案中，部署历史群集的方法是：
· 使用 vmbackup 定期备份实时群集的 metrics 数据到 s3
· 使用 vmrestore 定期恢复 s3 上的备份数据到本地磁盘
· 自己写了一个叫做 vmfile 的工具来合并历史数据
· 在新的数据目录上启动 vmstorage 服务

在这个方案中， vmfile 并未很完善，导致只能支持同一个实时群集的 sharding 对应的备份文件的合并。
这会带来一些问题：

• 历史群集的 sharding 的数量必须与实时群集一致；（扩容/缩容都不方便）
• 无法选择确定的日期范围来合并数据
• 未做深层次的去重（当 dup factor > 1 时，未考虑 metric 重复的情况）
• 跨 sharding 来使用 vmfile 合并，可能因为 tsid 冲突而出现意想不到的问题

同事史蒂文提了他的历史群集方案，要简单很多。我在他的思路上又整理了两种部署方法：

这个方案中有这样一些特点：

• 在 k8s 上部署时，使用了 vm 官方提供的 operator (https://github.com/VictoriaMetrics/operator)
• 数据源群集中的每个服务有自己的 exporter，通过 exporter 来暴露自己的监控数据
  • 业务服务通过 k8s 部署时，同时创建类似 VMServiceScrape 的对象
  • VMServiceScrape 会触发 vm operator 的事件处理，并产生 target 列表
  • vm operator 产生一个叫做 vmagent.yaml.gz 的 secret，内部以 yaml 格式记录了所有需要抓取的 target 的信息，并压缩成 gzip 格式
• VMAgent 这个 CRD 在部署时实际会产生三个容器：
  • init 容器使用位于 quay.io/prometheus-operator/prometheus-config-reloader 的镜像，把镜像中的 /etc/vmagent/config/vmagent.yaml.gz 作为初始数据
  • 配置文件生成容器：同样使用 prometheus-config-reloader 镜像，这个进程负责定期加载 secret vmagent.yaml.gz, 然后解压缩，写成一个新的配置 /etc/vmagent/config_out/vmagent.env.yaml
  • vmagent 的容器：容器内启动 vmagent 进程，进程使用 /etc/vmagent/config_out/vmagent.env.yaml 为配置文件 —— 最终获得所有要抓取的 targets 的列表
• 历史群集：
  • 历史群集不必非得使用冷备的数据来恢复。历史群集也可以实时采集，只不过历史群集使用很低的采样频率(5分钟)和很长的存储周期(半年)
  • 历史群集只要获得实时群集的 targets 列表，就可以采集与实时群集一样的数据了
• 可以部署用于级联的 vmselect，这样就可以同时查询实时群集和历史群集的数据了

这个方案的关键点在于：如何让历史群集中的 VMAgent 这个 CRD 中的 vmagent 进程，去实时群集中获取 target 列表。
我是通过了如下的方法来解决：

1. 开发一个 golang 服务 http sd service，部署在实时群集中。这个服务定期加载 secret vmagent.yaml.gz, 进行 gzip 解压缩，然后转换成 prometheus http sd 协议要求的 JSON 格式。当有用户请求时，从 HTTP 端口返回 json
2. 使用一个配置文件来作为 vmagent 最关键的 -promscrape.config 参数所需要的配置文件。文件的内容如下：

global:
  scrape_interval: 300s

scrape_configs:
- job_name: "dynamic-from-http"
  http_sd_configs:
  - url: "http://httpsd-vmcluster-realtime/"
    refresh_interval: 60s

3. 改写 vmagent 的参数，屏蔽 prometheus-config-reloader 产生的文件，改为使用 http sd

vmagenthistorical:
  extraArgs:  # extraArgs 中的参数会覆盖其他参数
    promscrape.config: "/etc/new_http_sd.yaml"

这个方案需要新增一个 golang 服务，但好处是不用调整实时群集的任何配置。

这个方案更加简单：只需要配置 vmagent，配置两个 remoteWriteURL，一个以 15s 的频率采样，然后写入实时群集；一个以 300s 的频率采样，然后写入历史群集。
经过试验，这样配置 vmagent 的参数就可以实现：

vmagent \
  -remoteWrite.url=http://realtime-cluster-vminsert/ \  # 实时群集的写入地址
  -remoteWrite.streamAggr.config=empty_file.yaml \   # 参数必须成组出现
  -remoteWrite.streamAggr.keepInput=true \
  -remoteWrite.streamAggr.dropInput=false \
  \  # 下一组参数为历史群集配置
  -remoteWrite.url=http://historical-cluster-vminsert/ \   # 历史群集的写入地址
  -remoteWrite.streamAggr.config=aggragetion.yaml    # 配置一个汇总的表达式
  -remoteWrite.streamAggr.keepInput=false \  # 只要汇总后的结果
  -remoteWrite.streamAggr.dropInput=true   # 丢弃汇总前的结果。这里的设计有问题，必须两个参数都加上。

aggragetion.yaml 的文件内容如下：

 - match: '{__name__=~"*"}'  # 对所有 metric 做处理
    interval: 5m   # 处理周期为 5 分钟
    keep_metric_names: true   # 不修改 metrics 名字
    outputs: [last]   # 降采样，只取最后一个点

至此，vmagent 就支持往两个不同的位置，以不同的采样评率发送数据了。