Azure Monitor Managed Service for Prometheus

解決する課題

Kubernetes やコンテナ環境では Prometheus がメトリクス監視の事実上の標準ですが、自前で Prometheus サーバーを運用すると、スケール・高可用性・長期保存・ストレージ管理がそのまま運用負担になります。Azure Monitor Managed Service for Prometheus は、その収集と保存をマネージドで肩代わりします。

• Prometheus サーバーのスケールや永続ストレージの運用から解放されたい
• AKS などKubernetes クラスターのメトリクスを Prometheus 形式のまま集めたい
• 既存の PromQL クエリやダッシュボード、アラート ルールを流用したい
• メトリクスを長期保存し、複数クラスターを横断して見たい（AWS の Amazon Managed Service for Prometheus に相当）

主要概念と用語

• Azure Monitor ワークスペース（Azure Monitor workspace）: Prometheus メトリクスの格納先となる専用リソース。Log Analytics ワークスペースとは別物で、メトリクス用のエンドポイント（クエリ/取り込み）を持つ
• Prometheus メトリクス: 時系列の数値で、メトリクス名とラベル（キーと値）の組で識別される。カウンター・ゲージ・ヒストグラムなどの型を持つ
• PromQL（Prometheus Query Language）: Prometheus 形式のメトリクスを集計・演算するクエリ言語。Managed Grafana やルールから利用する
• メトリクス アドオン / Managed Prometheus エージェント: AKS クラスターに導入され、Pod やノードからメトリクスをスクレイプして Azure Monitor ワークスペースへ送る収集コンポーネント
• スクレイプ（Scrape）: 対象が公開する HTTP のメトリクス エンドポイントを定期的に取得して値を集める Prometheus 流の収集方式
• リモート ライト（Remote Write）: 自前の Prometheus やコンテナ外のソースから、マネージド エンドポイントへメトリクスを書き込む取り込み経路
• Prometheus ルール グループ（記録ルール / アラート ルール）: PromQL を周期評価し、集計済み系列を作る記録ルールと、条件成立でアラートを発火するアラート ルール。Azure のリソースとして管理される
• Azure Managed Grafana: 可視化レイヤー。Azure Monitor ワークスペースをデータソースに PromQL でダッシュボードを描く

仕様・制限・クォータ

• メトリクスの格納先は Azure Monitor ワークスペースで、Log Analytics ワークスペースとは独立したリソース。クエリと取り込みはそれぞれ専用のエンドポイント経由で行う
• 取り込んだ Prometheus メトリクスは長期間保持され、保持は規定値として一定期間に設定される（具体的な保持日数や上限は変動するため公式値を確認する）
• クエリは PromQL に対応し、Managed Grafana やアラート ルールから利用する。Log Analytics の KQL とはクエリ言語が異なる
• 取り込みレートやアクティブ時系列数などにサービス上限があり、超過時は引き上げ申請を検討する（上限値は変動するため公式情報を確認する）
• AKS との連携ではメトリクス アドオンで収集を有効化でき、コンテナ外のソースはリモート ライトで取り込む
• Azure Monitor ワークスペースはリージョン リソースで、複数リージョンに展開する場合は配置とクエリ集約の方針を設計する

内部の仕組み

AKS クラスターでメトリクス収集を有効化すると、クラスター内に Managed Prometheus のエージェント（メトリクス アドオン）が配置されます。エージェントは Prometheus の設定に従って対象の HTTP エンドポイントを定期的にスクレイプし、収集したメトリクスを Azure Monitor ワークスペースの取り込みエンドポイントへ送ります。コンテナ外のソースや自前の Prometheus からは、リモート ライトでマネージド エンドポイントへ書き込めます。

格納されたメトリクスは、スケーラブルなバックエンドに保存され、クエリ用エンドポイント経由で PromQL から参照できます。可視化は主に Azure Managed Grafana が担います。Prometheus ルール グループは PromQL を周期的に評価し、記録ルールは集計済みの系列を生成、アラート ルールは条件成立でアラートを発火して、Azure Monitor のアクション グループへつなげます。

設計パターン / ベストプラクティス

• AKS はアドオンで標準化: 各クラスターでメトリクス アドオンを有効化し、収集設定を ConfigMap などで一元管理して構成のばらつきを抑える
• コンテナ外はリモート ライト: VM 上の Exporter や自前 Prometheus からは、リモート ライトで同じワークスペースへ集約する
• ラベル設計を最小限に: 高カーディナリティのラベル（ユーザー ID などほぼ一意な値）は時系列数を爆発させるため避け、集計に必要な軸に絞る
• 記録ルールで前計算: 重い PromQL は記録ルールで集計済み系列を作り、ダッシュボードやアラートの評価を軽くする
• ログとメトリクスで役割分担: 数値の傾向は Managed Prometheus、イベントやトレースの詳細は Log Analytics や Application Insights と分担する

運用・監視

• メトリクスが来ない → クラスターのメトリクス アドオンの有効化、スクレイプ設定、ワークスペースの関連付けを確認
• 一部の対象だけ取れない → スクレイプ対象のアノテーションや設定（ConfigMap）、対象側のメトリクス エンドポイント公開を確認
• 取り込みが頭打ち → アクティブ時系列数や取り込みレートの上限に達していないか、高カーディナリティなラベルがないかを点検
• アラートが鳴らない → Prometheus アラート ルールの評価・ルール グループの有効化、アクション グループの宛先を確認
• 可視化できない → Managed Grafana のデータソース設定と、クエリに必要な権限を確認

コスト

課金は主に取り込んだメトリクスのサンプル数を軸に発生し、クエリや可視化（Managed Grafana）など関連サービスのコストも併せて考えます。時系列数とサンプル頻度を抑えるのが効きます。

セキュリティ

• Azure Monitor ワークスペースへのアクセスは Microsoft Entra ID + Azure RBAC で制御し、取り込みとクエリそれぞれに適切なロールを割り当てる
• 収集エージェントやリモート ライトの認証にはマネージド ID を使い、資格情報のハードコードを避ける
• データは保存時に暗号化され、エンドポイントへの通信は TLS で保護される
• Managed Grafana 側でもデータソース接続の権限を最小権限で構成する

関連サービス・比較

Prometheus メトリクス（数値の時系列）に特化したマネージド サービスである点が、ログ中心の Log Analytics との大きな違いです。

ハンズオン / CLI例

# Azure Monitor ワークスペース（Prometheus メトリクスの格納先）を作成
az monitor account create \
  --name demo-amw \
  --resource-group demo-rg \
  --location japaneast

# 既存の AKS クラスターで Managed Prometheus のメトリクス収集を有効化し、
# 上で作成した Azure Monitor ワークスペースに関連付ける
az aks update \
  --name demo-aks \
  --resource-group demo-rg \
  --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id \
    "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Monitor/accounts/demo-amw"