Azure Monitorでアラートやダッシュボードを運用している場合、最初に確認すべきなのは「対象リソースで、そのメトリックが本当にサポートされているか」です。2026年5月7日付の更新情報として「Azure Monitor supported metrics by resource type – Azure Monitor」を確認している読者にとって、実務上の結論は明確です。既存の監視設定、診断設定、DCR、IaC、API連携で使っているメトリック名・ディメンション・集計方法・エクスポート可否を、リソースの種類ごとに棚卸ししてください。
この公式リファレンスは、Azure Monitorで利用できるプラットフォームメトリックをリソースプロバイダーとリソースタイプ別に整理した一覧です。なお、Microsoft Learn側のGitHubメタデータでは ms.date 04/28/2026 と表示されており、2026年4月28日から29日にかけて自動生成系の更新履歴も確認できます。日付だけで判断せず、実際の本番環境で使っているリソースタイプごとの最新定義を確認することが重要です。(GitHub)
まず押さえるべきポイント
今回確認すべき内容は、Azure Monitorの新機能を単純に有効化する話ではありません。ポイントは、Azure Monitorのメトリック定義が「リソースタイプ単位」で整理されており、同じAzureサービスに見えても、リソースタイプが違えば利用できるメトリック、ディメンション、時間粒度、診断設定でのエクスポート可否が異なるという点です。
たとえば、仮想マシン、ストレージアカウント、AKS、Key Vault、SQL Database、App Serviceなどは、それぞれ異なるメトリックセットを持ちます。監視ルールを横展開するときに「CPU使用率」「接続数」「要求数」といった表示名だけで判断すると、REST API名の違い、集計方法の違い、ディメンションの有無によってアラートやダッシュボードが期待どおり動かないことがあります。
| 確認項目 | 見るべき列・情報 | 実務での判断ポイント |
|---|---|---|
| メトリック名 | Metric、Name in REST API | ポータル表示名ではなく、自動化ではREST API名を基準にする |
| 単位 | Unit | Count、Percent、Bytes、BytesPerSecondなどをしきい値設計に反映する |
| 集計方法 | Aggregation | Average、Total、Maximumなどを誤るとアラート精度が落ちる |
| ディメンション | Dimensions | LUN、インスタンス、キューなどで分割監視できるか確認する |
| 時間粒度 | Time Grains | PT1Mなど、取得・評価できる間隔を確認する |
| 診断設定での出力 | DS Export | Log AnalyticsやEvent Hubsへ送れるかを確認する |
各メトリック詳細ページでは、ポータル上の表示名、REST APIで使うメトリック名、単位、既定の集計、利用可能なディメンション、サンプリング間隔、診断設定でのエクスポート可否が表形式で示されます。たとえば仮想マシンのページでは、Percentage CPU、ディスクIO、ネットワーク、可用性などの項目がリストされています。(Microsoft Learn)
Azure Monitor supported metrics by resource typeとは何か
「Azure Monitor supported metrics by resource type」は、Azure Monitorで現在利用できるプラットフォームメトリック、つまりAzureリソースから自動収集されるメトリックを、リソースプロバイダーとリソースタイプごとにまとめた公式リファレンスです。プログラムから一覧にアクセスする方法として、公式ページでは 2018-01-01 のAPIバージョンも案内されています。(Microsoft Learn)
ここで重要なのは、「Azure Monitorで見えるメトリック」と「自社の監視設定で安全に使えるメトリック」は同じではないという点です。公式リファレンスに載っていても、診断設定でエクスポートできない場合があります。逆に、ポータルやレガシーAPIで見えるメトリックが、リファレンス一覧にない場合もあります。新規構築やIaC化では、公式リファレンスと実際のメトリック定義APIの両方を確認するのが安全です。(Microsoft Learn)
何が変わるのか
今回の更新で見るべき変化は、特定の1機能が廃止・追加されたというより、リソースタイプ別の対応表を前提に監視設計を見直す必要がある点です。公式リファレンスは generated-reference として管理されており、GitHub履歴にも自動生成されたログ・メトリック関連の更新が並んでいます。つまり、今後もAzureサービス側の追加や仕様変更に合わせて、参照すべきメトリック一覧が更新される可能性があります。(GitHub)
管理者や開発者が見るべき変更点は、次の4つです。
| 変更・確認ポイント | 影響する作業 | 見落とすと起きること |
|---|---|---|
| 対応リソースタイプの追加・変更 | 新規監視、既存監視の横展開 | 対象リソースにメトリックが存在せず、アラート作成やAPI取得で失敗する |
| メトリック名・REST API名の確認 | IaC、CLI、PowerShell、REST API連携 | 表示名で設定してしまい、自動化スクリプトが動かない |
| ディメンションの有無 | ダッシュボード、原因分析、SRE運用 | ディスク別・インスタンス別などの切り分けができない |
| 診断設定でのエクスポート可否 | Log Analytics、Storage、Event Hubs連携 | 保存・転送したいメトリックが出力されない、または集約されて詳細を失う |
特に「DS Export」は重要です。すべてのメトリックはREST API経由でエクスポート可能とされていますが、診断設定ではエクスポートできないメトリックがあります。また、多次元メトリックを診断設定で送ると、ディメンション値ごとの詳細ではなく、集約された単一次元のデータとして扱われる場合があります。(Microsoft Learn)
影響を受ける対象者
Azure Monitorのメトリック一覧更新は、監視担当者だけの話ではありません。アラート、ログ転送、コスト管理、IaC、アプリケーション運用まで影響します。
| 対象者 | 確認すべきこと | 優先度が高いケース |
|---|---|---|
| Azure管理者 | 診断設定、DCR、Log Analytics転送、Event Hubs連携 | 複数サブスクリプションで監視設定を標準化している |
| SRE・運用担当 | メトリックアラート、ダッシュボード、ワークブック | 障害検知やSLO監視にAzure Monitorを使っている |
| 開発者 | REST API名、ディメンション、時間粒度 | アプリやCI/CDからメトリックを取得している |
| IaC担当 | Bicep、ARM、Terraform、CLIでの定義 | 監視ルールをテンプレート化している |
| セキュリティ・監査担当 | Storage、Log Analytics、Event Hubsへの出力 | 監査証跡や長期保管のためにメトリックを外部保管している |
たとえば、仮想マシンの監視で「Network In」や「Network Out」を使っている場合、公式リファレンス上では一部がDeprecatedとして示され、Network In Total や Network Out Total などの項目も確認できます。既存のアラートやダッシュボードが古いメトリック名に依存していないか確認しておくと、将来の移行時に慌てずに済みます。(Microsoft Learn)
管理者が確認すべき設定
監視対象のリソースタイプを洗い出す
最初に、監視対象をAzureサービス名ではなく、リソースタイプで整理します。たとえば「VM」ではなく Microsoft.Compute/virtualMachines、「AKS」ではなく Microsoft.ContainerService/managedClusters、「Storage」ではなく Microsoft.Storage/storageAccounts やその配下のサービスまで分けて確認します。
この分け方をしないと、同じサービス群に見えるリソースでも、メトリックの有無やログカテゴリが違うことに気づけません。公式リファレンスでは、リソースプロバイダーごとにメトリックとログカテゴリへのリンクが整理されています。(Microsoft Learn)
既存アラートのメトリック名を確認する
メトリックアラートでは、表示名だけでなくREST API名、集計方法、時間粒度を確認してください。特にIaCやCLIでアラートを作成している場合、ポータル上の日本語表示名や英語の表示名ではなく、REST APIで参照される正確なメトリック名を使う必要があります。
確認時は、次の観点で既存設定を棚卸しします。
| 確認対象 | 確認内容 | 修正が必要な例 |
|---|---|---|
| メトリック名 | REST API名と一致しているか | 表示名をそのままテンプレートに書いている |
| 集計 | Average、Total、Maximumなどが目的に合うか | 通信量をAverageで見てピークを見落とす |
| 評価間隔 | Time Grainとアラート評価間隔が合うか | 1分粒度のメトリックを長すぎる間隔で評価している |
| ディメンション | 分割監視が必要か | ディスク別に見るべきIOをVM全体でしか見ていない |
| しきい値 | 単位と集計に合っているか | BytesPerSecondとBytesを混同している |
Azure Monitorのメトリックアラートは、プラットフォームメトリック、カスタムメトリック、ログ由来のメトリック、Application Insightsメトリックなどを対象にできます。条件を満たすとアクショングループが実行されるため、メトリック定義の変更や誤設定は通知品質に直結します。(Microsoft Learn)
診断設定とDCRの使い分けを確認する
プラットフォームメトリックは、診断設定、DCR、Metrics REST APIなどで外部に送れます。送信先としては、Azure Storage、Log Analyticsワークスペース、Event Hubsが代表的です。(Microsoft Learn)
ただし、診断設定は簡単に使える一方で、多次元メトリックの扱いに制限があります。ディメンションごとの詳細を保ったまま転送したい場合や、必要なメトリックだけを選別してエクスポートしたい場合は、DCRによるメトリックエクスポートを検討します。DCRではディメンション付きメトリックのエクスポートや、メトリック名によるフィルタリングが可能とされています。(Microsoft Learn)
一方で、DCRによるメトリックエクスポートは記事タイトル上でPreviewとされており、対象リソース、リージョン、DCR数、宛先タイプなどの制限があります。本番環境で使う場合は、サポート対象のリソースタイプとリージョン、StorageやEvent Hubsへの権限設定を必ず確認してください。(Microsoft Learn)
開発者・IaC担当が確認すべき実装ポイント
REST API名を基準にする
ポータルで見えるメトリック表示名は、人が読むには分かりやすい一方、自動化には不向きです。Bicep、ARMテンプレート、Terraform、Azure CLI、PowerShell、REST APIでメトリックを扱う場合は、各リソースタイプの詳細ページにある「Name in REST API」を基準にしてください。
たとえば、仮想マシンの Percentage CPU のように表示名とREST API名が近いものもありますが、すべてが直感的に一致するとは限りません。ディスク系メトリックでは LUN ディメンションの有無も運用上重要です。(Microsoft Learn)
メトリック定義の取得をCI/CDに組み込む
監視設定をコード化している場合は、リリース前にメトリック定義の存在確認を行う仕組みを入れると安全です。Azure MonitorのMetric Definitions APIでは、リソースまたはサブスクリプションスコープでメトリック定義を一覧できます。(Microsoft Learn)
実務では、次のようなチェックをCI/CDに組み込むと効果的です。
| チェック | 目的 |
|---|---|
| 対象リソースタイプにメトリックが存在するか | 存在しないメトリックでアラートを作成しない |
| REST API名が正しいか | 表示名や翻訳名によるミスを防ぐ |
| ディメンションが想定どおりか | 分割条件やフィルターの失敗を防ぐ |
| Time Grainが評価間隔に合うか | 取得できない間隔でクエリしない |
| DS ExportがYesか | Log AnalyticsやEvent Hubsに出せないメトリックを事前に把握する |
移行・展開時の注意点
DCRと診断設定を重複させない
DCRと診断設定を同時に使うことはできますが、同じメトリックを両方で収集すると重複データになり、Log AnalyticsやEvent Hubs側のデータ量、運用コスト、分析結果に影響します。DCRでメトリックをエクスポートする場合は、重複を避けるために既存の診断設定を見直してください。(Microsoft Learn)
特に、既存環境で「とりあえず全メトリックを診断設定で送る」という運用をしている場合、DCR導入時に二重送信が起きやすくなります。移行時は、対象リソース、送信先、メトリックカテゴリ、保存先テーブルを一覧化してから切り替えるのが安全です。
多次元メトリックの詳細を失わない
多次元メトリックは、障害調査や性能分析で非常に重要です。たとえばディスクごとのIO、キューごとのメッセージ数、インスタンスごとの要求数などは、全体平均だけでは原因を特定しにくくなります。
診断設定では複数ディメンションのエクスポートがサポートされず、ディメンション値全体に集計された形で扱われる場合があります。ディメンションごとの分析が必要な監視では、DCR、Metrics REST API、Metrics Explorerなど、目的に合う方法を選んでください。(Microsoft Learn)
ゲストOSメトリックは別扱いにする
仮想マシン、Service Fabric、Cloud Servicesで動くゲストOSのメトリックは、このリソースタイプ別一覧だけで完結しません。ゲストOS側のCPU、メモリ、プロセス、パフォーマンスカウンターなどを扱うには、Azure Monitor AgentとDCRによる収集設計が必要です。(Microsoft Learn)
Azure Monitor Agentは、Azure VMだけでなく、Azure Arcを通じて他クラウドやオンプレミスのマシンにも対応する監視データ収集の仕組みです。レガシーのLog Analytics agentを使っている環境では、移行計画も合わせて確認してください。(Microsoft Learn)
リソースの削除・移動・リネームに注意する
診断設定は、リソース削除やリネーム、リソースグループ間・サブスクリプション間の移行時に見落とされやすい設定です。公式ドキュメントでは、対象リソースを削除・リネーム・移行する場合、関連する診断設定を削除するよう警告されています。設定が残ったまま同じリソースが再作成されると、意図せずログ収集が再開される可能性があります。(Microsoft Learn)
また、Azureリソースを移動またはリネームすると、メトリック履歴が失われる可能性があります。長期的な傾向分析や監査に使っている場合は、リソース変更前にLog AnalyticsやStorageへの保存状況を確認してください。(Microsoft Learn)
メトリック保持期間と長期分析の考え方
Azure Monitor Metricsでは、プラットフォームメトリックとカスタムメトリックは原則として93日間保存されます。ただし、ポータルのメトリックチャートでは一度に表示できる期間に制限があり、長期傾向を確認したい場合はLog Analyticsなどへの送信を検討する必要があります。(Microsoft Learn)
短期の障害検知ならAzure Monitorのメトリックアラートで十分なケースが多いですが、月次レポート、キャパシティ計画、監査、FinOps用途では、保存先と保持期間を別途設計してください。たとえば、急増検知はメトリックアラート、月次分析はLog Analytics、長期保管はStorageというように、用途ごとに分けると運用しやすくなります。
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| ポータル表示名でIaCを書く | デプロイ時にメトリックが見つからない | REST API名を使う |
| リソースタイプを確認しない | 同じサービス名でも監視項目が合わない | Microsoft.Provider/type 単位で確認する |
| AverageとTotalを混同する | 通信量や要求数のしきい値がずれる | 単位とAggregationをセットで確認する |
| ディメンションを無視する | 原因箇所の特定が遅れる | 必要ならディメンション分割で監視する |
| 診断設定で全て出せると思い込む | 欲しいメトリックがLog Analyticsに来ない | DS Export列とDCRの可否を確認する |
| DCRと診断設定を併用する | 重複収集でコストや分析結果がぶれる | 移行前後で送信元を整理する |
| ゲストOSメトリックを混同する | VM内部の状態を見ているつもりで見えていない | Azure Monitor AgentとDCRを設計する |
実務での確認手順
運用中の環境では、次の順番で確認すると抜け漏れを減らせます。
- Azure Resource Graphやポータルで監視対象リソースを一覧化する
- リソースタイプを
Microsoft.Compute/virtualMachinesのような形式で整理する - 公式リファレンスで対象リソースタイプのメトリックページを開く
- 既存のアラート、ダッシュボード、DCR、診断設定、IaCと照合する
- REST API名、Aggregation、Dimensions、Time Grains、DS Exportを確認する
- 診断設定で送れないメトリックや多次元メトリックは、DCRまたはMetrics REST APIの利用を検討する
- ゲストOSメトリックが必要なVMは、Azure Monitor AgentとDCRの設定を確認する
- 変更後はMetrics Explorer、Log Analytics、アラート履歴で実データを検証する
この手順で見ると、「アラートは作成できたが通知精度が低い」「Log Analyticsに送っているのにディメンションが消えている」「IaCの監視テンプレートを別リソースに展開できない」といった問題を事前に発見しやすくなります。
次に取るべき行動
Azure Monitor supported metrics by resource typeは、単なる一覧ページではなく、Azure Monitorの監視設計を見直すための基準表です。まずは、自社で利用している主要リソースタイプを3つから5つ選び、既存のアラートと診断設定を公式リファレンスと照合してください。
特に優先度が高いのは、障害通知に直結するメトリックアラート、Log AnalyticsやEvent Hubsへ送っている診断設定、テンプレート化されたIaCの監視定義です。REST API名、ディメンション、集計方法、DS Exportを確認し、必要ならDCRへの移行やゲストOSメトリック収集の見直しを進めることで、Azure Monitorの監視品質を安定させやすくなります。
コメント