Vultr 市场一键部署 VictoriaMetrics Single：配置、数据接入与源码级解析

Vultr 市场一键部署 VictoriaMetrics Single：配置、数据接入与源码级解析

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics

本指南以 deployment/marketplace/vultr/README.md 为骨架，完整讲解在 Vultr 云市场通过 One-Click 镜像部署 VictoriaMetrics Single 的完整流程：镜像内置的端口与配置布局、Prometheus 风格的指标抓取、五种主流写入协议的数据接入、vmui 查询界面以及 SSH/Web 控制台访问方式。同时结合本仓库deployment/marketplace/vultr目录下的 Packer 构建脚本、systemd 单元文件与实际抓取配置，从镜像构建到运行时参数逐层还原部署原理，帮助你在几台实例上快速落地一套可直接用于生产的小型监控方案。

一、这个 Vultr One-Click 应用是什么

Vultr Marketplace 提供的是VictoriaMetrics Single形态——单实例、全自主的监控与时间序列数据库。文档描述其定位为"Hassle-free monitoring solution"，一个实例即可支撑中小规模环境，并可直接作为时间序列的长期存储（long-term storage）。

VictoriaMetrics Single 在部署后的核心能力体现在两个层面：

• 采集层：既支持 Prometheus 拉取（pull）模型，也支持 Graphite、InfluxDB、OpenTSDB 等多种推送（push）协议；
• 查询层：支持 PromQL、MetricsQL 与 Graphite 三种查询语言，并内置 vmui 交互式查询界面。

该镜像并非简单的"装一个二进制"，而是由本仓库deployment/marketplace/vultr目录下的完整基础设施代码（Packer + systemd + UFW 防火墙 + cloud-init 脚本）支撑起来的一套开箱即用方案，下文将从构建源头开始逐层剖析。

二、镜像是怎么构建出来的：从 Packer 到 systemd

2.1 Packer 构建模板

镜像的构建入口是 victoriametrics-single.pkr.hcl。该文件声明了 Vultr 的 Packer 插件依赖（github.com/vultr/vultr，版本>= v2.3.2），并使用vc2-1c-1gb（1 vCPU / 1GB 内存）这一最小档位机型作为模板机，os_id = "387"指定基础操作系统镜像，ssh_username = "root"用于构建期远程执行脚本。

构建流程通过provisioner分四步完成：

1. 上传helper-scripts/vultr-helper.sh（提供install_cloud_init、clean_system等辅助函数）；
2. 上传setup-per-boot.sh与setup-per-instance.sh两个 cloud-init 生命周期脚本；
3. 将victoriametrics-single/etc/整目录拷贝到/etc/（包含 systemd 单元、抓取配置、运行参数文件、MOTD 欢迎页模板）；
4. 执行victoriametrics-single.sh完成二进制下载与系统准备。

2.2 二进制安装脚本

victoriametrics-single.sh 负责镜像内的实际装配，关键步骤包括：

• 创建一个无登录 shell 的系统用户victoriametrics（-s /sbin/nologin --system），数据目录/var/lib/victoria-metrics-data归属该用户；
• 通过wget从 GitHub Releases 下载对应VM_VERSION的victoria-metrics-linux-amd64-v${VM_VERSION}.tar.gz，解压到/usr/bin并安装为victoria-metrics-prod；
• 将两个生命周期脚本分别安装到/var/lib/cloud/scripts/per-boot/与/var/lib/cloud/scripts/per-instance/，并systemctl enable vmsingle.service实现开机自启；
• 最后调用clean_system清理构建痕迹，产出干净的 Marketplace 快照。

其中VM_VERSION由根目录 Makefile 中release-victoria-metrics-vultr-server目标自动注入：VM_VERSION ?= $(shell git describe --abbrev=0 --tags)，即取当前仓库最新的 git tag 作为发布版本。

2.3 systemd 单元：进程是如何跑起来的

服务由 vmsingle.service 管理，关键设计：

• User=victoriametrics/Group=victoriametrics，以非 root 低权限运行；
• EnvironmentFile=-/etc/victoriametrics/single/victoriametrics.conf，启动参数全部外置到独立配置文件，便于运维修改后systemctl restart vmsingle生效；
• ExecStart=/usr/bin/victoria-metrics-prod $ARGS加载配置中的参数；
• Restart=on-failure+RestartSec=5保证异常退出后自动拉起；
• ExecReload=/bin/kill -HUP $MAINPID支持向进程发送 HUP 信号触发配置热重载（对应 VictoriaMetrics 的-reloadAuthKey/ HTTP reload 机制，用于抓取配置变更场景）；
• LimitNOFILE=1048576与LimitNPROC=1048576放宽了文件描述符与进程数上限，避免高指标基数场景下的资源瓶颈；ProtectSystem=full则限制了对系统目录的写操作。

三、配置布局与开放端口

3.1 运行时参数文件

镜像把全部启动参数放在/etc/victoriametrics/single/victoriametrics.conf（对应仓库中的 victoriametrics.conf）：

ARGS="-promscrape.config=/etc/victoriametrics/single/scrape.yml -storageDataPath=/var/lib/victoria-metrics-data -retentionPeriod=12 -httpListenAddr=:8428 -graphiteListenAddr=:2003 -opentsdbListenAddr=:4242 -influxListenAddr=:8089 -enableTCP6"

各参数含义与部署影响如下：

这些协议端口的监听实现分别位于仓库的lib/ingestserver/graphite、lib/ingestserver/influx、lib/ingestserver/opentsdb与lib/ingestserver/opentsdbhttp等包中，VictoriaMetrics 通过-*ListenAddr系列参数为每种协议拉起独立的 ingest server。

3.2 抓取配置

默认抓取配置 scrape.yml 采用"自监控"模式：

# Scrape config example # scrape_configs: - job_name: self_scrape scrape_interval: 10s static_configs: - targets: ['127.0.0.1:8428']

即每 10 秒拉取一次本机8428端口上的/metrics，采集 VictoriaMetrics 自身暴露的运行指标（如vm_app_uptime_seconds）。这也解释了 README 中演示查询为何直接使用vm_app_uptime_seconds——它是镜像开箱即可查到的指标。需要采集其他 Prometheus exporter（如 node_exporter）时，只需在该文件追加新的job_name与static_configs目标，然后执行systemctl reload vmsingle或重启服务即可。

3.3 防火墙（UFW）开放策略

镜像首次启动时由 setup-per-instance.sh 配置 UFW 防火墙，开放规则与端口一一对应：

• 22SSH、80HTTP、443HTTPS（基础访问）；
• 8428：VictoriaMetrics HTTP 端口；
• 2003/tcp与2003/udp：Graphite 协议；
• 4242：OpenTSDB 协议；
• 8089/tcp与8089/udp：InfluxDB 行协议。

由于镜像默认开放了全部写入端口，README 明确建议：只保留实际使用的协议端口，其余一律用 UFW 关闭。例如仅需 Prometheus 远程写入时，可执行：

sudo ufw deny 2003/tcp sudo ufw deny 2003/udp sudo ufw deny 4242 sudo ufw deny 8089/tcp sudo ufw deny 8089/udp

登录服务器后通过sudo ufw status numbered即可查看当前规则，sudo ufw delete <编号>可删除指定规则。

四、指标抓取（Pull）与数据写入（Push）

4.1 抓取指标

VictoriaMetrics 的抓取行为与 Prometheus 完全一致，抓取配置由-promscrape.config指向的 YAML 文件控制，支持scrape_configs、job_name、scrape_interval、static_configs等 Prometheus 兼容字段。修改 scrape.yml 添加新目标后，通过kill -HUP（或systemctl reload vmsingle）热加载即可生效，无需中断服务。

4.2 五种协议的写入方式

镜像默认支持以下数据写入协议，README 中的对应关系如下：

• 8428 端口是一个多协议复用入口：Prometheus 远程写入（/api/v1/write）、exposition 格式导入（/api/v1/import/prometheus）、JSON 行格式导入（/api/v1/import）、CSV 导入（/api/v1/import/csv）以及 Datadog 兼容端点均监听于此。相关实现可参考app/vminsert下datadogv1、datadogv2、csvimport、promremotewrite等协议的接入代码。
• 2003 / 4242 / 8089 端口则分别对应lib/ingestserver中独立的 Graphite、OpenTSDB、Influx ingest server，由-graphiteListenAddr、-opentsdbListenAddr、-influxListenAddr参数决定是否开启。不需要的协议应通过 UFW 关闭对应端口，减小攻击面。

4.3 数据流向说明

Push 数据进入vminsert组件后，会按租户与时间序列哈希分片写入vmstorage；Pull 抓取的数据同样经由 scrape 流水线（lib/promscrape）处理后再落盘。对 Single 形态而言，写入与查询收敛在同一个进程内，存储层使用-storageDataPath指定的目录（默认/var/lib/victoria-metrics-data），-retentionPeriod=12控制保留 12 个月。

五、查询：vmui 与 Prometheus HTTP API

5.1 vmui 界面

VictoriaMetrics 内置的 Web UI（vmui）用于查询排障与数据探索，地址为：

http://your_server_public_ipv4:8428/vmui

该界面基于仓库app/vmselect/vmui目录下的前端源码构建。快速验证步骤：

1. 浏览器打开上述地址；
2. 在 Query Field 输入vm_app_uptime_seconds；
3. 点击 Execute Query，即可通过图表或表格查看该指标。

vm_app_uptime_seconds是 VictoriaMetrics 自身暴露的"进程运行秒数"指标，由-httpListenAddr对应的/metrics端点持续输出，镜像默认的自抓取任务每 10 秒采集一次，因此开箱即有数据可查。

5.2 curl 查询示例

README 提供了通过 HTTP API 查询区间数据的命令：

curl -sg http://your_server_public_ipv4:8428/api/v1/query_range?query=vm_app_uptime_seconds | jq

参数说明：

• -s：静默模式，隐藏进度信息；-g：关闭 URL 中的 glob 字符转义（避免[]被 shell 通配）；
• /api/v1/query_range：Prometheus 兼容的区间查询端点，返回该指标在时间范围内的序列点；
• | jq：将 JSON 响应格式化输出，便于阅读。

若未安装jq，可先执行apt install -y jq（镜像的 per-instance 脚本已安装wget、ufw、software-properties-common等基础工具，jq属于可选补充）。查询单点瞬时值可将端点替换为/api/v1/query，并附加&time=<unix_timestamp>参数。

六、访问服务器：SSH 与 Web 控制台

服务器创建完成后，有两种方式进入系统：

• Vultr Web 控制台：在 Vultr 控制台页面打开对应实例的 Web Console，直接开始交互式会话；
• SSH 直连 root：

ssh root@your_server_public_ipv4

登录后可通过以下路径管理服务：

常用管理命令：

# 查看服务状态 systemctl status vmsingle # 重启（修改 victoriametrics.conf 后） systemctl restart vmsingle # 热重载抓取配置（修改 scrape.yml 后） systemctl reload vmsingle # 跟踪日志 journalctl -u vmsingle -f

七、自定义与安全加固建议

• 按需裁剪协议端口：README 强调只保留实际使用的协议端口，这是该镜像最重要的安全动作。建议使用 UFW 关闭 2003、4242、8089 等未使用端口，仅保留 8428（或进一步限制为仅内网网段访问）。
• 调整数据保留期：修改/etc/victoriametrics/single/victoriametrics.conf中的-retentionPeriod（单位：月）可控制数据保留时长，修改后执行systemctl restart vmsingle。
• 扩展抓取目标：在/etc/victoriametrics/single/scrape.yml的scrape_configs下追加新 job，例如采集另一台主机的 node_exporter：在static_configs.targets中加入<node_ip>:9100，随后systemctl reload vmsingle热加载。
• 更新版本：镜像中VM_VERSION由构建期注入，实例内的二进制版本随 Marketplace 镜像固定；如需升级，可从官方 Releases 下载新版victoria-metrics-linux-amd64-*.tar.gz替换/usr/bin/victoria-metrics-prod后重启服务。
• 监控自身：默认的自抓取任务（self_scrape，10s 间隔）已保证vm_app_uptime_seconds、vm_*系列自身指标持续入库，可作为实例健康监控的基础数据源。

八、与 DigitalOcean 变体的对照

本仓库在 deployment/marketplace/digitialocean 目录下提供了同构的 DigitalOcean 一键镜像实现，两者共享同一套配置文件布局（/etc/victoriametrics/single/下的scrape.yml与victoriametrics.conf、vmsingle.servicesystemd 单元），仅在云厂商适配层（01-setup.sh、02-firewall.sh、04-install-victoriametrics.sh等分步脚本）与 Packer 模板（template.pkr.hcl）上存在差异。如果你同时运维多家云厂商，可以参考其脚本结构做横向迁移。

九、小结

通过 Vultr Marketplace 部署 VictoriaMetrics Single，你得到的不仅是一个二进制进程，而是一套由仓库代码驱动、自带 systemd 托管、UFW 防火墙策略、cloud-init 生命周期脚本与自监控抓取配置的完整最小监控系统。整个流程的关键事实均可追溯到仓库源码：

• 构建装配：victoriametrics-single.sh；
• 运行参数与抓取配置：victoriametrics.conf 与 scrape.yml；
• 进程托管：vmsingle.service；
• 防火墙与生命周期：setup-per-instance.sh；
• 镜像构建：victoriametrics-single.pkr.hcl。

按照本文的顺序：部署 → 确认端口与配置 → 接入抓取与写入 → vmui 验证 → SSH 加固，即可在数分钟内让一套可用的时间序列监控方案运行起来。

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics