远程写入调优

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

除了序列缓存外，每个分片及其队列也会增加内存使用量。分片内存与 分片数 * (容量 + max_samples_per_send) 成正比。在调优时，考虑在增加 capacity 和 max_samples_per_send 的同时减少 max_shards，以避免无意中耗尽内存。capacity: 10000 和 max_samples_per_send: 2000 的默认值将限制每个分片的内存使用量小于 2 MB。

远程写入还会增加 CPU 和网络使用量。然而，由于与上述相同的原因，很难预测会增加多少。如果您的 Prometheus 服务器在通过远程写入发送样本时落后（prometheus_remote_storage_samples_pending），通常检查 CPU 和网络饱和度是一个好习惯。

参数

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

capacity

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

Capacity 应该足够高，以在大多数情况下避免阻塞其他分片，但过多的容量会导致过度的内存消耗和在重新分片期间清理队列的时间更长。建议将容量设置为 max_samples_per_send 的 3-10 倍。

max_shards

Max shards 配置了 Prometheus 将为每个远程写入队列使用的最大分片数或并行度。Prometheus 会尽量不使用太多的分片，但如果队列落后，远程写入组件将增加分片数直至达到 max shards 以增加吞吐量。除非远程写入到一个非常慢的端点，否则不太可能需要将 max_shards 增加到超过默认值。然而，如果有可能压垮远程端点，或者为了在数据积压时减少内存使用，可能需要减少 max shards。

min_shards

Min shards 配置了 Prometheus 使用的最小分片数，并且是远程写入启动时使用的分片数。如果远程写入落后，Prometheus 会自动扩大分片数，因此大多数用户无需调整此参数。然而，增加 min shards 可以让 Prometheus 在开始计算所需分片数时避免落后。

max_samples_per_send

Max samples per send 可以根据所使用的后端进行调整。许多系统通过发送更多样本每批次而工作得很好，且延迟没有显著增加。其他后端如果尝试在每个请求中发送大量样本则会出现问题。默认值足够小，适用于大多数系统。

batch_send_deadline

Batch send deadline 设置单个分片发送之间的最大时间量。即使排队的分片尚未达到 max_samples_per_send，也会发送请求。对于不延迟敏感的低流量系统，可以增加 Batch send deadline 以提高请求效率。

min_backoff

Min backoff 控制在重试失败的请求之前等待的最小时间量。当远程端点恢复在线时，增加退避时间可以分散请求。对于每个失败的请求，退避间隔会加倍，直至达到 max_backoff。

max_backoff

Max backoff 控制在重试失败的请求之前等待的最大时间量。