##prometheus.yaml配置文件中遠程寫配置 - url: http://prometheus-kafka-adapter-v2:8090/receive remote_timeout: 30s queue_config: capacity: 1000 max_shards: 1000 min_shards: 1 max_samples_per_send: 100 batch_send_deadline: 5s max_retries: 3 min_backoff: 30ms max_backoff: 100ms
遠程寫特點
每個遠程寫目的地都啟動一個隊列，該隊列從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。
參數
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控制重試失敗請求之前等待的最長時間。
官方配置文件格式
# 要發送樣本的端點的URL. url: <string> # 對遠程寫端點的請求超時。 [ remote_timeout: <duration> | default = 30s ] # 遠程寫入重新標記配置列表。 write_relabel_configs: [ - <relabel_config> ... ] # 使用配置的用戶名和密碼在每個遠程寫請求上設置`Authorization`標頭.password和password_file是互斥的。 basic_auth: [ username: <string> ] [ password: <string> ] [ password_file: <string> ] # 使用配置的承載令牌在每個遠程寫請求上設置`Authorization`頭。 它與`bearer_token_file`互斥。 [ bearer_token: <string> ] # 使用配置的承載令牌在每個遠程寫請求上設置`Authorization`頭。 它與`bearer_token`互斥。 [ bearer_token_file: /path/to/bearer/token/file ] # 配置遠程寫入請求的TLS設置。 tls_config: [ <tls_config> ] # 可選的代理URL。 [ proxy_url: <string> ] # 配置用於寫入遠程存儲的隊列。 queue_config: # 在我們開始刪除之前每個分片緩沖的樣本數。 [ capacity: <int> | default = 10000 ] # 最大分片數，即並發數。 [ max_shards: <int> | default = 1000 ] # 最小分片數，即並發數。 [ min_shards: <int> | default = 1 ] # 每次發送的最大樣本數。 [ max_samples_per_send: <int> | default = 100] # 樣本在緩沖區中等待的最長時間。 [ batch_send_deadline: <duration> | default = 5s ] # 在可恢復錯誤上重試批處理的最大次數。 [ max_retries: <int> | default = 3 ] # 初始重試延遲。 每次重試都會加倍。 [ min_backoff: <duration> | default = 30ms ] # 最大重試延遲。 [ max_backoff: <duration> | default = 100ms ]