Azure Monitor メトリックス エクスプローラーの2026年5月更新でまず押さえるべきことは、既存のメトリック収集やアラート設定をすぐ移行しなければならない大規模変更ではない、という点です。主な変更は、メトリックの異常からログ調査へ進む Drill into Logs の説明で、古い「Diagnostic log」という表現が Resource logs に整理され、完全な Drill into Logs 体験を提供する対象が Azure Application Insights、Autoscale、Azure App Service、Azure Storage と明確化されたことです。(GitHub)
そのため、管理者や開発者が今すぐ確認すべきなのは、アプリケーション改修よりも、運用手順書、監視ダッシュボード、アラート作成手順、ログ連携の前提条件です。特に「メトリックは見えているのに、ログの深掘りができない」「複数リソースの比較ができない」「しきい値アラートが想定と違う値で発火する」といったトラブルを防ぐには、スコープ、権限、時間範囲、集計、ディメンション、リソースログの有効化をセットで見直す必要があります。
Azure Monitor メトリックス エクスプローラーの更新で何が変わったのか
今回の更新は、Azure Monitor メトリックス エクスプローラーそのものの利用方法を大きく変えるものではありません。公式変更履歴上の中心は、ログ連携に関する用語の整理と、Drill into Logs の対象リソースプロバイダーの明確化です。
| 確認項目 | 変更・明確化された内容 | 実務上の対応 |
|---|---|---|
| ログの名称 | 「Diagnostic log」ではなく「Resource logs」として説明 | 手順書や教育資料で「診断ログ」とだけ書いている箇所を「リソースログ」に更新する |
| Drill into Logs の対象 | Application Insights、Autoscale、Azure App Service、Azure Storage が明示 | これら以外のリソースで同じ深掘り操作を前提にしない |
| 移行作業 | 既存メトリック、既存アラートを一律で作り直す変更ではない | 監視設定の棚卸しと、ログ連携の前提確認を優先する |
| 運用影響 | メトリック異常からログ原因調査へ進む流れに影響 | 障害対応手順で「どのログを有効化しているか」を確認する |
Azure Monitor メトリックス エクスプローラーでは、メトリックのスパイクや急落を起点にログへ掘り下げられます。このとき参照対象になる Resource logs は、Azure リソース内部、つまりデータプレーン側の操作を把握するためのログです。たとえば Key Vault からのシークレット取得や、データベースへの要求などが該当します。リソースログの内容はサービスやリソースの種類によって異なり、利用するには対象リソース側で有効化が必要です。(Microsoft Learn)
Azure Monitor メトリックス エクスプローラーでできることを整理する
Azure Monitor のメトリックは、時間の経過に沿って収集・保存される数値データです。標準メトリック、つまりプラットフォームメトリックは Azure リソースの正常性や使用状況を表します。一方で、アプリケーション独自の処理時間、業務件数、キュー滞留数などは、カスタムメトリックとして収集する設計が必要です。(Microsoft Learn)
Azure Monitor メトリックス エクスプローラーは、これらのメトリックを Azure portal 上でグラフ化し、傾向の確認、急増・急減の調査、複数メトリックの比較、アラート作成、ダッシュボード共有に使うための機能です。単に「CPU 使用率を見る画面」ではなく、障害調査やキャパシティ計画の入り口として使うのが実務上の位置づけです。(Microsoft Learn)
メトリックの種類も整理しておきましょう。Azure Monitor では、プラットフォームメトリック、カスタムメトリック、Prometheus メトリックなどが扱われます。プラットフォームメトリックは構成不要で収集され、カスタムメトリックはアプリケーションやエージェントなどの収集元に応じた設定が必要です。Prometheus メトリックは Azure Monitor ワークスペースなどを使って扱う設計になります。(Microsoft Learn)
管理者が最初に確認すべきスコープと権限
Azure Monitor メトリックス エクスプローラーで最初に確認すべき設定は、どのリソースを分析対象にするかです。単一リソースであれば比較的単純ですが、複数リソース、リソースグループ、サブスクリプション単位で分析する場合は条件があります。
複数リソースのメトリックを同時に表示するには、対象リソースが同じサブスクリプション、同じリージョン、同じリソース種類である必要があります。条件を満たさないリソースは選択できません。また、複数リソース、リソースグループ、サブスクリプション全体のメトリックを可視化するには、サブスクリプションレベルで Monitoring Reader 権限が必要です。(Microsoft Learn)
| 確認ポイント | よくある失敗 | 対応 |
|---|---|---|
| サブスクリプション | 別サブスクリプションの VM を同じグラフで比較しようとする | サブスクリプション単位でグラフを分ける |
| リージョン | 東日本と西日本の同種リソースを同時選択できない | リージョン別に比較し、Workbook などで並べる |
| リソース種類 | App Service と Storage Account を同じスコープで比較しようとする | メトリックの目的ごとにチャートを分ける |
| 権限 | 個別リソースは見えるが、リソースグループ全体が見えない | サブスクリプションレベルの Monitoring Reader を確認する |
管理者は、監視担当者に Contributor 権限を広く付与する前に、まず Monitoring Reader で足りるか確認してください。読み取り専用でメトリック分析できる範囲を広げれば、運用の安全性を保ちながら調査スピードを上げられます。
時間範囲と保持期間は障害調査の成否を左右する
メトリック分析では、時間範囲の設定を誤ると原因を見逃します。Azure Monitor メトリックス エクスプローラーでは、既定で直近24時間のメトリックデータが表示されます。多くの Azure メトリックは93日間保存されますが、1つのグラフで一度にクエリできるのは最大30日分です。ログベースのメトリックはこの30日制限の例外です。(Microsoft Learn)
障害対応では、次のように時間範囲を使い分けると効率的です。
| 調査シーン | 推奨する時間範囲 | 見るべきポイント |
|---|---|---|
| いま発生中の障害 | 直近30分〜6時間 | 急激なスパイク、急落、直前の変更 |
| 昨日からの性能劣化 | 直近24〜48時間 | 前日同時刻との違い、継続的な上昇傾向 |
| 月次の容量確認 | 7〜30日 | ピーク時間帯、週次傾向、増加ペース |
| 過去障害との比較 | 30日を超える場合はパン操作や別チャートを活用 | 同じ曜日・同じ時間帯の再現性 |
特に、アラート後に「その時間帯だけ詳細に見る」場合は、グラフのズーム機能を使うと便利です。時間粒度を自動にしていると、ズーム時により細かい粒度が選択され、同じメトリックス エクスプローラー内のすべてのグラフに新しい時間範囲が適用されます。(Microsoft Learn)
集計方法を間違えると、グラフの読み方もアラートもずれる
Azure Monitor メトリックス エクスプローラーでは、メトリックをグラフ化する際に集計が適用されます。利用できる集計は、Sum、Count、Average、Min、Max の5種類です。メトリックによって使える集計は異なり、関係のない集計は非表示になります。(Microsoft Learn)
| 集計 | 向いている用途 | 注意点 |
|---|---|---|
| Sum | リクエスト数、転送量、エラー件数の合計 | 時間粒度が変わると値の見え方が変わる |
| Count | 測定値の件数、イベント数 | 値が常に1のメトリックでは Sum と近い意味になる場合がある |
| Average | CPU 使用率、平均応答時間 | 瞬間的なピークが隠れやすい |
| Min | 空き容量、最低可用性、最小応答値 | 障害検知では「低下」を見る用途に向く |
| Max | 最大応答時間、最大 CPU、ピーク負荷 | 短時間のスパイク確認に向く |
たとえば、サーバー応答時間を Average だけで見ていると、一部ユーザーだけが極端に遅い状態を見逃すことがあります。逆に Max だけを見ると、一瞬の外れ値を過大評価する可能性があります。実務では、平均値で全体傾向を見た後、Max やディメンション分割で異常なセグメントを確認する流れが有効です。
ディメンションのフィルターと分割で「どこが悪いか」を特定する
Azure Monitor メトリックス エクスプローラーの強みは、ディメンションを使ってメトリックを絞り込んだり、分割したりできる点です。フィルターは表示するディメンション値を選ぶ機能で、分割はディメンションの値ごとに別々の線として表示する機能です。(Microsoft Learn)
たとえば、Storage Account の Transaction count で Response type ディメンションを使えば、成功と失敗を分けて確認できます。App Service や Application Insights では、インスタンス別、エンドポイント別、成功/失敗別のように分割すると、全体平均では見えない外れ値を見つけやすくなります。
分割後に表示できる値の数には制限があり、既定は10、範囲は1〜50です。また、選択した時間範囲の結果セットに存在しないディメンション値は、フィルター値の候補に表示されません。(Microsoft Learn)
実務では、以下の順番で使うと迷いにくくなります。
- まず全体のメトリックを表示する
- 異常が見えた時間帯へズームする
- 影響がありそうなディメンションで分割する
- 無関係なセグメントをフィルターで除外する
- 問題のセグメントをログやアプリ側の変更履歴と照合する
同じディメンションでフィルターと分割を組み合わせると、不要な線を減らしながら重要な差分だけを見られます。これは、障害調査だけでなく、コストや性能のばらつきを確認する場面でも役立ちます。
Y軸ロックは見た目の調整ではなく、異常検知の補助になる
グラフのY軸範囲をロックする機能は、単なる見た目の調整ではありません。たとえば成功率が99.99%から99.5%に落ちた場合、通常の自動スケールでは小さな変動に見えてしまうことがあります。しかし、Y軸の下限を99%に固定すれば、サービス品質上は大きな低下であることが視覚的に分かりやすくなります。(Microsoft Learn)
ただし、Count、Sum、Min、Max のように時間粒度の影響を受けやすい集計でY軸をロックする場合は、時間粒度を固定してください。自動のままにすると、ブラウザーサイズや画面解像度の変更で時間粒度が変わり、グラフの値や見え方が変わることがあります。(Microsoft Learn)
アラート作成時はグラフ設定をそのまま信用しすぎない
Azure Monitor メトリックス エクスプローラーでは、表示中のグラフ条件を使ってメトリックベースのアラートルールを作成できます。新しいアラートルールには、チャートの対象リソース、メトリック、分割、フィルターのディメンションが含まれます。(Microsoft Learn)
便利な機能ですが、グラフで見やすい条件と、アラートとして安全な条件は必ずしも同じではありません。たとえば、障害調査中に一時的に特定インスタンスだけをフィルターしていた場合、その条件を意図せずアラートに反映してしまうと、他のインスタンスの異常を検知できない可能性があります。
アラート作成前に、次の項目を確認してください。
| 確認項目 | 確認する理由 |
|---|---|
| 対象リソース | 調査用に絞ったリソースだけを監視していないか確認する |
| 集計 | Average、Max、Sum の違いで発火条件が大きく変わる |
| 時間粒度 | 短すぎるとノイズが増え、長すぎると検知が遅れる |
| フィルター | 成功だけ、失敗だけ、特定リージョンだけなどの条件が残っていないか確認する |
| 分割 | インスタンス別・API別に発火させたいのか、全体で発火させたいのか決める |
| 重大度 | Critical、Error、Warning などを通知ルールと合わせる |
アラートは「グラフで異常に見えたから作る」だけでは不十分です。誰が受け取り、何分以内に対応し、どの手順で切り分けるのかまで決めて初めて運用に使えます。
Drill into Logs を使う前にリソースログの有効化を確認する
今回の更新で特に注意したいのが、メトリックからログへ深掘りする流れです。Drill into Logs は、メトリックの異常とアクティビティログ、リソースログ、推奨ログを関連付けて原因調査を支援します。ただし、完全な Drill into Logs 体験が明示されているリソースプロバイダーは、Azure Application Insights、Autoscale、Azure App Service、Azure Storage です。(Microsoft Learn)
リソースログは既定では収集されません。診断設定を作成して、Log Analytics ワークスペース、Storage Account、Event Hubs などの送信先を指定する必要があります。プラットフォームメトリックとアクティビティログは構成なしで自動収集されますが、リソースログは別扱いです。(Microsoft Learn)
ここを誤解すると、次のような問題が起きます。
| 状況 | 原因 | 対応 |
|---|---|---|
| メトリックは表示されるがログが出ない | リソースログの診断設定がない | 対象リソースで診断設定を作成する |
| Log Analytics に期待したテーブルがない | ログがまだ送信されていない、またはカテゴリ未選択 | ログカテゴリと送信先を確認する |
| Storage Account や Event Hubs に送れない | 宛先のネットワーク制限やリージョン条件 | 信頼された Microsoft サービスの許可や宛先リージョンを確認する |
| コストが急増する | 必要以上のカテゴリやメトリックを送信している | 必要なカテゴリだけを収集する |
診断設定にはコスト面の注意もあります。公式ドキュメントでは、各サービスに必要なカテゴリのみを収集し、Log Analytics で複雑なログクエリ分析が必要な場合にだけメトリックデータをワークスペースへ送るよう推奨されています。プラットフォームメトリックは既に収集されているため、Metrics Explorer で見るだけなら診断設定で重複収集する必要はありません。(Microsoft Learn)
PromQL を使う場合は通常のメトリック分析と分けて考える
Azure Monitor メトリックス エクスプローラーでは、Azure Monitor ワークスペースに保存されたメトリックに対して PromQL を使った分析もできます。PromQL を使う場合は、Azure Monitor ワークスペースの [メトリック] メニューから利用します。(Microsoft Learn)
ここで注意したいのは、PromQL のエディターと通常のクエリビルダーの役割が違うことです。エディターでは Azure Monitor ワークスペースに格納されたメトリックに対して PromQL クエリを入力できます。一方、ビルダーでは任意の Azure リソースからメトリック、集計、グラフ種類を選択できますが、Azure Monitor ワークスペースに格納されたメトリックをグラフ化する用途ではありません。(Microsoft Learn)
また、同じグラフでコードエディターとクエリビルダーの両方を使うことはサポートされておらず、予期しない動作につながる可能性があります。Prometheus メトリックを扱うチームは、通常の Azure リソースメトリック用チャートと PromQL 用チャートを分けて設計した方が安全です。(Microsoft Learn)
ダッシュボード、Workbook、Grafana への共有時に確認すること
構成したメトリックチャートは、Azure ダッシュボードや Workbook に追加できます。チームで監視状況を共有する場合は、単発のリンク共有だけでなく、運用導線に合わせて保存先を選ぶことが重要です。Azure Monitor メトリックス エクスプローラーの共有メニューでは、Excel へのダウンロード、リンクコピー、Workbook への送信、Grafana ダッシュボードへのピン留めなどが利用できます。(Microsoft Learn)
| 共有方法 | 向いている用途 | 注意点 |
|---|---|---|
| Azure ダッシュボード | 運用担当者が日常的に見る監視画面 | チャートの意味が分かる名前を付ける |
| Workbook | 障害調査、月次レビュー、複数観点の分析 | メトリック、ログ、説明文をまとめやすい |
| Excel ダウンロード | 一時的な報告、数値の確認 | 継続監視には向かない |
| Grafana | 既存の可視化基盤と統合したい場合 | 権限とデータソース設計を事前に確認する |
| リンクコピー | 調査中の共有 | 権限がない相手には見えない可能性がある |
監視画面は「作って終わり」になりがちです。リリース後にサービス構成が変わったら、対象リソース、リージョン、メトリック名、ディメンションが古くなっていないかを定期的に確認してください。
管理者・開発者が今すぐ確認すべきチェックリスト
今回の更新を受けて、Azure Monitor メトリックス エクスプローラーを利用している環境では、以下を確認しておくと安全です。
| 対象 | 確認内容 | 優先度 |
|---|---|---|
| 運用手順書 | 「Diagnostic log」や「診断ログ」という表現が、実際には Resource logs を指していないか | 高 |
| 障害対応フロー | メトリック異常から Drill into Logs へ進む対象リソースが明記されているか | 高 |
| 診断設定 | リソースログが必要なリソースで有効化され、正しい宛先に送信されているか | 高 |
| 権限 | 複数リソース分析に必要な Monitoring Reader が適切な範囲で付与されているか | 高 |
| アラート | フィルター、分割、集計、時間粒度が意図どおりか | 高 |
| ダッシュボード | 対象リソースやリージョンが現行構成と一致しているか | 中 |
| PromQL 利用 | Azure Monitor ワークスペースのメトリックと通常の Azure リソースメトリックを混同していないか | 中 |
| コスト | 診断設定で不要なログカテゴリやメトリックを送信していないか | 中 |
移行という観点では、今回の更新だけを理由に既存のダッシュボードやアラートを一括作り直す必要はありません。ただし、ログ連携を前提にしている監視設計では、リソースログの有効化、対象プロバイダー、権限、コストをまとめて確認すべきです。
まとめ：まずはログ連携とアラート条件を棚卸しする
Azure Monitor メトリックス エクスプローラーの今回のポイントは、機能の大規模変更ではなく、メトリック異常からログ調査へ進む際の前提がより明確になったことです。特に、Resource logs という用語への整理と、Drill into Logs の対象リソースプロバイダーの明示は、運用手順や障害対応フローに影響します。
次に取るべき行動は明確です。まず、既存の監視手順書に「Diagnostic log」「診断ログ」と書かれている箇所を確認し、必要に応じて Resource logs に修正します。次に、重要リソースでリソースログの診断設定が有効か、Log Analytics などの送信先が適切かを確認します。最後に、メトリックアラートの集計、時間粒度、フィルター、分割条件を見直してください。
Azure Monitor メトリックス エクスプローラーは、グラフを見るだけの機能ではありません。メトリックで異常を見つけ、ディメンションで影響範囲を絞り、ログで原因を掘り下げ、アラートとダッシュボードで再発検知に備えるための運用基盤です。今回の更新をきっかけに、監視設定を「見える」状態から「調べられる・対応できる」状態へ整えておきましょう。
コメント