Azure Monitor で大規模に Prometheus メトリックをスクレイピングする
この記事では、Prometheus 用の Azure Monitor 管理サービスに関するメトリックを大規模に収集するときに予想されるパフォーマンスに関するガイダンスを提供します。
CPU とメモリ
CPU とメモリの使用量は、各サンプルのバイト数およびスクレイピングされたサンプル数と関連付けられます。 これらのベンチマークは、スクレイピングされた既定のターゲット、スクレイピングされたカスタム メトリックのボリューム、ノードの数、ポッドの数、コンテナーの数に基づいています。 使用量はメトリックあたりの時系列の数とバイト数に応じて大きく異なる可能性があるので、これらの数値は参照用です。
現在、ポッドあたりのボリュームの上限は、サンプルあたりのバイト数に応じて、1 分あたり約 300 万から 350 万までの数のサンプルです。 この制限は、シャーディングが今後追加されるときに対応されます。
エージェントは、メトリックをスクレイピングするための 1 つのレプリカとデーモンセットがある 1 つのデプロイで構成されます。 デーモンセットは、cAdvisor、kubelet、ノード エクスポーターなどのノード レベルのターゲットをスクレイピングします。 静的構成を使用して、カスタム ターゲットをノード レベルでスクレイピングするように構成することもできます。 レプリカセットは、kube-state-metrics や、サービス検出を利用するカスタム スクレーピング ジョブなど、他のすべてをスクレイピングします。
レプリカの場合の小規模クラスターと大規模クラスターの比較
| スクレーピングのターゲット | 送信されるサンプル数/分 | ノード数 | ポッド数 | Prometheus-Collector の CPU 使用量 (コア数) | Prometheus-Collector のメモリ使用量 (バイト数) |
|---|---|---|---|---|---|
| 既定のターゲット | 11,344 | 3 | 40 | 12.9 mc | 148 Mi |
| 既定のターゲット | 260,000 | 340 | 13000 | 1.10 c | 1.70 GB |
| 既定のターゲット + カスタム ターゲット |
356 万 | 340 | 13000 | 5.13 c | 9.52 GB |
デーモンセットの場合の小規模クラスターと大規模クラスターの比較
| スクレーピングのターゲット | 送信されるサンプル数/分の合計 | 送信されるサンプル数/分/ポッド | ノード数 | ポッド数 | Prometheus-Collector の CPU 使用量の合計 (コア数) | Prometheus-Collector のメモリ使用量の合計 (バイト数) | Prometheus-Collector の CPU 使用量/ポッド (コア数) | Prometheus-Collector のメモリ使用量/ポッド (バイト数) |
|---|---|---|---|---|---|---|---|---|
| 既定のターゲット | 9,858 | 3,327 | 3 | 40 | 41.9 mc | 581 Mi | 14.7 mc | 189 Mi |
| 既定のターゲット | 230 万 | 14,400 | 340 | 13000 | 805 mc | 305.34 GB | 2.36 mc | 898 Mi |
カスタム メトリックがさらに多い場合、カスタム メトリックのボリュームによっては単一ポッドはレプリカ ポッドと同じように動作します。
リソースが多いノードプール上で ama-metrics レプリカ ポッドをスケジュールする
ポッドあたりのメトリックのボリュームが大きい場合は、必要な CPU とメモリの使用量を処理できるだけの大きさのノードが必要です。 十分なリソースがあるノードまたはノードプール上で ama-metrics レプリカ ポッドがスケジュール設定されていない場合は、OOMKilled を取得し続けて CrashLoopBackoff に移行する可能性があります。 この問題を解決するために、(システム ノードプール内に) リソースがより多いクラスター上にノードまたはノードプールがあり、そのノードでレプリカをスケジュール設定する場合は、ノードにラベル azuremonitor/metrics.replica.preferred=true を追加すると、このノードでレプリカ ポッドがスケジュール設定されます。 また、必要に応じて、より大きなノードを使用して追加のシステム プールを作成し、それらのノードまたはノードプールに同じラベルを追加することもできます。 また、ノードではなく、ノードプールにラベルを追加することをお勧めします。これにより、同じプール内の新しいノードも、このラベルがプール内のすべてのノードに適用可能な場合にスケジュール設定に使用できます。
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"