VictoriaMetrics 资源规划¶
VictoriaMetrics 相关组件在 Prometheus RemoteWrite 实际使用过程中，会受到集群容器数量以及指标量的影响，而导致 vminsert 和 vmstorage 的 CPU、内存 等资源使用量超出设定的资源。为了保证不同规模集群下 VictoriaMetrics 组件的正常运行，需要根据集群的实际规模对 VictoriaMetrics 进行资源调整。
测试结果¶
经过对 Prometheus RemoteWrite 到 VictoriaMetrics 的指标持续观测，我们发现 VictoriaMetrics 相关组件资源大部分情况和 ingestion rate（指标摄取率）呈正相关，而指标摄取率和 Pod 数量同样呈正相关。
- Ingestion_rate：sum(rate(vm_rows_inserted_total{job="vminsert-insight-victoria-metrics-k8s-stack"}[1m]))
- Pod 数量：sum(kube_pod_info)
其中，以上的 ingestion_rate 显示每秒有多少数据点插入到 vminsert 中，即此指标不考虑由于复制而导致的数据增加。如果想知道包括复制因子在内的指标摄取率，可以使用查询 sum(rate(vm_vminsert_metrics_read_total{job="vmstorage-insight-victoria-metrics-k8s-stack"}[1m]))，该查询显示 vmstorage 从 vminsert 读取了多少个数据点。
通过对多集群长时间的测试，两个指标摄取率差别不大。因此，该文的指标摄取率主要以每秒插入到 vminsert 的数据点为准。
计算方法¶
资源使用¶
| 组件 | 资源 | 计算公式 | 备注 |
|---|---|---|---|
| vminsert | CPU | ( ingestion_rate / 100k + 0.07 ) * 2 | |
| 接收带宽 (KB/s) | 60 * ingestion_rate / 1k + 120 | ||
| 传输带宽 (KB/s) | 20 * ingestion_rate / 1k + 40 | 大约是接收带宽的 ⅓ | |
| vmstorage | CPU | ( 2 * ingestion_rate / 100k - 0.02 ) * 2 | |
| 内存 (MB) | 100 * ingestion_rate / 1k * 2 | ||
| 接收带宽 (KB/s) | 30 * ingestion_rate / 1k |
参数说明：
- CPU 计算公式： * 2 是为了预留 50% 的空闲 CPU，以降低在工作负载高峰期间出现性能瓶颈的风险。
- 内存计算公式：* 2 是为了预留 50% 的空闲内存，以减少在工作负载激增时因 OOM（内存溢出）导致崩溃的可能性。
集群规模¶
按照现存环境，集群规模和指标摄取率关系大概如下：**ingestion_rate = Pod 数量 * 1000 / 120
参考资源规划¶
以下为 Prometheus RemoteWrite 场景下，不同规模集群中 VictoriaMetrics 组件大概所需资源：
| 集群规模（Pod 数量） | ingestion_rate | vminsert CPU(core) | vminsert 内存 | vminsert 接收带宽 | vminsert 传输带宽 | vmstorage CPU(core) | vmstorage 内存 | vmstorage 接收带宽 |
|---|---|---|---|---|---|---|---|---|
| 100 | 8k | 0.3 | 160 MB | 600 KB/s | 200 KB/s | 0.28 | 1.6 GB | 240 KB/s |
| 200 | 17k | 0.48 | 340 MB | 1.1 MB/s | 380 KB/s | 0.64 | 3.3 GB | 510 KB/s |
| 300 | 25k | 0.64 | 500 MB | 1.6 MB/s | 540 KB/s | 0.96 | 4.9 GB | 750 KB/s |
| 400 | 34k | 0.84 | 500 MB | 2.1 MB/s | 720 KB/s | 1.32 | 6.7 GB | 1020 KB/s |
| 500 | 42k | 0.98 | 500 MB | 2.6 MB/s | 880 KB/s | 1.64 | 8.2 GB | 1.3 MB/s |
| 800 | 67k | 1.48 | 500 MB | 4.1 MB/s | 1.4 MB/s | 2.64 | 13.1 GB | 2 MB/s |
| 1000 | 84k | 1.82 | 500 MB | 5.1 MB/s | 1.7 MB/s | 3.32 | 16.4 GB | 2.5 MB/s |
| 2000 | 167k | 3.48 | 500 MB | 10 MB/s | 3.3 MB/s | 6.64 | 32.6 GB | 4.9 MB/s |
说明：
- 表格中的 Pod 数量 指已正常安装 insight-agent 的集群中基本稳定运行的 Pod 数量，如出现大量的 Pod 重启，则会造成短时间内指标量的陡增，此时资源需要进行相应上调。
- 表格中数据为对应规模下组件可正常运行的资源使用值。如环境有精确的资源要求，建议在已有业务类型的集群运行一段时间后，查看对应 VictoriaMetrics 的资源占用量再进行精确配置。
- 在 Prometheus RemoteWrite 过程中，主要是 vminsert 和 vmselect 参与工作。暂无 vmselect 的资源规划，需要根据 读取量 进行评估。
组件资源扩展建议¶
-
扩展
vminsert的副本数可以提升数据摄取能力，因为摄取的数据可以在更多的vminsert节点之间进行拆分。 -
扩展
vmstorage副本数或者增加 CPU 和内存都能提升可处理的活跃时间序列数量。相比之下，更推荐扩展副本数，这样可以在高流失率（churn rate）情况下提高时间序列的查询性能，并增强集群的稳定性。 -
增加
vmselect的 CPU 和内存可以提升复杂查询的性能，尤其是处理大量时间序列和原始样本时。扩展vmselect的副本数可以提高查询的并发处理能力，因为传入的请求可以在更多的 vmselect 节点之间分配，从而提升查询的最大速度。 -
正常安装模式下
VictoriaMetrics使用官方默认配置。指标vm_concurrent_insert_capacity默认为指标vm_available_cpu_coresvm_available_cpu_cores{job="vminsert-insight-victoria-metrics-k8s-stack"}的 2 倍；vm_concurrent_select_capacity默认为vm_available_cpu_cores{job="vmselect-insight-victoria-metrics-k8s-stack"}的 2 倍。当给定组件的 CPU 不足时，可能出现vm_concurrent_insert_current 或vm_concurrent_select_current达到上限，这种情况下需根据实际情况在 CR 中增加以下配置：
# vmcluster的cr中，在spec.vminsert.extraArgs下增加如下，则可以将最大并发提高到32
maxConcurrentInserts: "32"
# vmcluster的cr中，在spec.vmselect.extraArgs下增加如下，则可以将最大并发提高到16
search.maxConcurrentRequests: "16"