Azure Monitor で大規模に Prometheus メトリックをスクレイピングする

この記事では、Prometheus 用の Azure Monitor 管理サービスに関するメトリックを大規模に収集するときに予想されるパフォーマンスに関するガイダンスを提供します。

CPU とメモリ

CPU とメモリの使用量は、各サンプルのバイト数およびスクレイピングされたサンプル数と関連付けられます。 これらのベンチマークは、スクレイピングされた既定のターゲット、スクレイピングされたカスタム メトリックのボリューム、ノードの数、ポッドの数、コンテナーの数に基づいています。 使用量はメトリックあたりの時系列の数とバイト数に応じて大きく異なる可能性があるので、これらの数値は参照用です。

現在、ポッドあたりのボリュームの上限は、サンプルあたりのバイト数に応じて、1 分あたり約 300 万から 350 万までの数のサンプルです。

エージェントは、既定で 2 つのレプリカ (メモリ使用率に基づいて HPA によって自動的に構成される) とメトリックをスクレイピングするための DaemonSet を含むデプロイで構成されます。 デーモンセットは、cAdvisor、kubelet、ノード エクスポーターなどのノード レベルのターゲットをスクレイピングします。 静的構成を使用して、カスタム ターゲットをノード レベルでスクレイピングするように構成することもできます。 レプリカ セットは、kube-state-metrics や、サービス検出を利用するカスタム スクレイピング ジョブなど、他のすべてをスクレイピングします。

レプリカの場合の小規模クラスターと大規模クラスターの比較

デーモンセットの場合の小規模クラスターと大規模クラスターの比較

カスタム メトリックがさらに多い場合、カスタム メトリックのボリュームによっては単一ポッドはレプリカ ポッドと同じように動作します。

リソースが多いノードプール上で ama-metrics レプリカ ポッドをスケジュールする

ポッドあたりのメトリックが大量にある場合は、十分な CPU とメモリを備えたノードが必要です。 ama-metrics レプリカ ポッドが十分なリソースを持つノードまたはノード プールでスケジュールされていない場合は、OOMKilled が発生し、CrashLoopBackoff に入る可能性があります。 これを修正するには、(azuremonitor/metrics.replica.preferred=true内の) リソースが多いクラスター上のノードまたはノード プールにラベル を追加します。 これにより、レプリカ ポッドがそれらのノードでスケジュールされます。 また、より大きなノードを使用する追加のシステム プールを作成し、同じラベルを追加することもできます。 プール内の新しいノードもスケジュールに使用できるように、個々のノードではなくノード プールにラベルを付けることをお勧めします。

kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"

次のステップ

• Prometheus データ収集に関する問題のトラブルシューティングを行います。