AKS と Azure Monitor Managed Service for Prometheus の統合ガイド

2026年5月15日

Contents

1 前提条件と環境設定
- 1.1 必要な権限
- 1.2 推奨バージョンと確認方法
2 Azure Monitor Managed Service for Prometheus の有効化とワークスペース作成
- 2.1 ポータルでの手順
- 2.2 Azure CLI での手順
3 AKS 上でのエクスポーター構築と Managed Identity 設定
- 3.1 Managed Identity の作成とロール割り当て
- 3.2 kube‑state-metrics と node-exporter のデプロイ
4 Prometheus の remote_write 設定と既存環境からのマイグレーション
- 4.1 remote_write エンドポイント設定例
  - 4.1.1 Pod へのトークンマウント方法
- 4.2 マイグレーション手順（バックアップ → 設定 → デプロイ）
5 コスト最適化・保持期間設定・タグ付けベストプラクティス
6 可視化・運用、障害対策
7 参考情報

スポンサードリンク

前提条件と環境設定

このセクションでは、Azure Monitor Managed Service for Prometheus（以下 MSP） を Azure Kubernetes Service (AKS) と統合する際に最低限必要な権限・バージョン情報を整理します。要件が満たされていないと、リソース作成や認証でエラーが頻発し、以降の手順が途中で止まってしまいます。ここで確認した内容は、すべて後続の手順で前提として使用されますので必ずチェックしてください。

必要な権限

対象	推奨ロール / 権限
Azure サブスクリプション	`Owner` または `Contributor`（リソース作成・ロール割当が可能）
Azure AD	Managed Identity 作成権限 (`Microsoft.ManagedIdentity/userAssignedIdentities/write`)
AKS クラスタ	クラスター管理者 (Cluster Admin) もしくは `azure-cli` がクラスタに対して `kubectl` 実行できる権限

備考：組織のポリシーで最小権限を徹底する場合は、上記ロールを個別にカスタムロールとして定義し、必要なアクションだけ許可してください。

推奨バージョンと確認方法

コンポーネント	最低要件 (2026‑05)	確認コマンド例
Azure CLI	2.62.0 以上（公式ドキュメント: https://learn.microsoft.com/ja-jp/cli/azure/install-azure-cli#prerequisites）	`az version --output json`
PowerShell Az モジュール	12.0.0 以上	`Get-Module -ListAvailable Az.* \| Sort-Object Version -Descending \| Select-Object -First 1`
AKS クラスタ	1.26 以降（MSP API がサポート開始したバージョン）	`az aks show -g <RG> -n <CLUSTER> --query kubernetesVersion -o tsv`
Helm	3.14 以上	`helm version --short`

更新手順のヒント：CLI が古い場合は az upgrade、PowerShell は Update-Module -Name Az -Force、Helm は公式スクリプト (curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash) で最新版に更新できます。

Azure Monitor Managed Service for Prometheus の有効化とワークスペース作成

このセクションでは、Azure Monitor ワークスペース を作成し、そこに MSP を有効化する手順をポータルと Azure CLI の両方で示します。どちらの方法でも同等の結果が得られるため、チームの好みや自動化要件に合わせて選択してください。

ポータルでの手順

まずは Azure Portal から UI 操作でワークスペースと MSP を有効化する流れを確認します。UI は随時更新されるため、画面表示が若干変わっていても本手順の概念は同じです。

Azure Portal にサインインし、左側メニューから 「Azure Monitor」 → 「ワークスペース」 を選択。
「+ 作成」 ボタンをクリックし、以下情報を入力してワークスペースを作成します。
名前：prometheus-ws-<env>（例: prometheus-ws-prod）
リージョン：AKS クラスタと同一リージョン（レイテンシ低減のため必須）
タグ：env=prod,team=devops など運用管理で活用できるキー/バリューを設定
作成が完了したら一覧から対象ワークスペースを選択し、左ペインにある 「Managed Service for Prometheus」 タブを開く。
「有効化」 ボタンをクリックするだけで MSP がオンになります。

注意点：ポータル UI は 2026‑04 更新版（https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/prometheus-managed-service) に合わせて表示が変わっています。従来の「Prometheus」メニューは廃止されていますので、上記タブを必ず確認してください。

Azure CLI での手順

CLI を利用すればスクリプト化や CI/CD パイプラインへの組み込みが容易です。以下は最新 Azure CLI（2.62.0 以降）で動作する公式コマンドです。

# 1. Azure CLI のバージョン確認（必須は 2.62.0 以上）
az version --output json | jq '.[&quot;azure-cli&quot;]'

# 2. リソースグループの作成（既存があればスキップ可）
az group create \
  --name rg-monitor \
  --location japaneast

# 3. Azure Monitor ワークスペースの作成
az monitor workspace create \
  --resource-group rg-monitor \
  --name prometheus-ws-prod \
  --location japaneast \
  --tags env=prod team=devops

# 4. Managed Service for Prometheus の有効化
#   ※本コマンドは Azure CLI 2.55.0 以降で利用可能です（2026‑05 時点では 2.62.0 が推奨）
az monitor metrics prometheus enable \
  --resource-group rg-monitor \
  --workspace-name prometheus-ws-prod

# 1. Azure CLI のバージョン確認（必須は 2.62.0 以上）

az version --output json | jq '.["azure-cli"]'

# 2. リソースグループの作成（既存があればスキップ可）

az group create \

--name rg-monitor \

--location japaneast

# 3. Azure Monitor ワークスペースの作成

az monitor workspace create \

--resource-group rg-monitor \

--name prometheus-ws-prod \

--location japaneast \

--tags env=prod team=devops

# 4. Managed Service for Prometheus の有効化

# ※本コマンドは Azure CLI 2.55.0 以降で利用可能です（2026‑05 時点では 2.62.0 が推奨）

az monitor metrics prometheus enable \

--resource-group rg-monitor \

--workspace-name prometheus-ws-prod

公式リファレンス：https://learn.microsoft.com/ja-jp/cli/azure/monitor/metrics/prometheus#az_monitor_metrics_prometheus_enable

AKS 上でのエクスポーター構築と Managed Identity 設定

MSP にデータを送るために、kube-state-metrics と node-exporter の2つのエクスポーターを Helm でデプロイし、Managed Identity に適切なロールを付与します。以下では User‑Assigned Managed Identity を例に手順を示していますが、システム割り当て型でも同様です。

Managed Identity の作成とロール割り当て

まずは AKS クラスタに紐づく Managed Identity を作成し、Workspace への書き込み権限（Monitoring Metrics Publisher）を付与します。

# 1. User‑Assigned Managed Identity 作成
az identity create \
  --resource-group rg-monitor \
  --name prometheus-mi

# 2. 作成した ID の clientId と principalId を取得
MI_CLIENT_ID=$(az identity show -g rg-monitor -n prometheus-mi --query clientId -o tsv)
MI_PRINCIPAL_ID=$(az identity show -g rg-monitor -n prometheus-mi --query principalId -o tsv)

# 3. Workspace にロール割り当て
WORKSPACE_ID=$(az monitor workspace show \
    -g rg-monitor -n prometheus-ws-prod \
    --query id -o tsv)

az role assignment create \
  --assignee $MI_PRINCIPAL_ID \
  --role &quot;Monitoring Metrics Publisher&quot; \
  --scope $WORKSPACE_ID

# 4. AKS クラスタに Managed Identity をアタッチ（System‑Assigned が有効でないことを前提）
AKS_RG=rg-aks
AKS_NAME=myAKSCluster

az aks update \
  --resource-group $AKS_RG \
  --name $AKS_NAME \
  --enable-managed-identity \
  --assign-identity $MI_CLIENT_ID

# 1. User‑Assigned Managed Identity 作成

az identity create \

--resource-group rg-monitor \

--name prometheus-mi

# 2. 作成した ID の clientId と principalId を取得

MI_CLIENT_ID=$(az identity show -g rg-monitor -n prometheus-mi --query clientId -o tsv)

MI_PRINCIPAL_ID=$(az identity show -g rg-monitor -n prometheus-mi --query principalId -o tsv)

# 3. Workspace にロール割り当て

WORKSPACE_ID=$(az monitor workspace show \

-g rg-monitor -n prometheus-ws-prod \

--query id -o tsv)

az role assignment create \

--assignee $MI_PRINCIPAL_ID \

--role "Monitoring Metrics Publisher" \

--scope $WORKSPACE_ID

# 4. AKS クラスタに Managed Identity をアタッチ（System‑Assigned が有効でないことを前提）

AKS_RG=rg-aks

AKS_NAME=myAKSCluster

az aks update \

--resource-group $AKS_RG \

--name $AKS_NAME \

--enable-managed-identity \

--assign-identity $MI_CLIENT_ID

ベストプラクティス：User‑Assigned Identity はリソースごとに権限を切り分けられるため、最小特権の原則（Least Privilege）を実現しやすくなります。

kube‑state-metrics と node-exporter のデプロイ

次にエクスポーター本体を Helm でインストールします。バージョンは 2026‑05 時点の最新チャート（v5.15.0 系）です。

# Helm リポジトリ追加（最新版取得）
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# kube-state-metrics デプロイ
helm install kube-state-metrics prometheus-community/kube-state-metrics \
  --namespace monitoring \
  --create-namespace \
  --set resources.limits.cpu=200m,resources.limits.memory=256Mi \
  --set resources.requests.cpu=100m,resources.requests.memory=128Mi

# node-exporter デプロイ（hostNetwork 必須）
helm install node-exporter prometheus-community/prometheus-node-exporter \
  --namespace monitoring \
  --set hostNetwork=true \
  --set resources.limits.cpu=300m,resources.limits.memory=512Mi \
  --set resources.requests.cpu=150m,resources.requests.memory=256Mi

# Helm リポジトリ追加（最新版取得）

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update

# kube-state-metrics デプロイ

helm install kube-state-metrics prometheus-community/kube-state-metrics \

--namespace monitoring \

--create-namespace \

--set resources.limits.cpu=200m,resources.limits.memory=256Mi \

--set resources.requests.cpu=100m,resources.requests.memory=128Mi

# node-exporter デプロイ（hostNetwork 必須）

helm install node-exporter prometheus-community/prometheus-node-exporter \

--namespace monitoring \

--set hostNetwork=true \

--set resources.limits.cpu=300m,resources.limits.memory=512Mi \

--set resources.requests.cpu=150m,resources.requests.memory=256Mi

注意：hostNetwork=true を設定しないとノードレベルのハードウェア指標（CPU、メモリ、ディスク I/O 等）が取得できません。クラスタ規模に応じて resources の上限・要求は調整してください。

Prometheus の remote_write 設定と既存環境からのマイグレーション

この章では、Prometheus（セルフホスト） から MSP へメトリクスを送信するための remote_write 設定方法と、実際にマイグレーションを行う手順を解説します。Managed Identity を利用した認証が推奨されている点に注目してください。

remote_write エンドポイント設定例

以下は prometheus.yml に追加する最小構成です。bearer_token_file には Managed Identity のトークンをマウントします。

remote_write:
  - url: https://&lt;workspace-id&gt;.monitor.azure.com/api/v1/push
    bearer_token_file: /var/run/secrets/azure/tokens/prometheus-token
    tls_config:
      insecure_skip_verify: false   # 必ず false にして証明書検証を有効化
    queue_config:
      capacity: 50000               # バッファ不足でデータロス防止（必要に応じて調整）

remote_write:

- url: https://<workspace-id>.monitor.azure.com/api/v1/push

bearer_token_file: /var/run/secrets/azure/tokens/prometheus-token

tls_config:

insecure_skip_verify: false # 必ず false にして証明書検証を有効化

queue_config:

capacity: 50000 # バッファ不足でデータロス防止（必要に応じて調整）

Pod へのトークンマウント方法

volumeMounts:
  - name: azure-identity-token
    mountPath: /var/run/secrets/azure/tokens
    readOnly: true
volumes:
  - name: azure-identity-token
    projected:
      sources:
        - serviceAccountToken:
            path: prometheus-token
            expirationSeconds: 3600   # 1 時間ごとに自動ローテーション

volumeMounts:

- name: azure-identity-token

mountPath: /var/run/secrets/azure/tokens

readOnly: true

volumes:

- name: azure-identity-token

projected:

sources:

- serviceAccountToken:

path: prometheus-token

expirationSeconds: 3600 # 1 時間ごとに自動ローテーション

参考：Managed Identity のトークン取得は Azure Workload Identity が内部で行います。azure.workload.identity/client-id アノテーションを ServiceAccount に付与するだけで、Kubernetes 側の設定は完了します。

マイグレーション手順（バックアップ → 設定 → デプロイ）

既存 Prometheus のバックアップ
bash # ConfigMap とデータディレクトリを取得 kubectl get cm prometheus-config -n monitoring -o yaml > backup/prometheus-config.yaml kubectl cp <pod>:/prometheus /backup/prometheus-data
remote_write 設定の追記（上記 YAML を prometheus.yml にマージ）
ServiceAccount に Managed Identity を紐付ける
yaml apiVersion: v1 kind: ServiceAccount metadata: name: prometheus-sa namespace: monitoring annotations: azure.workload.identity/client-id: <MI_CLIENT_ID>
完全マニフェスト例（公式ドキュメントに準拠）

apiVersion: v1
kind: Namespace
metadata:
  name: monitoring
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-sa
  namespace: monitoring
  annotations:
    azure.workload.identity/client-id: &lt;MI_CLIENT_ID&gt;
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      serviceAccountName: prometheus-sa
      containers:
        - name: prometheus
          image: prom/prometheus:v2.49.0
          args:
            - &quot;--config.file=/etc/prometheus/prometheus.yml&quot;
            - &quot;--storage.tsdb.path=/prometheus&quot;
          volumeMounts:
            - name: config-volume
              mountPath: /etc/prometheus
            - name: data-volume
              mountPath: /prometheus
            - name: azure-identity-token
              mountPath: /var/run/secrets/azure/tokens
              readOnly: true
      volumes:
        - name: config-volume
          configMap:
            name: prometheus-config
        - name: data-volume
          emptyDir: {}
        - name: azure-identity-token
          projected:
            sources:
              - serviceAccountToken:
                  path: prometheus-token
                  expirationSeconds: 3600
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 30s
    scrape_configs:
      - job_name: 'kubernetes-nodes'
        static_configs:
          - targets: ['node-exporter.monitoring.svc.cluster.local:9100']
    remote_write:
      - url: https://&lt;workspace-id&gt;.monitor.azure.com/api/v1/push
        bearer_token_file: /var/run/secrets/azure/tokens/prometheus-token
        tls_config:
          insecure_skip_verify: false

apiVersion: v1

kind: Namespace

metadata:

---

apiVersion: v1

kind: ServiceAccount

metadata:

namespace: monitoring

annotations:

azure.workload.identity/client-id: <MI_CLIENT_ID>

---

apiVersion: apps/v1

kind: Deployment

metadata:

namespace: monitoring

spec:

replicas: 1

selector:

matchLabels:

app: prometheus

template:

metadata:

labels:

app: prometheus

spec:

serviceAccountName: prometheus-sa

containers:

- name: prometheus

image: prom/prometheus:v2.49.0

args:

- "--config.file=/etc/prometheus/prometheus.yml"

- "--storage.tsdb.path=/prometheus"

volumeMounts:

- name: config-volume

mountPath: /etc/prometheus

- name: data-volume

mountPath: /prometheus

- name: azure-identity-token

mountPath: /var/run/secrets/azure/tokens

readOnly: true

volumes:

- name: config-volume

configMap:

- name: data-volume

emptyDir: {}

- name: azure-identity-token

projected:

sources:

- serviceAccountToken:

path: prometheus-token

expirationSeconds: 3600

---

apiVersion: v1

kind: ConfigMap

metadata:

namespace: monitoring

data:

prometheus.yml: |

global:

scrape_interval: 30s

scrape_configs:

- job_name: 'kubernetes-nodes'

static_configs:

- targets: ['node-exporter.monitoring.svc.cluster.local:9100']

remote_write:

- url: https://<workspace-id>.monitor.azure.com/api/v1/push

bearer_token_file: /var/run/secrets/azure/tokens/prometheus-token

tls_config:

insecure_skip_verify: false

移行後の検証：kubectl logs <prometheus-pod> で remote_write の成功ログ（sent samples to remote write endpoint）が出ていることを確認し、Azure Portal の Metrics Explorer にメトリクスが表示されれば完了です。

コスト最適化・保持期間設定・タグ付けベストプラクティス

MSP は使用量に応じた従量課金モデルです。データ保持や送信頻度を適切に管理しないと、思わぬコストが発生します。この章では 具体的な手順 と 影響評価 を交えて解説します。

データ保持期間の変更方法

Azure Monitor のワークスペースはデフォルトで 30 日保持です。短縮したい場合は CLI またはポータルから設定できます。

# 例: 保持期間を 7 日に変更（2026‑05 時点の最新 API）
az monitor workspace update \
  --resource-group rg-monitor \
  --name prometheus-ws-prod \
  --retention-time 7

# 例: 保持期間を 7 日に変更（2026‑05 時点の最新 API）

az monitor workspace update \

--resource-group rg-monitor \

--name prometheus-ws-prod \

--retention-time 7

コストインパクト：保持日数が 30→7 に減ると、データ保管料は約 76% 削減（1 GB/日あたり $0.10 の場合、月額 $9 → $2.1）。ただし、過去 30 日分のメトリクスが必要な監査要件がある場合は注意してください。

メトリクス送信コストの確認と削減テクニック

手段	実装例	コスト削減効果
スクレイプ間隔の緩和	`global.scrape_interval` を `60s` に変更	送信サンプル数約 50% 減少
不要メトリクスの除外	`relabel_configs` で `__name__=~"^node_.*"` 以外をフィルタ	無駄なデータ転送が排除され、月額 $0.5 程度削減
サンプリングレートの調整（remote_write の `queue_config`）	`capacity` を適切に設定し、過剰バッファリングを防止	バックエンドへの再送回数が減り、ネットワークコスト低減

料金確認方法：Azure Portal → 「Cost Management」→「Cost analysis」で「Resource type: Azure Monitor Metrics」フィルタをかけると、日次・月次の使用料が可視化できます。

リソースタグ付与の自動化例

タグはコスト配分だけでなく、ポリシー遵守や障害切り分けにも有用です。以下は Azure Policy と CLI を組み合わせた自動付与スクリプトです。

# 1. タグ付与ポリシー（例: env, team, project が必須）
az policy definition create \
  --name &quot;require-tags-monitoring&quot; \
  --display-name &quot;Require tags on monitoring resources&quot; \
  --rules '{
      &quot;if&quot;: {
          &quot;field&quot;: &quot;type&quot;,
          &quot;in&quot;: [
              &quot;Microsoft.Insights/workspaces&quot;,
              &quot;Microsoft.ContainerService/managedClusters&quot;
          ]
      },
      &quot;then&quot;: {
          &quot;effect&quot;: &quot;modify&quot;,
          &quot;details&quot;: {
              &quot;roleDefinitionIds&quot;: [
                  &quot;/providers/microsoft.authorization/roleDefinitions/&lt;role-id&gt;&quot;
              ],
              &quot;operations&quot;: [
                  {
                      &quot;operation&quot;: &quot;addOrReplace&quot;,
                      &quot;field&quot;: &quot;tags.env&quot;,
                      &quot;value&quot;: &quot;[parameters('env')]&quot;
                  },
                  {
                      &quot;operation&quot;: &quot;addOrReplace&quot;,
                      &quot;field&quot;: &quot;tags.team&quot;,
                      &quot;value&quot;: &quot;[parameters('team')]&quot;
                  }
              ]
          }
      }
  }' \
  --mode All

# 2. ポリシー適用
az policy assignment create \
  --policy &quot;require-tags-monitoring&quot; \
  --name &quot;enforce-monitoring-tags&quot; \
  --params '{&quot;env&quot;:{&quot;value&quot;:&quot;prod&quot;},&quot;team&quot;:{&quot;value&quot;:&quot;devops&quot;}}' \
  --scope &quot;/subscriptions/&lt;sub-id&gt;&quot;

# 1. タグ付与ポリシー（例: env, team, project が必須）

az policy definition create \

--name "require-tags-monitoring" \

--display-name "Require tags on monitoring resources" \

--rules '{

"if": {

"field": "type",

"in": [

"Microsoft.Insights/workspaces",

"Microsoft.ContainerService/managedClusters"

]

"then": {

"effect": "modify",

"details": {

"roleDefinitionIds": [

"/providers/microsoft.authorization/roleDefinitions/<role-id>"

"operations": [

{

"operation": "addOrReplace",

"field": "tags.env",

"value": "[parameters('env')]"

{

"operation": "addOrReplace",

"field": "tags.team",

"value": "[parameters('team')]"

}

]

}

}' \

--mode All

# 2. ポリシー適用

az policy assignment create \

--policy "require-tags-monitoring" \

--name "enforce-monitoring-tags" \

--params '{"env":{"value":"prod"},"team":{"value":"devops"}}' \

--scope "/subscriptions/<sub-id>"

運用上のポイント：タグが未設定リソースは自動でポリシーにより作成時に付与されます。既存リソースには az tag create コマンドで一括適用できます。

可視化・運用、障害対策

MSP に送られたメトリクスは Azure Monitor Metrics Explorer と Grafana（Azure Monitor データソース） の両方で確認できます。ここでは基本的な操作手順と、実務でよく遭遇する障害シナリオの対処法をまとめます。

Metrics Explorer と Grafana の基本操作

ツール	主な利点	手順概要
Azure Portal → Metrics Explorer	Azure ネイティブ、ロールベースアクセスが自動適用	1. ポータルで「Monitor」→「Metrics Explorer」 2. 対象ワークスペースを選択 3. メトリクス名（例: `kube_node_status_condition`）を検索・可視化
Grafana (Azure Monitor データソース)	ダッシュボードの再利用性、アラート機能が豊富	1. Grafana にサインイン → 「Data Sources」→「Add data source」 2. 「Azure Monitor」を選択し、Managed Identity 認証を設定 3. クエリビルダーで `kube_node_status_condition` 等を選択

注意：Grafana の Azure Monitor プラグインは 2026‑04 時点で PromQL モードが正式にサポートされています。従来の Metrics API に比べ、Prometheus と同様のクエリ記述が可能です。

代表的な PromQL クエリ集

目的	PromQL
ノード CPU 使用率（平均）	`avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100`
Pod 再起動回数（過去1時間）	`sum(increase(kube_pod_container_status_restarts_total[1h])) by (namespace, pod)`
Deployment のレプリカ利用率	`kube_deployment_status_replicas{deployment="my-app"} / kube_deployment_spec_replicas{deployment="my-app"}`
メモリ使用率（トップ10）	`topk(10, node_memory_Active_bytes / node_memory_MemTotal_bytes)`

よくある障害シナリオとトラブルシューティング手順

障害シナリオ	主な原因	推奨対策
証明書エラー（`x509: certificate signed by unknown authority`）	OS の CA ストアが古い、または社内プロキシで TLS が改変された	`apt-get update && apt-get install -y ca-certificates` で最新化。プロキシ使用時は `HTTPS_PROXY` 環境変数を正しく設定し、`NO_PROXY` に `*.monitor.azure.com` を追加
認可失敗（401 Unauthorized）	Managed Identity が Workspace にロール未付与、または ServiceAccount のアノテーションミス	`az role assignment list --assignee <principalId> --scope $WORKSPACE_ID` で割当確認。ServiceAccount の `azure.workload.identity/client-id` が正しいか再チェック
データ遅延（数分以上のラグ）	`remote_write.queue_config.capacity` が不足、ネットワーク帯域制限	`queue_config.capacity` を 100000 に増やし、AKS ノードのアウトバウンド帯域を Azure Monitor の推奨値（最低 1 Gbps）に合わせる
リトライ無限ループで CPU 飙升	`remote_write` が永続的にエラー応答（5xx）を受け取ってバックオフが無効化された	`remote_write.retry_on_http_5xx: true` と `backoff_min`, `backoff_max` を明示的に設定し、Prometheus のリソースリクエストを増やす
保持期間変更が反映されない	CLI で `--retention-time` が数値ではなく文字列として渡された	正式なパラメータは整数（日数）です。例: `az monitor workspace update -g rg-monitor -n prometheus-ws-prod --retention-time 7`

障害時のログ取得：
Azure Monitor の Activity Log → 該当リソース → 「診断設定」から「Log Analytics」に出力させる。
Prometheus コンテナの標準出力 (kubectl logs <pod>) に remote_write エラーが記録されます。

運用上のベストプラクティスまとめ

タグ・ポリシー：全監視リソースに env, team, project タグを必須化し、Cost Management で部門別コストを可視化。
ロギング統合：AKS の Container Insights と Log Analytics を同一ワークスペースに集約し、エラーパターン検索を Kusto クエリで自動化。
データ保持：30 日がデフォルトなので、監査要件がない環境は 7〜14 日へ短縮し、ストレージコストを最大 80% 削減。
送信頻度：scrape_interval を 30s → 60s に変更するとサンプル数が半減。必要に応じて exporter ごとに個別設定可能。
障害検知：Grafana のアラートで remote_write の失敗率（5xx）を閾値 1% 超えたら Slack 通知を送るように設定。

参考情報

内容	URL
Azure Monitor Managed Service for Prometheus（公式概要）	https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/prometheus-managed-service
`az monitor metrics prometheus enable` コマンドリファレンス	https://learn.microsoft.com/ja-jp/cli/azure/monitor/metrics/prometheus#az_monitor_metrics_prometheus_enable
Managed Identity と Azure Workload Identity の設定ガイド	https://learn.microsoft.com/ja-jp/azure/aks/workload-identity-overview
Prometheus → Azure Monitor へのマイグレーション手順	https://learn.microsoft.com/ja-jp/azure/azure-monitor/metrics/prometheus-migrate
Cost Management の使用方法（Metrics）	https://learn.microsoft.com/ja-jp/azure/cost-management-billing/costs/
Azure Policy によるタグ強制適用サンプル	https://learn.microsoft.com/ja-jp/azure/governance/policy/samples/enforce-tag-and-location

以上で、Azure Monitor Managed Service for Prometheus を AKS に安全かつコスト効率的に導入・運用するための全手順が完了です。
不明点や環境固有の要件がある場合は、公式ドキュメントと本稿の「参考情報」セクションを併せてご確認ください。

スポンサードリンク

-Prometheus

comment コメントをキャンセル

: Prometheus

Prometheus と Grafana の最新バージョンと導入手順 (2024‑2025)

Prometheus 2.50 系と Grafana 10.1+ の概要、Docker Compose と Helm によるインストール手順、設定例、TLS・Alertmanager 連携までを解説します。

: Prometheus

AWS Managed Service for Prometheus 料金徹底解説とコスト最適化ガイド

Amazon Managed Service for Prometheus（AMP）の最新価格構造と、AWS Pricing Calculatorによる見積もり手順、競合他社との比較、コスト削減の具体策をまとめた実践ガイド。

: Prometheus

Prometheus のデプロイと高可用構成・Grafana 連携ベストプラクティス

本稿では、Prometheus のスタンドアロンから Operator/Helm までのデプロイ手法と HA 実装ポイント、Kubernetes・EC2・静的ファイル向け Service Discovery と relabeling、Grafana のデータソース自動プロビジョニング、Alertmanager と Grafana Unified Alerting の統合フロー、TLS/mTLS や OAuth2/OIDC を用いた認証強化、さらに remote_write とフェデレーションによるスケールアウト戦略を網羅的に紹介します。

河合塾One公式ログイン方法とトラブル対策【スマホ・アプリ対応】

Classi授業配信：スマホ設定と事前チェックリスト