作者:张富春(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 冲突而出现意想不到的问题
同事史蒂文提了他的历史群集方案,要简单很多。我在他的思路上又整理了两种部署方法:
历史群集部署方法 1:历史群集通过自己的 vmagent 来低频采样实时群集的 targets
这个方案中有这样一些特点:
- 在 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 列表。
我是通过了如下的方法来解决:
- 开发一个 golang 服务 http sd service,部署在实时群集中。这个服务定期加载 secret vmagent.yaml.gz, 进行 gzip 解压缩,然后转换成 prometheus http sd 协议要求的 JSON 格式。当有用户请求时,从 HTTP 端口返回 json
- 使用一个配置文件来作为 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
复制代码
- 改写 vmagent 的参数,屏蔽 prometheus-config-reloader 产生的文件,改为使用 http sd
- vmagenthistorical:
- extraArgs: # extraArgs 中的参数会覆盖其他参数
- promscrape.config: "/etc/new_http_sd.yaml"
复制代码 这个方案需要新增一个 golang 服务,但好处是不用调整实时群集的任何配置。
历史群集部署方法 2:实时群集的 vmagent 支持两个 remoteWrite 地址和两组不同的 scrape_interval
这个方案更加简单:只需要配置 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 就支持往两个不同的位置,以不同的采样评率发送数据了。
来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |
|
|
|
相关推荐
|
|