クラスターのサイズが大きくなると、Prometheus によって収集されるデータが増え、ある時点で、Prometheus エージェントが処理できるデータ量の限界に達します。最も一般的な障害モードは、時系列のカーディナリティの増加によるメモリ不足です。これが発生すると、より多くのメモリが必要になるため、Prometheus インスタンスが停止し始めます。つまり、スケーリングを開始する必要があります。
ソリューションを詳細に分析するために、Prometheus ソリューションをいつスケーリングする必要があるかを知るのに役立つさまざまなグラフを含むダッシュボードを提供します。
New Relic の Prometheus エージェントには、垂直または水平という 2 つの異なるスケーリング アプローチがあります。
垂直スケーリング
この種のスケーリングは複雑ではありません。これは、クラスター ノードが稼働している対応するマシンのメモリまたは CPU を更新するのと同じくらい簡単です。
ただし、このアプローチは大規模なクラスターにはスケーラブルではない可能性があります。または、ノードで非常に多くの GB のメモリを消費する単一のポッドを持ちたくないだけです。その場合は、水平スケーリングを使用する必要がある場合があります。
水平スケーリング
シャーディングとも呼ばれる水平スケーリングは、複数のプロメテウス サーバーをエージェント モードで実行してデータを収集できる構成パラメーターを設定することでサポートされます。
sharding.total_shards_count値を定義すると、デプロイされたStatefulSetには、定義した数のレプリカが含まれます。これを使用すると、 configuratorコンポーネントにはいくつかの追加のラベル変更ルールが自動的に含まれるため、各ターゲットは 1 つの Prometheus サーバーによってのみスクレイピングされます。これらのルールは、ターゲットのアドレスhash-modに依存しています。
各ターゲットのラベル変更ルールを設定するために、エージェントは指定されたターゲット__address__のハッシュを計算し、ハッシュにmodulusを適用します。モジュラスはシャードの総数です。次に、スクレイピングされたターゲットを含める必要があるシャードを認識します。
たとえば、 custom-values.yamlファイルに以下を含めるとします。
# (...)sharding: total_shards_count: 2# (...)次に、次を実行してリリースをアップグレードします。
$helm upgrade my-prometheus-release newrelic-prometheus-configurator/newrelic-prometheus-agent -f custom-values.yaml次に、2 つのプロメテウス サーバーが実行され、各ターゲットはそのうちの 1 つによってのみスクレイピングされます。
例の図は次のようになります。
ターゲットスクレーパーの識別
シャード ID ( StatefulSet Podの名前) がprometheus_serverラベルとしてすべての指標に追加され、これを使用して、どの Prometheus インスタンスが各ターゲットをスクレイピングしているかを理解できます。
アカウント内で Prometheus サーバー インスタンスを一意に識別するには、 cluster_nameとprometheus_serverのラベルを組み合わせて使用する必要があります。
自己指標
Prometheus サーバーの自己メトリックは、すべての Prometheus サーバーから収集する必要があるため、シャーディングが構成されている場合の追加のルールは、prometheus 自己メトリックを収集するジョブには適用されません。これが可能なのは、エージェントがstatic_targetジョブでskip_shardingフラグを受け入れるためです。このパラメータは、デフォルトのセルフ メトリクス ジョブですでに設定されています。
制限
extra_scrape_configsとして構成に追加のスクレイプ ジョブを含める場合、そのフィールドにはプロメテウス ジョブの生の定義が保持されるため、エージェントはシャーディング構成に対応するルールを含めず、その結果、対応するターゲットはすべてのプロメテウス サーバー。
現在、自動スケーリングはサポートされていません。シャードの数を増減するには、チャート設定を更新する必要があります。これにより、prometheus ポッドが再起動されます。