Prometheus 为 remote write 实现了合理的默认值，但许多用户有不同的需求，希望优化其远程写入设置。
本页描述了通过 remote write 配置可用的调优参数。
Remote write 特性
每个 remote write 目标会启动一个队列，该队列从预写日志（WAL）读取数据，将样本写入由 shard 拥有的内存队列，然后向配置的端点发送请求。数据流如下：
|--> queue (shard_1) --> remote endpoint
WAL --|--> queue (shard_...) --> remote endpoint
|--> queue (shard_n) --> remote endpoint
当一个 shard 积压并填满其队列时，Prometheus 将阻止从 WAL 读取到任何 shard。失败会在不丢失数据的情况下重试，除非远程端点持续宕机超过 2 小时。超过 2 小时后，WAL 将被压缩，未发送的数据将会丢失。
在运行期间，Prometheus 会根据传入的样本速率、未发送的积压样本数量以及每个样本的发送耗时，持续计算最优的 shard 数量。
资源使用
使用 remote write 会增加 Prometheus 的内存占用。大多数用户报告内存使用量增加约 25%，但该数字取决于数据的形态。对于 WAL 中的每个时间序列，remote write 代码会缓存一个从序列 ID 到标签值的映射，导致大量序列变更会显著增加内存使用。
除了序列缓存外，每个 shard 及其队列也会增加内存使用。Shard 内存与 shard 数量 * (capacity + max_samples_per_send) 成正比。调优时，请考虑在增加 capacity 和 max_samples_per_send 的同时减少 max_shards，以避免意外耗尽内存。capacity: 10000 和 max_samples_per_send: 2000 的默认值将每个 shard 的内存使用限制在 2 MB 以内。
Remote write 还会增加 CPU 和网络使用。然而，出于上述相同原因，很难预测增加多少。如果你的 Prometheus 服务器在通过 remote write 发送样本时出现落后（prometheus_remote_storage_samples_pending），检查 CPU 和网络饱和度通常是一个好的做法。
参数
所有相关参数都在 remote write 配置的 queue_config 部分中。
`capacity`
capacity 控制在阻止从 WAL 读取之前，每个 shard 在内存中排队多少样本。一旦 WAL 被阻止，样本将无法追加到任何 shard，所有吞吐量将停止。
Capacity 应该足够高以避免在大多数情况下阻塞其他 shard，但过大的 capacity 会导致过多的内存消耗和在重新分片期间清除队列的时间更长。建议将 capacity 设置为 max_samples_per_send 的 3-10 倍。
`max_shards`
max_shards 配置 Prometheus 为每个 remote write 队列使用的最大 shard 数量，即最大并行度。Prometheus 会尽量不使用过多的 shard，但如果队列落后，remote write 组件会增加 shard 数量直到 max_shards 以提高吞吐量。除非远程写入到一个非常慢的端点，否则不太可能需要将 max_shards 增加到超过默认值。然而，如果可能会导致远程端点过载，或者在数据积压时需要减少内存使用，可能需要减少 max_shards。
`min_shards`
min_shards 配置 Prometheus 使用的最小 shard 数量，也是 remote write 启动时使用的 shard 数量。如果 remote write 出现落后，Prometheus 会自动增加 shard 数量，因此大多数用户不需要调整此参数。然而，增加 min_shards 可以让 Prometheus 在计算所需 shard 数量的初期避免落后。
`max_samples_per_send`
max_samples_per_send 可以根据使用的后端进行调整。许多系统在每批发送更多样本时工作得很好，而不会显著增加延迟。其他后端在尝试每个请求发送大量样本时可能会出现问题。默认值足够小，适用于大多数系统。
`batch_send_deadline`
batch_send_deadline 设置单个 shard 两次发送之间的最大时间间隔。即使排队的 shard 未达到 max_samples_per_send，也会发送请求。对于不敏感于延迟的低流量系统，可以增加 batch_send_deadline 以提高请求效率。
`min_backoff`
min_backoff 控制在重试失败请求之前等待的最短时间。增加退避间隔可以在远程端点恢复在线时分散请求。每次请求失败时，退避间隔会翻倍，直到 max_backoff。
`max_backoff`
max_backoff 控制在重试失败请求之前等待的最长时间。