监控指标太多，VictoriaMetrics 如何自保？

在监控、可观测性领域，指标的数量与日俱增，各类中间件的指标相对固定，但是很多业务方有时会上报很多稀奇古怪的指标，也不管有用没用反正就是上报了，而且有时是偶发性流量暴增，比如业务方为了做测试，部署了一套新环境之类的。作为平台存储侧，VictoriaMetrics 在突发大流量下如何自保，就非常重要了。本文梳理一下其中一些关键点，供各位参考。

1. 和业务做好沟通

问题本身不好解决，如果能绕过去是最好的。我们要和业务方做好沟通，偶发性的大量指标上报需要提前告知我们，尤其是偶尔搭建一套测试环境，部署几百个微服务，这些微服务吭哧一下上报巨量新指标。

对于时序数据的存储而言，短期上报很多新指标是非常要命的，容易对现有存储造成压力，而且这些指标是新环境测试所用，此时就建议单独搭建一套 VictoriaMetrics 给测试场景专属使用，隔离爆炸半径。当然了，有时不好沟通，有时沟通了又忘了，还是要从自身做好一些自保措施。

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: 10Mingestion rate: 800K samples/sectotal number of datapoints: more than 2 trilliontotal number of entries in inverted index: more than 1 billiondaily time series churn rate: 2.6Mdata size on disk: 1.5 TBindex size on disk: 27 GBaverage datapoint size on disk: 0.75 bytesrange query rate: 16 rpsinstant query rate: 25 rpsrange query duration: max: 0.5s; median: 0.05s; 97th percentile: 0.29sinstant query duration: max: 2.1s; median: 0.04s; 97th percentile: 0.15sVictoriaMetrics 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

另外最近我攒了一个开源项目，想整理一下常见的各类组件的告警规则并翻译为中文且增加更多注释，感兴趣的小伙伴可以一起参与：

https://github.com/sretalk/prometheus-rules

5. VictoriaMetrics 监控数据单独存储

监控系统自身的监控指标，建议单独存储，比如你可以搞一个小的 Prometheus 或 VictoriaMetrics 单机版来监控生产用的 VictoriaMetrics，这样即便生产的时序库出问题，也不影响自身的监控指标。

另外，因为自监控的指标量相对较小，可以把采集频率调大一些，这样可以拿到更多细节。

6. VMUI Explore

VictoriaMetrics 提供了一个简易的 UI 界面，除了可以查询监控数据，还可以分析高基数指标和重查询等问题：

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，这样可以减少存储压力。

临时就想到这么多，如有说的不对或遗漏，欢迎大家留言补充共同进步哈。监控、可观测性整套体系是比较复杂的，而且即便搭建了一些零零散散的指标、日志、链路追踪的系统，故障定位速度也不尽如人意，如果你也有类似的困扰，欢迎 联系我们 交流经验思路，我们很乐意作为乙方帮您一起建设整套体系