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_shards，同时增加 capacity 和 max_samples_per_send，以避免意外耗尽内存。 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最大退避时间控制重试失败请求之前要等待的最长时间。
本文档是开源的。请通过提交问题或拉取请求来帮助改进它。