リモート書き込みのチューニング
Prometheusはリモート書き込みの適切なデフォルトを実装していますが、多くのユーザーは異なる要件を持っており、リモート設定を最適化したいと考えています。
このページでは、リモート書き込みの設定で利用できるチューニングパラメータについて説明します。
リモート書き込みの特性
各リモート書き込み先は、ライトアヘッドログ(WAL)から読み取り、サンプルをシャードが所有するインメモリキューに書き込み、その後設定されたエンドポイントにリクエストを送信するキューを開始します。データの流れは次のようになります。
|--> queue (shard_1) --> remote endpoint
WAL --|--> queue (shard_...) --> remote endpoint
|--> queue (shard_n) --> remote endpoint
1つのシャードがバックアップしてキューをいっぱいになると、PrometheusはWALからの読み取りをブロックし、すべてのシャードへのサンプル追加を停止します。リモートエンドポイントが2時間以上ダウンしない限り、データ損失なしで失敗したリクエストは再試行されます。2時間後、WALは圧縮され、送信されていないデータは失われます。
動作中、Prometheusは受信サンプルレート、送信されていない未処理サンプルの数、各サンプルの送信にかかる時間に基づいて、使用する最適なシャード数を継続的に計算します。
リソース使用量
リモート書き込みを使用すると、Prometheusのメモリフットプリントが増加します。ほとんどのユーザーは約25%のメモリ使用量増加を報告していますが、この数値はデータの形状に依存します。WAL内の各シリーズについて、リモート書き込みコードはシリーズIDからラベル値へのマッピングをキャッシュするため、大量のシリーズのチャーンが発生するとメモリ使用量が大幅に増加します。
シリーズキャッシュに加えて、各シャードとそのキューもメモリ使用量を増加させます。シャードのメモリは、シャード数 * (容量 + max_samples_per_send)
に比例します。チューニング時には、誤ってメモリ不足にならないように、max_shards
を減らし、capacity
とmax_samples_per_send
を増やすことを検討してください。capacity: 10000
とmax_samples_per_send: 2000
のデフォルト値は、シャードあたりのメモリ使用量を2MB未満に制限します。
リモート書き込みはCPUとネットワークの使用量も増加させます。しかし、上記と同じ理由で、どれだけ増加するかを予測するのは困難です。Prometheusサーバーがリモート書き込み(prometheus_remote_storage_samples_pending
)でサンプルを送信するのに遅れをとっている場合は、CPUとネットワークの飽和を確認するのが一般的に良い習慣です。
パラメータ
関連するすべてのパラメータは、リモート書き込み設定のqueue_config
セクションにあります。
capacity
容量は、WALからの読み取りをブロックする前に、シャードごとにメモリ内でキューに入れられるサンプルの数を制御します。WALがブロックされると、サンプルをどのシャードにも追加できなくなり、すべてのスループットが停止します。
容量はほとんどの場合、他のシャードをブロックしないように十分に高く設定する必要がありますが、容量が大きすぎると過剰なメモリ消費や、再シャーディング中のキューのクリアに時間がかかる可能性があります。容量はmax_samples_per_send
の3〜10倍に設定することをお勧めします。
max_shards
max shardsは、Prometheusが各リモート書き込みキューに使用するシャードの最大数、つまり並列度を設定します。Prometheusはシャードを使いすぎないようにしますが、キューが遅れると、リモート書き込みコンポーネントはスループットを上げるためにシャードの数をmax shardsまで増やします。非常に低速なエンドポイントにリモート書き込みを行わない限り、max_shards
をデフォルト以上に増やす必要はほとんどありません。ただし、リモートエンドポイントに過負荷をかける可能性がある場合や、データがバックアップされたときにメモリ使用量を削減する必要がある場合は、max shardsを減らす必要があるかもしれません。
min_shards
min shardsは、Prometheusが使用するシャードの最小数を設定し、リモート書き込みが開始されるときに使用されるシャードの数です。リモート書き込みが遅れると、Prometheusは自動的にシャードの数をスケールアップするため、ほとんどのユーザーはこのパラメータを調整する必要はありません。ただし、min shardsを増やすことで、Prometheusは必要なシャードの数を計算している間に最初から遅れるのを避けることができます。
max_samples_per_send
max samples per sendは、使用しているバックエンドに応じて調整できます。多くのシステムは、バッチあたりにより多くのサンプルを送信しても、レイテンシが大幅に増加することなく非常にうまく機能します。他のバックエンドでは、各リクエストで大量のサンプルを送信しようとすると問題が発生する可能性があります。デフォルト値は、ほとんどのシステムで機能するのに十分小さいです。
batch_send_deadline
batch send deadlineは、単一シャードの送信間の最大時間を設定します。キューに入っているシャードがmax_samples_per_send
に達していなくても、リクエストが送信されます。レイテンシに敏感ではない低容量システムの場合、リクエスト効率を高めるためにbatch send deadlineを増やすことができます。
min_backoff
min backoffは、失敗したリクエストを再試行するまでの最小待機時間を制御します。バックオフを増やすと、リモートエンドポイントがオンラインに戻ったときにリクエストが分散されます。バックオフ間隔は、max_backoff
まで失敗したリクエストごとに2倍になります。
max_backoff
max backoffは、失敗したリクエストを再試行するまでの最大待機時間を制御します。