远程写入调优

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

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

容量应足够高，以在大多数情况下避免阻塞其他分片，但过多的容量可能导致过度的内存消耗和在重新分片期间需要更长的时间来清除队列。建议将容量设置为 max_samples_per_send 的 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

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