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とラベル値のマッピングをキャッシュするため、大量のシリーズの変更によりメモリ使用量が大幅に増加します。
シリーズキャッシュに加えて、各シャードとそのキューによりメモリ使用量が増加します。シャードメモリはシャード数 * (capacity + max_samples_per_send)に比例します。チューニングする際には、意図せずメモリ不足になるのを避けるために、capacityとmax_samples_per_sendの増加とともにmax_shardsを削減することを検討してください。capacity: 10000とmax_samples_per_send: 2000のデフォルト値により、シャードあたりのメモリ使用量は2MB未満に制限されます。
リモート書き込みは、CPUとネットワークの使用量も増加させます。ただし、上記と同じ理由で、どの程度増加するかを予測することは困難です。Prometheusサーバーがリモート書き込みを介してサンプルの送信に遅れる場合（prometheus_remote_storage_samples_pending）、CPUとネットワークの飽和状態を確認することをお勧めします。
関連するすべてのパラメーターは、リモート書き込み設定のqueue_configセクションにあります。
capacityCapacityは、WALからの読み取りをブロックする前に、シャードごとにメモリにキューに入れられるサンプル数を制御します。WALがブロックされると、サンプルをどのシャードにも追加できなくなり、すべてのスループットが停止します。
Capacityは、ほとんどの場合、他のシャードのブロックを回避するのに十分な高さにする必要がありますが、Capacityが高すぎると、過剰なメモリ消費と、リシャード中のキューのクリアにかかる時間の増加につながる可能性があります。Capacityをmax_samples_per_sendの3〜10倍に設定することをお勧めします。
max_shardsMax shardsは、各リモート書き込みキューに対してPrometheusが使用するシャード数、つまり並列処理の最大数を設定します。Prometheusはあまり多くのシャードを使用しないようにしようとしますが、キューが遅れると、リモート書き込みコンポーネントはスループットを高めるためにシャード数を最大シャード数まで増加させます。非常に遅いエンドポイントにリモート書き込みしない限り、max_shardsをデフォルト値を超えて増加させる必要性は低いでしょう。ただし、リモートエンドポイントを圧倒する可能性がある場合、またはデータがバックアップされている場合のメモリ使用量を削減するために、max shardsを減らす必要がある場合があります。
min_shardsMin shardsは、Prometheusが使用するシャードの最小数を設定し、リモート書き込み開始時に使用されるシャード数です。リモート書き込みが遅れると、Prometheusはシャード数を自動的にスケールアップするため、ほとんどのユーザーがこのパラメーターを調整する必要はありません。ただし、min shardsを増やすと、必要なシャード数の計算中にPrometheusが遅れるのを回避できます。
max_samples_per_send使用しているバックエンドに応じて、Max samples per sendを調整できます。多くのシステムは、レイテンシの顕著な増加なしに、バッチごとに多くのサンプルを送信することで非常にうまく機能します。他のバックエンドは、各リクエストで大量のサンプルを送信しようとすると問題が発生します。デフォルト値は、ほとんどのシステムで機能するのに十分小さいです。
batch_send_deadlineBatch send deadlineは、単一シャードの送信間の最大時間を設定します。キューに入れられたシャードがmax_samples_per_sendに達していなくても、リクエストが送信されます。レイテンシに影響を受けない低容量のシステムでは、リクエストの効率を高めるために、Batch send deadlineを増やすことができます。
min_backoffMin backoffは、失敗したリクエストを再試行する前に待つ最小時間を制御します。バックオフを増やすと、リモートエンドポイントがオンラインに戻ったときにリクエストが分散されます。バックオフ間隔は、失敗したリクエストごとにmax_backoffまで2倍になります。
max_backoffMax backoffは、失敗したリクエストを再試行する前に待つ最大時間を制御します。
このドキュメントはオープンソースです。問題点やプルリクエストを提出して、改善にご協力ください。