尧图网站建设 
VictoriaMetrics 容量规划实战指南从 Active Time Series 到磁盘空间的完整估算方法【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本文基于 VictoriaMetrics 官方容量规划指南Single-Node / Cluster / VictoriaMetrics Cloud整理成文帮助你在部署、扩容或上云前用一套可量化的方法估算监控系统所需的时序规模、写入速率、查询压力与磁盘空间。读完本文你将掌握 Active Time Series、Churn Rate、Ingestion Rate、QPS、Retention 等核心指标的含义与度量方式能够独立完成 VictoriaMetrics 单机与集群的容量估算并学会利用仓库源码与内置指标验证估算结果。核心术语Terminology容量规划的第一步是统一术语。下表汇总了本文反复使用到的五个核心概念及其在本仓库中的定义来源术语定义Active Time Series活跃时序在最近 1 小时内被更新过至少一次的时序Ingestion Rate摄入速率每秒写入数据库的 samples样本 数量Churn Rate时序流失率新时序被创建的频繁程度。例如 Kubernetes 中 Pod 名称变化就是常见的时序流失来源Queries per Second每秒查询数每秒执行的读查询数量Retention Period保留期数据在数据库中存储的时间长度在深入研究每个指标前建议先阅读 keyConcepts 文档 理解 time series、raw samples、push/pull 模型等基础概念这些是后续所有公式的前提。Active Time Series衡量监控规模的第一指标什么是活跃时序应用在/metrics页面上暴露pull 模型的时序中最近 1 小时内被更新过的才被计入 Active Time Series。例如 Node exporter 每个实例暴露约1000个时序。因此如果你采集 50 个 node exporter 实例活跃时序的近似数量就是1000 × 50 50,000。注意这个估算只覆盖 pull 模型。对于推送push 模型的指标估算方式相同——先测算单个应用推送的平均唯一时序数再乘以应用数量。如何度量活跃时序对 Prometheus通过如下查询获取最近 24 小时内的最大活跃时序数sum(max_over_time(prometheus_tsdb_head_series[24h]))对 VictoriaMetrics对应查询为sum(max_over_time(vm_cache_entries{typestorage/hour_metric_ids}[24h]))这条查询在源码中对应vmstorage导出的hour_metric_ids缓存指标见 app/vmstorage/main.go 中的vm_cache_entries{typestorage/hour_metric_ids}定义。该缓存记录的是每小时级别的 metricID 集合其规模直接反映活跃时序数量因此max_over_time取 24h 最大值即可代表部署高峰期的活跃时序规模。注意如果部署了多个 Prometheus需要在每个实例上分别运行上述查询并汇总结果。复制因子的放大效应应用复制因子Replication Factor后由于每个时序都会被存储 ReplicationFactor 次活跃时序数将按复制因子成倍放大。这一点在集群容量规划要点中有明确说明复制使集群所需资源最高增加N倍N 为复制因子因为vminsert会将每个样本的N份副本写入不同的vmstorage节点。Churn Rate影响资源效率的隐形杀手为什么 Churn Rate 重要Churn Rate 越高VictoriaMetrics 正常工作所需的计算资源就越多。它同时影响 Active Time Series 的统计、缓存效率、查询性能和磁盘压缩率因此官方强烈建议尽可能降低 churn rate。高 Churn Rate 通常由高易变标签high-volatile labels引起例如client_id、url、checksum、timestamp等。在 Kubernetes 中Pod 名称也是易变标签——每次 Pod 重新部署都会变化。举例某服务暴露 1000 个时序部署 100 个副本后活跃时序为1000 × 100 100,000一旦重新部署该服务每个副本的 Pod 名都会变化将一次性产生100,000个新时序。如何度量 Churn Rate在 VictoriaMetrics 中查看最近 24 小时的 Churn Ratesum(increase(vm_new_timeseries_created_total[24h]))vm_new_timeseries_created_total在 app/vmstorage/main.go 中作为计数器导出其底层计数逻辑在 lib/storage/storage.go 与 lib/storage/storage.go 中通过s.newTimeseriesCreated.Add(newSeriesCount)累加——每当存储层为新写入的时序分配新的 TSID时序 ID时计数加一。因此该指标能精确反映新时序被创建的速率即 churn 的规模。定位高基数指标时序数最高的指标可以通过 VictoriaMetrics 的Cardinality Explorer追踪详见单机版文档中的 Cardinality Explorer 章节。它可以帮助你找出造成高基数的具体指标与标签组合从而针对性地做标签精简如移除client_id、url等易变标签或利用 relabeling 在采集端降基数。Ingestion Rate每秒写入的样本数定义与估算示例Ingestion Rate 是每秒被拉取scrape或推送到数据库的时序样本数。例如如果以15s的间隔采集一个暴露1000个时序的服务Ingestion Rate 为1000 / 15 ≈ 66samples/s。被采集的服务越多、采集间隔越短Ingestion Rate 就越高。如何度量对 Prometheussum(rate(prometheus_tsdb_head_samples_appended_total[24h]))对 VictoriaMetrics复制前sum(rate(vm_rows_inserted_total[24h]))vm_rows_inserted_total是 VictoriaMetrics 按写入协议分别计数的一组计数器。以当前仓库为例app/vminsert/prometheusimport/request_handler.go 定义了vm_rows_inserted_total{typeprometheus}app/vminsert/influx/request_handler.go 定义了typeinflux此外还有graphite、opentsdb、opentsdbhttp、promremotewrite、datadogv1、datadogv2、opentelemetry、newrelic、csvimport、native、vmimport、zabbixconnector等见 app/vminsert 下各子目录的request_handler.go。因此sum(rate(vm_rows_inserted_total[24h]))实际是对所有协议入口的写入总量求和得到的是复制前的摄入速率。如果你需要包含复制因子在内的真实写入速率使用sum(rate(vm_vminsert_metrics_read_total[24h]))说明该指标反映包含复制副本在内的整体写入流量通常在集群部署中观察集群版实现位于独立的 cluster 分支见 Cluster-VictoriaMetrics.md。Queries per Second查询负载的轻与重查询分为两类轻查询light计算范围在 5m 区间内、或只选中少量时序的查询重查询heavy计算范围达 30d、或选中大量时序的查询。时间范围越大、需要扫描的时序越多查询就越重、开销越大。针对两类查询集群扩容策略不同提高整体 RPS查询吞吐横向扩容部署更多 vmselect 副本让查询分散到更多节点降低 heavy 查询延迟纵向扩容为 vmselect 分配更多计算资源CPU 核数。这一策略在集群容量规划要点中有源码级依据每个查询由单个 vmselect 节点处理heavy 查询的性能随 vmselect 可用 CPU 核数线性扩展查询涉及的所有时序会在所有可用 CPU 核上并行处理而当需要高查询吞吐时增加 vmselect 节点即可让请求分布到更多节点。Compute Resources用真实负载测试替代拍脑袋估算仅凭 Ingestion Rate 和 Active Time Series 很难准确预测 CPU、内存或集群规模。更好的方法是为你的负载类型写入与读取运行测试然后据此外推。推荐的两种测试路径生产流量复制最精确如果你已经在用 Prometheus 或 Telegraf 采集指标只需将其或其中一部分配置为同时向 VictoriaMetrics 复制数据就能获得对生产环境最精确的模拟。合成测试官方推荐的 Prometheus benchmark suite 会运行指定数量的 Node exporter 主机并把指标写入目标端。该工具不仅可以测试 VictoriaMetrics还能与其他兼容方案对比。此外单机版容量规划文档给出了一个非常实用的外推方法磁盘空间需求可以直接从测试运行中的磁盘占用外推——例如-storageDataPath目录在一天测试后占用了 10GB那么在-retentionPeriod100d100 天保留期下至少需要10GB × 100 1TB磁盘。关于资源预留官方建议保留以下余量50% 空闲内存降低 OOM 崩溃概率超过 50% 空闲内存可能导致缓存驱逐、过度 I/O 与整体变慢50% 空闲 CPU应对突发的负载尖峰至少 20% 空闲磁盘保证压缩与读性能对应-storage.minFreeDiskSpaceBytes命令行参数。Retention Period 与磁盘空间计算磁盘空间公式Retention Period 决定数据存储的天数/月数直接影响磁盘占用。官方给出的磁盘空间计算公式如下Bytes Per Sample × Ingestion Rate × Replication Factor × (Retention Period in Seconds 1 Retention Cycle) × 1.25其中Retention Cycle为一个天或一个月当保留期超过 30 天时按月计否则按天计公式中折算为秒;1.25 系数对应官方建议保留的 20% 空闲空间用于合并操作即× 1.25 × (1 20%);保留期在代码层面的实现见 app/vmstorage/main.go-retentionPeriod默认值为1M一个月/31 天最小保留期为 24h 或 1d。同时注意 README 文档 的说明给定-retentionPeriod的最大磁盘占用为(-retentionPeriod 1)个月因为数据分区在完全超出保留期后才会被删除。压缩后单样本大小平均而言压缩后每个样本占用不超过 1 字节。可以通过以下查询验证sum(vm_data_size_bytes) / sum(vm_rows{type!~indexdb.*})vm_data_size_bytes与vm_rows在 app/vmstorage/main.go 与 app/vmstorage/main.go 中按存储层级storage/inmemory、storage/small、storage/big、storage/metaindex等分别导出。分母排除indexdb.*类型的行是为了只计算原始样本数据的行数从而得到样本数据的平均字节数。请注意高 Churn Rate 会降低压缩效率导致单样本实际占用超过 1 字节因此高 churn 场景下建议按更大值估算。计算示例一个 Kubernetes 环境每秒产生 5k 个时序保留期 1 年ReplicationFactor 2(1 byte-per-sample × 5000 series × 2 replication × 34128000 seconds) × 1.25 / 2^30 397 GB其中34128000 秒 365 天 30 天对应公式中的1 年保留期 1 个 Retention Cycle月。索引indexdb的额外磁盘开销除了样本数据VictoriaMetrics 还需要额外的磁盘空间用于索引。Churn Rate 越低索引占用的磁盘越少。通常索引约占数据存储磁盘的20%高基数部署中索引占比可能达到存储大小的50%。如果发现 indexdb 异常偏大可参考 FAQ 中关于 indexdb 体积的说明 了解典型占比与排查方法。降低磁盘占用的手段Downsampling 与 Retention Filters你可以通过以下两种方式显著降低磁盘用量两者在 VictoriaMetrics Cloud 和 Enterprise 版本中可用Downsampling降采样通过-downsampling.periodoffset:interval参数配置多级降采样。例如-downsampling.period30d:5m表示比offset30 天更老的数据只保留每 5 分钟区间内的最后一个样本见 README 文档中的 Downsampling 章节。该参数可多次指定为不同时间范围配置不同级别的降采样。Retention Filters保留过滤器通过-retentionFilter为不同标签集合的时序配置不同的保留期让高精度数据与低频数据各得其所见 README 文档中的 Retention filters 章节。当某个时序匹配多个过滤器时采用最小的保留期。集群规模Cluster Size小节点多的策略关于集群规模官方建议遵循集群部署与容量规划文档中的结论运行多个小型 vmstorage 节点优于少数大型 vmstorage 节点。原因在于当某些 vmstorage 节点临时不可用时升级、配置变更、迁移等维护场景剩余节点的负载增量会被摊薄集群有 10 个 vmstorage 节点、其中 1 个临时不可用时剩余 9 个节点的负载增加1/9 ≈ 11%集群只有 3 个 vmstorage 节点、其中 1 个临时不可用时剩余 2 个节点的负载增加1/2 50%——可能没有足够余量承载增量负载导致集群过载、可用性下降。一般建议 vmstorage 节点数量在10 到 50 之间。注意增加 vmstorage 节点是简单直接的过程但减少 vmstorage 节点非常复杂应尽量避免。其他关键建议每个 vmstorage 节点最好分配整数个 vCPU 核以获得最优性能vminsert与vmselect是无状态组件可以随时水平扩缩容请根据负载灵活调整集群中 vmstorage 的活跃时序容量可以通过增加单节点内存/CPU 或增加节点数来提升见 Cluster-VictoriaMetrics.md默认情况下 vmstorage 会在查询时压缩发给 vmselect 的数据以节省网络带宽但会占用 vmstorage 的 CPU若 vmstorage CPU 紧张可通过-rpc.disableCompression参数禁用见 Cluster-VictoriaMetrics.md。将术语与 VictoriaMetrics 部署形态对齐VictoriaMetrics Cloud各 tier 与部署规模的具体信息请参考 Cloud 官方文档中关于 tiers and types 的说明。On-Premise 自建请参考两份官方容量规划文档——单机版Single-Node容量规划与集群版Cluster容量规划其中给出了处理特定 Ingestion Rate、Active Time Series、Churn Rate、QPS 与 Retention Period 所需的 CPU 核数与内存建议。附录容量规划指标速查表目标Prometheus 查询VictoriaMetrics 查询活跃时序24h 峰值sum(max_over_time(prometheus_tsdb_head_series[24h]))sum(max_over_time(vm_cache_entries{typestorage/hour_metric_ids}[24h]))Churn Rate24h 新增时序—sum(increase(vm_new_timeseries_created_total[24h]))Ingestion Rate复制前sum(rate(prometheus_tsdb_head_samples_appended_total[24h]))sum(rate(vm_rows_inserted_total[24h]))Ingestion Rate含复制—sum(rate(vm_vminsert_metrics_read_total[24h]))平均单样本字节数—sum(vm_data_size_bytes) / sum(vm_rows{type!~indexdb.*})掌握以上指标与估算公式后你可以在部署前用本文的磁盘公式与示例流程完成初步规划再通过真实/合成负载测试验证并外推——这也是官方推荐的、最接近生产实际的方法。建议进一步阅读单机版容量规划与资源使用限制包括-maxIngestionRate、-memory.allowedPercent、-search.maxMemoryPerQuery等资源限制参数与集群版架构与部署文档以获得完整的容量管理闭环。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VictoriaMetrics 容量规划实战指南：从 Active Time Series 到磁盘空间的完整估算方法
VictoriaMetrics 容量规划实战指南从 Active Time Series 到磁盘空间的完整估算方法【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本文基于 VictoriaMetrics 官方容量规划指南Single-Node / Cluster / VictoriaMetrics Cloud整理成文帮助你在部署、扩容或上云前用一套可量化的方法估算监控系统所需的时序规模、写入速率、查询压力与磁盘空间。读完本文你将掌握 Active Time Series、Churn Rate、Ingestion Rate、QPS、Retention 等核心指标的含义与度量方式能够独立完成 VictoriaMetrics 单机与集群的容量估算并学会利用仓库源码与内置指标验证估算结果。核心术语Terminology容量规划的第一步是统一术语。下表汇总了本文反复使用到的五个核心概念及其在本仓库中的定义来源术语定义Active Time Series活跃时序在最近 1 小时内被更新过至少一次的时序Ingestion Rate摄入速率每秒写入数据库的 samples样本 数量Churn Rate时序流失率新时序被创建的频繁程度。例如 Kubernetes 中 Pod 名称变化就是常见的时序流失来源Queries per Second每秒查询数每秒执行的读查询数量Retention Period保留期数据在数据库中存储的时间长度在深入研究每个指标前建议先阅读 keyConcepts 文档 理解 time series、raw samples、push/pull 模型等基础概念这些是后续所有公式的前提。Active Time Series衡量监控规模的第一指标什么是活跃时序应用在/metrics页面上暴露pull 模型的时序中最近 1 小时内被更新过的才被计入 Active Time Series。例如 Node exporter 每个实例暴露约1000个时序。因此如果你采集 50 个 node exporter 实例活跃时序的近似数量就是1000 × 50 50,000。注意这个估算只覆盖 pull 模型。对于推送push 模型的指标估算方式相同——先测算单个应用推送的平均唯一时序数再乘以应用数量。如何度量活跃时序对 Prometheus通过如下查询获取最近 24 小时内的最大活跃时序数sum(max_over_time(prometheus_tsdb_head_series[24h]))对 VictoriaMetrics对应查询为sum(max_over_time(vm_cache_entries{typestorage/hour_metric_ids}[24h]))这条查询在源码中对应vmstorage导出的hour_metric_ids缓存指标见 app/vmstorage/main.go 中的vm_cache_entries{typestorage/hour_metric_ids}定义。该缓存记录的是每小时级别的 metricID 集合其规模直接反映活跃时序数量因此max_over_time取 24h 最大值即可代表部署高峰期的活跃时序规模。注意如果部署了多个 Prometheus需要在每个实例上分别运行上述查询并汇总结果。复制因子的放大效应应用复制因子Replication Factor后由于每个时序都会被存储 ReplicationFactor 次活跃时序数将按复制因子成倍放大。这一点在集群容量规划要点中有明确说明复制使集群所需资源最高增加N倍N 为复制因子因为vminsert会将每个样本的N份副本写入不同的vmstorage节点。Churn Rate影响资源效率的隐形杀手为什么 Churn Rate 重要Churn Rate 越高VictoriaMetrics 正常工作所需的计算资源就越多。它同时影响 Active Time Series 的统计、缓存效率、查询性能和磁盘压缩率因此官方强烈建议尽可能降低 churn rate。高 Churn Rate 通常由高易变标签high-volatile labels引起例如client_id、url、checksum、timestamp等。在 Kubernetes 中Pod 名称也是易变标签——每次 Pod 重新部署都会变化。举例某服务暴露 1000 个时序部署 100 个副本后活跃时序为1000 × 100 100,000一旦重新部署该服务每个副本的 Pod 名都会变化将一次性产生100,000个新时序。如何度量 Churn Rate在 VictoriaMetrics 中查看最近 24 小时的 Churn Ratesum(increase(vm_new_timeseries_created_total[24h]))vm_new_timeseries_created_total在 app/vmstorage/main.go 中作为计数器导出其底层计数逻辑在 lib/storage/storage.go 与 lib/storage/storage.go 中通过s.newTimeseriesCreated.Add(newSeriesCount)累加——每当存储层为新写入的时序分配新的 TSID时序 ID时计数加一。因此该指标能精确反映新时序被创建的速率即 churn 的规模。定位高基数指标时序数最高的指标可以通过 VictoriaMetrics 的Cardinality Explorer追踪详见单机版文档中的 Cardinality Explorer 章节。它可以帮助你找出造成高基数的具体指标与标签组合从而针对性地做标签精简如移除client_id、url等易变标签或利用 relabeling 在采集端降基数。Ingestion Rate每秒写入的样本数定义与估算示例Ingestion Rate 是每秒被拉取scrape或推送到数据库的时序样本数。例如如果以15s的间隔采集一个暴露1000个时序的服务Ingestion Rate 为1000 / 15 ≈ 66samples/s。被采集的服务越多、采集间隔越短Ingestion Rate 就越高。如何度量对 Prometheussum(rate(prometheus_tsdb_head_samples_appended_total[24h]))对 VictoriaMetrics复制前sum(rate(vm_rows_inserted_total[24h]))vm_rows_inserted_total是 VictoriaMetrics 按写入协议分别计数的一组计数器。以当前仓库为例app/vminsert/prometheusimport/request_handler.go 定义了vm_rows_inserted_total{typeprometheus}app/vminsert/influx/request_handler.go 定义了typeinflux此外还有graphite、opentsdb、opentsdbhttp、promremotewrite、datadogv1、datadogv2、opentelemetry、newrelic、csvimport、native、vmimport、zabbixconnector等见 app/vminsert 下各子目录的request_handler.go。因此sum(rate(vm_rows_inserted_total[24h]))实际是对所有协议入口的写入总量求和得到的是复制前的摄入速率。如果你需要包含复制因子在内的真实写入速率使用sum(rate(vm_vminsert_metrics_read_total[24h]))说明该指标反映包含复制副本在内的整体写入流量通常在集群部署中观察集群版实现位于独立的 cluster 分支见 Cluster-VictoriaMetrics.md。Queries per Second查询负载的轻与重查询分为两类轻查询light计算范围在 5m 区间内、或只选中少量时序的查询重查询heavy计算范围达 30d、或选中大量时序的查询。时间范围越大、需要扫描的时序越多查询就越重、开销越大。针对两类查询集群扩容策略不同提高整体 RPS查询吞吐横向扩容部署更多 vmselect 副本让查询分散到更多节点降低 heavy 查询延迟纵向扩容为 vmselect 分配更多计算资源CPU 核数。这一策略在集群容量规划要点中有源码级依据每个查询由单个 vmselect 节点处理heavy 查询的性能随 vmselect 可用 CPU 核数线性扩展查询涉及的所有时序会在所有可用 CPU 核上并行处理而当需要高查询吞吐时增加 vmselect 节点即可让请求分布到更多节点。Compute Resources用真实负载测试替代拍脑袋估算仅凭 Ingestion Rate 和 Active Time Series 很难准确预测 CPU、内存或集群规模。更好的方法是为你的负载类型写入与读取运行测试然后据此外推。推荐的两种测试路径生产流量复制最精确如果你已经在用 Prometheus 或 Telegraf 采集指标只需将其或其中一部分配置为同时向 VictoriaMetrics 复制数据就能获得对生产环境最精确的模拟。合成测试官方推荐的 Prometheus benchmark suite 会运行指定数量的 Node exporter 主机并把指标写入目标端。该工具不仅可以测试 VictoriaMetrics还能与其他兼容方案对比。此外单机版容量规划文档给出了一个非常实用的外推方法磁盘空间需求可以直接从测试运行中的磁盘占用外推——例如-storageDataPath目录在一天测试后占用了 10GB那么在-retentionPeriod100d100 天保留期下至少需要10GB × 100 1TB磁盘。关于资源预留官方建议保留以下余量50% 空闲内存降低 OOM 崩溃概率超过 50% 空闲内存可能导致缓存驱逐、过度 I/O 与整体变慢50% 空闲 CPU应对突发的负载尖峰至少 20% 空闲磁盘保证压缩与读性能对应-storage.minFreeDiskSpaceBytes命令行参数。Retention Period 与磁盘空间计算磁盘空间公式Retention Period 决定数据存储的天数/月数直接影响磁盘占用。官方给出的磁盘空间计算公式如下Bytes Per Sample × Ingestion Rate × Replication Factor × (Retention Period in Seconds 1 Retention Cycle) × 1.25其中Retention Cycle为一个天或一个月当保留期超过 30 天时按月计否则按天计公式中折算为秒;1.25 系数对应官方建议保留的 20% 空闲空间用于合并操作即× 1.25 × (1 20%);保留期在代码层面的实现见 app/vmstorage/main.go-retentionPeriod默认值为1M一个月/31 天最小保留期为 24h 或 1d。同时注意 README 文档 的说明给定-retentionPeriod的最大磁盘占用为(-retentionPeriod 1)个月因为数据分区在完全超出保留期后才会被删除。压缩后单样本大小平均而言压缩后每个样本占用不超过 1 字节。可以通过以下查询验证sum(vm_data_size_bytes) / sum(vm_rows{type!~indexdb.*})vm_data_size_bytes与vm_rows在 app/vmstorage/main.go 与 app/vmstorage/main.go 中按存储层级storage/inmemory、storage/small、storage/big、storage/metaindex等分别导出。分母排除indexdb.*类型的行是为了只计算原始样本数据的行数从而得到样本数据的平均字节数。请注意高 Churn Rate 会降低压缩效率导致单样本实际占用超过 1 字节因此高 churn 场景下建议按更大值估算。计算示例一个 Kubernetes 环境每秒产生 5k 个时序保留期 1 年ReplicationFactor 2(1 byte-per-sample × 5000 series × 2 replication × 34128000 seconds) × 1.25 / 2^30 397 GB其中34128000 秒 365 天 30 天对应公式中的1 年保留期 1 个 Retention Cycle月。索引indexdb的额外磁盘开销除了样本数据VictoriaMetrics 还需要额外的磁盘空间用于索引。Churn Rate 越低索引占用的磁盘越少。通常索引约占数据存储磁盘的20%高基数部署中索引占比可能达到存储大小的50%。如果发现 indexdb 异常偏大可参考 FAQ 中关于 indexdb 体积的说明 了解典型占比与排查方法。降低磁盘占用的手段Downsampling 与 Retention Filters你可以通过以下两种方式显著降低磁盘用量两者在 VictoriaMetrics Cloud 和 Enterprise 版本中可用Downsampling降采样通过-downsampling.periodoffset:interval参数配置多级降采样。例如-downsampling.period30d:5m表示比offset30 天更老的数据只保留每 5 分钟区间内的最后一个样本见 README 文档中的 Downsampling 章节。该参数可多次指定为不同时间范围配置不同级别的降采样。Retention Filters保留过滤器通过-retentionFilter为不同标签集合的时序配置不同的保留期让高精度数据与低频数据各得其所见 README 文档中的 Retention filters 章节。当某个时序匹配多个过滤器时采用最小的保留期。集群规模Cluster Size小节点多的策略关于集群规模官方建议遵循集群部署与容量规划文档中的结论运行多个小型 vmstorage 节点优于少数大型 vmstorage 节点。原因在于当某些 vmstorage 节点临时不可用时升级、配置变更、迁移等维护场景剩余节点的负载增量会被摊薄集群有 10 个 vmstorage 节点、其中 1 个临时不可用时剩余 9 个节点的负载增加1/9 ≈ 11%集群只有 3 个 vmstorage 节点、其中 1 个临时不可用时剩余 2 个节点的负载增加1/2 50%——可能没有足够余量承载增量负载导致集群过载、可用性下降。一般建议 vmstorage 节点数量在10 到 50 之间。注意增加 vmstorage 节点是简单直接的过程但减少 vmstorage 节点非常复杂应尽量避免。其他关键建议每个 vmstorage 节点最好分配整数个 vCPU 核以获得最优性能vminsert与vmselect是无状态组件可以随时水平扩缩容请根据负载灵活调整集群中 vmstorage 的活跃时序容量可以通过增加单节点内存/CPU 或增加节点数来提升见 Cluster-VictoriaMetrics.md默认情况下 vmstorage 会在查询时压缩发给 vmselect 的数据以节省网络带宽但会占用 vmstorage 的 CPU若 vmstorage CPU 紧张可通过-rpc.disableCompression参数禁用见 Cluster-VictoriaMetrics.md。将术语与 VictoriaMetrics 部署形态对齐VictoriaMetrics Cloud各 tier 与部署规模的具体信息请参考 Cloud 官方文档中关于 tiers and types 的说明。On-Premise 自建请参考两份官方容量规划文档——单机版Single-Node容量规划与集群版Cluster容量规划其中给出了处理特定 Ingestion Rate、Active Time Series、Churn Rate、QPS 与 Retention Period 所需的 CPU 核数与内存建议。附录容量规划指标速查表目标Prometheus 查询VictoriaMetrics 查询活跃时序24h 峰值sum(max_over_time(prometheus_tsdb_head_series[24h]))sum(max_over_time(vm_cache_entries{typestorage/hour_metric_ids}[24h]))Churn Rate24h 新增时序—sum(increase(vm_new_timeseries_created_total[24h]))Ingestion Rate复制前sum(rate(prometheus_tsdb_head_samples_appended_total[24h]))sum(rate(vm_rows_inserted_total[24h]))Ingestion Rate含复制—sum(rate(vm_vminsert_metrics_read_total[24h]))平均单样本字节数—sum(vm_data_size_bytes) / sum(vm_rows{type!~indexdb.*})掌握以上指标与估算公式后你可以在部署前用本文的磁盘公式与示例流程完成初步规划再通过真实/合成负载测试验证并外推——这也是官方推荐的、最接近生产实际的方法。建议进一步阅读单机版容量规划与资源使用限制包括-maxIngestionRate、-memory.allowedPercent、-search.maxMemoryPerQuery等资源限制参数与集群版架构与部署文档以获得完整的容量管理闭环。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考