在监控、可观测性领域，指标的数量与日俱增，各类中间件的指标相对固定，但是很多业务方有时会上报很多稀奇古怪的指标，也不管有用没用反正就是上报了，而且有时是偶发性流量暴增，比如业务方为了做测试，部署了一套新环境之类的。作为平台存储侧，VictoriaMetrics 在突发大流量下如何自保，就非常重要了。本文梳理一下其中一些关键点，供各位参考。
核心摘要
- VictoriaMetrics 自保的第一步不是调参数，而是提前和业务约定指标上报边界，尤其是测试环境、临时环境和突发压测场景。
- 指标量较大时，按业务拆分多套 VictoriaMetrics 可以控制故障半径，避免一个业务的高基数或突发流量拖垮全局存储。
- 单机版和集群版的选择要看数据量、硬件、可靠性和运维复杂度。小集群不一定比高配单机更有性能优势。
- 生产 VictoriaMetrics 的自监控数据建议单独存储，避免主库异常时连自身监控也一起不可用。
- 高基数和高流失率是自保重点，
storage.maxHourlySeries、dedup.minScrapeInterval等参数可以作为防线，但不能替代指标治理。
1. 和业务做好沟通
问题本身不好解决，如果能绕过去是最好的。我们要和业务方做好沟通，偶发性的大量指标上报需要提前告知我们，尤其是偶尔搭建一套测试环境，部署几百个微服务，这些微服务吭哧一下上报巨量新指标。
对于时序数据的存储而言，短期上报很多新指标是非常要命的，容易对现有存储造成压力，而且这些指标是新环境测试所用，此时就建议单独搭建一套 VictoriaMetrics 给测试场景专属使用，隔离爆炸半径。当然了，有时不好沟通，有时沟通了又忘了，还是要从自身做好一些自保措施。
这里的关键不是“让业务少上报指标”这么简单，而是把指标上报当作生产资源使用来管理：谁会上报、上报多少、标签里能不能放 requestid、userid、ip，临时环境是否要接入生产时序库，都应该提前约定。
2. VictoriaMetrics 按业务拆分
如果整体指标量不大，比如每秒接收的数据点小于 5 万，就一台单机的 VictoriaMetrics 就可以搞定了，谈不上业务拆分。如果指标量比较大，比如每秒上报 500 万，拆成多套 VictoriaMetrics 控制故障半径是非常有必要的。
每秒接收的数据点 5 万是个什么概念呢？操作系统层面的 CPU、内存等常规指标只有 200 个左右，如果只是机器监控，采集频率设置为 15s 的话，每秒 5 万个指标量相当于同时监控 3750 台机器，算法如下：
50000 / (200 / 15) = 3750
如果你的采集频率不是 15s，是 60s，那么每秒 5 万个指标量相当于同时监控 15000 台机器。
实际上，每秒 5万 指标远非 VictoriaMetrics 的极限，我们看一个 VictoriaMetrics 官网给出的用户生产数据：
Here are some numbers from our single-node VictoriaMetrics setup:
active time series: 10M
ingestion rate: 800K samples/sec
total number of datapoints: more than 2 trillion
total number of entries in inverted index: more than 1 billion
daily time series churn rate: 2.6M
data size on disk: 1.5 TB
index size on disk: 27 GB
average datapoint size on disk: 0.75 bytes
range query rate: 16 rps
instant query rate: 25 rps
range query duration: max: 0.5s; median: 0.05s; 97th percentile: 0.29s
instant query duration: max: 2.1s; median: 0.04s; 97th percentile: 0.15s
VictoriaMetrics consumes about 50GB of RAM.
这个用户说，每秒指标量是 80万，活跃指标 1000万，采用的单机 VictoriaMetrics，消耗了 50GB 内存，如果你也是单机 VictoriaMetrics，可以参考这个数据（注意留出偶尔的突发流量、突发查询等）。
这个例子的价值不是证明“单机一定够用”，而是提醒大家不要只看平均写入量。活跃时间序列、日流失率、查询请求、磁盘和索引大小、内存占用都要一起看。
3. VictoriaMetrics 集群 or 单机
就像上面的数据，如果你的指标量每秒小于 80万，有一台高配机器（比如128C256G），那可以用单机版，对于绝大部分用户来说，单机版的 VictoriaMetrics 是足够的。
你可能担心，单机版如何保证数据可靠性？建议从存储介质上着手，比如采用云盘，由云厂商来保障底层数据可靠性。
如果你没有云盘，又想保证数据可靠性，就要用 VictoriaMetrics 集群版了，集群版可以配置副本数，保证数据的可靠性。但是要注意，小集群的性能不如单机版。
比如你搞了 3 台机器，设置副本数为 2，从数据可靠性上来看，确实比单机可靠，但从性能上来看，也就相当于一台单机版。千万不要觉得有 3 台机器其性能就是单机版的 3 倍。为啥呢？因为单机版是单副本，集群版是 2 副本，而且集群版要引入 vmselect、vminsert 等额外的组件进程，组件之间有大量的网络通信，性能上是有损耗的。
VictoriaMetrics 官方建议：集群版也采用单副本的方式，数据可靠性由底层的存储介质来保障，而非采用 VictoriaMetrics 的副本机制。
可以这样理解：单机版适合用更简单的架构吃下足够大的规模，集群版适合在容量、租户隔离或可靠性需求明确时使用。不要因为“集群”两个字天然觉得它一定更快、更省心。
4. 应该重点关注哪些指标
首先，是机器的 CPU、内存、磁盘 IO 等指标，这些指标是最基础的，任何时候都要关注。
其次，是 VictoriaMetrics 自身的指标，VictoriaMetrics 官方提供了仪表盘：
- 官方提供的单机版：https://grafana.com/grafana/dashboards/10229
- 官方提供的集群版：https://grafana.com/grafana/dashboards/11176
- 社区提供的集群版：https://grafana.com/grafana/dashboards/11831
尤其要关注 VictoriaMetrics 自身进程的 CPU、内存占用情况，以及慢写入、短期新增指标量等指标。
另外 VictoriaMetrics 也给大家准备了告警规则，记得配置上：
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/master/deployment/docker/rules
另外最近我攒了一个开源项目，想整理一下常见的各类组件的告警规则并翻译为中文且增加更多注释，感兴趣的小伙伴可以一起参与：
自保类监控最好覆盖三层：机器资源层，VictoriaMetrics 进程层，指标质量层。前两层告诉你系统是不是扛得住，第三层告诉你是谁在制造高基数、高流失率或异常新增指标。
5. VictoriaMetrics 监控数据单独存储
监控系统自身的监控指标，建议单独存储，比如你可以搞一个小的 Prometheus 或 VictoriaMetrics 单机版来监控生产用的 VictoriaMetrics，这样即便生产的时序库出问题，也不影响自身的监控指标。
另外，因为自监控的指标量相对较小，可以把采集频率调大一些，这样可以拿到更多细节。
这条实践很重要：监控系统出问题时，最需要看的就是监控系统自己的状态。如果这些数据也存放在同一个已经异常的 VictoriaMetrics 里，排障会变得很被动。
6. VMUI Explore
VictoriaMetrics 提供了一个简易的 UI 界面，除了可以查询监控数据，还可以分析高基数指标和重查询等问题：
VMUI Explore 适合用于临时分析：哪些指标最容易造成高基数，哪些查询比较重，哪些标签值异常膨胀。它不能替代长期治理机制，但在定位问题指标时很方便。
7. 如何丢弃一些指标自保
VictoriaMetrics 有个布隆过滤器实现的高基数指标丢弃机制，帮助我们丢弃一些高基数的指标，避免内存占用过高。
-storage.maxHourlySeries int
The maximum number of unique series can be added to the storage during the last hour. Excess series are logged and dropped. This can be useful for limiting series cardinality. See https://docs.victoriametrics.com/#cardinality-limiter . See also -storage.maxDailySeries
监控指标正常来讲是周期性上报的，VictoriaMetrics 这类存储最怕的是高基数、高流失率的指标，高基数业内谈的较多大家都清楚，就是某些标签的 value 特别多导致大量 time series，比如把 requestid、userid、ip 这类信息放到标签中，大概率会导致高基数。高流失率是指某些指标的上报频率不稳定，比如有些指标是偶尔上报的，或者有些指标是突发性上报的，上报一次就再也不报了，这类指标会导致存储压力增大。
storage.maxHourlySeries 可以解决短时间上报很多新指标的问题。建议配置上，可以通过 promql：count({__name__=~".+"}) 查询当前 unique series 的数量，然后乘以 2，设置 storage.maxHourlySeries 的值。
-dedup.minScrapeInterval duration
Leave only the last sample in every time series per each discrete interval equal to -dedup.minScrapeInterval > 0. See https://docs.victoriametrics.com/#deduplication and https://docs.victoriametrics.com/#downsampling
dedup.minScrapeInterval 是一个去重的配置项，默认是 0，表示不去重。这个配置项可以帮助我们丢弃一些重复的指标，比如同一个指标在同一时间点上报了多次，这个配置项可以帮助我们只保留一个值。多用于 HA 采集器的场景。
如果平时指标上报频率是 15s，这个值就可以设置为 15，如果指标采集频率是 15s，但是故意把这个配置项设置为 60s，那么就变相把指标采集频率变成了 60s，这样可以减少存储压力。
这两个参数的定位不同：storage.maxHourlySeries 是限制短时间新增 series 的防线，dedup.minScrapeInterval 是处理重复样本的防线。前者更适合应对突发新指标，后者更适合 HA 采集器或重复上报场景。
常见问题
VictoriaMetrics 自保应该先从参数开始吗？
不应该。参数是最后的防线。更靠前的工作是业务沟通、测试环境隔离、按业务拆分、指标命名和标签规范、自监控数据独立存储。
高基数和高流失率有什么区别？
高基数通常指某些标签的 value 特别多，导致 time series 数量爆炸；高流失率指某些时间序列短时间出现、很快消失，或者偶发上报一次后不再上报。两者都会增加存储和索引压力。
小集群一定比单机版更可靠吗？
不一定。集群可以通过副本数提高数据可靠性，但副本会消耗更多 CPU、内存、磁盘和网络资源。原文强调，小集群的性能不如单机版，数据可靠性优先考虑底层存储介质保障。
总结
VictoriaMetrics 面对突发指标暴增时，自保不是某一个参数能解决的问题。更有效的路径是：先管理指标入口和业务边界，再通过业务拆分控制故障半径；生产库和自监控库分开；用官方仪表盘、告警规则和 VMUI Explore 观察资源与高基数问题；最后再用 storage.maxHourlySeries、dedup.minScrapeInterval 等参数做兜底。这样才能在突发流量下尽量保持系统稳定。
临时就想到这么多，如有说的不对或遗漏，欢迎大家留言补充共同进步哈。监控、可观测性整套体系是比较复杂的，而且即便搭建了一些零零散散的指标、日志、链路追踪的系统，故障定位速度也不尽如人意，如果你也有类似的困扰，欢迎联系我们交流经验思路，我们很乐意作为乙方帮您一起建设整套体系 👇
