リモート書き込みチューニング

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_samples_per_sendを増やしながらmax_shardsを減らすことを検討してください。capacity: 10000 および max_samples_per_send: 2000 のデフォルト値は、シャードあたりのメモリ使用量を 2 MB 未満に制限します。

リモート書き込みは CPU とネットワークの使用量も増加させます。しかし、上記と同じ理由で、どの程度増加するかを予測することは困難です。Prometheus サーバーがリモート書き込みによるサンプル送信に遅れをとっている場合（prometheus_remote_storage_samples_pending）、CPU とネットワークの飽和を確認することは一般的に良い実践です。

パラメータ

関連するすべてのパラメータは、リモート書き込み設定の queue_config セクションにあります。

capacity

容量は、WAL からの読み込みをブロックする前に、シャードごとにメモリにキューイングされるサンプルの数を示します。WAL がブロックされると、どのシャードにもサンプルを追加できなくなり、すべてのスループットが停止します。

ほとんどの場合、他のシャードをブロックしないように、容量は max_samples_per_send の 3〜10 倍に設定する必要がありますが、容量が大きすぎるとメモリ消費量が増加し、リシャーディング中にキューをクリアするのに時間がかかる場合があります。max_samples_per_send の 3〜10 倍に容量を設定することが推奨されます。

max_shards

Max shards は、Prometheus が各リモート書き込みキューに使用するシャードの最大数、つまり並列度を設定します。Prometheus はシャードを多用しないように試みますが、キューが遅延すると、リモート書き込みコンポーネントはスループットを向上させるためにシャード数を max shards まで増やします。非常に低速なエンドポイントにリモート書き込みを行わない限り、max_shards をデフォルト値以上に増やすことはほとんどありません。ただし、リモートエンドポイントを圧倒する可能性がある場合や、データがバックアップされている場合にメモリ使用量を削減するために、max shards を減らす必要がある場合があります。

min_shards

Min shards は Prometheus が使用するシャードの最小数を設定し、リモート書き込みが開始されるときに使用されるシャード数です。リモート書き込みが遅延した場合、Prometheus は自動的にシャード数をスケールアップするため、ほとんどのユーザーはこのパラメータを調整する必要はありません。ただし、必要なシャード数を計算している間に Prometheus が遅延するのを避けるために、min shards を増やすと効果的です。

max_samples_per_send

Max samples per send は、使用中のバックエンドに応じて調整できます。多くのシステムは、レイテンシを大幅に増加させることなく、バッチごとに多くのサンプルを送信することで非常にうまく機能します。他のバックエンドは、各リクエストで多数のサンプルを送信しようとすると問題が発生する可能性があります。デフォルト値はほとんどのシステムで機能するのに十分小さいです。

batch_send_deadline

Batch send deadline は、単一シャードあたりの送信間の最大時間を設定します。キューイングされたシャードが max_samples_per_send に達していなくても、リクエストが送信されます。バッチ送信デッドラインは、リクエスト効率を高めるために、レイテンシに敏感でない低ボリュームシステムで増加させることができます。

min_backoff

Min backoff は、失敗したリクエストをリトライする前に待機する最小時間を制御します。バックオフを増やすと、リモートエンドポイントがオンラインに戻ったときにリクエストが分散されます。バックオフ間隔は、max_backoff まで各失敗したリクエストで倍増されます。

max_backoff

Max backoff は、失敗したリクエストをリトライする前に待機する最大時間を制御します。