VictoriaMetrics 部署——比 Prometheus 更省资源的时序数据库 • 七万号·数据平台实战手记

明朗北街七万号·数研工坊｜扎根雄安新区中关村科技园，专注受限环境下软件搭建与数据平台落地

适用场景#

如果你属于以下任一种情况，这篇对你有用：

想用 Prometheus 体系做监控，但机器资源紧张（Prometheus 本体吃内存）

数据平台已经搭起来，需要一个地方存指标数据

监控数据量大了之后，Prometheus 频繁 OOM 或磁盘暴涨

想用一套兼容 PromQL 的方案，但比 Prometheus 更省资源

应用范围： 监控体系的存储层。在第 9 篇的架构图里，Categraf（采集）→ VictoriaMetrics（存储）→ Grafana（展示）。本篇解决「采集到的数据放哪、怎么存、怎么查」。

一、问题#

采集器（Categraf）已经把数据送上来了，但送上来之后呢？

需要一个「大仓库」把指标数据存起来，而且要能随时查询。行业标准是 Prometheus，但它在资源受限环境下有一个痛点——内存占用大。

Prometheus 的架构决定了它为了查询速度会把大量数据缓存在内存里。一台 4G 内存的机器，Prometheus 跑起来能吃掉 1.5-2G，这在资源受限的环境里非常肉疼。

二、约束#

无公网，需离线部署
机器资源紧张，存储引擎必须省内存
需要兼容 Prometheus 协议（采集端、查询端都要兼容）
数据要长期保留（至少 30 天以上）
磁盘空间有限，存储要高效压缩

三、为什么选 VictoriaMetrics#

维度	Prometheus	VictoriaMetrics
内存占用	高（大量缓存）	低（约 1/3~1/2）
磁盘占用	高	低（压缩率高）
查询语言	PromQL	完全兼容 PromQL
数据写入	Pull 为主	Push/Pull 都支持
部署	一套组件	单二进制
集群扩展	需要额外组件	单机足够，可扩展

一句话：同样的功能，VictoriaMetrics 用更少的资源。 这正是受限环境最需要的。

四、部署#

4.1 获取安装包#

# 外网下载单二进制
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.101.0/victoria-metrics-linux-amd64-v1.101.0.tar.gz

# ARM 架构
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.101.0/victoria-metrics-linux-arm64-v1.101.0.tar.gz

plaintext

4.2 解压部署#

tar xzf victoria-metrics-linux-amd64-v1.101.0.tar.gz
mv victoria-metrics-prod /usr/local/bin/victoria-metrics

plaintext

4.3 启动#

# 单机模式，数据目录 /data/vm，监听 8428 端口
nohup /usr/local/bin/victoria-metrics \
    -storageDataPath /data/vm \
    -retentionPeriod 90d \
    -memory.allowedPercent 40 \
    > /var/log/victoria-metrics.log 2>&1 &

plaintext

参数说明：

参数	作用	建议
`-storageDataPath`	数据目录	放磁盘大的分区
`-retentionPeriod`	数据保留时间	90d（监控数据 90 天够用）
`-memory.allowedPercent`	内存上限百分比	40（关键！防止吃满内存）
`-httpListenAddr`	监听地址	默认 8428，内网可绑定 0.0.0.0

⚠️ -memory.allowedPercent 40 一定要设。VictoriaMetrics 默认会用尽可用内存做缓存，多库共存时它会抢内存。

4.4 systemd 管理#

cat > /etc/systemd/system/victoria-metrics.service << 'EOF'
[Unit]
Description=VictoriaMetrics
After=network.target

[Service]
ExecStart=/usr/local/bin/victoria-metrics \
    -storageDataPath /data/vm \
    -retentionPeriod 90d \
    -memory.allowedPercent 40
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now victoria-metrics

plaintext

4.5 验证#

# 健康检查
curl http://127.0.0.1:8428/health
# OK

# 查询接口
curl 'http://127.0.0.1:8428/api/v1/query?query=up'

plaintext

五、对接 Categraf（第 9 篇）#

在第 9 篇里我们配置了 Categraf 的 writers 指向 VM。现在 VM 起来了，确认数据进来了：

# 查询主机指标（Categraf 默认采集的）
curl 'http://127.0.0.1:8428/api/v1/query?query=cpu_usage_active'

# 查询所有指标名
curl 'http://127.0.0.1:8428/api/v1/label/__name__/values' | python3 -m json.tool

plaintext

能看到 cpu_*、mem_*、disk_* 等指标，说明链路已经打通。

六、数据管理#

6.1 数据保留策略#

-retentionPeriod 控制保留时间。数据超出保留期会自动删除，无需手动清理。

6.2 磁盘空间估算#

数据量 ≈ 每秒写入点数 × 指标大小

# 简单估算：1000 个指标 × 15s 间隔 × 90 天 ≈ 30-50GB
# 如果指标多，提前规划磁盘

plaintext

6.3 查询性能优化#

减少 query 跨度过大的聚合（尽量缩小时间范围）
用 instant 查询代替 range 查询（如果只需要当前值）
避免在查询中做大量正则匹配

七、常见坑#

坑	症状	解决
内存吃满	机器卡死	`-memory.allowedPercent` 调低
写入失败	Categraf 日志 4xx	确认 writers URL 是 `/prometheus/api/v1/write`
数据查不到	有指标但查询为空	检查时间范围、label 名写对没
端口冲突	8428 被占	`ss -tlnp` 查占用
时间不对	数据错位	配 NTP 同步时钟

八、总结#

环节	关键动作	一句话
选型	VictoriaMetrics 替代 Prometheus	同功能，少一半资源
部署	单二进制 + 参数启动	一行命令的事
内存	`-memory.allowedPercent 40`	必须设，防抢内存
保留	`-retentionPeriod 90d`	90 天够用
对接	Categraf writers 指向 8428	链路打通

数据有了存储，下一步把它「画」出来给人看。下一篇部署 Grafana——监控体系的最后一环。

本文首发于掘金 · 作者：七万号扎根雄安新区中关村科技园，专注受限环境下软件搭建与数据平台落地