完整譯文請訪問：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。