Azure MonitorのAzure VM／Azure Arc対応サーバー監視では、OpenTelemetryメトリックを使った新しい監視体験が一般提供（GA）になりました。結論から言うと、新規にVM監視を設計するなら、まずOpenTelemetryメトリックベースの監視を標準候補にするのが自然です。一方で、既存のVM insights、Log Analytics、KQLクエリ、InsightsMetricsテーブルに依存している環境では、すぐに旧方式を止めるのではなく、依存関係を確認して段階的に移行する必要があります。
今回の更新は、Azure MonitorでAzure Virtual MachinesとArc-enabled serversを監視する際の「メトリック収集」「可視化」「アラート」「運用画面」を、より統一された形に寄せるものです。Azure Updatesでは対象更新が「Launched」として掲載されており、Azure Updates上のLaunchedは本番利用可能な一般提供状態を意味します。(マイクロソフト Azure)
Azure MonitorのOpenTelemetryメトリックGAで何が変わったのか
今回のポイントは、Azure MonitorでVMのゲストOSメトリックを扱う際に、OpenTelemetryベースのメトリック監視が本格的な選択肢になったことです。
これまでAzure VMやArc対応サーバーの監視では、Log Analytics workspaceに収集するログベースのVM insightsを使っている環境が多くありました。これに対してOpenTelemetryメトリックベースの監視では、メトリックをAzure Monitor workspaceに保存し、PromQLでクエリします。Microsoft Learnでは、拡張監視を有効化する際に「OpenTelemetry metrics-based monitoring」と「logs-based monitoring」を選択でき、新規デプロイではOpenTelemetryメトリックが推奨されています。(Microsoft Learn)
実務上の変化は、次の3点です。
| 観点 | これまでのログベース監視 | OpenTelemetryメトリックベース監視 |
|---|---|---|
| データ保存先 | Log Analytics workspace | Azure Monitor workspace |
| 主なクエリ言語 | KQL | PromQL |
| データモデル | OSやカウンターに依存しやすい | OpenTelemetryのsystem metricsに基づく統一的な名前付け |
| 新規導入時の位置づけ | 既存互換向け | 新規環境で推奨 |
| 注意点 | Log Analyticsの取り込み・保持コストに注意 | ログとの単一KQL相関やVM Scale Sets対応などに注意 |
この変更は「Azure MonitorがOpenTelemetryという業界標準に寄せた」というだけではありません。WindowsとLinuxで異なるパフォーマンスカウンターを、より一貫したメトリック名で扱えるようにすることで、監視クエリ、ダッシュボード、アラートの標準化を進めやすくする更新です。OpenTelemetryは、テレメトリーデータを取得するためのオープンソースのオブザーバビリティフレームワークで、API、ライブラリ、エージェント、Collectorなどを通じてメトリックやトレースを収集できます。(OpenTelemetry)
対象になるリソースと影響範囲
今回のAzure Monitor OpenTelemetryメトリックの主な対象は、Azure Virtual MachinesとAzure Arc-enabled serversです。Microsoft LearnのVM監視ドキュメントでは、Azure VM、Azure VM Scale Sets、Arc-enabled serversが監視対象として整理されていますが、OpenTelemetryメトリックベースの制約や適用範囲はログベース監視と完全には同じではありません。(Microsoft Learn)
特に影響を受けるのは、次のような管理者・開発者です。
- Azure VMやArc対応サーバーのCPU、メモリ、ディスク、ネットワークを監視している運用担当者
- VM insightsのブック、ダッシュボード、アラートを運用している管理者
- Log Analyticsの
InsightsMetricsやPerfテーブルを使ったKQLクエリを保守している担当者 - Azure Monitor workspace、PromQL、Grafanaベースの可視化へ監視基盤を寄せたいSRE／開発チーム
- Azure Arcでオンプレミスや他クラウド上のサーバーをAzure Monitorに統合している組織
注意したいのは、Azure VMを使っていれば自動的にすべてのゲストOSメトリックが新方式へ移るわけではない点です。Azure Monitorはホストメトリックを自動収集しますが、ゲストOSやワークロード内の詳細なメトリックを取るには、拡張監視の構成が必要です。Microsoft Learnでは、拡張監視を有効にするとAzure Monitor AgentがVMにインストールされ、既定のメトリック収集が始まると説明されています。(Microsoft Learn)
管理者がまず確認すべき設定
Azure管理者が最初に確認すべきなのは、「どのVMがどの監視方式で収集されているか」です。ここを把握しないまま移行すると、アラートが発火しない、ダッシュボードのグラフが空になる、コスト削減のつもりが追加メトリックで費用が増える、といった失敗につながります。
Azure Monitor workspaceが用意されているか
OpenTelemetryメトリックを使う場合、メトリックの保存先としてAzure Monitor workspaceが必要です。大規模展開のドキュメントでも、OpenTelemetryメトリックを有効化する前提条件としてAzure Monitor workspaceが挙げられています。(Microsoft Learn)
既存環境でLog Analytics workspaceだけを使っていた場合は、次を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| Azure Monitor workspaceの有無 | 対象リージョン・サブスクリプションで既に作成済みか |
| ワークスペースの管理単位 | 本番／検証、部門、リージョンで分ける必要があるか |
| アクセス制御 | 運用担当者がPromQLやメトリック閲覧に必要な権限を持つか |
| 既存Log Analyticsとの役割分担 | ログはLog Analytics、メトリックはAzure Monitor workspaceとして分離するか |
特に大規模環境では、VMごとに場当たり的にワークスペースを作ると後から管理しにくくなります。まず「どの単位でAzure Monitor workspaceを分けるか」を決めてから展開するのが安全です。
Azure Monitor AgentとDCRの状態
VMのゲスト監視は、Azure Monitor AgentとData Collection Rule（DCR）の組み合わせで構成されます。Microsoft Learnでは、監視有効化の流れとして、Azure Monitor Agentのインストール、DCRの作成、DCRとVMの関連付けが説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| Azure Monitor Agent | 対象VMまたはArc対応サーバーにインストール済みか |
| DCR | OpenTelemetry用DCRとログベース用DCRが混在していないか |
| DCR association | 対象VMに意図したDCRが関連付けられているか |
| 収集先 | Azure Monitor workspaceとLog Analytics workspaceを取り違えていないか |
| 命名規則 | MSVMOtel-など、DCR名から用途を判別できるか |
OpenTelemetryメトリックのDCRは、Azure portalのData Collection RulesからVMに関連付くDCRを確認できます。Microsoft Learnでは、OTel DCRの名前がMSVMOtel-<region>-<name>の形式になることが説明されています。(Microsoft Learn)
開発者・SREが押さえるべきPromQLと可視化の違い
OpenTelemetryメトリックベース監視では、メトリックの問い合わせにPromQLを使います。これは、KQL中心で運用してきたAzure管理者にとって大きな変更点です。
たとえば、従来はLog Analytics workspaceに対してKQLでInsightsMetricsを集計していた場合、OpenTelemetryメトリックではAzure Monitor workspace上のメトリックに対してPromQLを使う設計へ置き換える必要があります。Microsoft Learnの比較表でも、メトリックベースはPromQL、ログベースはKQLと整理されています。(Microsoft Learn)
置き換え時に失敗しやすいポイント
KQLからPromQLへ移る際、単純な構文変換だけで済むとは限りません。失敗しやすいのは次のケースです。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| 既存アラートが動かない | InsightsMetrics依存のままログベースDCRを外した | 事前にアラートルールのデータソースを棚卸しする |
| ダッシュボードが空になる | GrafanaやWorkbookのクエリが旧テーブル前提 | PromQLベースのパネルへ置き換える |
| ログとメトリックを一つのKQLで相関できない | メトリックはAzure Monitor workspace、ログはLog Analytics workspaceに分かれる | 相関分析が必要な対象はログベース併用を検討する |
| VM Scale Setsで期待通り使えない | OpenTelemetryメトリックベースの制約を見落とした | 対象リソースごとに対応範囲を確認する |
| コストが下がらない | 追加メトリックやログベース収集を併用し続けている | DCR単位で収集項目と保存先を確認する |
Microsoft Learnでは、メトリックベース監視はログとメトリックを単一のKQLクエリで横断できず、ログベース監視は同一Log Analytics workspace内で相関しやすい点が示されています。また、メトリックベース収集は個別VMとArc対応サーバー向けで、ログベースはVM Scale Setsにも使えると整理されています。(Microsoft Learn)
収集できる主なメトリックと追加コストの考え方
OpenTelemetryメトリックベース監視では、既定のメトリックが収集されます。Microsoft Learnでは、system.uptime、system.cpu.time、system.memory.usage、system.network.io、system.disk.io、system.filesystem.usageなどが既定メトリックとして挙げられています。(Microsoft Learn)
既定メトリックでまず見るべき代表例は次の通りです。
| 監視対象 | 代表的なメトリック | 実務での見方 |
|---|---|---|
| CPU | system.cpu.time | CPU時間の内訳を見て、user/system/idleの偏りを確認する |
| メモリ | system.memory.usage | メモリ使用量の増加傾向や枯渇兆候を見る |
| ネットワーク | system.network.io | 送受信量の急増、通信量の偏りを確認する |
| ディスクI/O | system.disk.io、system.disk.operations | 読み書き量や操作回数からI/Oボトルネックを推測する |
| ファイルシステム | system.filesystem.usage | ディスク使用量の増加と容量逼迫を検知する |
| 稼働時間 | system.uptime | 意図しない再起動や短時間での再起動繰り返しを把握する |
コスト面では、既定のOpenTelemetryメトリックは追加料金なしで収集される一方、DCRを変更して追加のOTelメトリックを収集する場合は追加コストが発生すると説明されています。たとえば、プロセス単位のCPU使用率、メモリ使用量、ディスクI/Oなどを取得したい場合は、必要性とコストをセットで判断すべきです。(Microsoft Learn)
Grafanaダッシュボードで確認できること
今回の更新では、可視化も重要なポイントです。Azure MonitorのGrafanaダッシュボードでは、Azure portal内からVM向けの事前構築済みダッシュボードを利用でき、プラットフォームメトリック、Azure Monitor workspaceに保存されたOpenTelemetryベースのVMメトリック、Log Analytics workspaceに保存されたクラシックVMデータを扱えます。(Microsoft Learn)
用意されている代表的なダッシュボードには、次のようなものがあります。
| ダッシュボード | 向いている用途 |
|---|---|
| Platform Metrics | ゲスト監視に依存せず、Azure VM全体の基本的な稼働状況を見る |
| OpenTelemetry – Default Metrics | 追加コストなしの既定メトリックでVM状態を確認する |
| OpenTelemetry – Detailed Metrics | DCRで追加カウンターを構成したVMを詳しく見る |
| OpenTelemetry – Process Monitoring | process.*メトリックを使い、プロセス単位で調査する |
| Log Analytics | 従来のVM insightsやLog Analyticsベース監視を継続して見る |
運用では、まずPlatform Metricsで大まかな異常を確認し、OpenTelemetryのDefault MetricsでゲストOS内の状態を見て、必要に応じてDetailed MetricsやProcess Monitoringへ進む流れが使いやすいでしょう。
既存環境から移行する場合の進め方
既存のログベースVM insightsを使っている場合、いきなりログベースDCRを削除するのは危険です。Microsoft Learnの移行ガイドでは、メトリックベース監視を既定の選択肢としつつ、古いログベース監視を有効化している環境では「保持が必要か」「いつ廃止できるか」を判断する流れが示されています。(Microsoft Learn)
現実的な移行手順は次の通りです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 現状棚卸し | VM、Arc対応サーバー、DCR、ワークスペース、アラートを一覧化 | InsightsMetrics依存の有無 |
| OpenTelemetry監視を有効化 | Azure Monitor workspaceとOTel DCRを構成 | データがAzure Monitor workspaceへ入っているか |
| 可視化を確認 | Azure portal、Grafana、必要ならWorkbookで確認 | 既存ダッシュボードの代替になるか |
| アラートを置き換え | KQLベースからPromQLベースへ必要に応じて移行 | 通知先、しきい値、重大度を再確認 |
| 並行運用 | 旧方式と新方式を短期間併用 | 数日〜数週間の傾向比較を行う |
| ログベース収集を停止 | 不要になったログベースDCR associationを削除 | 過去データは保持期間内で参照可能か確認 |
| 後片付け | 不要なWorkbook、アラート、VM insights solutionを整理 | 他VMが依存していないか確認 |
ログベース監視を残すべき典型例もあります。VM Scale Setsを監視している、Private Linkが必要、組み込みの複数VMダッシュボードを使っている、ログとメトリックを単一KQLで相関している、InsightsMetricsに依存したアラートやWorkbookが残っている場合は、すぐにログベースを停止しない方が安全です。(Microsoft Learn)
新規導入ならどう設計すべきか
新規にAzure VMやArc対応サーバー監視を設計するなら、次の方針が扱いやすいです。
まず、CPU、メモリ、ディスク、ネットワークの基本監視はOpenTelemetryメトリックベースで始めます。既定メトリックで足りる範囲は追加収集を増やさず、障害調査で必要になった対象だけ、DCRで詳細メトリックやプロセス単位のメトリックを追加します。
次に、ログは別物として設計します。OpenTelemetryメトリックは時系列の性能監視に向いていますが、Windows Event Logs、Syslog、アプリケーションログ、IISログなどの調査にはLog Analytics workspaceが引き続き重要です。メトリックとログを同じものとして扱わず、「兆候検知はメトリック」「原因調査はログ」という役割分担を明確にしましょう。
最後に、アラートとダッシュボードを運用単位で標準化します。チームごとにPromQLやGrafanaパネルをバラバラに作ると、障害時に見方が揃いません。共通のDCR、共通のAzure Monitor workspace設計、共通のダッシュボードテンプレートを用意しておくと、Azure VMとArc対応サーバーの監視を同じルールで運用しやすくなります。
展開前のチェックリスト
本番環境へ展開する前に、最低限次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 対象リソース | Azure VM、Arc対応サーバー、VM Scale Setsのどれか |
| 監視方式 | OpenTelemetryメトリックのみ、ログベース併用、旧方式継続のどれか |
| ワークスペース | Azure Monitor workspaceとLog Analytics workspaceの役割が明確か |
| DCR | OTel用DCR、ログ用DCR、追加メトリック用DCRを識別できるか |
| クエリ | KQL依存をPromQLへ置き換える必要があるか |
| アラート | 既存アラートが旧テーブルに依存していないか |
| 可視化 | Grafana、Workbook、Azure portalのどこで見るか決めたか |
| コスト | 追加OTelメトリックやLog Analytics取り込み量を確認したか |
| 権限 | DCR作成、DCR関連付け、ワークスペース閲覧に必要なRBACがあるか |
| ロールバック | ログベース監視へ戻す手順を残しているか |
特に見落としやすいのは「データが取れているか」ではなく「障害時に必要なデータが取れているか」です。CPUやメモリのグラフが表示されていても、プロセス単位の原因分析、ログとの突き合わせ、既存SLAレポートへの反映ができなければ、運用上は不十分です。
まとめ：新規はOpenTelemetry、既存は依存関係を見て段階移行
Azure MonitorのOpenTelemetryメトリックGAは、Azure VMとArc対応サーバーの監視を標準化しやすくする重要な更新です。新規環境では、Azure Monitor workspace、OpenTelemetryメトリック、PromQL、Grafanaダッシュボードを前提に設計すると、Windows／LinuxやAzure／Arcの違いをまたいだ監視を組みやすくなります。
一方で、既存環境ではLog Analytics、KQL、InsightsMetrics、VM insightsのWorkbookやアラートが残っていることが多いため、すぐに旧方式を削除するのは避けるべきです。まずは対象VMとDCRを棚卸しし、OpenTelemetryメトリックで必要なデータが取れることを確認し、アラートとダッシュボードを置き換えてからログベース収集を整理しましょう。
次に取るべき行動は明確です。対象VMを数台選び、OpenTelemetryメトリックベース監視を有効化し、既定メトリック、Grafanaダッシュボード、既存アラートとの差分を確認してください。その検証結果をもとに、DCR、ワークスペース、PromQL、コスト管理の標準ルールを作ることが、本番展開で失敗しない近道です。
コメント