强曰为道

与天地相似,故不违。知周乎万物,而道济天下,故不过。旁行而不流,乐天知命,故不忧.
文档目录

16 - 最佳实践

16 · 最佳实践

本章目标

  • 掌握容量规划的方法论
  • 建立生产环境的标准化规范
  • 了解不同规模场景的最佳架构
  • 学会持续优化监控系统

16.1 容量规划

16.1.1 容量规划流程

┌────────────────────────────────────────────────────┐
│              容量规划流程                            │
│                                                    │
│  1. 评估需求                                       │
│     ├── 活跃时间序列数                              │
│     ├── 采集间隔                                   │
│     ├── 数据保留期                                  │
│     └── 查询并发量                                  │
│                                                    │
│  2. 计算资源                                       │
│     ├── 磁盘空间 = 序列 × 样本大小 × 天数           │
│     ├── 内存 ≈ 序列 × 1KB                          │
│     └── CPU = 写入核 + 查询核                       │
│                                                    │
│  3. 选择架构                                       │
│     ├── < 100 万序列 → 单节点                       │
│     ├── 100 万 - 1000 万 → 单节点(高配)或集群     │
│     └── > 1000 万 → 集群版                         │
│                                                    │
│  4. 部署验证                                       │
│     ├── 基准测试                                   │
│     ├── 压力测试                                   │
│     └── 监控告警                                   │
└────────────────────────────────────────────────────┘

16.1.2 磁盘空间计算

磁盘空间 = 活跃序列数 × 每样本字节数 × 每天样本数 × 保留天数 × 压缩系数

示例:
  活跃序列 = 500 万
  每样本字节 = 0.2 bytes (VM 平均压缩后)
  每天样本数 = 86400 / 15 = 5760
  保留天数 = 90
  压缩系数 = 1.3 (索引 + 开销)

  磁盘空间 = 5,000,000 × 0.2 × 5760 × 90 × 1.3 / 1,000,000,000
           ≈ 67.4 GB

16.1.3 不同规模资源配置参考

规模活跃序列采集间隔保留期配置方案月成本估算
小型< 50 万30s30 天单节点 2C/4G, 50GB~¥200
中型50-500 万15s90 天单节点 8C/16G, 500GB~¥800
大型500-2000 万15s180 天集群版 6 节点~¥5,000
超大型> 2000 万10-15s1 年+集群版 15+ 节点~¥20,000

16.1.4 网络带宽规划

写入带宽 = 活跃序列 × (metric_name + labels + timestamp + value) / 采集间隔

示例:
  序列数 = 100 万
  平均每序列 payload = 200 bytes
  采集间隔 = 15s

  写入带宽 = 1,000,000 × 200 / 15 = 13.3 MB/s ≈ 107 Mbps

16.2 生产环境规范

16.2.1 部署规范

规范项推荐配置
操作系统Ubuntu 22.04 LTS / Debian 12
文件系统XFS 或 ext4,noatime 挂载
磁盘类型SSD (NVMe 最佳)
内存60-70% 分配给 VM
绑定地址127.0.0.1:8428(通过反向代理暴露)
systemd使用 cgroup 限制资源
日志JSON 格式,集中收集

16.2.2 systemd 服务文件模板

# /etc/systemd/system/victoria-metrics.service
[Unit]
Description=VictoriaMetrics Time Series Database
Documentation=https://docs.victoriametrics.com/
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=victoriametrics
Group=victoriametrics
WorkingDirectory=/var/lib/victoria-metrics

ExecStart=/usr/local/bin/victoria-metrics \
    -storageDataPath=/var/lib/victoria-metrics/data \
    -httpListenAddr=127.0.0.1:8428 \
    -retentionPeriod=90d \
    -memory.allowedPercent=60 \
    -dedup.minScrapeInterval=15s \
    -loggerLevel=INFO \
    -loggerFormat=json \
    -envflag.enable=true \
    -envflag.prefix=VM_

ExecStop=/bin/kill -SIGTERM $MAINPID
Restart=on-failure
RestartSec=10
TimeoutStopSec=30

# 资源限制
LimitNOFILE=65536
LimitNPROC=32768

# cgroup v2 资源限制
CPUQuota=200%
MemoryMax=16G
MemoryHigh=14G

# 安全加固
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/victoria-metrics /var/log/victoria-metrics

[Install]
WantedBy=multi-user.target

16.2.3 监控规范

# 必须监控的指标
alerting_rules:
  - vm_health:
      - InstanceDown        # 服务存活
      - TooHighMemoryUsage  # 内存使用率
      - DiskRunningOut      # 磁盘空间
      - TooHighActiveSeries # 活跃序列数
      - TooSlowQueries      # 查询延迟
      - TooManySlowInserts  # 写入延迟
      - TooManyErrors       # 错误率

  - infrastructure:
      - CPU > 80%          # CPU 使用率
      - 内存 > 85%         # 内存使用率
      - 磁盘 > 80%         # 磁盘使用率
      - fd > 50000         # 文件描述符数

16.2.4 备份规范

频率保留内容
每日7 天全量数据备份
每周4 周全量数据备份(独立存储)
每月12 个月归档备份(冷存储)

16.3 标签设计最佳实践

16.3.1 标签命名规范

# 标签命名规范
naming_convention:
  - 全小写,使用下划线分隔    # ✅ host_name / ❌ HostName
  - 语义清晰                  # ✅ region / ❌ r
  - 避免高基数                # ❌ user_id / ✅ user_bucket
  - 避免动态值                # ❌ request_id / ✅ request_path
  - 统一命名                  # ✅ job / ❌ service_name vs app

16.3.2 常见标签及其推荐值

标签推荐值基数说明
job“api-server”, “web”应用名
instance“host:port”实例地址
env“prod”, “staging”, “dev”极低环境
region“cn-north”, “us-east”极低地域
host“web01”, “db02”主机名
status“200”, “404”, “500”状态码
method“GET”, “POST”极低HTTP 方法
path“/api/users”请求路径

16.3.3 避免高基数标签

# ❌ 避免:高基数标签
http_requests_total{user_id="12345678"}  # 用户数可能几百万

# ✅ 正确:使用分桶或其他聚合方式
http_requests_total{user_bucket="12xx"}  # 只保留前 2 位
# 或
http_requests_total{endpoint="/api/users", status="200"}
# 用户维度放在日志/链路中,不在指标中

16.4 查询优化最佳实践

16.4.1 常见查询优化模式

# ❌ 不推荐:全量扫描
rate(http_requests_total[5m])

# ✅ 推荐:精确过滤
rate(http_requests_total{job="api-server", env="prod"}[5m])

# ❌ 不推荐:大时间窗口
avg_over_time(cpu_usage[7d])

# ✅ 推荐:使用 Recording Rule 预计算
# 预计算规则:
# record: job:cpu_usage:avg_7d
# expr: avg by (job) (avg_over_time(cpu_usage[7d]))
# 查询时:
job:cpu_usage:avg_7d

# ❌ 不推荐:嵌套聚合
topk(10, sum by (host) (rate(http_requests_total[5m])))

# ✅ 推荐:使用 Recording Rule 分步计算
# 步骤 1: 录制中间结果
# record: host:http_requests:rate5m
# expr: sum by (host) (rate(http_requests_total[5m]))
# 步骤 2: 查询
topk(10, host:http_requests:rate5m)

16.4.2 Grafana 仪表盘优化

dashboard_best_practices:
  - 使用变量(Variables):
    - $job: 允许用户选择 job
    - $host: 允许用户选择 host
    - $interval: 允许用户选择聚合间隔

  - 时间范围对齐:
    - 使用 $__rate_interval 代替固定 [5m]
    - 保证 rate() 的时间窗口 ≥ 2 × scrape_interval

  - 减少面板数据量:
    - 限制每个面板的最大序列数
    - 使用 topk/bottomk 限制显示数量
    - 使用 Recording Rule 预计算复杂表达式

16.4.3 Recording Rule 命名规范

命名格式:level:metric_name:aggregation

示例:
  job:http_request_duration_seconds:p99    # 按 job 聚合的 P99 延迟
  host:http_requests:rate5m               # 按 host 聚合的 5m 请求速率
  cluster:cpu_usage:avg                   # 按集群聚合的平均 CPU 使用率
  job:http_errors:ratio5m                 # 按 job 聚合的 5m 错误率

16.5 高可用架构最佳实践

16.5.1 架构选型决策树

你的数据规模和可用性要求?

├── 数据量 < 100 万序列,可用性要求一般
│   └── 单节点版 + 定期备份
│       ├── 简单部署
│       ├── 最低成本
│       └── 适合开发/测试/小规模生产
│
├── 数据量 100 万 - 1000 万,可用性要求高
│   └── 集群版 + 副本因子 2
│       ├── vminsert × 2
│       ├── vmselect × 2
│       ├── vmstorage × 3 (副本 2)
│       └── 适合中大规模生产
│
└── 数据量 > 1000 万,极高可用性要求
    └── 集群版 + 副本因子 3 + 多可用区
        ├── vminsert × 3+
        ├── vmselect × 3+
        ├── vmstorage × 5+ (副本 3)
        ├── 多可用区部署
        └── 适合大型企业生产

16.5.2 集群高可用配置

# vminsert HA 配置
vminsert \
    -storageNode=vmstorage1:8400,vmstorage2:8400,vmstorage3:8400 \
    -replicationFactor=2 \
    -dedup.minScrapeInterval=15s

# vmselect HA 配置
vmselect \
    -storageNode=vmstorage1:8401,vmstorage2:8401,vmstorage3:8401 \
    -dedup.minScrapeInterval=15s \
    -search.maxConcurrentRequests=16 \
    -cacheDataPath=/var/lib/vmselect/cache

16.5.3 多可用区部署

可用区 A                          可用区 B
┌──────────────┐                ┌──────────────┐
│ vminsert-1   │                │ vminsert-2   │
│ vmselect-1   │                │ vmselect-2   │
│ vmstorage-1  │◀──复制──▶│ vmstorage-2  │
│ vmstorage-3  │                │ vmstorage-4  │
└──────────────┘                └──────────────┘

每个可用区至少 2 个 vmstorage 节点
副本因子 = 2,确保每个副本在不同可用区

16.6 安全最佳实践

16.6.1 安全清单

#项目推荐配置
1绑定地址127.0.0.1:8428
2反向代理Nginx + TLS + Basic Auth
3防火墙只开放必要端口
4认证vmauth 或 Nginx Basic Auth
5TLS生产环境必须启用
6最小权限只读用户 / 写入用户分离
7定期审计检查访问日志
8版本更新定期升级到最新稳定版

16.6.2 网络安全配置

# Nginx 反向代理 + TLS + 认证
server {
    listen 443 ssl http2;
    server_name vm.example.com;

    ssl_certificate /etc/ssl/vm.crt;
    ssl_certificate_key /etc/ssl/vm.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    # 写入端点 - 只允许内部 IP
    location /api/v1/write {
        allow 10.0.0.0/8;
        allow 172.16.0.0/12;
        deny all;
        proxy_pass http://127.0.0.1:8428;
    }

    # 查询端点 - Basic 认证
    location /api/v1/query {
        auth_basic "VictoriaMetrics";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:8428;
    }

    # VMUI - Basic 认证
    location /vmui/ {
        auth_basic "VictoriaMetrics";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:8428;
    }
}

16.7 持续优化

16.7.1 定期审查项目

频率审查内容工具/命令
每周活跃序列数趋势vm_active_timeseries
每周磁盘使用趋势vm_free_disk_space_bytes
每周查询性能Top Queries 页面
每月标签基数/api/v1/status/tsdb
每月慢查询分析vm_slow_queries_total
每月资源使用率Grafana 仪表盘
每季度容量规划序列增长趋势分析
每季度保留策略按业务需求调整
每半年版本升级评估新版本功能

16.7.2 成本优化

成本优化路径:

1. 数据压缩(已内置)
   └── VM 比 Prometheus 节省 7-10 倍存储成本

2. 降采样
   └── 老数据降低精度,减少存储

3. 按需保留
   └── 不同数据类型不同保留期

4. 标签优化
   └── 减少高基数标签,降低序列数

5. 采集频率优化
   └── 非关键指标 30s-60s 间隔

6. 架构优化
   └── 使用 vmagent 流式聚合

16.7.3 版本升级策略

版本升级流程:

1. 评估
   ├── 阅读 Release Notes
   ├── 检查 Breaking Changes
   └── 在测试环境验证

2. 备份
   ├── 创建数据快照
   └── 备份配置文件

3. 升级
   ├── 单节点:停止服务 → 替换二进制 → 启动
   └── 集群版:滚动升级(vmstorage → vminsert → vmselect)

4. 验证
   ├── 健康检查通过
   ├── 查询返回正常
   └── 写入速率正常

5. 监控
   ├── 升级后 24 小时密切监控
   └── 关注内存和 CPU 变化

16.8 生产部署检查清单

16.8.1 上线前检查

#检查项通过标准
1版本选择使用最新稳定版
2资源配置CPU/内存/磁盘按规划分配
3存储类型SSD (NVMe)
4文件系统XFS/ext4, noatime
5fd 限制>= 65536
6数据目录独立分区,权限正确
7日志配置JSON 格式,集中收集
8认证配置vmauth/Nginx 已配置
9TLS已启用
10备份自动化备份已配置
11监控自我监控 + 告警规则已配置
12高可用副本因子 >= 2 (集群版)
13采集配置vmagent/Prometheus 已配置
14查询限制maxConcurrentRequests 已设置
15灾难恢复恢复流程已演练

16.8.2 上线后监控

指标告警阈值说明
服务存活up == 0 持续 1m服务宕机
内存使用率> 85% 持续 5m可能 OOM
磁盘使用率> 80%需要扩容或清理
CPU 使用率> 80% 持续 15m需要优化或扩容
查询延迟 P99> 10s需要优化查询
写入延迟vm_slow_inserts > 0检查磁盘 I/O
活跃序列数趋势性增长容量规划
缓存命中率< 70%检查缓存配置

16.9 总结

VictoriaMetrics 核心价值

维度价值
成本存储成本降低 7-10 倍
性能查询速度快 10-100 倍
运维单二进制,无需外部依赖
兼容完全兼容 Prometheus 生态
扩展原生集群支持,水平扩展

关键成功因素

成功的 VM 部署 = 合理的容量规划
               + 正确的架构选型
               + 规范的标签设计
               + 完善的监控告警
               + 定期的优化审查

扩展阅读