VictoriaMetrics 单机口
VictoriaMetrics 单机版把写入、查询、自带 UI 与自身指标集中在 8428：Prometheus 的 remote_write 打到 /api/v1/write，PromQL 查询走 /api/v1/query，/metrics 暴露运行指标。它常被用作 Prometheus 的长周期存储或替代品，单二进制部署、资源占用低。
基本信息
| 服务 | VictoriaMetrics single-node |
|---|---|
| 协议 | TCP/HTTP（Prometheus 兼容 API） |
| 默认端口 | 8428 |
| 常用路径 | /api/v1/write、/api/v1/query、/metrics、/health |
| 暴露面 | 仅监控网段 |
典型使用场景
- 作为 Prometheus 远端存储：remote_write 指向 8428 保住历史数据
- Grafana 数据源直连 8428 跑 PromQL，查跨月区间比本地 Prometheus 快
- 容量评估：从 /metrics 读存储增长与写入速率，决定保留期
- 多环境统一查询入口：一套 Grafana 挂多个 8428 数据源
- 迁移期双写对比：同一个查询分别打新旧存储，验证结果一致
存活与读写核对
存活与读写核对
curl -s http://vm01:8428/health # 返回 OK 即存活
curl -s 'http://vm01:8428/api/v1/query?query=up' | head -c 300
ss -lntp | grep 8428
# Prometheus 侧配置:
# remote_write:
# - url: http://vm01:8428/api/v1/write排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 存活 | curl -s http://vm01:8428/health | 无响应：进程未起或端口被别的服务占用 |
| 写入链路 | Prometheus 的 remote_write 失败计数 | 采集正常但没数据：地址写错或被网络策略拦 |
| 查询 | PromQL 查近期与历史两个区间 | 近期有、历史无：保留期或时间参数配置问题 |
| 存储增长 | /metrics 中的磁盘与内存指标 | 磁盘异常增长：保留期过长或标签基数爆炸 |
8428 同时承载写入、查询与指标三类流量。暴露到公网时查询接口可枚举全部指标名与标签，等于把内部架构画成图送给外部；集群版把角色拆到 8480、8481、8482 等端口，网络策略不能照搬单机版。
和 Prometheus 的分工
单机版适合「一个二进制顶一套存储」的场景：抓取仍由 Prometheus 或 vmagent 负责，8428 只做存储与查询，好处是查询快、运维面小。代价是它本身也是单点，要高可用得上集群版或双写方案，别指望单机节点扛住故障。
8428 不是被 scrape 的目标而是接收方：Prometheus 的 targets 页面里看不到它很正常，判断健康要看 remote_write 的失败计数与 /health，别把抓取列表当成存储监控。
把 8428 裸放在公网：任何人可以写入伪造指标污染告警，也能通过查询接口读到全部指标与标签，两个方向的风险都要防。