Prometheus 用 Azure Monitor マネージド サービスを使用すると、メトリックを大規模に収集して分析できます。 Prometheus メトリックは、Azure Monitor ワークスペースに格納されます。 ワークスペースでは、Azure Managed Grafana、PromQL を使用した Azure Monitor メトリック ス エクスプローラー、PromQL や Grafana などのオープン ソース ツールなどの分析ツールがサポートされています。
この記事では、データ インジェストの規模と増大する量に合わせて Azure Monitor ワークスペースを整理するためのベスト プラクティスについて説明します。
トポロジの設計基準
ほとんどのユース ケースでは、1 つの Azure Monitor ワークスペースで十分です。 一部の組織では、要件をより適切に満たすために複数のワークスペースを作成します。 追加のワークスペースを作るための適切な条件を見極めながら、管理オーバーヘッドを最小限に抑えるように最適化し、要件に適合する最小数のワークスペースを作成します。
Azure Monitor ワークスペースを複数のワークスペースに分割しなければならないシナリオを次に示します。
| シナリオ | ベスト プラクティス |
|---|---|
| ソブリン クラウド | 複数のソブリン クラウドを使用する場合は、各クラウドに Azure Monitor ワークスペースを作成します。 |
| コンプライアンスまたは規制の要件 | 特定のリージョンでのデータの保存を義務付ける規制の対象となる場合は、要件に従ってリージョンごとに Azure Monitor ワークスペースを作成します。 |
| 地域別の拡張 | リージョンのアカウントを持つ大規模なサービスや金融機関など、リージョンで多様な組織のメトリックを管理する場合は、リージョンごとに Azure Monitor ワークスペースを作成します。 |
| Azure テナント | 複数の Azure テナントがある場合は、各テナントで Azure Monitor ワークスペースを作成します。 テナント間でのデータのクエリはサポートされていません。 |
| デプロイ環境 | デプロイ環境ごとに個別のワークスペースを作成して、開発、テスト、運用前、運用環境の個別のメトリックを維持します。 |
| サービスの制限とクォータ | Azure Monitor ワークスペースには既定のインジェスト制限があり、サポート チケットを開くことで増やすことができます。 制限に近づいている場合、またはインジェストの制限を超えると予想される場合は、増加を要求するか、2 つ以上のワークスペースに分割することを検討してください。 |
サービスの制限とクォータ
Azure Monitor ワークスペースには既定のクォータと、1 分間に 100 万件のイベントがインジェストされるメトリクスに対する制限があります。 使用量が増加し、より多くのメトリックを取り込む必要がある場合は、増加を要求できます。 容量要件が非常に大きく、データ インジェストのニーズが 1 つの Azure Monitor ワークスペースの制限を超えている場合は、複数の Azure Monitor ワークスペースの作成を検討してください。 Azure Monitor ワークスペース プラットフォーム メトリックを使用して、使用率と制限を監視します。 制限とクォータの詳細については、Azure Monitor サービスの制限とクォータについての記事をご覧ください。
Azure Monitor ワークスペースの制限とクォータを管理するために、次のベスト プラクティスを検討してください。
| ベスト プラクティス | 説明 |
|---|---|
| インジェストの制限と使用率に関するアラートを監視して作成する。 | Azure portal で Azure Monitor ワークスペースに移動します。 メトリックに移動し、メトリックのアクティブな時系列使用率と 1 分あたりのイベントの取り込まれた使用率が 100% を下回っていることを確認します。 使用率を監視し、使用率が制限の 80% を超えた場合に発生するよう、Azure Monitor アラートを設定します。 使用率と制限の監視の詳細については、サービスの制限とクォータを監視する方法についての記事をご覧ください。 |
| 使用率が現在の制限の 80% を超えた場合に、制限の引き上げを要求する。 | Azure の使用量が増加すると、取り込まれるデータの量が増える可能性があります。 データ インジェストがインジェスト制限の 80% を超えているか、80% に近い場合は、制限の引き上げを要求することを推奨します。 制限の引き上げを要求するには、サポート チケットを開きます。 サポート チケットを送信するには、「Azure サポート要求を作成する」をご覧ください。 |
| 予想されるスケールを見積もる。 | 使用量が増加し、より多くのメトリックをワークスペースに取り込むにつれ、予想されるスケールと増加率を見積もります。 予測に基づいて、制限の引き上げを要求します。 |
| Azure Monitor サイドカー コンテナーを使用したリモート書き込みによるインジェスト。 | Azure Monitor サイドカー コンテナーとリモート書き込みを使用してメトリックを Azure Monitor ワークスペースに取り込む場合は、次の制限を考慮してください。 |
| DCR/DCE の制限。 | 制限は、Prometheus メトリックを Azure Monitor ワークスペースに送信するデータ収集規則 (DCR) とデータ収集エンドポイント (DCE) に適用されます。 これらの制限については、Prometheus サービスの制限についての記事をご覧ください。 これらの制限を増やすことはできません。 インジェスト負荷を複数のエンドポイントに分散させるために、追加の DCR と DCE を作成することを検討してください。 このアプローチは、パフォーマンスの最適化に役立ち、データが効率的に処理されます。 DCR と DCE の作成の詳細については、「 Prometheus メトリックを取り込むための既存の Azure Monitor ワークスペースのカスタム データ収集エンドポイント (DCE) とカスタム データ収集規則 (DCR) を作成する方法」を参照してください。 |
大量のデータに対するパフォーマンスの最適化
インジェスト
インジェストを最適化するには、次のベスト プラクティスを検討してください。
| ベスト プラクティス | 説明 |
|---|---|
| カーディナリティが高いメトリックを特定します。 | カーディナリティが高いメトリック、または多数の時系列を生成しているメトリックを特定します。 カーディナリティの高いメトリックを特定した後、不要なラベルを削除して時系列の数を減らすためにそれらを最適化します。 |
| Prometheus 構成を使用してインジェストを最適化します。 | Azure Managed Prometheus には、Configmap が用意されています。これは、インジェストを最適化するために構成し、使用できます。 詳細については、ama-metrics-settings-configmap および、ama-metrics-prometheus-config-configmap をご覧ください。 これらの構成は、Prometheus 構成ファイルと同じ形式に従います。 コレクションのカスタマイズの詳細については、「Prometheus 用 Azure Monitor マネージド サービスで Prometheus メトリックのスクレイピングをカスタマイズする」をご覧ください。 たとえば、次の点を考えてみましょう。 scrape_interval と scrape_timeout を調整します。metric_relabel_configs を使用して、インジェストから特定のラベルを削除します。 詳細については、Prometheus 構成についての記事をご覧ください。 |
configmap で必要に応じて設定を変更し、クラスターの kube-system 名前空間に configmap を適用します。 Azure Monitor ワークスペースへのリモート書き込みを使用している場合は、インジェスト中にカスタマイズを Prometheus 構成に直接適用します。
クエリ
クエリを最適化するには、次のベスト プラクティスを検討してください。
レコーディング ルールを使用してクエリのパフォーマンスを最適化する
Prometheus のレコーディング ルールは、頻繁に使用されるクエリまたは計算コストの高いクエリを事前計算するために使用され、クエリの効率と速度が向上します。 レコーディング ルールは、生データのクエリが遅くなり、リソースを大量に消費する可能性がある大量のメトリックに特に役立ちます。 詳細については、「レコーディング ルール」をご覧ください。 Azure Managed Prometheus は、 Azure Managed Prometheus ルール グループを使用して記録ルールを作成および更新するための、マネージドでスケーラブルな方法を提供します。
ルール グループが作成されると、Azure Managed Prometheus が自動的に読み込んで評価を開始します。 他の Prometheus メトリックと同様の、Azure Monitor ワークスペースのクエリ ルール グループ。
レコーディング ルールには、次の利点があります。
クエリのパフォーマンスを向上させる 記録ルールを使用すると、複雑なクエリを事前に計算できるため、後ですばやくクエリを実行できます。 複雑なクエリを事前計算することで、これらのメトリックを照会する際に Prometheus の負荷が軽減されます。
効率とクエリ時間の短縮 記録ルールはクエリ結果を事前に計算し、データのクエリにかかる時間を短縮します。 これは、複数のパネルまたはカーディナリティの高いメトリックを含むダッシュボードで特に便利です。
簡略 記録ルールは、事前計算済みのメトリックを参照できるため、Grafana やその他の視覚化ツールのクエリを簡略化します。
次の例は、Azure Managed Prometheus ルール グループで定義されているレコーディング ルールを示しています。
"record": "job:request_duration_seconds:avg ",
"expression": "avg(rate(request_duration_seconds_sum[5m])) by (job)",
"labels": { "workload_type": "job"
},
"enabled": true
より複雑なメトリックの場合は、複数のメトリックを集計するレコーディング ルールを作成するか、より高度な計算を実行します。 次の例では、instance:node_cpu_utilisation:rate5m は CPU がアイドル状態でないときに CPU 使用率を計算します
"record": "instance:node_cpu_utilisation:rate5m",
"expression": "1 - avg without (cpu) (sum without (mode)(rate(node_cpu_seconds_total{job=\"node\", mode=~\"idle|iowait|steal\"}[5m])))",
"labels": {
"workload_type": "job"
},
"enabled": true
レコーディング ルールを最適化するには、次のベスト プラクティスを検討してください。
| ベスト プラクティス | 説明 |
|---|---|
| 量の多いメトリックを特定する。 | 頻繁にクエリを実行し、カーディナリティが高いメトリックに焦点を当てます。 |
| ルールの評価間隔を最適化する。 | データの鮮度と計算負荷のバランスを取るために、レコーディング ルールの評価間隔を調整します。 |
| パフォーマンスを監視する。 | クエリのパフォーマンスを監視し、必要に応じてレコーディング ルールを調整します。 |
| スコープを制限してルールを最適化する。 | レコーディング ルールをより高速にするには、スコープ内のルールを特定のクラスターに制限します。 詳細については、「特定のクラスターへのルールの制限」をご覧ください。 |
クエリでのフィルターの使用
フィルターを使用して Prometheus クエリを最適化するには、必要なデータのみを返すようにクエリを調整し、処理済みデータの量を減らし、パフォーマンスを向上させる必要があります。 Prometheus クエリを絞り込む一般的な手法を次に示します。
| ベスト プラクティス | 説明 |
|---|---|
| ラベル フィルターを使用する。 | ラベル フィルターは、必要なものだけにデータを絞り込むのに役立ちます。 Prometheus では、{label_name="label_value"} 構文を使用してフィルター処理できます。 複数のクラスターに対して多数のメトリックがある場合、時系列を制限する簡単な方法は、cluster フィルターを使用することです。たとえば、 container_cpu_usage_seconds_total のクエリではなく、クラスター container_cpu_usage_seconds_total{cluster="cluster1"} でフィルター処理します。 |
| 時間範囲セレクターを適用する。 | 特定の時間範囲を使用すると、クエリされるデータの量を大幅に削減できます。 たとえば、過去 7 日間のすべてのデータポイントを http_requests_total{job="myapp"} でクエリする代わりに、過去 1 時間を http_requests_total{job="myapp"}[1h] でクエリします。 |
| 集計とグループ化を使用する。 | 集計関数を使用すると、生データ ポイントの処理よりも効率的にデータを集計できます。 データを集計する場合は、by を使用して特定のラベルでグループ化するか、without を使用して特定のラベルを除外します。たとえば、ジョブ別にグループ化された要求を sum(rate(http_requests_total[5m])) by (job) で合計します。 |
| クエリの早い段階でフィルター処理する。 | データセットを最初から制限するには、クエリでできるだけ早くフィルターを適用します。 たとえば、sum(rate(http_requests_total[5m])) by (job) ではなく、最初にフィルター処理してから、sum(rate(http_requests_total{job="myapp"}[5m])) by (job) のように集計します。 |
| 可能な場合は正規表現を使用しない。 | 正規表現フィルターは強力ですが、計算コストも高くなります。 可能な限り完全一致を使います。 たとえば、http_requests_total{job=~"myapp.*"} の代わりに、http_requests_total{job="myapp"} を使用します。 |
| 履歴データにはオフセットを使用する。 | 現在のデータと履歴データを比較する場合は、offset 修飾子を使用します。たとえば、現在の要求を 24 時間前からの要求と比較するには、 rate(http_requests_total[5m]) - rate(http_requests_total[5m] offset 24h) を使用します。 |
| グラフ内のデータ ポイントを制限する。 | グラフを作成する場合は、表示パフォーマンスを向上させるためにデータ ポイントの数を制限します。 解像度を制御するには、ステップ パラメーターを使用します。 たとえば、Grafana では、 http_requests_total{job="myapp"}[1h:10s] でデータポイントを減らすためにステップ値を高く設定します。 |
並列クエリ
Prometheus で多数の並列クエリを実行すると、パフォーマンスのボトルネックが発生し、Prometheus サーバーの安定性に影響を与える可能性があります。 大量の並列クエリを効率的に処理するには、次のベスト プラクティスに従います。
| ベスト プラクティス | 説明 |
|---|---|
| クエリの負荷を分散する。 | 異なる時間間隔または Prometheus インスタンスにクエリを分散することで、クエリの負荷を分散します。 |
| クエリの時間差実行。 | クエリの同時実行のピークを回避するために、異なる間隔で実行するようにクエリをスケジュールします。 |
多くの並列クエリの実行で問題が引き続き発生する場合は、サポート チケットを作成して、クエリの制限の引き上げを要求します。
アラートとレコーディング ルール
アラートとレコーディング ルールを高スケール用に最適化する
Prometheus アラートとレコーディング ルールは、Prometheus ルール グループとして定義できます。 1 つのルール グループには、最大 20 個のアラートまたはレコーディング ルールを含めることができます。 必要なアラート/ルールの数に対応するために、ワークスペースごとに最大 500 のルール グループを作成します。 制限を増やすには、サポート チケットを開いてください
レコーディング ルールを定義する場合は、評価間隔を考慮して、ルールごとの時系列の数とルールの評価のパフォーマンスを最適化します。 評価間隔は 1 分から 24 時間です。 既定値は 1 分です。
Resource Health を使用して、レコーディング ルールの状態からクエリを表示する
ポータルで Prometheus ルール グループの正常性を表示するように Resource Health を設定します。 Resource Health を使用すると、正しくない構成やクエリ調整の問題など、レコーディング ルールの問題を検出できます。 Resource Health の設定の詳細については、「 Prometheus ルール グループのリソース正常性状態を表示する」を参照してください。