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 到标签值的映射，导致大量序列 churn 显着增加内存使用量。
除了序列缓存之外，每个分片及其队列都会增加内存使用量。分片内存与 分片数量 * (容量 + 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_shardsMax shards 配置 Prometheus 将为每个远程写入队列使用的最大分片数或并行度。Prometheus 会尽量不使用过多的分片，但如果队列落后于远程写入组件，则会增加分片数，最多增加到最大分片数以提高吞吐量。除非远程写入到非常慢的端点，否则 max_shards 不太可能需要增加超出默认值。但是，如果有可能压垮远程端点，或者在数据备份时减少内存使用量，则可能需要减少最大分片数。
min_shardsMin shards 配置 Prometheus 使用的最小分片数，并且是远程写入启动时使用的分片数。如果远程写入落后，Prometheus 将自动扩展分片数，因此大多数用户不必调整此参数。但是，增加最小分片数将使 Prometheus 能够避免在开始时在计算所需分片数时落后。
max_samples_per_sendMax samples per send 可以根据正在使用的后端进行调整。许多系统通过在每个批次中发送更多样本而不会显着增加延迟来工作得非常好。如果尝试在每个请求中发送大量样本，其他后端会出现问题。默认值足够小，可以适用于大多数系统。
batch_send_deadlineBatch send deadline 设置单个分片发送之间最长的时间量。即使排队的分片尚未达到 max_samples_per_send，也会发送请求。可以为对延迟不敏感的低容量系统增加 Batch send deadline，以提高请求效率。
min_backoffMin backoff 控制在重试失败请求之前要等待的最短时间量。当远程端点重新联机时，增加退避会分散请求。对于每个失败的请求，退避间隔会加倍，直到 max_backoff。
max_backoffMax backoff 控制在重试失败请求之前要等待的最长时间量。
该文档是开源的。请通过提交问题或拉取请求来帮助改进它。