远程写入调优

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

本页描述了可通过 远程写入配置 进行调优的参数。

远程写入特性

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

      |-->  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 到标签值的映射，导致大量系列变化会显著增加内存使用量。

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

远程写入还会增加 CPU 和网络使用量。但是，与上述原因相同，很难预测增加的幅度。如果您的 Prometheus 服务器在通过远程写入发送样本方面落后 (prometheus_remote_storage_samples_pending)，通常最好检查 CPU 和网络饱和度。

参数

所有相关参数都位于远程写入配置的 queue_config 部分。

capacity

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

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

max_shards

最大分片数配置了 Prometheus 为每个远程写入队列使用的最大分片数，即并行度。Prometheus 会尽量不使用过多的分片，但如果队列滞后，远程写入组件将增加分片数量，最多可达最大分片数以提高吞吐量。除非远程写入到一个非常慢的端点，否则 最大分片数 不太可能需要增加到默认值之外。但是，如果有可能压垮远程端点，或者在数据备份时减少内存使用，则可能需要减小最大分片数。

min_shards

最小分片数配置了 Prometheus 使用的最小分片数，这是远程写入启动时使用的分片数。如果远程写入滞后，Prometheus 将自动扩展分片数量，因此大多数用户无需调整此参数。但是，增加最小分片数可以使 Prometheus 在计算所需分片数量的初始阶段避免滞后。

max_samples_per_send

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

batch_send_deadline

批次发送截止时间设置了单个分片之间发送的最大时间。即使队列中的分片尚未达到 每个发送的最大样本数，也会发送一个请求。对于不敏感于延迟的低吞吐量系统，可以增加批次发送截止时间以提高请求效率。

min_backoff

最小回退时间控制着在重试失败请求之前等待的最小时间。增加回退时间会在远程端点恢复联机时分散请求。回退间隔对于每个失败的请求都会加倍，直到达到 max_backoff。

max_backoff

最大回退时间控制着在重试失败请求之前等待的最大时间。