VictoriaMetrics 中文教程（06）容量规划

VictoriaMetrics 中文教程系列文章：

• VictoriaMetrics 中文教程（01）简介
• VictoriaMetrics 中文教程（02）安装
• VictoriaMetrics 中文教程（03）如何配置 Prometheus 使其把数据远程写入 VictoriaMetrics
• VictoriaMetrics 中文教程（04）对接 Grafana 同时介绍 vmui
• VictoriaMetrics 中文教程（05）对接各类监控数据采集器

VictoriaMetrics 容量规划

根据我们的案例研究，与竞争解决方案（Prometheus、Thanos、Cortex、TimescaleDB、InfluxDB、QuestDB、M3DB）相比，VictoriaMetrics 在生产工作负载上使用的 CPU、RAM 和存储空间更少。

VictoriaMetrics 的容量随可用资源呈线性扩展。所需的 CPU 和 RAM 数量高度依赖于工作负载 - 活动时间序列的数量、序列流失率、查询类型、查询 qps 等。建议为您的生产工作负载搭建测试 VictoriaMetrics，慢慢扩展压力以及 CPU 和 RAM 资源，直到它变得稳定。通过生产环境的部分负载测试，您可以了解 VictoriaMetrics 在您的环境中的性能和资源需求。根据我们的案例研究，单节点 VictoriaMetrics 可以完美处理以下生产工作负载：

• 采集率：每秒 150 万个样本
• 活跃时间序列：5000 多万
• 总时间序列：50 多亿
• 时间序列流失率：每天有 1.5 亿个新序列
• 样本总数：10+万亿
• 查询：200+ qps
• 查询延迟（第 99 百分位）：1 秒

可以根据测试运行中的磁盘空间使用情况推断出给定保留（通过 -retentionPeriod 命令行标志设置保留）所需的存储空间。例如，如果在生产工作负载上进行一天的测试运行后，-storageDataPath 目录大小变为 10GB，则 -retentionPeriod=100d（100 天保留期）将需要至少 10GB*100=1TB 的磁盘空间。

建议保留以下数量的备用资源：

• 50% 的可用 RAM 用于降低工作负载暂时激增期间发生 OOM（内存不足）崩溃和速度变慢的概率。
• 50% 的备用 CPU 用于降低工作负载暂时激增时出现速度变慢的概率。
• -storageDataPath 命令行标志指向的目录中至少有 20% 的可用存储空间。

VictoriaMetrics 资源限制参数

默认情况下，VictoriaMetrics 针对典型工作负载已经给出了默认配置。某些工作负载可能需要细粒度的资源使用限制。在这些情况下，以下命令行参数可能会有用：

• -memory.allowedPercent 和 -memory.allowedBytes 限制可用于 VictoriaMetrics 各种内部缓存的内存量。请注意，VictoriaMetrics 可能会使用更多内存，因为这些标志不会限制每个查询可能需要的额外内存。
• -search.maxMemoryPerQuery 限制了处理单个查询时可使用的内存量。需要更多内存的查询将被拒绝。选择大量时间序列的繁重查询可能会超出每个查询的内存限制一小部分。并发执行查询的总内存限制可以估算为 -search.maxMemoryPerQuery 乘以 -search.maxConcurrentRequests。
• -search.maxUniqueTimeseries 限制单个查询可以查找和处理的唯一时间序列的数量。默认情况下，VictoriaMetrics 会根据可用内存和它可以处理的最大并发请求数（参见 -search.maxConcurrentRequests）自动计算限制。VictoriaMetrics 会在内存中保存有关每个查询找到的时间序列的一些元信息，并花费一些 CPU 时间来处理找到的时间序列。这意味着单个查询可以使用的最大内存使用量和 CPU 使用量与 -search.maxUniqueTimeseries 成正比。
• -search.maxQueryDuration 限制单个查询的持续时间。如果查询所用时间超过给定的持续时间，则取消查询。这可以在执行意外的繁重查询时节省 CPU 和 RAM。可以通过传递超时 GET 参数来更改每个查询的限制，但不能超过通过 -search.maxQueryDuration 命令行标志指定的限制。
• -search.maxConcurrentRequests 限制 VictoriaMetrics 可以处理的并发请求数。并发请求数越多通常意味着内存使用量越大。例如，如果单个查询在执行期间需要 100 MiB 的额外内存，那么 100 个并发查询可能需要 100 * 100 MiB = 10 GiB 的额外内存。因此，最好限制并发查询数，同时在达到并发限制时暂停其他传入查询。VictoriaMetrics 提供 -search.maxQueueDuration 命令行标志来限制暂停查询的最大等待时间。另请参阅 -search.maxMemoryPerQuery 命令行标志。
• -search.maxQueueDuration 限制执行 -search.maxConcurrentRequests 并发查询时查询可能等待执行的最长持续时间。
• -search.ignoreExtraFiltersAtLabelsAPI 允许忽略 /api/v1/labels 和 /api/v1/label/…/values 处的 match[]、extra_filters[] 和 extra_label 查询参数。如果提供的额外过滤器匹配太多时间序列，这可能有助于减少 VictoriaMetrics 的负载。缺点是端点可能会返回与提供的额外过滤器不匹配的标签和序列。
• -search.maxSamplesPerSeries 限制查询可以处理的每条时间序列的原始样本数量。VictoriaMetrics 在查询期间按顺序处理每个找到的时间序列的原始样本。它将每个时间序列的选定时间范围内的原始样本解压到内存中，然后应用给定的汇总函数。-search.maxSamplesPerSeries 命令行标志允许在查询执行的时间范围内限制内存使用量，该时间范围包含每个选定的时间序列的数亿个原始样本。
• -search.maxSamplesPerQuery 限制单个查询可以处理的原始样本数量。这可以限制繁重查询的 CPU 使用率。
• -search.maxResponseSeries 限制单个查询可以从 /api/v1/query 和 /api/v1/query_range 返回的时间序列数量。
• -search.maxPointsPerTimeseries 限制范围查询中每个匹配时间序列可返回的计算点的数量。
• -search.maxPointsSubqueryPerTimeseries 限制在子查询评估期间每个匹配时间序列可以生成的计算点的数量。
• -search.maxSeriesPerAggrFunc 限制时间序列的数量，这些序列可以由 MetricsQL 聚合函数在单个查询中生成。
• -search.maxSeries 限制时间序列的数量，这些时间序列可能从 /api/v1/series 返回。此端点主要由 Grafana 用于自动完成指标名称、标签名称和标签值。当数据库包含大量唯一时间序列时，由于高流失率，对此端点的查询可能会占用大量 CPU 时间和内存。在这种情况下，将 -search.maxSeries 设置为相当低的值可能会很有用，以限制 CPU 和内存使用率。另请参阅 -search.maxLabelsAPIDuration 和 -search.maxLabelsAPISeries。
• -search.maxDeleteSeries 限制了单个 /api/v1/admin/tsdb/delete_series 调用可以删除的唯一时间序列的数量。删除太多时间序列可能需要大量 CPU 和内存，此限制可防止计划外的资源使用量激增。另请参阅如何删除时间序列部分以了解删除序列的不同方法。
• -search.maxTagKeys 限制了从 /api/v1/labels 返回的项目数量。此端点主要由 Grafana 用于自动完成标签名称。当数据库包含大量唯一时间序列时，由于高流失率，对此端点的查询可能会占用大量 CPU 时间和内存。在这种情况下，将 -search.maxTagKeys 设置为相当低的值可能会很有用，以限制 CPU 和内存使用率。另请参阅 -search.maxLabelsAPIDuration 和 -search.maxLabelsAPISeries。
• -search.maxTagValues 限制了可从 /api/v1/label/…/values 返回的项目数。此端点主要由 Grafana 用于自动完成标签值。当数据库包含大量唯一时间序列时，由于高流失率，对此端点的查询可能会占用大量 CPU 时间和内存。在这种情况下，将 -search.maxTagValues 设置为相当低的值可能会很有用，以限制 CPU 和内存使用率。另请参阅 -search.maxLabelsAPIDuration 和 -search.maxLabelsAPISeries。
• -search.maxLabelsAPISeries 限制执行 /api/v1/labels、/api/v1/label/…/values 或 /api/v1/series 请求时可以扫描的时间序列数量。这些端点主要由 Grafana 用于自动完成标签名称和标签值。当数据库包含大量唯一时间序列时，由于高流失率，对这些端点的查询可能会占用大量 CPU 时间和内存。在这种情况下，将 -search.maxLabelsAPISeries 设置为相当低的值可能会很有用，以限制 CPU 和内存使用率。另请参阅 -search.maxLabelsAPIDuration 和 -search.ignoreExtraFiltersAtLabelsAPI。
• -search.maxLabelsAPIDuration 限制对 /api/v1/labels、/api/v1/label/…/values 或 /api/v1/series 的请求持续时间。可以通过传递超时 GET 参数来更改每个查询的限制，但不能超过通过命令行标志指定的限制。这些端点主要由 Grafana 用于自动完成标签名称和标签值。当数据库包含大量唯一时间序列时，由于高流失率，对这些端点的查询可能会占用大量 CPU 时间和内存。在这种情况下，将 -search.maxLabelsAPIDuration 设置为相当低的值可能会很有用，以限制 CPU 和内存使用率。另请参阅 -search.maxLabelsAPISeries 和 -search.ignoreExtraFiltersAtLabelsAPI。
• -search.maxTagValueSuffixesPerSearch 限制从 /metrics/find 端点返回的条目数。请参阅 Graphite Metrics API 使用文档。

总结

VictoriaMetrics 是一个高性能、低资源消耗的时序数据库，可以替代 Prometheus 的存储，用于高可用和持久化。在使用 VictoriaMetrics 时，需要根据实际情况进行容量规划，以确保系统的稳定性和性能。核心思路是先运行一段时间，接入少量数据，运行一天之后就可以对全量数据做预估测算做容量规划。同时本文介绍了 VictoriaMetrics 很多应对大规模场景的参数配置，可以根据实际情况进行调整。