远程写入调优

Prometheus 为远程写入实施了合理的默认设置，但许多用户有不同的需求，并希望优化其远程设置。

本页面介绍了可通过远程写入配置调整的参数。

远程写入特性

每个远程写入目标都会启动一个队列，该队列从预写日志 (WAL) 中读取数据，将样本写入属于某个分片 (shard) 的内存队列中，然后向配置的端点发送请求。数据流向大致如下：

      |-->  queue (shard_1)   --> remote endpoint
WAL --|-->  queue (shard_...) --> remote endpoint
      |-->  queue (shard_n)   --> remote endpoint

当某个分片积压并填满其队列时，Prometheus 将阻塞从 WAL 读取数据到任何分片的操作。如果远程端点保持离线超过 2 小时，数据在重试过程中可能会丢失。2 小时后，WAL 将进行压缩，未发送的数据将会丢失。

在运行期间，Prometheus 会根据传入的样本速率、未发送的待处理样本数量以及发送每个样本所花费的时间，持续计算并使用最优的分片数量。

资源使用

使用远程写入会增加 Prometheus 的内存占用。大多数用户反馈内存使用量增加了约 25%，但具体数值取决于数据的形态。对于 WAL 中的每个序列，远程写入代码都会缓存一个序列 ID 到标签值的映射，因此大量的序列流失 (series churn) 会显著增加内存使用量。

除了序列缓存外，每个分片及其队列也会增加内存占用。分片内存与 分片数量 * (容量 + 每次发送的最大样本数) 成正比。在进行调优时，请考虑在增加 容量 和 每次发送的最大样本数 的同时减少 最大分片数，以避免无意中耗尽内存。默认值 容量: 10000 和 每次发送的最大样本数: 2000 会将每个分片的内存占用限制在 2 MB 以内。

远程写入还会增加 CPU 和网络使用量。然而，由于上述原因，很难准确预测会增加多少。如果您的 Prometheus 服务器通过远程写入发送样本滞后 (prometheus_remote_storage_samples_pending)，通常建议检查 CPU 和网络饱和度。

参数

所有相关参数都可以在远程写入配置的 queue_config 部分找到。

capacity（容量）

容量控制在阻塞从 WAL 读取数据之前，每个分片在内存中排队的样本数量。一旦 WAL 被阻塞，样本就无法追加到任何分片中，所有的吞吐量都将停止。

在大多数情况下，容量应设置得足够高以避免阻塞其他分片，但过大的容量可能导致过多的内存消耗，并在重新分片时需要更长的时间来清除队列。建议将容量设置为 每次发送的最大样本数 的 3-10 倍。

max_shards（最大分片数）

最大分片数配置了 Prometheus 将用于每个远程写入队列的最大分片数（即并发度）。Prometheus 会尽量不使用过多的分片，但如果队列积压，远程写入组件会将分片数量增加到最大值以提高吞吐量。除非远程写入的目标端点非常慢，否则几乎不需要增加 max_shards 的默认值。然而，如果存在压垮远程端点的风险，或者为了在数据积压时减少内存使用，可能有必要减小最大分片数。

min_shards（最小分片数）

最小分片数配置了 Prometheus 使用的最小分片数量，也是远程写入启动时所使用的分片数量。如果远程写入积压，Prometheus 会自动向上扩展分片数量，因此大多数用户无需调整此参数。但是，增加最小分片数可以让 Prometheus 在计算所需分片数量的同时，避免在一开始就出现积压。

max_samples_per_send（每次发送的最大样本数）

每次发送的最大样本数可以根据所使用的后端进行调整。许多系统通过在每个批次中发送更多样本，且不会显著增加延迟，从而运行得非常好。如果尝试在每个请求中发送大量样本，其他后端可能会出现问题。默认值足够小，适用于大多数系统。

batch_send_deadline（批处理发送截止时间）

批处理发送截止时间设置了单个分片两次发送之间的最大时间间隔。即使排队的分片尚未达到 max_samples_per_send，也会发送请求。对于不敏感于延迟的低容量系统，可以增加该截止时间以提高请求效率。

min_backoff（最小退避时间）

最小退避时间控制重试失败请求前的最少等待时间。增加退避时间可以在远程端点恢复在线时分散请求压力。每次失败请求后，退避间隔都会加倍，直到达到 max_backoff。

max_backoff（最大退避时间）

最大退避时间控制重试失败请求前的最长等待时间。