prometheus如何優(yōu)化遠(yuǎn)程讀寫的性能

場景

為了解決prometheus本地存儲(chǔ)帶來的單點(diǎn)問題，我們一般在高可用監(jiān)控架構(gòu)中會(huì)使用遠(yuǎn)程存儲(chǔ)，并通過配置prometheus的remote_write和remote_read來對(duì)接

遠(yuǎn)程寫優(yōu)化：remote_write

遠(yuǎn)程寫的原理：

每個(gè)遠(yuǎn)程寫入目標(biāo)都會(huì)啟動(dòng)一個(gè)內(nèi)存寫隊(duì)列（shards），這個(gè)隊(duì)列從WAL中緩存數(shù)據(jù)。，通過隊(duì)列去將指標(biāo)數(shù)據(jù)寫到有遠(yuǎn)程存儲(chǔ)服務(wù)中,數(shù)據(jù)流如下所示：

      |-->  queue (shard_1)   --> remote endpoint
WAL --|-->  queue (shard_...) --> remote endpoint|-->  queue (shard_n)   --> remote endpoint

重試機(jī)制：

當(dāng)一個(gè)分片備份并填滿隊(duì)列時(shí)，Prometheus將阻止從WAL中讀取數(shù)據(jù)到任何分片。（關(guān)于這點(diǎn)就涉及到對(duì)以上參數(shù)優(yōu)化，后面參數(shù)capacity部分講解）
遠(yuǎn)程端點(diǎn)寫入失敗會(huì)進(jìn)行重試操作，并且保證數(shù)據(jù)不會(huì)丟失，除非遠(yuǎn)程端點(diǎn)保持關(guān)閉狀態(tài)超過2小時(shí)，因?yàn)?小時(shí)后，WAL將被壓縮，尚未發(fā)送的數(shù)據(jù)將丟失。重試時(shí)間見下面參數(shù)：min_backoff和max_backoff。

內(nèi)存使用：

使用遠(yuǎn)程寫入會(huì)增加Prometheus的內(nèi)存占用量。大多數(shù)用戶報(bào)告的內(nèi)存使用量增加了約25％，但這取決于數(shù)據(jù)的形狀。對(duì)于WAL中的每個(gè)系列，遠(yuǎn)程寫代碼都會(huì)緩存系列ID到標(biāo)簽值的映射，從而顯著增加內(nèi)存使用率。除了series緩存之外，每個(gè)分片及其隊(duì)列還會(huì)增加內(nèi)存使用量。當(dāng)進(jìn)行優(yōu)化調(diào)整時(shí)，請(qǐng)考慮減少max_shards增加的數(shù)量，同時(shí)提高capacity和max_samples_per_send參數(shù)的大小從而避免無意間耗盡內(nèi)存。默認(rèn)capacity和 max_samples_per_send的取值將使得每每個(gè)shard使用內(nèi)存小于100kb。

remote write queue的可調(diào)參數(shù)：

# Configures the queue used to write to remote storage.
queue_config:# Number of samples to buffer per shard before we block reading of more# samples from the WAL. It is recommended to have enough capacity in each# shard to buffer several requests to keep throughput up while processing# occasional slow remote requests.[ capacity: <int> | default = 2500 ]# Maximum number of shards, i.e. amount of concurrency.[ max_shards: <int> | default = 200 ]# Minimum number of shards, i.e. amount of concurrency.[ min_shards: <int> | default = 1 ]# Maximum number of samples per send.[ max_samples_per_send: <int> | default = 500]# Maximum time a sample will wait in buffer.[ batch_send_deadline: <duration> | default = 5s ]# Initial retry delay. Gets doubled for every retry.[ min_backoff: <duration> | default = 30ms ]# Maximum retry delay.[ max_backoff: <duration> | default = 5s ]# Retry upon receiving a 429 status code from the remote-write storage.# This is experimental and might change in the future.[ retry_on_http_429: <boolean> | default = false ]

max_shards和max_samples_per_send決定了Prometheus寫入遠(yuǎn)程存儲(chǔ)的最大TPS

參數(shù)解析：

• 1、capacity

  定義：每個(gè)內(nèi)存隊(duì)列（shard：分片）的容量。

  一旦WAL被阻塞，就無法將樣本附加到任何分片，并且所有吞吐量都將停止。所以在大多數(shù)情況下，單個(gè)隊(duì)列容量應(yīng)足夠打以避免阻塞其他分片，但是太大的容量可能會(huì)導(dǎo)致過多的內(nèi)存消耗，并導(dǎo)致重新分片期間清除隊(duì)列的時(shí)間更長。

• 2、max_shards

  顧名思義，最大的分片數(shù)（即隊(duì)列數(shù)），也可以理解為遠(yuǎn)程寫的并行度。peometheus遠(yuǎn)程寫的時(shí)候會(huì)使用所有的分片，只有在寫隊(duì)列落后于遠(yuǎn)程寫的速度，使用的隊(duì)列數(shù)會(huì)達(dá)到max_shards,目的在于提高遠(yuǎn)程寫的吞吐量。

  PS：在操作過程中，Prometheus將根據(jù)傳入的采樣率，未發(fā)送的未處理樣本數(shù)以及發(fā)送每個(gè)樣本所花費(fèi)的時(shí)間，連續(xù)計(jì)算要使用的最佳分片數(shù)。（實(shí)際的分片數(shù)是動(dòng)態(tài)調(diào)整的）

• 3、min_shards
  最小分片配置Prometheus使用的最小分片數(shù)量，并且是遠(yuǎn)程寫入開始時(shí)使用的分片數(shù)量。如果遠(yuǎn)程寫入落后，Prometheus將自動(dòng)擴(kuò)大分片的數(shù)量，因此大多數(shù)用戶不必調(diào)整此參數(shù)。但是，增加最小分片數(shù)將使Prometheus在計(jì)算所需分片數(shù)時(shí)避免在一開始就落后。

• 4、max_samples_per_send

  定義：每次遠(yuǎn)程寫發(fā)送的最大指標(biāo)數(shù)量，即批處理；

  這個(gè)值依賴于遠(yuǎn)程存儲(chǔ)系統(tǒng)，對(duì)于一些系統(tǒng)而言，在沒有顯著增加延遲的情況下發(fā)送更多指標(biāo)數(shù)據(jù)而運(yùn)行良好，然而，對(duì)于另外一些系統(tǒng)而言，每次請(qǐng)求中發(fā)送大量指標(biāo)數(shù)據(jù)可能導(dǎo)致其出現(xiàn)故障，使用的默認(rèn)值是適用于絕大多數(shù)系統(tǒng)的。

• 5、batch_send_deadline

  定義：單一分片批量發(fā)送指標(biāo)數(shù)據(jù)的最大等待時(shí)間；

  即使排隊(duì)的分片尚未達(dá)到max_samples_per_send，也會(huì)發(fā)送請(qǐng)求。 對(duì)于對(duì)延遲不敏感的小批量系統(tǒng)，可以增加批量發(fā)送的截止時(shí)間，以提高請(qǐng)求效率。

• 6、min_backoff

  定義：遠(yuǎn)程寫失敗的最小等待時(shí)間；

  min_backoff是第一次的重試等待時(shí)間，第二次等待時(shí)間是其2倍，以此類推，直到max_backoff的值；

• 7、max_backoff

  定義：遠(yuǎn)程寫失敗的最大等待時(shí)間；

推薦做法：

• 當(dāng)進(jìn)行優(yōu)化調(diào)整時(shí)，請(qǐng)考慮減少max_shards的數(shù)量，同時(shí)提高capacity和max_samples_per_send參數(shù)的大小從而避免無意間耗盡內(nèi)存

• max_shards和max_samples_per_send決定了Prometheus寫入遠(yuǎn)程存儲(chǔ)的最大TPS，
  max_shards * max_samples_per_send決定了TPS的值，所以要考慮這兩個(gè)的合理搭配

給出阿里云prometheus對(duì)接TSDB調(diào)優(yōu)參考表：

遠(yuǎn)程讀優(yōu)化：remote_read

默認(rèn)情況下，prometheus除了使用remote_write將數(shù)據(jù)發(fā)送到遠(yuǎn)程時(shí)序數(shù)據(jù)庫，同時(shí)還會(huì)按照以下參數(shù)來保留數(shù)據(jù)到本地自己的時(shí)序數(shù)據(jù)庫，兩者取最先達(dá)到限制的：

--storage.tsdb.retention.time=30d
--storage.tsdb.retention.size=512MB

也就說默認(rèn)情況下，prometheus保存了兩份數(shù)據(jù)，一份到遠(yuǎn)程時(shí)序數(shù)據(jù)庫，一份在本地

那么讀取的時(shí)候是讀取遠(yuǎn)程的還是讀取本地是由read_recent參數(shù)決定

# Whether reads should be made for queries for time ranges that
# the local storage should have complete data for.
[ read_recent: <boolean> | default = false ]

read_recent作用：

• 當(dāng)設(shè)置為 true 時(shí)，所有查詢都將從遠(yuǎn)程和本地存儲(chǔ)中得到答復(fù)。
• 當(dāng)為 false（默認(rèn)值）時(shí)，任何可以從本地存儲(chǔ)完全回答的查詢都不會(huì)發(fā)送到遠(yuǎn)程端點(diǎn)

推薦做法：

• 通過storage.tsdb.retention.time與storage.tsdb.retention.size控制緩存短期數(shù)據(jù)在本地
• 配置read_recent為false，使得本地能查詢到的數(shù)據(jù)都優(yōu)先在本地進(jìn)行查詢