Prometheus远程写调优
完整译文请访问：http://www.coderdocument.com/docs/prometheus/v2.14/best_practices/remote_write_tuning.html。
Prometheus为远程写实现了健全的默认设置，但许多用户有不同的需求，希望优化远程写设置。
此页描述了可用的远程写配置调优参数。
远程写特点
每个远程写目的地都启动一个队列，该队列从write-ahead log (WAL)中读取数据，将样本写到一个由（分片）shard拥有的内存队列中，然后分片将请求发送到配置的端点。数据流程如下：
|--> queue (shard_1) --> remote endpoint
WAL --|--> queue (shard_...) --> remote endpoint
|--> queue (shard_n) --> remote endpoint
当一个分片备份并填满它的队列时，Prometheus将阻止从WAL中读取任何分片。如果失败了，则进行重试，其间不会丢失数据，除非远程端点保持关闭状态超过2小时。2小时后，WAL将被压缩，未发送的数据将丢失。
在远程写过程中，Prometheus将根据输入采样速率、未发送的采样数量和发送每个采样数据所需的时间，不断计算出最优的分片数量。
内存使用
使用远程写操作会增加Prometheus的内存占用。大多数用户报告内存使用量增加了25%，但是这个数字取决于数据的结构。对于WAL中的每个时间序列，远程写缓存一个key为时间序列ID，value为标签值的map，导致大量的时间序列变动，从而显著地增加内存使用量。
除了时间序列缓存之外，每个分片及其队列还会增加内存使用量。分片内存与 number of shards * (capacity + max_samples_per_send)成比例。在进行调优时，可以考虑减少max_shards，同时增加capacity和max_samples_per_send，以避免内存耗尽。使用capacity和max_samples_per_send的默认值，可以将分片内存的使用量限制在每个分片少于100 kB。
参数
所有相关参数都可以在远程写配置的queue_config部分找到。
capacity
capacity控制在阻止从WAL读取之前，每个分片中有多少个采样在内存中排队。一旦WAL被阻塞，就不能将采样附加到任何分片上，停止所有吞吐量。
在大多数情况下，容量应该足够大，以避免阻塞其他分片，但是太大的容量会导致过多的内存消耗和在重新分片期间清除队列的时间更长。建议将容量设置为max_samples_per_send的3-10倍。
max_shards
max_shards配置Prometheus将为每个远程写队列使用的最大分片数量，即并行度。Prometheus将尽量不使用过多的分片，但如果队列落后于远程写组件，将增加分片的数量到最大分片数量，以增加吞吐量。除非远程写入非常慢的端点，否则不太可能将max_shards超出默认值。但是，如果有压跨远程端点的可能性，则需要减少最大分片数量，或者在备份数据时减少内存使用。
min_shards
min_shards配置Prometheus使用的分片的最小数量，是远程写入启动时使用的分片的数量。如果远程写迟滞，Prometheus将自动增加分片的数量，这样大多数用户就不必调整这个参数。然而，增加最小分片可以让Prometheus在开始计算所需分片数量时避免迟滞。
max_samples_per_send
每次发送的最大采样数量可以根据使用的后端进行调整。许多系统在不显著增加延迟的情况下发送更多的批处理采样而工作得非常好。如果试图在每个请求中发送大量采样，其他后端将会出现问题。足够小的默认值，适用于大多数系统。
batch_send_deadline
批量发送截止时间设置发送单个分片之间的最大时间隔。即使队列中的分片没有到达max_samples_per_send，也会发送一个请求。低容量系统，对延迟敏感的系统可以增加batch_send_deadline，以提高请求效率。
min_backoff
min_backoff控制在重试失败请求之前等待的最短时间。当远程端点重新上线时，增加backoff spreads out请求。对于达到max_backoff的每个失败请求，backoff间隔增加一倍。
max_backoff
max_backoff控制重试失败请求之前等待的最长时间。
完整译文请访问：http://www.coderdocument.com/docs/prometheus/v2.14/best_practices/remote_write_tuning.html。