1. VictoriaMetrics时序数据清理实战指南刚接触VictoriaMetrics时我曾被突增的磁盘占用吓到——某个凌晨3点监控系统突然报警原来是一个标签值异常导致生成了数百万条时间序列。这种场景下单纯的停止数据采集根本不够必须彻底清理异常数据。下面分享我总结的完整操作方案。VictoriaMetrics的删除API设计得非常直观基本格式为http://vmselect:8481/delete/accountID/prometheus/api/v1/admin/tsdb/delete_series?match[]timeseries_selector_for_delete实际操作时有个容易踩的坑直接复制文档中的地址会导致端口错误。真实环境中vmselect默认使用8481端口而文档示例经常写成8428。我第一次操作时就因为这个问题折腾了半小时直到用netstat检查端口才发现问题。典型删除命令示例curl http://vm-cluster:8481/delete/0/prometheus/api/v1/admin/tsdb/delete_series?match[]node_cpu_seconds_total{modesteal}这个命令会删除所有带modesteal标签的node_cpu_seconds_total指标。注意要先用http://vmselect:8481/select/0/prometheus/api/v1/series?match[]selector确认匹配的序列数量避免误删。2. 异常数据处理全流程2.1 识别问题指标去年我们遇到一个经典案例某服务将HTTP路径直接作为标签值结果因为路径参数不同生成了上百万条序列。通过以下方法快速定位问题# 查看序列数量增长趋势 curl -s http://vmselect:8481/select/0/prometheus/api/v1/series?match[]{__name__~.} | jq .data | length # 按标签统计序列分布 curl -s http://vmselect:8481/select/0/prometheus/api/v1/labels | jq .data[] | while read label; do count$(curl -s http://vmselect:8481/select/0/prometheus/api/v1/series?match[]{$label~.} | jq .data | length) echo $label: $count done2.2 安全删除策略直接全量删除可能引发查询中断。我们的最佳实践是分批次操作# 第一阶段标记异常数据 curl -XPUT http://vminsert:8480/insert/0/prometheus/api/v1/admin/tsdb/series_control \ -d {action:mark_deleted,selectors:[{path~\/api/.*\}]} # 第二阶段验证业务影响 curl http://vmselect:8481/select/0/prometheus/api/v1/query?querycount_over_time({path~\/api/.*\}[1h]) # 第三阶段正式删除 curl -XPOST http://vmstorage:8482/internal/delete_series \ -d {selector: {path~\/api/.*\}}3. 磁盘空间深度优化3.1 强制合并实战删除数据后如果不执行合并磁盘空间不会立即释放。我们团队曾因此浪费了40%的存储空间。强制合并的正确姿势# 查看现有分区 ls -lh /var/lib/victoria-metrics/data/0/small/ # 合并特定月份分区 curl http://vmstorage:8482/internal/force_merge?partition_prefix2024_08关键细节必须在vmstorage节点执行分区格式必须是YYYY_MM大集群建议逐个节点操作3.2 自动化维护方案我们开发了定期维护脚本包含这些核心功能#!/bin/bash # 自动识别3个月前的冷数据分区 OLD_PARTITIONS$(find /var/lib/victoria-metrics/data -name 202* | sort | head -n -3) for part in $OLD_PARTITIONS; do # 提取分区名 prefix$(basename $part | cut -d_ -f1-2) # 执行合并 curl -s http://localhost:8482/internal/force_merge?partition_prefix$prefix # 验证空间释放 df -h /var/lib/victoria-metrics done4. 高级调优技巧4.1 预防性配置在vmstorage的启动参数中加入这些配置可以预防大部分问题-retentionPeriod12个月 -storageDataPath/data/vm/storage -snapshotAuthKeyyour_secure_key -search.maxUniqueTimeseries10000004.2 性能监控方案我们部署的监控看板包含这些关键指标# 序列增长趋势 rate(vm_new_timeseries_created_total[5m]) # 删除操作统计 sum by(instance) (vm_deleted_series_total) # 合并性能监控 histogram_quantile(0.9, sum by(le) (rate(vm_force_merge_duration_seconds_bucket[5m])))把这些PromQL配置到Grafana配合适当的告警阈值可以提前发现80%的潜在问题。
VictoriaMetrics 时序数据清理与优化实践
发布时间:2026/7/17 7:41:07
1. VictoriaMetrics时序数据清理实战指南刚接触VictoriaMetrics时我曾被突增的磁盘占用吓到——某个凌晨3点监控系统突然报警原来是一个标签值异常导致生成了数百万条时间序列。这种场景下单纯的停止数据采集根本不够必须彻底清理异常数据。下面分享我总结的完整操作方案。VictoriaMetrics的删除API设计得非常直观基本格式为http://vmselect:8481/delete/accountID/prometheus/api/v1/admin/tsdb/delete_series?match[]timeseries_selector_for_delete实际操作时有个容易踩的坑直接复制文档中的地址会导致端口错误。真实环境中vmselect默认使用8481端口而文档示例经常写成8428。我第一次操作时就因为这个问题折腾了半小时直到用netstat检查端口才发现问题。典型删除命令示例curl http://vm-cluster:8481/delete/0/prometheus/api/v1/admin/tsdb/delete_series?match[]node_cpu_seconds_total{modesteal}这个命令会删除所有带modesteal标签的node_cpu_seconds_total指标。注意要先用http://vmselect:8481/select/0/prometheus/api/v1/series?match[]selector确认匹配的序列数量避免误删。2. 异常数据处理全流程2.1 识别问题指标去年我们遇到一个经典案例某服务将HTTP路径直接作为标签值结果因为路径参数不同生成了上百万条序列。通过以下方法快速定位问题# 查看序列数量增长趋势 curl -s http://vmselect:8481/select/0/prometheus/api/v1/series?match[]{__name__~.} | jq .data | length # 按标签统计序列分布 curl -s http://vmselect:8481/select/0/prometheus/api/v1/labels | jq .data[] | while read label; do count$(curl -s http://vmselect:8481/select/0/prometheus/api/v1/series?match[]{$label~.} | jq .data | length) echo $label: $count done2.2 安全删除策略直接全量删除可能引发查询中断。我们的最佳实践是分批次操作# 第一阶段标记异常数据 curl -XPUT http://vminsert:8480/insert/0/prometheus/api/v1/admin/tsdb/series_control \ -d {action:mark_deleted,selectors:[{path~\/api/.*\}]} # 第二阶段验证业务影响 curl http://vmselect:8481/select/0/prometheus/api/v1/query?querycount_over_time({path~\/api/.*\}[1h]) # 第三阶段正式删除 curl -XPOST http://vmstorage:8482/internal/delete_series \ -d {selector: {path~\/api/.*\}}3. 磁盘空间深度优化3.1 强制合并实战删除数据后如果不执行合并磁盘空间不会立即释放。我们团队曾因此浪费了40%的存储空间。强制合并的正确姿势# 查看现有分区 ls -lh /var/lib/victoria-metrics/data/0/small/ # 合并特定月份分区 curl http://vmstorage:8482/internal/force_merge?partition_prefix2024_08关键细节必须在vmstorage节点执行分区格式必须是YYYY_MM大集群建议逐个节点操作3.2 自动化维护方案我们开发了定期维护脚本包含这些核心功能#!/bin/bash # 自动识别3个月前的冷数据分区 OLD_PARTITIONS$(find /var/lib/victoria-metrics/data -name 202* | sort | head -n -3) for part in $OLD_PARTITIONS; do # 提取分区名 prefix$(basename $part | cut -d_ -f1-2) # 执行合并 curl -s http://localhost:8482/internal/force_merge?partition_prefix$prefix # 验证空间释放 df -h /var/lib/victoria-metrics done4. 高级调优技巧4.1 预防性配置在vmstorage的启动参数中加入这些配置可以预防大部分问题-retentionPeriod12个月 -storageDataPath/data/vm/storage -snapshotAuthKeyyour_secure_key -search.maxUniqueTimeseries10000004.2 性能监控方案我们部署的监控看板包含这些关键指标# 序列增长趋势 rate(vm_new_timeseries_created_total[5m]) # 删除操作统计 sum by(instance) (vm_deleted_series_total) # 合并性能监控 histogram_quantile(0.9, sum by(le) (rate(vm_force_merge_duration_seconds_bucket[5m])))把这些PromQL配置到Grafana配合适当的告警阈值可以提前发现80%的潜在问题。