一、背景介绍

上一篇文章中介绍过，我们针对Thanos与VictoriaMetrics开展了深入调研，并精心组织了一系列严谨的测试与对比分析。在生产资源消耗、查询响应时长以及系统维护成本等多个关键维度的评估中，VictoriaMetrics展现出了令人瞩目的优势，其各项测试数据相较于Thanos有着显著提升。

经审慎考量，决定在Q4全面启动监控的迁移工作，将其整体迁移至VictoriaMetrics（简称VM）集群版本。接下来，我们将详细梳理并总结从Thanos平稳、顺滑地切换至VM的全流程，深入剖析这一过程中所遭遇的各类问题，同时客观呈现切换后在实际应用中所收获的收益。

二、架构体系

我们将Thanos和VM的对比分为三个组件体系

• 存储层：thanos()->vm()主要的是用来提供时序的存储和高可用的读写分离作用

• 采集层：prometheus->vmagent几乎全部兼容，vmagent在性能上面更胜一筹，且适合大规模部署和任务采集

• 告警层：vmalert相比thaos-ruler->vmalert，在告警持久化、组件重启做得更好；二者均兼容Prometheus的告警规则设置，然而vmalert凭借更为高效的评估机制，有效降低了资源消耗。尽管与Thanos相比，优势并非极其显著，但在整体性能与稳定性上仍有一定程度的提升

三、切换计划

1.准备阶段

• 需求分析:明确迁移的目标和预期效果，包括性能提升、资源优化等

• 环境搭建:在测试环境中搭建VictoriaMetrics集群，模拟生产环境的数据负载进行初步验证

2.测试阶段

• 功能测试:验证VictoriaMetrics及其组件的功能完整性，确保满足现有系统的各项需求

• 性能测试:对比Thanos和VictoriaMetrics在相同负载下的性能表现，重点关注查询响应时间和资源占用情况

• 兼容性测试:检查所有自定义配置文件和脚本是否需要调整，确保顺利迁移

3.切换阶段

• 分步实施:选择一个较小的范围进行试点，观察运行情况并及时调整策略

• 逐步推广:根据试点反馈，逐步扩大切换范围直至覆盖整个系统

• 实时监控:在切换过程中持续监控新旧系统的运行状态，确保平稳过渡

• 快速回滚:确保历史数据得以完整保存，一旦出现问题可直接回滚，且整个过程对用户无感知

4.监控和优化

• 性能调优:收集运行数据，根据实际情况调整VictoriaMetrics的参数设置，以达到最佳性能

• 用户反馈:广泛收集用户反馈，持续优化用户体验，解决可能出现的问题。鉴于VM自身默认限制较多，而Thanos限制相对较少，在查询方面，一些大规模查询必然会受到影响，因此需要根据用户的持续反馈，在资源条件允许的范围内选取较为合适的参数

四、切换过程

1. 集群拆分

在监控系统中，随着业务的增长和数据量的增加，单一大规模集群可能会遇到性能瓶颈、维护复杂度增加以及资源利用不均衡等问题。

• 性能瓶颈：单一集群处理大量时间序列数据时，查询性能会显著下降，尤其是在大规模历史数据查询时

• 高维护成本：管理一个庞大的集群需要更多的运维资源，包括监控、备份、升级等操作

• 资源利用率低：不同服务或模块的数据访问模式差异较大，统一的集群配置难以满足所有需求。监控系统从单一的大规模集群迁移到多个较小的VictoriaMetrics集群。通过合理的集群拆分，可以显著提升系统的可管理性和性能表现

2.扩容策略

动态扩容

• 垂直扩展：增加单个节点的资源（CPU、内存）。可以通过调整虚拟机或物理服务器的资源配置来实现

• 水平扩展：增加更多的 vmstorage、 vminsert和 vmselect节点。通过服务配置与发现来实现

自动扩容

• vminsert和vmselect目前部署在ECS，后面切换容器部署，并开始弹性策略

• 使用Kubernetes编排工具结合HPA，利用监控关键指标(CPU、内存使用率)，实现自动扩缩容

3.vmagent切换

VictoriaMetrics的 vmagent作为Prometheus兼容的远程写入代理，能够显著提升数据收集和存储效率，并提供更灵活的扩展性。以下是详细的迁移步骤和配置说明。

我们vmagent主要运行在k8s里面，这里就不过多介绍安装

• 配置及参数

Prometheus兼容配置文件：使用现有的Prometheus配置文件 prometheus.yml，将其路径传递给 vmagent

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
- job_name: 'node_exporter'
    static_configs:
- targets: ['localhost:9100']

远程写入配置：在 vmagent命令行中指定远程写入地址，指向VM集群的 vmselect或 vminsert端点

-remoteWrite.url=http://localhost:8481/api/v1/write
-promscrape.concurrentScrapers=10并发抓取器数量，默认为CPU核心数
-promscrape.scrapeTimeout=10s抓取超时时间，默认为10秒
-promscrape.relabelConfig.file=/etc/prometheus/relabel.yaml 标签重命名配置文件

• 限制采集行数

使用 metric_relabel_configs 进行过滤，你可以通过 metric_relabel_configs 来过滤掉不需要的指标，从而间接地限制采集行数。例如，只保留特定的指标：

scrape_configs:
job_name: 'node_exporter'
    static_configs:
- targets: ['localhost:9100']
    metric_relabel_configs:
- action: keep
        regex: "^(metric_to_keep_1|metric_to_keep_2)$"
        source_labels: [__name__]

上述配置只会保留名称为 metric_to_keep_1 和 metric_to_keep_2 的指标，其他指标将被忽略；使用 sample_limit 限制每条抓取的最大样本数，如果你希望限制每个抓取目标返回的最大样本数，可以使用 sample_limit 参数：

scrape_configs:
- job_name: 'node_exporter'
    sample_limit: 1000# 每个抓取目标最多返回1000个样本
    static_configs:
- targets: ['localhost:9100']

4.grafana迁移

Grafana在Soul内部广泛应用于各项业务模块的监控和展示，包括业务研发、推荐算法以及大数据等领域，总Dashboard数量超过了2500个。我们主要依赖Grafana进行前端可视化，由于历史原因，大量告警信息也集成在Grafana上，其中大部分使用Thanos作为数据源，因此确保数据源切换的稳定性至关重要。

在切换期间，为有效控制影响范围并保证操作的完整性，我们决定通过分批批量替换的方式，直接操作Grafana的元数据。我们计划逐步在不同业务场景（如基础架构和增长团队）中，以灰度方式替换其Dashboard。经过一段时间观察并完成修复新发现的问题后，再逐步推广至所有业务场景，以此确保切换过程中的稳定性。

5.报警规则迁移

Thanos Ruler用于在Prometheus架构中生成和管理告警规则，并将其推送到Alertmanager。VM的 vmalert提供了类似的功能，并且与VictoriaMetrics集群深度集成，能够提供更高的性能和更低的维护成本。以下是详细的迁移步骤和配置说明。

• 规则生成

• 导出现有告警规则：所有的prom规则都存在mysql里面，可以直接生成一份新的；将规则导入vmalert

• 放置规则文件：将导出的告警规则文件放置在 /etc/vmalert/rules/目录下

• 验证规则文件：确保规则文件中的表达式语法正确，并且能够在VictoriaMetrics中正常解析。可以使用以下命令测试规则文件：

vmalert -ruleFilePath=/etc/vmalert/rules/example_rules.yaml -datasource.url=http://localhost:8481/api/v1/query -test

• 切换流量

• 小规模测试：选择一个非关键的服务或模块，先进行小规模的迁移测试，确保新系统能够正常运行

• 逐步替换：根据测试结果，逐步将其他服务或模块的告警规则从Thanos Ruler切换到 vmalert

• 全面切换：当确认所有服务都能稳定运行后，完全停止Thanos Ruler的数据收集任务，仅保留 vmalert作为唯一的告警管理代理

五、切换过程中遇到的问题

1.组件配置问题：

• 问题表现：vmagent没有报警规则配置，导致启动异常

• 解决思路：Prometheus配置文件中包含规则（rules）配置，但 vmagent 不支持规则引擎，需要移除这些配置

• 问题表现：vmagent的 scrape_configs部分参数在启动参数中，（如Consul 的 refresh_interval），导致启动异常

• 解决思路：需要在 vmagent 启动参数中进行配置。./vmagent-prod -promscrape.config=/path/to/vmagent.yml-promscrape.consulSDCheckInterval=30s

• 问题表现：Prometheus的 remote_write在配置文件中，而 vmagent 在启动参数中，会导致启动异常

• 解决思路：调整启动参数：在vmagent启动命令中添加 remoteWrite.url参数。 /vmagent-prod -promscrape.config=/path/to/vmagent.yml-remoteWrite.url=http://vminsert:8428/insert/0/prometheus

2.采集指标问题：

• 问题表现：目标采集对象指标过大不被采集，我们有的业务暴露了大量的指标，比如kafka一个集群topic过多会被限制掉，超过的没有被采集，因为默认的 --promscrape.maxScrapeSize设置可能导致目标采集的数据过大而不被采集。

• 解决思路：调整最大抓取大小：增加 --promscrape.maxScrapeSize参数值。 ./vmagent-prod -promscrape.config=/path/to/vmagent.yml--promscrape.maxScrapeSize=10MB

• 问题表现：指标labels过多被 maxLabelsPerTimeseries限制，导致指标被漏采 解决思路：这个可以直接用VictoriaMetrics暴露的指标vmmetricswithdroppedlabels_total查看到具体的目标进行优化或者是调整标签限制：增加 --storage.maxLabelsPerTimeseries参数值。 ./vmstorage-prod--storage.maxLabelsPerTimeseries=100

3.查询指标问题

• 问题表现： vmselect查询参数body过大被 vmselect的 --search.maxQueryLen参数限制。查询报错

• 解决思路：调整查询长度限制：增加 --search.maxQueryLen参数值 ./vmselect-prod-search.maxQueryLen=65536

• 问题表现：查询数据量过大报错内存不足，查询返回了大量的数据点，超出了可用内存限制。 enough memoryforprocessing node_cpu_seconds_total,which returns625172592data points across1386192time serieswith451pointsineach time series;total available memoryforconcurrent requests:6549641625bytes;requested memory:11388953472bytes;possible solutions are:reducing the number of matching time series;increasing step query arg(step=4s);switching to nodewithmore RAM;increasing-memory.allowedPercent，导致查询报错

• 解决思路：、减少匹配的时间序列数量 2、增加查询步长 (step) 3、增加可用内存(其实这步骤可以不用做，能触发到这一步骤，要么就是我们资源本身就很小，要么就是查询就是很大问题的)

• 问题表现：查询基数过高导致搜索失败，ERROR:422,error occured during search:cannot fetch query resultsfromvmstorage nodes:cannot perform search on vmstorage172.16.155.68:8401:cannot execute funcName="search_v7"on vmstorage"172.16.155.68:8401":errorwhensearchingfortagFilters=[{AccountID=0,ProjectID=0,__name__="bury_visual:exp_total"}]on the time range[2025-01-22T08:21:32.702Z..2025-01-22T08:26:36.702Z]:errorwhensearchingformetricIDsinthe current indexdb:the number of matching timeseries exceeds300000;either narrow down the searchorincrease-search.max*command-line flag values at vmselect;see https://docs.victoriametrics.com/#resource-usage-limits，查询返回了超过300,000个时间序列，超过了默认的最大限制。导致查询报错

• 解决思路：、缩小查询范围：减少查询的时间范围或使用更精确的标签过滤条件，2、增加查询限制：调整 vmselect的命令行标志值，允许更多的请求(调整这个需要根据资源成本和收益衡量) 3、优化索引：定期清理不再需要的时间序列数据，减少索引大小

4.查询展示问题

• 问题表现：部分Dashboard的一些Panel在使用过程中逐渐废弃，未及时删除，对切换造成干扰

• 解决思路：有无数据显示是判断切换成功与否的关键因素，因此我们采用“一切一查”的操作方式，使用工具提升切换操作本身的效率，而在对切换的检查上，还是稳扎稳打，对每个Dashboard的切换均进行检查

• 问题表现：切换数据源操作繁琐，效率较低且易遗漏

• 解决思路：由于待切换的Panel和Alert数量较多（分别超过了10000和1000个），手动修改Panel的数据源在实际操作中易出现遗漏或误操作，我们调研了Grafana配置数据的存储方式，开发小工具在Dashboard纬度批量更新Dashboard和Alert的data structure，自动替换数据库中数据源UID，并且在操作后进行全面检查，从而提高效率并降低人为失误风险

六、切换后收益

1.性能提升

• VictoriaMetrics在处理大规模时间序列数据时表现出色，查询响应速度显著加快，极大地提升了用户体验。

• 实际测试显示，在相同的硬件条件下，VictoriaMetrics的查询响应时间相比Thanos缩短了约至少50%。稳定性Q4达到100%

2.运维成本与资源消耗

• 组件重启变更：在高可用系统中，组件的重启和变更操作需要尽可能快且不影响系统的整体性能和稳定性。VictoriaMetrics的各个组件（如vminsert、vmselect和vmstorage）在进行重启或变更时，能够快速完成操作，并尽量减少对服务的影响。

• 扩容操作：随着监控数据量的增长，系统需要具备良好的扩展性，读写的无状态设计，存储的水平扩展，以便快速增加计算和存储资源，以应对不断增长的需求。

• 资源消耗对比：相比Thanos，VictoriaMetrics在相同的数据规模下占用更少的内存和CPU资源，降低了运营成本。具体到实际生产环境中，资源消耗减少了大约30%，有效降低了硬件投入。

• 用户使用反馈：内部反馈称，切换到VictoriaMetrics后，查询响应时间缩短了约50%，特别是在高并发查询场景下表现尤为明显。切换后整个Q4不可用的状态几乎是没有的

3.扩展性强

• VictoriaMetrics支持水平扩展，能够轻松应对未来业务增长带来的监控数据量激增。

• 可以根据业务需求灵活调整集群规模，确保系统始终处于最佳状态。

• 并且我们已经将vminsert和vmselect对vmstoage进行二次开发支持consul服务发现的方式，完全可以不用更改配置文件进行热扩容缩容

• 大量的源代码来源于prom，这样我们针对VictoriaMetrics的组件可以定制化的开发，并且社区源代码研究的贡献和文章远远大于thanos

七、总结

此次从Thanos切换到VictoriaMetrics的项目不仅解决了原有系统的性能瓶颈问题，还带来了诸多额外收益。这是一次成功的技术转型，为我们未来探索更高效的监控解决方案奠定了坚实的基础。希望本文能为其他考虑类似迁移的企业提供有价值的参考。通过这次迁移，我们不仅提高了系统的整体性能和稳定性，还大大降低了运维成本，为公司的长远发展提供了有力的支持。