VictoriaMetrics 面试题
30 道题- 分类
- 可观测性
- 子分类
- metrics
- 题目数
- 30 道
1 VictoriaMetrics 的核心架构和设计理念是什么?
答案:
VictoriaMetrics 是高性能的时间序列数据库和监控解决方案,兼容 Prometheus 生态,以单节点和集群两种模式部署。
核心架构:
graph TD
subgraph 单节点模式
VM["VictoriaMetrics<br/>(single binary)"] --> M1["/metrics<br/>(Prometheus Pull)"]
VM --> M2["/api/v1/write<br/>(Remote Write)"]
VM --> M3["/api/v1/query<br/>(PromQL)"]
end
subgraph 集群模式
VMI1["vminsert<br/>(写入入口)"] --> VMS["vmstorage<br/>(3+ 节点)"]
VMI2["vminsert<br/>(写入入口)"] --> VMS
VMI3["vminsert<br/>(写入入口)"] --> VMS
VMS --> VS1["vmselect<br/>(查询入口)"]
VMS --> VS2["vmselect<br/>(查询入口)"]
VMS --> VS3["vmselect<br/>(查询入口)"]
end
设计理念:
| 原则 | 说明 |
|---|---|
| 高性能 | Go 实现,自研存储引擎,单节点百万级指标 |
| 兼容 Prometheus | 完全兼容 PromQL 和 Metrics API |
| 低资源消耗 | 10-20× 压缩比,内存高效 |
| 运维简单 | 单 Binary 即可运行,配置最少 |
| 集群模式 | 线性扩展,无单点故障 |
2 VictoriaMetrics 的存储引擎与 Prometheus TSDB 的区别是什么?
答案:
VictoriaMetrics 使用自研的 LSM-Tree 变体存储引擎,与 Prometheus TSDB 在数据结构和压缩算法上有本质差异。
对比分析:
| 维度 | Prometheus TSDB | VictoriaMetrics |
|---|---|---|
| 存储结构 | 2h Block + 倒排索引 | LSM-Tree + 稀疏索引 |
| 压缩算法 | Gorilla (float64) | 自研压缩 (10-20×) |
| 内存模型 | Head Chunk (2h) | In-memory Parts |
| 索引结构 | 倒排索引 (Posting) | 稀疏索引 + 位图 |
| 写入路径 | WAL → Head → Block | In-memory → Disk Parts |
| 合并策略 | 分层合并 (2h→10h→…) | 增量合并 |
| 数据保留 | 基于时间的保留 | 基于时间 + 大小 |
压缩效率:
同一数据集(1 亿时间序列点):
Prometheus TSDB:
磁盘占用: ~130MB
内存占用: ~2-4GB (Head)
VictoriaMetrics:
磁盘占用: ~20-40MB
内存占用: ~500MB-1GB
写入性能:
# Prometheus TSDB 写入
rate(prometheus_tsdb_head_samples_appended_total[5m])
# 单机极限: ~100 万样本/s
# VictoriaMetrics 写入
# 单机极限: ~500 万样本/s
# 集群模式: 线性扩展
3 VictoriaMetrics 的集群组件和通信方式是什么?
答案:
VictoriaMetrics 集群由三个核心组件组成,通过内部 RPC 协议通信。
组件职责:
| 组件 | 职责 | 端口 | 状态 |
|---|---|---|---|
| vminsert | 写入入口,数据分片 | :8480 (metrics) | 无状态 |
| vmstorage | 数据存储和查询 | :8401 (内部), :8482 (metrics) | 有状态 |
| vmselect | 查询入口,数据合并 | :8481 (metrics) | 无状态 |
通信矩阵:
vminsert → vmstorage (内部 RPC :8401)
数据写入和分片分发
vmselect → vmstorage (内部 RPC :8401)
数据查询和聚合
vmstorage 间不直接通信(shared-nothing 架构)
数据流:
写入:
Client → vminsert (:8480) → vmstorage (:8401)
查询:
Client → vmselect (:8481) → vmstorage (:8401)
多租户:
/insert/:accountID/:projectID/prometheus/...
/select/:accountID/:projectID/prometheus/...
4 VictoriaMetrics 的数据分片和路由机制是什么?
答案:
VictoriaMetrics 通过一致性哈希算法将数据分布到多个 vmstorage 节点,支持线性扩展。
分片原理:
graph TD
Metric["Metric 数据"] --> Hash["计算 metric 的 Hash"]
Hash --> Mod["Hash mod N<br/>(N = vmstorage 节点数)"]
Mod --> VS1["vmstorage-1<br/>(分片 A)"]
Mod --> VS2["vmstorage-2<br/>(分片 B)"]
Mod --> VS3["vmstorage-3<br/>(分片 C)"]
分片配置:
# vminsert 配置(列出所有 vmstorage 节点)
vminsert:
- -storageNode=vmstorage-1:8401,vmstorage-2:8401,vmstorage-3:8401
# 新增节点时自动重平衡
- -replicationFactor=2 # 副本数,可选
路由特性:
1. 相同 metric 始终路由到相同节点
- 保证数据本地性
- 查询时只需访问少数节点
2. 新增/删除节点
- 一致性哈希最小化数据迁移
- 仅迁移 hash 环中的部分数据
3. 查询路由
- vmselect 向所有 vmstorage 广播查询
- 各节点并行返回结果
- vmselect 合并后返回客户端
5 VictoriaMetrics 的查询处理流程是什么?
答案:
VictoriaMetrics 的查询从 vmselect 接收 PromQL 请求到 vmstorage 返回数据的完整链路。
查询流程:
1. vmselect 接收 PromQL 请求
POST /api/v1/query?query=up{job="node"}
2. PromQL 解析和优化
- 解析表达式树
- 识别标签匹配器和时间范围
- 查询优化(下推过滤条件)
3. 分发到所有 vmstorage
- 广播查询请求
- 并行执行
4. vmstorage 本地执行
- 查找标签索引
- 读取数据块
- 本地 PromQL 计算
- 返回结果
5. vmselect 合并
- 汇总各节点结果
- 去重(副本数据)
- 最终计算(聚合函数等)
- 返回客户端
查询类型:
# 瞬时查询 → 单时间点快照
/api/v1/query?query=up&time=1717000000
# 范围查询 → 时间范围序列
/api/v1/query_range?query=rate(http_requests_total[5m])&start=1717000000&end=1717003600&step=15
# 标签查询 → 标签元数据
/api/v1/labels?match[]=up
/api/v1/label/__name__/values
6 VictoriaMetrics 的 PromQL 兼容性和扩展功能是什么?
答案:
VictoriaMetrics 完全兼容 PromQL 的基础上,增加了多项扩展函数和语法糖。
兼容 PromQL 函数:
rate, irate, increase, delta
histogram_quantile, quantile_over_time
avg, sum, min, max, count, stddev
label_replace, label_join
absent, absent_over_time
sgn, sort, sort_desc
topk, bottomk, limitk
VictoriaMetrics 扩展函数:
| 函数 | 作用 | 示例 |
|---|---|---|
| rollup_rate | 自动选择最佳速率函数 | rollup_rate(http_requests_total[5m]) |
| rollup_increase | 自动增加函数 | rollup_increase(metric[5m]) |
| rollup_delta | 自动差值函数 | rollup_delta(metric[5m]) |
| histogram_share | 自定义阈值请求占比 | histogram_share(0.5, http_request_duration_seconds) |
| topk_last | 选取 Top K 的最后值 | topk_last(5, metric) |
| range_avg | 时间范围的平均值 | range_avg(metric[1h]) |
| range_min | 时间范围的最小值 | range_min(metric[1h]) |
| range_max | 时间范围的最大值 | range_max(metric[1h]) |
| range_quantile | 时间范围的分位数 | range_quantile(0.99, metric[1h]) |
| smooth_exponential | 指数平滑 | smooth_exponential(metric, 0.5) |
| outliers_iqr | IQR 异常检测 | outliers_iqr(metric) |
| outliers_mad | MAD 异常检测 | outliers_mad(metric) |
| if | 条件过滤 | metric if metric > 100 |
| default | 默认值替换 | metric default 0 |
| alias | 指标别名 | alias(metric, “new_name”) |
7 VictoriaMetrics 的数据压缩和存储格式是什么?
答案:
VictoriaMetrics 采用自研的列式压缩算法,实现 10-20× 的压缩比。
压缩策略:
| 数据类型 | 压缩算法 | 压缩比 | 说明 |
|---|---|---|---|
| 时间戳 | Delta-of-Delta + Variable Integer | 20-40× | 相邻时间戳差值编码 |
| 浮点值 | XOR + 前值预测 | 15-30× | 优化后 Gorilla-like |
| 整数 | Variable Integer + Delta | 30-50× | 小整数高效编码 |
| 标签 | 字典压缩 + 差值编码 | 10-20× | 全局字典 + 局部差值 |
| 字符串 | Snappy/Zstd | 5-10× | 通用压缩 |
存储结构:
graph TD
subgraph Dir["目录结构 (/data/vm/)"]
Tenant["tenant/"] --> Date["date/"]
Date --> Index["index (全局索引)"]
Date --> Timestamps["timestamps (时间戳列)"]
Date --> Values["values (值列)"]
Date --> Metadata["metadata (元数据)"]
end
subgraph Part["每个 part (数据分区)"]
PIdx["索引 (index)<br/>- 倒排标签索引<br/>- 时序 ID 映射"]
PTs["时间戳列 (timestamps)<br/>- 压缩后的时间戳序列"]
PVal["值列 (values)<br/>- 压缩后的浮点值序列"]
PIdx --> PTs --> PVal
end
磁盘空间对比:
1 亿时间序列点, 30 天保留:
Prometheus TSDB: ~130GB
VictoriaMetrics: ~20-40GB
节省: 70-85%
8 VictoriaMetrics 的多租户模型是什么?
答案:
VictoriaMetrics 原生支持多租户,通过 accountID 和 projectID 实现数据和查询隔离。
租户标识:
URL 格式:
/insert/<accountID>:<projectID>/prometheus/...
/select/<accountID>:<projectID>/prometheus/...
例如:
/insert/0:0/prometheus/api/v1/write # 租户 0
/insert/1:0/prometheus/api/v1/write # 租户 1
/select/0:0/prometheus/api/v1/query # 查询租户 0
多租户示例:
# vminsert 写入
# 不同租户写入不同 URL
curl -X POST http://vminsert:8480/insert/0:0/prometheus/api/v1/write \
--data-binary @metrics.bin
curl -X POST http://vminsert:8480/insert/1:0/prometheus/api/v1/write \
--data-binary @metrics.bin
# vmselect 查询
curl http://vmselect:8481/select/0:0/prometheus/api/v1/query?query=up
curl http://vmselect:8481/select/1:0/prometheus/api/v1/query?query=up
租户隔离级别:
| 隔离维度 | 实现方式 | 说明 |
|---|---|---|
| 数据隔离 | accountID:projectID | 不同租户数据物理分离 |
| 查询隔离 | URL 路径区分 | 按租户查询,互不可见 |
| 资源隔离 | 独立 vminsert/vmselect | 需独立部署组件 |
| 存储隔离 | 独立磁盘目录 | 按 accountID 分目录 |
9 VictoriaMetrics 的数据保留策略和存储降级机制是什么?
答案:
VictoriaMetrics 支持基于时间和存储大小的双维度保留策略,以及存储自动降级机制。
保留策略配置:
# 单节点
--retentionPeriod=30d # 保留 30 天
--storageDataPath=/data/vm # 数据路径
--maxDiskUsagePerGB=10 # 每 GB 最大写入(限流)
# 集群模式
vmstorage:
- -retentionPeriod=30d
- -storageDataPath=/storage/vm
存储自动降级:
当磁盘使用率超过阈值时,VictoriaMetrics 自动执行降级:
阶段 1: 达到 85%
限流写入速率 (throttle)
阶段 2: 达到 90%
强制删除过期数据
阶段 3: 达到 95%
删除最旧的数据块(即使未过期)
阶段 4: 达到 98%
只读模式,拒绝新写入
存储清理机制:
后台合并任务同时执行数据清理:
1. 删除超过 retentionPeriod 的数据
- 按时间戳对比
- 逐块删除
2. 合并时自动去重
- 相同时间戳的重复样本
- 合并过程中丢弃过期数据块
3. 存储大小限制(可选)
- retention.size 模式
- 超出限制时删除最旧数据
10 VictoriaMetrics 的高可用和故障恢复方案是什么?
答案:
VictoriaMetrics 集群模式通过组件冗余和副本机制实现高可用。
组件 HA:
| 组件 | HA 方案 | 故障切换 |
|---|---|---|
| vminsert | 多副本 + LB | LB 自动摘除故障节点 |
| vmstorage | 多节点 + 副本 | 故障节点数据由副本提供 |
| vmselect | 多副本 + LB | 自动切换健康节点 |
副本机制:
# vminsert 副本配置
vminsert:
- -replicationFactor=2 # 每个样本写入 2 个 vmstorage
- -storageNode=vmstorage-1:8401,vmstorage-2:8401,vmstorage-3:8401
# 副本数据流:
# Client → vminsert
# → vmstorage-1 (主副本)
# → vmstorage-2 (从副本)
#
# 查询时:
# vmselect → vmstorage-1 (正常) → 返回数据
# vmselect → vmstorage-2 (正常) → 返回数据
# vmselect 去重后返回客户端
故障恢复场景:
1. vmstorage 节点宕机
- vminsert 只写入健康节点
- vmselect 跳过宕机节点
- 有副本时: 副本提供数据
2. vmstorage 恢复
- 自动重新加入集群
- 从副本同步缺失数据
- 恢复正常写入和查询
3. vminsert 扩容
- 新增节点自动加入
- LB 分发写入请求
- 数据一致性由一致性哈希保证
4. 全集群恢复
- 从快照恢复数据
- 重建索引
- 逐步恢复服务
11 VictoriaMetrics 的写入吞吐量和延迟指标是什么?
答案:
VictoriaMetrics 在写入方面具有极高的吞吐量和较低的延迟。
性能指标:
| 指标 | 单节点 | 集群模式 |
|---|---|---|
| 写入吞吐量 | 500 万样本/s | 线性扩展 |
| P99 写入延迟 | < 10ms | < 20ms |
| 最大活跃序列 | 1000 万 | 无硬限制 |
| 最大指标数 | 1 亿+ | 10 亿+ |
写入延迟分解:
样本到达 → VictoriaMetrics
│
├── 协议解析: ~1ms
├── 标签索引: ~2ms
├── 数据压缩: ~3ms
├── 内存写入: ~1ms
└── 返回 ACK: ~1ms
│
总计: < 10ms
监控写入性能:
# 写入速率 (单节点)
rate(vm_rows_inserted_total[5m])
# 写入延迟
vm_ingestion_request_duration_seconds
# 写入失败
rate(vm_ingestion_errors_total[5m])
# 丢弃的样本
rate(vm_rows_dropped_total[5m])
写入优化:
# vminsert 配置
vminsert:
- -maxInsertRequestSize=32MB # 增大请求大小
- -maxConcurrentInserts=100 # 并发写入数
- -rpcConcurrency=100 # 存储 RPC 并发
12 VictoriaMetrics 的查询性能和 QPS 能力是多少?
答案:
VictoriaMetrics 在查询性能上针对 PromQL 做了大量优化,支持高并发查询。
查询性能:
| 查询类型 | 延迟 | QPS (单节点) |
|---|---|---|
| Instant Query(单标签) | < 5ms | 10000+ |
| Instant Query(多标签) | < 20ms | 5000+ |
| Range Query(1h) | < 50ms | 2000+ |
| Range Query(24h) | < 500ms | 500+ |
| Range Query(30d) | < 5s | 100+ |
查询优化:
# vmselect 配置
vmselect:
- -search.maxQueryDuration=1m # 最大查询时间
- -search.maxConcurrentRequests=50 # 最大并发查询数
- -search.maxPointsPerTimeseries=30000 # 每序列最大点数
- -search.maxUniqueTimeseries=300000 # 最大唯一序列数
# 查询缓存
- -search.cacheTimestamp=1ms # 缓存时间戳精度
监控查询性能:
# 查询延迟
vm_select_request_duration_seconds
# QPS
rate(vm_select_requests_total[5m])
# 慢查询
rate(vm_select_requests_total{status="slow"}[5m])
# 并发查询数
vm_concurrent_select_current
13 VictoriaMetrics 的 memory mapping 技术是什么?
答案:
VictoriaMetrics 大量使用 mmap 技术管理数据,降低内存占用并提升查询性能。
mmap 使用场景:
| 数据结构 | mmap 策略 | 内存效率 |
|---|---|---|
| 索引文件 | 只读 mmap | 按需加载页 |
| 时间序列数据 | 只读 mmap | 访问时按页加载 |
| 倒排索引 | 只读 mmap | 大索引只需少量内存 |
| 元数据 | 内存分配 | 常驻内存 |
mmap 优势:
传统文件读取:
读取 → 内存缓冲 → 用户空间
内存开销 = 数据量
mmap 读取:
映射 → 虚拟内存 → 按页按需加载
内存开销 = 活跃访问的数据量
差异:
100GB 数据索引
传统: 需要 100GB 内存
mmap: 仅占用活跃访问的 ~1-2GB
mmap 配置:
# VictoriaMetrics 自动使用 mmap
# 无需额外配置
# 操作系统层面确保 mmap 计数足够
sysctl -w vm.max_map_count=262144
# 监控 mmap 使用
vm_mmap_memory_total_bytes # mmap 映射的大小
vm_memory_mmap_count # mmap 映射数量
14 VictoriaMetrics 的 vmbackup 和 vmrestore 工具如何使用?
答案:
VictoriaMetrics 提供专门的备份和恢复工具,支持对象存储和本地文件系统。
vmbackup:
# 备份到本地目录
./vmbackup -storageDataPath=/data/vm \
-snapshot.createURL=http://localhost:8428/snapshot/create \
-dst=fs:///backup/vm-20260526
# 备份到 S3
./vmbackup -storageDataPath=/data/vm \
-snapshot.createURL=http://localhost:8428/snapshot/create \
-dst=s3://vm-backup-bucket/vm-20260526 \
-credsFilePath=/etc/vm/credentials
# 增量备份
./vmbackup -storageDataPath=/data/vm \
-snapshot.createURL=http://localhost:8428/snapshot/create \
-dst=fs:///backup/vm/ \
-prevBackupPath=fs:///backup/vm-20260525/
# 定期备份(Cron 示例)
0 2 * * * /usr/local/bin/vmbackup -storageDataPath=/data/vm \
-snapshot.createURL=http://localhost:8428/snapshot/create \
-dst=s3://vm-backup/vm-daily/$(date +\%Y\%m\%d)
vmrestore:
# 从 S3 恢复
./vmrestore -src=s3://vm-backup-bucket/vm-20260526 \
-storageDataPath=/data/vm
# 从本地恢复
./vmrestore -src=fs:///backup/vm-20260526 \
-storageDataPath=/data/vm
# 恢复完成后启动
./victoria-metrics -storageDataPath=/data/vm
备份策略:
| 备份类型 | 频率 | 保留时间 | 说明 |
|---|---|---|---|
| 快照备份 | 实时 | 12h | 用于快速恢复 |
| 日备份 | 每日 | 30 天 | 增量备份 |
| 周备份 | 每周 | 6 个月 | 全量备份 |
| 月备份 | 每月 | 2 年 | 归档 |
15 VictoriaMetrics 的 downsampling 功能是什么?
答案:
VictoriaMetrics 支持自动降采样和自定义降采样配置,降低长期数据存储成本。
自动降采样:
VictoriaMetrics 自动将 1 小时内旧数据压缩为 1 个聚合点:
原始数据: 15s 分辨率 → 240 点/小时
降采样后: 1 个聚合点/小时
聚合函数: avg, min, max, count
降采样时机:
数据写入后 ~1 小时
由后台合并任务自动执行
自定义降采样(企业版):
# 降采样规则配置
downsampling:
# 7 天内保留原始数据
- period: 7d
step: 1m
# 7-30 天降采样到 5m
- period: 30d
step: 5m
aggregation: avg
# 30-90 天降采样到 30m
- period: 90d
step: 30m
aggregation: [min, max, avg]
# 90 天以上降采样到 4h
- period: 365d
step: 4h
aggregation: [min, max, avg, count]
存储节省:
每天 100GB 数据,保留 365 天:
无降采样: 100GB × 365 = 36.5TB
降采样:
原始 7d: 100GB × 7 = 700GB
5m 23d: 700GB / 5 × 23 = 3.2TB (avg)
30m 60d: 700GB / 30 × 60 = 1.4TB
4h 275d: 700GB / 240 × 275 = 800GB
总计: ~6TB,节省 ~84%
16 VictoriaMetrics 的 deduplication(数据去重)机制是什么?
答案:
VictoriaMetrics 在查询时对多副本数据进行去重,保证最终一致性。
去重策略:
同一时间序列在多个 vmstorage 副本中的数据:
vmstorage-1:
node_cpu_seconds_total{cpu="0", instance="node1"} @ T=10 value=100
node_cpu_seconds_total{cpu="0", instance="node1"} @ T=20 value=110
vmstorage-2:
node_cpu_seconds_total{cpu="0", instance="node1"} @ T=10 value=100
node_cpu_seconds_total{cpu="0", instance="node1"} @ T=20 value=112
去重逻辑(查询时):
1. 比较相同时间戳的样本
2. 选择值最大(或最小)的样本
3. 丢弃重复样本
去重配置:
# vmselect 去重
vmselect:
- -dedup.minScrapeInterval=1ms # 去重时间窗口
# 时间窗口内相同的时间戳视为重复
- -replicationFactor=2 # 告知 vmselect 副本数
# 实际配置建议
- -dedup.minScrapeInterval=30s # 如果采集间隔 15s
去重行为:
dedup.minScrapeInterval=30s:
样本时间戳:
T=10, T=12, T=20, T=25, T=30
去重后:
10-30 窗口内 → 保留最终值 T=25
30+ → 正常处理
17 VictoriaMetrics 的 Cache 机制和配置是什么?
答案:
VictoriaMetrics 使用多层缓存加速数据读取,缓存命中率影响查询性能。
缓存类型:
| 缓存 | 内容 | 存储 | 默认大小 | 配置 |
|---|---|---|---|---|
| 索引缓存 | 标签 → 时序 ID | 内存 | 所有可用的 20% | –memory.allowedBytes |
| 存储缓存 | 数据块 | mmap | 系统管理 | - |
| 查询缓存 | 查询结果 | 内存 | 5% 内存 | –search.cacheSize |
缓存配置:
# 单节点 VMS
./victoria-metrics \
-memory.allowedBytes=8GB \
-storage.cacheSize=2GB
# vmselect
vmselect:
- -memory.allowedBytes=4GB
- -search.cacheSize=1GB
# 查询结果缓存 TTL
- -search.cacheTimestamp=1ms
缓存监控:
# 索引缓存命中率
rate(vm_cache_hits_total{type="index"}[5m])
/
rate(vm_cache_requests_total{type="index"}[5m])
# 缓存大小
vm_cache_size_bytes{type="index"}
# 缓存驱逐率
rate(vm_cache_evictions_total[5m])
# 缓存请求延迟
vm_cache_request_duration_seconds{type="index"}
18 VictoriaMetrics 的 Merge 机制和后台任务管理是什么?
答案:
VictoriaMetrics 的后台合并任务持续对数据分区进行合并和优化。
合并触发条件:
自动合并触发:
1. 小分区数量 > 30 个
→ 合并为更大的分区
2. 分区超过 1 小时
→ 自动进行降采样和压缩
3. 磁盘 IO 空闲时
→ 后台低优先级合并
合并过程:
分区合并:
3 个小分区 (part):
Part-A (10K 样本, 1 分钟)
Part-B (8K 样本, 30 秒)
Part-C (12K 样本, 45 秒)
合并后:
Merged-Part (30K 样本, 2 分钟)
- 更紧凑的索引
- 更高的压缩比
- 更快的查询
合并监控:
# 当前合并任务数
vm_merges_current
# 合并延迟
vm_merge_duration_seconds_total
# 分区数量
vm_parts_count
# 合并速度
rate(vm_rows_merged_total[5m])
合并配置:
# 合并并发控制
./victoria-metrics \
-maxSmallMergeConcurrency=4 # 小分区合并并发数
-maxLargeMergeConcurrency=1 # 大分区合并并发数
-smallMergeSize=1TB # 小分区大小阈值
-finalMergeEnabled=false # 禁用最终合并(集群模式推荐)
19 VictoriaMetrics 与 Prometheus 的兼容性如何?
答案:
VictoriaMetrics 在设计上与 Prometheus 生态高度兼容,可作为 Prometheus Server 的替代品。
兼容性矩阵:
| 功能 | Prometheus | VictoriaMetrics | 兼容度 |
|---|---|---|---|
| PromQL | 原生 | 完全兼容 + 扩展 | 100% |
| Prometheus HTTP API | /api/v1/query, /api/v1/query_range 等 | 完全兼容 | 100% |
| Remote Write | 支持 | 接收端 | 100% |
| Remote Read | 支持 | 提供端 | 100% |
| Service Discovery | 多种 SD | 支持 file_sd, k8s_sd 等 | 100% |
| Alerting | Alertmanager | 通过 vmagent | 100% |
| Recording Rules | 支持 | 通过 vmagent/vmalert | 100% |
| Prometheus Operator | CRD | vmalert + 手动配置 | 部分 |
| Scrape Config | scrape_config.yaml | 通过 vmagent | 100% |
| Exemplar | 支持 | 支持 | 100% |
替换 Prometheus:
# 原 Prometheus 配置
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['node-exporter:9100']
# 直接用于 vmagent
vmagent:
-promscrape.config=/etc/vmagent/prometheus.yml
-remoteWrite.url=http://victoriametrics:8428/api/v1/write
# Grafana 数据源
datasources:
- name: VictoriaMetrics
type: prometheus
url: http://victoriametrics:8428
20 VictoriaMetrics 的 vmalert 组件的作用是什么?
答案:
vmalert 是 VictoriaMetrics 的告警和记录规则评估组件,替代 Prometheus 的规则评估功能。
架构:
graph TD
VMS["vmselect"] -->|查询| VA["vmalert"]
VA --> AM["Alertmanager"]
VA --> RW["Remote Write"]
VA --> NF["Notifier<br/>(Webhook)"]
RW --> VMI["vminsert"]
配置:
# vmalert 启动参数
vmalert:
- -rule=/etc/vmalert/rules/*.yaml
- -datasource.url=http://vmselect:8481/select/0:0/prometheus
- -remoteWrite.url=http://vminsert:8480/insert/0:0/prometheus
- -notifier.url=http://alertmanager:9093
- -evaluationInterval=30s
# 规则文件(兼容 Prometheus 格式)
groups:
- name: node-alerts
interval: 30s
rules:
- alert: NodeCPUUsageHigh
expr: (100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > 80
for: 5m
labels:
severity: warning
- record: node:node_cpu_utilization:ratio
expr: (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
vmalert 集群模式:
# 多副本部署,通过 replica 标签去重
vmalert:
replicas: 2
- -external.label=replica=$(HOSTNAME)
- -remoteWrite.url=http://vminsert:8480/insert/0:0/prometheus
21 VictoriaMetrics 的 vmagent 组件的作用是什么?
答案:
vmagent 是 VictoriaMetrics 的数据采集代理,替代 Prometheus Server 的采集功能。
功能特性:
| 功能 | 说明 |
|---|---|
| Prometheus 兼容采集 | 完全兼容 scrape_config 格式 |
| 服务发现 | K8s, Consul, file_sd 等 |
| Remote Write | 写入 VictoriaMetrics 或其他后端 |
| 数据过滤 | relabel, metric_relabel |
| 协议转换 | Prometheus → Remote Write |
| 数据持久化 | 写入失败本地缓冲 |
| 多路复用 | 一份数据写入多个后端 |
配置示例:
# vmagent 采集配置
vmagent:
- -promscrape.config=/etc/vmagent/scrape.yml
- -remoteWrite.url=http://vminsert:8480/insert/0:0/prometheus
- -remoteWrite.url=http://thanos-receiver:19291/api/v1/receive
- -remoteWrite.queues=4
- -remoteWrite.maxBlockSize=1MB
# scrape.yml(完全兼容 Prometheus 格式)
scrape_configs:
- job_name: 'node'
scrape_interval: 15s
static_configs:
- targets: ['node-exporter:9100']
relabel_configs:
- source_labels: [__address__]
regex: '(.*):.*'
target_label: instance
vmagent 优势:
1. 更低资源消耗
- 内存: Prometheus ~2GB vs vmagent ~500MB
- CPU: Prometheus ~2Core vs vmagent ~0.5Core
2. 本地数据持久化
- 写入失败时数据缓冲到磁盘
- 重新连接后自动续传
3. 多后端写入
- 同时发送到多个 Remote Write
- 可作为数据复制代理
22 VictoriaMetrics 的 vmui(Web UI)功能是什么?
答案:
VictoriaMetrics 内置 Web UI 界面 vmui,提供 PromQL 查询、指标探索和调试功能。
功能列表:
| 功能 | 路径 | 说明 |
|---|---|---|
| 查询编辑器 | /vmui | PromQL 输入和结果展示 |
| 指标搜索 | /vmui/#/metrics | 按名称搜索指标 |
| 标签浏览 | /vmui/#/labels | 查看标签名和值 |
| 卡目录 | /vmui/#/cardinality | 高基数分析 |
| Top Queries | /vmui/#/top-queries | 最耗时查询 |
| Active Queries | /vmui/#/active-queries | 当前运行查询 |
| Trace Profiling | /vmui/#/trace | 查询 Trace 分析 |
vmui 路径:
单节点 VMS:
http://victoriametrics:8428/vmui/
集群模式:
http://vmselect:8481/select/0:0/vmui/
Grafana 集成:
datasources → VictoriaMetrics → 使用 vmui
http://victoriametrics:8428/select/0:0/vmui/
卡目录分析:
# vmui 卡目录页显示的查询:
Top 10 高基数指标:
sort_desc(count by (__name__) ({__name__=~".+"}))
Top 10 高基数标签:
sort_desc(count by (job) (count by (__name__, job) ({__name__=~".+"})))
Top 10 高基数标签值:
sort_desc(count by (url) ({__name__="http_requests_total"}))
23 VictoriaMetrics 的 Prometheus Operator 集成方式是什么?
答案:
VictoriaMetrics 可以替代 Prometheus Operator 中的 Prometheus Server,需要特定的适配配置。
集成架构:
Prometheus Operator CRD → VictoriaMetrics 适配
ServiceMonitor/PodMonitor → vmagent (替代 Prometheus Server)
PrometheusRule → vmalert (替代 Prometheus Rule evaluation)
Alertmanager → 复用 Prometheus Operator 的 Alertmanager
Grafana → VictoriaMetrics 数据源
vmagent CRD 配置:
# 通过 Scrape Config 直接使用 ServiceMonitor
apiVersion: v1
kind: ConfigMap
metadata:
name: vmagent-scrape-config
data:
scrape.yml: |
scrape_configs:
- job_name: 'kubernetes-service-endpoints'
kubernetes_sd_configs:
- role: endpoints
relabel_configs:
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
Grafana 集成:
# Grafana 数据源
datasources:
- name: VictoriaMetrics
type: prometheus
url: http://vmselect:8481/select/0:0/prometheus
access: proxy
isDefault: true
jsonData:
timeInterval: "30s"
Operator 扩展(VM Operator):
VictoriaMetrics 提供了专门的 VM Operator,原生支持 ServiceMonitor/PodMonitor:
- github.com/VictoriaMetrics/operator
- 支持 CRD: VMServiceScrape, VMPodScrape, VMRule, VMAlert, VMAgent
24 VictoriaMetrics 的指标卡目录(Cardinality)管理是什么?
答案:
VictoriaMetrics 提供内置的卡目录管理工具,帮助识别和降低高基数指标。
卡目录类型:
| 类型 | 描述 | 阈值 |
|---|---|---|
| 高基数指标 | 具有大量唯一标签组合的指标 | > 10K 序列 |
| 高基数标签 | 具有大量唯一值的标签 | > 1K 值 |
| 高基数标签值 | 标签值变化频繁 | 影响索引性能 |
卡目录查询:
# 查看所有指标的时间序列数
sort_desc(count by (__name__) ({__name__=~".+"}))
# 查看特定指标的高基数标签
sort_desc(count by (url, method) (http_requests_total))
# 查看标签值的分布
sort_desc(count by (url) ({__name__="http_requests_total"}))
# 总时间序列数
count({__name__=~".+"})
卡目录降低策略:
# vmagent relabel 丢弃高基数标签
scrape_configs:
- job_name: 'myapp'
metric_relabel_configs:
# 丢弃 URL 标签(高基数)
- source_labels: [__name__]
regex: 'http_request_.*'
- action: labeldrop
regex: 'url|request_id|user_id|session_id'
# 或者替换为低基数标签
relabel_configs:
- source_labels: [__meta_kubernetes_pod_name]
target_label: pod
- action: labeldrop
regex: 'pod'
# 使用 deployment 替代 pod(降低基数)
25 VictoriaMetrics 的 vmctl 工具支持哪些功能?
答案:
vmctl 是 VictoriaMetrics 的数据迁移工具,支持从多种数据源导入数据。
支持的数据源:
| 源端 | 目标端 | 说明 |
|---|---|---|
| Prometheus | VictoriaMetrics | 直接读取 Prometheus TSDB |
| Prometheus Remote Write | VictoriaMetrics | 模拟 Remote Write |
| Graphite | VictoriaMetrics | Carbon 协议兼容 |
| OpenTSDB | VictoriaMetrics | Telnet/HTTP 协议 |
| InfluxDB | VictoriaMetrics | 兼容 InfluxDB line protocol |
| VictoriaMetrics 间迁移 | VictoriaMetrics | 原生迁移 |
Prometheus 迁移:
# 从 Prometheus TSDB 迁移到 VictoriaMetrics
./vmctl prometheus \
-prom-snapshot=/path/to/prometheus/snapshot \
-vm-addr=http://victoriametrics:8428
# 增量迁移
./vmctl prometheus \
-prom-snapshot=/path/to/prometheus/snapshot \
-vm-addr=http://victoriametrics:8428 \
-vm-concurrency=4 \
-vm-batch-size=10000
Remote Write 迁移:
# 从 Prometheus Remote Write 迁移
./vmctl prometheus-remotewrite \
-src-addr=http://prometheus:9090 \
-dst-addr=http://victoriametrics:8428/api/v1/write
数据校验:
# 迁移后校验
./vmctl verify \
-src-addr=http://prometheus:9090 \
-dst-addr=http://victoriametrics:8428 \
-start=1717000000 \
-end=1717003600
26 VictoriaMetrics 的安全配置和认证机制是什么?
答案:
VictoriaMetrics 原生支持 TLS 和 Basic Auth,通过反向代理实现更复杂的认证。
原生支持:
# TLS 配置
./victoria-metrics \
-tls=true \
-tlsCertFile=/etc/vm/tls/cert.pem \
-tlsKeyFile=/etc/vm/tls/key.pem \
-tlsCAFile=/etc/vm/tls/ca.pem
# Basic Auth
./victoria-metrics \
-httpAuth.username=admin \
-httpAuth.password=<password>
# 或通过配置文件
./victoria-metrics \
-httpAuth.config=/etc/vm/auth.yml
反向代理认证:
# Nginx 前置认证
server {
listen 443 ssl;
server_name victoriametrics.example.com;
location / {
auth_basic "VictoriaMetrics";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_pass http://localhost:8428;
}
}
网络策略:
# K8s NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: vm-cluster
spec:
podSelector:
matchLabels:
app: vmstorage
ingress:
- from:
- podSelector:
matchLabels:
app: vminsert
- podSelector:
matchLabels:
app: vmselect
ports:
- port: 8401
27 VictoriaMetrics 的日志和调试方法是什么?
答案:
VictoriaMetrics 通过结构化的 JSON 日志和内置 HTTP 端点提供全面的诊断信息。
日志配置:
./victoria-metrics \
-loggerLevel=INFO # 日志级别: INFO/WARN/ERROR
-loggerFormat=json # JSON 格式日志
-loggerOutput=stdout # 输出到 stdout
关键日志事件:
{"level":"error","msg":"cannot open storage","path":"/data/vm"}
{"level":"warn","msg":"high cardinality detected","metric":"http_requests_total","series":100000}
{"level":"info","msg":"merge completed","parts":5,"size":"2GB","duration":"30.5s"}
{"level":"error","msg":"cannot insert to vmstorage","storageNode":"vmstorage-1:8401"}
诊断端点:
# 健康检查
GET /health # 200 OK
GET /ping # 存活检测
# 性能诊断
GET /metrics # Prometheus 指标
GET /debug/pprof/ # Go pprof 分析
GET /debug/pprof/profile # CPU Profile
GET /debug/pprof/heap # 内存 Profile
# 内部状态
GET /api/v1/status/tsdb # TSDB 状态
GET /api/v1/status/cache # 缓存状态
GET /api/v1/status/config # 运行时配置
GET /api/v1/status/buildinfo # 版本信息
# 集群状态
GET /admin/tenants # 租户列表 (集群)
GET /api/v1/status/storage_nodes # 存储节点 (集群)
28 VictoriaMetrics 的常见性能问题和优化方法是什么?
答案:
VictoriaMetrics 的性能问题通常集中在高基数、磁盘 IO 和内存使用三个方面。
常见问题:
| 问题 | 症状 | 原因 | 优化 |
|---|---|---|---|
| 写入延迟高 | 写入 QPS 下降 | 高基数 | 降低标签基数 |
| 查询超时 | 查询返回 503 | 时间范围过大 | 缩小时间范围 |
| 内存高 | OOM 风险 | 序列基数高 | 增加内存或降低基数 |
| 磁盘 IO 高 | 写入延迟增加 | 磁盘性能不足 | 使用 SSD |
| 慢查询 | 查询耗时 > 10s | 复杂 PromQL | 使用记录规则 |
优化 checklist:
1. 内存优化
-memory.allowedBytes = 物理内存的 60%
-storage.cacheSize = 内存的 25%
2. 磁盘优化
使用 NVMe SSD
独立数据盘 (非系统盘)
监控 IO 延迟
3. PromQL 优化
使用精确标签匹配(= 而非 =~)
缩小查询时间范围
使用记录规则预计算
4. 基数控制
监控 `vm_tsdb_series_count`
设置 relabel 丢弃高基数标签
定期审查指标标签
配置模板:
# 8 核 32GB 内存服务器推荐配置
./victoria-metrics \
-memory.allowedBytes=20GB \
-storage.cacheSize=5GB \
-maxConcurrentInserts=50 \
-search.maxConcurrentRequests=30 \
-search.maxQueryDuration=30s \
-retentionPeriod=30d \
-storageDataPath=/data/vm
29 VictoriaMetrics 的 Grafana Dashboard 集成和推荐面板是什么?
答案:
VictoriaMetrics 提供官方 Grafana Dashboard,全面展示 VictoriaMetrics 运行状态。
官方 Dashboard:
| Dashboard ID | 名称 | 用途 |
|---|---|---|
| 10229 | VictoriaMetrics | 单节点 VMS 监控 |
| 11176 | VictoriaMetrics Cluster | 组件状态监控 |
| 14980 | VMCluster by operator | VM Operator 部署监控 |
| 16611 | VM Agent | VMAgent 采集状态 |
| 17727 | VM Alert | VMAlert 规则评估 |
关键监控面板:
VictoriaMetrics Dashboard 核心指标:
1. 写入性能
- 插入速率 (rows/s)
- 写入延迟 (P50/P99)
- 写入错误
2. 存储
- 时间序列总数
- 磁盘使用率
- 压缩比
3. 查询性能
- QPS
- 查询延迟 (P50/P99)
- 并发查询数
4. 系统资源
- CPU 使用率
- 内存使用
- 磁盘 IO
- 网络 IO
Grafana 数据源配置:
datasources:
- name: VictoriaMetrics
type: prometheus
url: http://vmselect:8481/select/0:0/prometheus
access: proxy
jsonData:
timeInterval: "30s"
prometheusType: "VictoriaMetrics"
prometheusVersion: "1.80.0"
30 VictoriaMetrics 的版本升级策略和注意事项是什么?
答案:
VictoriaMetrics 遵循语义化版本,升级策略根据部署模式不同有所差异。
版本号规范:
v1.95.0
│ │ └─ 补丁版本(bug 修复、小改进)
│ └──── 次要版本(新功能、向后兼容)
└─────── 主版本(重大变更)
单节点 VMS 和集群版本保持一致:
v1.95.0 表示单节点和集群组件的相同版本
升级流程:
# 单节点升级
1. 备份数据快照
curl -X POST http://localhost:8428/snapshot/create
2. 确认快照成功
3. 停止 VMS 进程
4. 替换二进制文件
5. 启动新版本
6. 验证数据完整性
# 集群升级(滚动)
步骤 1: 升级 vmstorage(先升级存储)
vmstorage-1: 停止 → 替换 → 启动 → 验证
vmstorage-2: 停止 → 替换 → 启动 → 验证
vmstorage-3: 停止 → 替换 → 启动 → 验证
步骤 2: 升级 vminsert(写入层)
vminsert-1: 停止 → 替换 → 启动 → 验证
vminsert-2: 停止 → 替换 → 启动 → 验证
步骤 3: 升级 vmselect(查询层)
vmselect-1: 停止 → 替换 → 启动 → 验证
vmselect-2: 停止 → 替换 → 启动 → 验证
升级注意事项:
1. 版本兼容性
- 避免跨大版本升级(如 v1.80 → v1.95)
- 如需要跨大版本,逐步升级
2. 数据格式兼容性
- vmstorage 数据格式跨版本兼容
- 无需数据迁移
3. 配置兼容性
- 检查弃用的命令行参数
- 查看 Release Notes
4. 集群升级顺序
- 先存储,再写入,最后查询
- vmstorage 升级可能导致临时查询延迟
5. 回滚
- 保留旧版本二进制
- 保留数据备份快照
- 集群模式下只需回滚对应组件