次の方法で共有


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"

次のステップ