当监控系统采集的指标数量从几万涨到几百万，写入速率从每秒几千样本飙升到几十万样本时，不少团队会发现原本的存储方案开始频繁告警：磁盘写满、查询超时、Prometheus内存溢出。VictoriaMetrics正是为这类场景而生的开源时序数据库，它兼容Prometheus的远程写入协议，数据压缩率可达Prometheus的七分之一左右，在相同硬件条件下能承载更高的写入吞吐。本文将从架构选择、云盘配置、参数调优等方面，完整讲解如何在云服务器上搭建一套高性能的VictoriaMetrics存储方案。
一、先搞清楚该用单机版还是集群版
VictoriaMetrics提供了单机版（victoria-metrics）和集群版（vmcluster）两种形态，选择错了会直接影响成本和运维复杂度。单机版是一个二进制文件，开箱即用，官方实测在普通云服务器上单节点即可支持每秒百万级样本写入，对于大多数中小规模场景，比如活跃时间序列在百万以内、日增原始数据几个GB的规模，单机版完全够用。
集群版由vmstorage、vminsert、vmselect三类组件构成。vmstorage负责实际的数据存储，vminsert负责接收写入请求并按时间序列哈希分片，vmselect负责聚合查询请求并把结果合并返回。三类角色可以独立扩缩容，比如写入瓶颈就加vminsert节点，查询慢就加vmselect节点，存储不够就加vmstorage节点。这种水平扩展能力适合单机版已经明显吃力的场景。
一个实用的判断标准是：先从单机版跑起来，观察-retentionPeriod配置周期内的磁盘占用和查询延迟。当单机磁盘IOPS或容量接近上限，或者查询高峰明显影响写入时，再考虑迁移到集群版。VictoriaMetrics支持vmbackup、vmrestore等工具做数据迁移，切换成本并不高。
二、云盘选型与容量规划
在云服务器上部署，存储介质的选择往往比CPU和内存更关键。VictoriaMetrics的写入模式是顺序追加为主，但查询时会产生大量随机读，尤其是高基标签的聚合查询。因此推荐使用SSD类云盘（如阿里云ESSD、AWS EBS gp3），避免使用吞吐型HDD盘，否则查询高峰期延迟会非常明显。
容量估算可以参考一个经验公式：假设每秒写入N个样本，保留周期为R天，则原始数据量约为N × 10字节 × 86400 × R。再结合VictoriaMetrics平均0.4到1字节每样本的实际压缩效果（取决于标签基数和数据特征），留出两倍冗余即可。举个例子，每秒50万样本、保留90天，压缩后大约占用1TB到2TB空间，建议配置3TB以上的云盘。
另外要注意inode和文件句柄限制。VictoriaMetrics的存储引擎会在存储路径下按分区和小时粒度生成大量小文件，云服务器默认的文件句柄数（通常1024）远远不够，需要修改/etc/security/limits.conf并确保fs.file-max足够大，否则运行几天后会出现too many open files错误。
三、关键启动参数调优
安装包默认的启动参数比较保守，针对大规模写入场景需要重点调整以下几项。假设机器有16核64GB内存，数据目录挂载在独立云盘上，可以参考这样一组配置：
-storageDataPath=/data/vm -retentionPeriod=90d -maxConcurrentImports=8 -search.maxQueryDuration=30s -memory.allowedPercent=60
- -memory.allowedPercent：控制缓存可用内存比例，默认60%，内存充裕的机器可以适当调高到70%到80%，能显著提升热点数据的查询速度。
- -retentionPeriod：数据保留周期，支持带单位写法如90d、1y，设置后按此周期自动清理过期数据，务必与容量规划匹配。
- -search.maxQueryDuration：查询超时上限，配合Grafana的数据源超时设置，避免慢查询拖垮整个服务。
- -influxListenAddr：如果同时需要接收InfluxDB协议数据，可以开启此参数，多协议共存不影响性能。
写入侧建议调整Prometheus或vagrant-agent的remote_write批量参数，适当增大batch_send_queue_size和max_samples_per_send，减少HTTP请求次数，让VictoriaMetrics的写入合并机制发挥更大作用。同时开启-replicationFactor（集群版）可以在容量成本和数据安全之间取得平衡，副本数设为2通常已经足够应对单节点故障。
四、数据可靠性与日常运维
云服务器存在实例迁移、磁盘故障等风险，纯靠云盘的快照机制恢复粒度太粗。推荐使用官方的vmbackup工具，它支持增量备份到对象存储（如阿里云OSS、AWS S3），配合vmrestore或vmbackuperestore可以快速恢复。典型做法是通过systemd定时任务，每小时执行一次增量备份，成本低且恢复点明确。
日常运维要关注几个核心指标：vm_free_disk_space_bytes（剩余磁盘）、vm_rows（写入速率）、vm_active_queries（并发查询数）。把这些指标本身也接入监控，当磁盘剩余低于20%时及时扩容云盘。VictoriaMetrics支持在线调大云盘后自动识别新容量，无需重启进程。
最后提醒一点，升级版本前务必阅读官方changelog，虽然VictoriaMetrics承诺数据格式向后兼容，但跨多个大版本升级时建议先在测试环境验证查询结果的正确性，再在生产环境操作，并提前做好全量备份。
五、方案对比一览
| 方案 | 适用规模 | 运维复杂度 | 成本 |
|---|---|---|---|
| 单机版VictoriaMetrics | 活跃序列百万级以内 | 低，单个二进制 | 一台云服务器加一块SSD云盘 |
| 集群版vmcluster | 千万级序列、高并发查询 | 中高，需维护三类组件 | 至少三组节点的费用 |
| Prometheus本地存储 | 小规模、短期保留 | 低但容量受限 | 长期保留需额外方案 |
总体来说，云服务器上跑VictoriaMetrics的关键在于：存储选SSD、容量按压缩后两倍冗余规划、参数根据内存和写入量调整、备份交给vmbackup加对象存储。把这些环节做扎实，一套单机或小规模集群方案就能稳定支撑大规模时序数据的写入与查询，成本也能控制在一个合理的范围内。
VictoriaMetrics时序数据库云服务器存储配置修改时间：2026-09-12 04:18:33