Azure Monitor agent（AMA）が Windows Arc-enabled server で動かない、ログが Log Analytics に届かない、DCR を関連付けたのに反映されない――この場合、最初に見るべき場所は「エージェント単体」ではありません。結論から言うと、Azure Arc 接続、AzureMonitorWindowsAgent 拡張機能、DCR の関連付け、DCR のダウンロード、データソース別設定の順に切り分けるのが最短です。
特に今回の公式情報で重要なのは、Windows イベントログ収集について「イベントログファイルがローカルディスク上にある場合のみ Azure Monitor Agent でサポートされる」という注記です。ネットワーク共有や UNC パス上にある Windows Event Log ファイルはサポート対象外のため、オンプレミスや他クラウドの Windows Server を Azure Arc 経由で監視している環境では、ログ配置と DCR 設計を見直す必要があります。(Microsoft Learn)
Azure Monitor agent on Windows Arc-enabled serverで何が変わったのか
Microsoft Learn の対象ページ「Troubleshoot the Azure Monitor agent on Windows Arc-enabled server」は、Windows Arc 対応サーバー上の Azure Monitor Agent と Data Collection Rules（DCR）のトラブルシューティングを扱う公式ガイドです。ページ上は 2026年5月8日最終更新と表示され、GitHub 履歴では 2026年4月9日にコンテンツ鮮度レビュー、2026年4月28日に Windows イベントログ収集に関する注記追加が確認できます。(Microsoft Learn)
今回の更新は「新しいエージェント機能が追加された」というより、Windows Arc 対応サーバーでログが取れないときの確認ポイントがより明確になったと捉えるのが実務的です。
| 確認ポイント | 実務上の意味 | 管理者が取るべき対応 |
|---|---|---|
| Windows イベントログはローカルディスク上のみサポート | UNC パスやネットワーク共有に置いたイベントログは収集対象外 | イベントログの保存場所を確認し、必要ならローカル保存へ変更する |
| DCR の存在と関連付けを重視 | AMA は DCR に従って何を収集し、どこへ送るかを決める | DCR が Arc サーバーに関連付けられているか確認する |
| Arc エージェントと拡張機能の状態確認が前提 | AMA は Arc 対応サーバーでは拡張機能として展開される | azcmagent show と Azure portal の拡張機能状態を見る |
| Log Analytics 送信時はリージョンも確認 | DCR と送信先ワークスペースのリージョン不整合が原因になる場合がある | DCR と Log Analytics workspace の物理リージョンを確認する |
| 旧 Log Analytics agent との併用に注意 | 二重収集や移行漏れの原因になる | 移行計画を立て、検証後に旧エージェントを外す |
Azure Monitor Agent は、Azure VM やハイブリッド VM のゲスト OS から監視データを収集し、Azure Monitor、Microsoft Sentinel、Microsoft Defender for Cloud などで利用できるようにするエージェントです。収集対象、処理方法、送信先は DCR で定義されます。(Microsoft Learn)
影響範囲：対象になるWindows環境
影響を受けるのは、主に次のような環境です。
- オンプレミスの Windows Server を Azure Arc-enabled servers として登録している環境
- 他クラウド上の Windows Server を Azure Arc 経由で Azure Monitor に接続している環境
- Azure Monitor Agent で Windows イベントログ、パフォーマンスカウンター、カスタムメトリックを収集している環境
- Log Analytics agent から Azure Monitor Agent へ移行中、または移行が完了していない環境
- DCR を Azure Policy、ARM テンプレート、Azure CLI、PowerShell で展開している環境
Windows のサポート OS は Microsoft Learn のサポート一覧で確認できます。2026年5月時点の公式ページでは、Windows Server 2025、2022、2019、2016、ESU 契約付き Windows Server 2012 R2 などが一覧化され、x86 はサポート対象外とされています。展開前に、対象 OS とエージェント要件を必ず確認してください。(Microsoft Learn)
最初に確認すべき全体像
Windows Arc-enabled server で Azure Monitor agent の問題を調べるときは、次の順番で確認します。順番を飛ばすと、DCR の JSON を何度直しても、実は Arc 接続や拡張機能が失敗していた、という遠回りになりがちです。
| 順番 | 確認する層 | 主な確認方法 | よくある原因 |
|---|---|---|---|
| 1 | Azure Arc 接続 | azcmagent show | HIMDS、GC、Extension Service が動いていない |
| 2 | AMA 拡張機能 | Azure portal の Extensions | AzureMonitorWindowsAgent が Succeeded になっていない |
| 3 | AMA プロセス | タスクマネージャー、Heartbeat | MonAgentCore.exe が動いていない |
| 4 | DCR 関連付け | DCR の Resources、ローカル設定ファイル | Arc サーバーが DCR に関連付いていない |
| 5 | DCR ダウンロード | configchunks フォルダー | AMCS から DCR を取得できていない |
| 6 | データソース別設定 | DCR JSON、mcsconfig.lkg.xml | performanceCounters や windowsEventLogs がない |
公式の基本トラブルシューティングでは、Azure portal で AzureMonitorWindowsAgent 拡張機能が Succeeded になっていること、azcmagent show で Arc 関連サービスが running であること、Heartbeat クエリ、DCR の関連付け、DCR のダウンロード状態を順に確認する流れが示されています。(Microsoft Learn)
Azure Arcエージェントと拡張機能を確認する
Azure 以外のマシンでは、Azure Monitor Agent を入れる前に Azure Arc agent、つまり Connected Machine agent が必要です。Azure Monitor Agent は Arc 対応サーバー上では拡張機能として導入されます。VM 拡張機能として AMA だけを入れても、DCR が作成・関連付けされていなければデータ収集は始まりません。(Microsoft Learn)
まず対象サーバー上で次を実行します。
azcmagent show確認すべきポイントは、少なくとも次のサービスが running になっていることです。
Agent Service (himds) : running
GC Service (gcarcservice) : running
Extension Service (extensionservice) : running次に Azure portal で、対象の Arc-enabled server を開きます。
Arc-enabled server
→ Settings
→ Extensions
→ AzureMonitorWindowsAgent
→ Status: Succeeded拡張機能が表示されない、または Succeeded にならない場合は、Arc agent の接続、拡張機能サービス、インストールログを確認します。公式ガイドでは、状態遷移中の可能性もあるため 10〜15分待ってから再確認し、それでも表示されない場合は拡張機能のアンインストールと再インストールを検討する流れが示されています。(Microsoft Learn)
Arc 対応 Windows サーバーの拡張機能ログは、次の場所を確認します。
C:\ProgramData\GuestConfig\extension_logs\Microsoft.Azure.Monitor.AzureMonitorWindowsAgentエージェントが動いているかHeartbeatで確認する
拡張機能が Succeeded でも、実際に Log Analytics にデータが届いているとは限りません。次に、Heartbeat を確認します。
Heartbeat
| where Category == "Azure Monitor Agent"
| where Computer == "<computer-name>"
| take 10Azure Monitor Agent が Azure Monitor と正常に通信している場合、Heartbeat テーブルにレコードが送信されます。公式のデータ収集ガイドでは、エージェントが正しく通信している場合に Heartbeat テーブルを確認できると説明されています。(Microsoft Learn)
ただし、DCR の送信先が Custom Metrics のみの場合は、Log Analytics workspace に Heartbeat が出ない前提で判断します。公式の Windows Arc トラブルシュートでも、DCR の宛先が Custom Metrics のみの場合は Heartbeat 確認をスキップするよう示されています。(Microsoft Learn)
Heartbeat が出ない場合は、タスクマネージャーで次のプロセスを確認します。
MonAgentCore.exeプロセスが存在する場合は、数分待ってから再度 Heartbeat を確認します。プロセスがない、またはログにエラーがある場合は、次のコアエージェントログを確認します。
C:\Resources\Directory\AMADataStore\ConfigurationDCRの関連付けとリージョンを確認する
Azure Monitor Agent のトラブルでは、DCR の見落としが非常に多いです。AMA は「インストールされているか」だけではなく、「どの DCR が関連付けられているか」で収集内容が決まります。DCR は、収集するデータ、変換、送信先を定義する Azure リソースです。(Microsoft Learn)
Log Analytics workspace を送信先にしている場合は、DCR がそのワークスペースと同じ物理リージョンにあるか確認します。公式トラブルシュートでは、Log Analytics workspace を送信先にする場合、DCR がワークスペースと同じ物理リージョンに存在することを確認するよう案内されています。(Microsoft Learn)
対象サーバーでは、次のファイルを確認します。
C:\Resources\Directory\AMADataStore\mcs\mcsconfig.latest.xmlこのファイルが存在しない場合、対象の Arc-enabled server が DCR に関連付けられていない可能性があります。Azure portal では次の順に確認します。
Data Collection Rule
→ Configuration
→ Resources
→ 対象の Arc-enabled server が表示されているか確認表示されていない場合は、DCR の Resources に対象サーバーを追加します。複数の DCR を運用している場合は、すべての関連 DCR で対象サーバーが正しく関連付けられているか確認してください。
DCRがサーバーにダウンロードされているか確認する
DCR が Azure 側で存在していても、エージェントが DCR を取得できていなければデータ収集は始まりません。Azure Monitor Agent は Azure Monitor Configuration Service（AMCS）から関連付けられた DCR を取得します。公式ページの用語説明でも、AMCS はエージェントが DCR を取得するために呼び出す Azure 側の構成サービスと説明されています。(Microsoft Learn)
次のフォルダーに最新の DCR 構成があるか確認します。
C:\Resources\Directory\AMADataStore\mcs\configchunksここに構成がない場合は、DCR 関連付け、Arc 接続、ネットワーク、認証のどれかで問題が起きている可能性があります。
パフォーマンスカウンターが収集されない場合
Windows の CPU、メモリ、ディスクなどのパフォーマンスカウンターが Log Analytics に出ない場合は、DCR のデータソース設定と、サーバー側に反映された構成の両方を見ます。
まず DCR JSON に performanceCounters セクションがあるか確認します。
"performanceCounters": [
{
"streams": [
"Microsoft-Perf"
],
"samplingFrequencyInSeconds": 60,
"counterSpecifiers": [
"\\Processor(_Total)\\% Processor Time",
"\\Memory\\Committed Bytes"
],
"name": "perfCounterDataSource"
}
]次に、対象サーバー上で次のファイルを確認します。
C:\Resources\Directory\AMADataStore\mcs\mcsconfig.lkg.xmlこのファイル内に CounterSet ノードがあるか確認します。公式トラブルシュートでも、DCR JSON に performanceCounters があること、mcsconfig.lkg.xml が存在すること、CounterSet ノードが含まれることを確認する手順が示されています。(Microsoft Learn)
よくある失敗は、DCR を作成したものの対象サーバーに関連付けていないケースです。もう一つは、同じサーバーに似た DCR を複数関連付け、意図しない重複収集やコスト増につながるケースです。Azure Monitor のデータ収集ガイドでは、同じデータソースを持つ複数の DCR を同じ VM に関連付けると重複データになり、課金増につながる可能性があると説明されています。(Microsoft Learn)
Custom Metricsを送信している場合の確認点
Custom Metrics を宛先にしている場合は、Log Analytics の Heartbeat だけで判断しないことが重要です。DCR が Azure Monitor Metrics に送る構成になっているか、認証トークンやメトリック拡張の設定ファイルがあるかを確認します。
DCR には、次のような azureMonitorMetrics 宛先が必要です。
"destinations": {
"azureMonitorMetrics": {
"name": "myAmMetricsDest"
}
}さらに、PowerShell で MetricsExtension.Native.exe の実行状態を確認します。
Get-WmiObject Win32_Process -Filter "name = 'MetricsExtension.Native.exe'" |
select Name,ExecutablePath,CommandLine |
Format-ListCommandLine に次の引数が含まれているか確認します。
-TokenSource MSI続いて、次のファイルの存在を確認します。
C:\Resources\Directory\AMADataStore\mcs\AuthToken-MSI.json
C:\Resources\Directory\AMADataStore\mcs\CUSTOMMETRIC_<subscription>_<region>_MonitoringAccount_Configuration.json公式ガイドでは、Custom Metrics のトラブルシュートとして、DCR の azureMonitorMetrics 宛先、MetricsExtension.Native.exe の -TokenSource MSI、AuthToken-MSI.json、MonitoringAccount 構成ファイル、table2csv.exe によるログ採取を確認する流れが示されています。(Microsoft Learn)
なお、Azure Arc-enabled servers では、Azure Monitor Agent の認証としてシステム割り当てマネージド ID のみがサポートされます。これは Azure Arc agent のインストール時に自動的に有効化されます。(Microsoft Learn)
Windowsイベントログが収集されない場合
Windows イベントログの収集で最初に確認すべき点は、DCR JSON に windowsEventLogs があるかです。
"windowsEventLogs": [
{
"streams": [
"Microsoft-Event"
],
"xPathQueries": [
"System!*[System[(Level=1 or Level=2 or Level=3)]]",
"Application!*[System[(Level=1 or Level=2 or Level=3)]]"
],
"name": "eventLogsDataSource"
}
]次に、対象サーバー上で次のファイルを確認します。
C:\Resources\Directory\AMADataStore\mcs\mcsconfig.lkg.xmlこのファイル内に Subscription ノードがあるかを見ます。公式トラブルシュートでは、DCR JSON の windowsEventLogs、mcsconfig.lkg.xml、Subscription ノードを確認する手順が示されています。(Microsoft Learn)
ここで重要なのが、今回追加された注記です。Azure Monitor Agent による Windows イベントログ収集は、Windows Event Log ファイルがローカルディスク上に保存されている場合のみサポートされます。ネットワーク共有や UNC パス上に設定されたイベントログはサポートされません。(Microsoft Learn)
たとえば、監査ログやアプリケーションログをファイルサーバー上に逃がしている環境では、DCR が正しくても Azure Monitor Agent 側では収集できない可能性があります。この場合は、次のどちらかを検討します。
| 状況 | 推奨対応 |
|---|---|
| Windows Event Log 自体を UNC パスに保存している | ローカルディスク保存に戻し、必要に応じて別手段でアーカイブする |
| アプリケーションログを共有フォルダーに出している | AMA の Windows event logs ではなく、対象データソースとして扱える形式か再設計する |
| セキュリティ要件で共有先保存が必須 | 収集経路を AMA だけに依存せず、SIEM 側や別の転送方式を検討する |
| 監視対象が多数ある | DCR とログ保存場所を標準化し、例外サーバーを棚卸しする |
ネットワークとプロキシの注意点
Arc 対応サーバーはオンプレミスや他クラウドに存在することが多いため、ネットワーク制御が原因で DCR 取得やログ送信に失敗することがあります。
Azure Monitor Agent のネットワーク構成では、必要なエンドポイントへのアウトバウンド 443/TCP 通信が前提です。公式ページでは、ファイアウォールで許可すべきエンドポイントと用途が整理されており、すべてのエンドポイントで HTTPS inspection を無効にする必要があるとされています。(Microsoft Learn)
特に確認したい宛先は次の通りです。
| 用途 | 代表的な宛先 |
|---|---|
| 制御サービスへのアクセス | global.handler.control.monitor.azure.com |
| マシン固有リージョンの DCR 取得 | <region>.handler.control.monitor.azure.com |
| Log Analytics へのログ送信 | <workspace-id>.ods.opinsights.azure.com |
| Custom Metrics 送信 | management.azure.com、<region>.monitoring.azure.com |
| DCE 経由のログ送信 | <data-collection-endpoint>.<region>.ingest.monitor.azure.com |
また、Azure Monitor Agent は直接プロキシ、Log Analytics gateway、Private Link などをサポートしますが、Arc-enabled servers では OMS Gateway がプロキシ接続、Private Link 接続、パブリックエンドポイント接続の選択肢としてサポートされない点に注意が必要です。(Microsoft Learn)
ネットワーク調査では、単に「インターネットに出られるか」ではなく、DCR 取得用、ログ送信用、メトリック送信用の宛先を分けて確認してください。DCR は取得できるがログが送れない、ログは送れるが Custom Metrics だけ失敗する、という切り分けができます。
展開時に確認すべき設定
Windows Arc-enabled server に Azure Monitor Agent を展開する方法は複数あります。単体であれば Azure portal や PowerShell、Azure CLI で対応できますが、台数が多い場合は Azure Policy や IaC を使って標準化するのが現実的です。
Arc 対応サーバーへ PowerShell で Azure Monitor Agent を入れる場合の公式例は、次の形式です。(Microsoft Learn)
New-AzConnectedMachineExtension `
-Name AzureMonitorWindowsAgent `
-ExtensionType AzureMonitorWindowsAgent `
-Publisher Microsoft.Azure.Monitor `
-ResourceGroupName <resource-group-name> `
-MachineName <arc-server-name> `
-Location <arc-server-location> `
-EnableAutomaticUpgradeAzure CLI では次の形式です。
az connectedmachine extension create \
--name AzureMonitorWindowsAgent \
--publisher Microsoft.Azure.Monitor \
--type AzureMonitorWindowsAgent \
--machine-name <arc-server-name> \
--resource-group <resource-group-name> \
--location <arc-server-location> \
--enable-auto-upgrade true注意したいのは、拡張機能のインストールだけでは DCR は作られないという点です。VM extension 方式で AMA を入れた場合、少なくとも 1 つの DCR を作成してエージェントに関連付ける必要があります。一方、Azure portal で DCR を作成し、その DCR のリソースとして対象マシンを追加する流れでは、対象マシンに Azure Monitor Agent がインストールされ、DCR に従ってデータ収集が始まります。(Microsoft Learn)
移行時の注意：Log Analytics agentとの二重収集を避ける
旧 Log Analytics agent、別名 Microsoft Monitoring Agent（MMA）や OMS agent から Azure Monitor Agent へ移行する場合は、二重収集に注意してください。Microsoft Learn では、Log Analytics agent は 2024年8月31日に廃止され、2026年3月2日以降はデータアップロードがいつ停止してもおかしくない状態になると説明されています。(Microsoft Learn)
移行の基本手順は次の通りです。
| フェーズ | 作業 | 失敗しやすいポイント |
|---|---|---|
| 棚卸し | 旧エージェント、ワークスペース、依存サービスを確認 | 使っていないと思ったワークスペースに依存サービスが残っている |
| DCR 作成 | 既存設定を DCR に変換・再設計 | 旧エージェントの設定をそのまま再現できると思い込む |
| パイロット展開 | 少数サーバーで AMA と DCR を検証 | Heartbeat だけ見て、イベントや Perf の件数比較をしない |
| 二重収集対策 | テスト中は旧エージェントの収集設定を外す | 同じテーブルに重複データが入り課金が増える |
| 本番展開 | Azure Policy などで横展開 | 手動展開でサーバーごとに DCR 差分が出る |
| 旧エージェント削除 | AMA の収集確認後に MMA を削除 | SCOM 利用環境の例外整理を忘れる |
公式の移行ガイドでも、パイロットグループで DCR を展開し、データ収集を検証し、二重取り込みを避けるためにテスト中は Log Analytics agent のワークスペース構成を外し、検証後に旧エージェントを削除する流れが示されています。(Microsoft Learn)
DCR編集で失敗しやすいポイント
DCR は Azure portal から編集できるため便利ですが、JSON を直接編集して高度な設定を入れている環境では注意が必要です。公式のデータ収集ガイドでは、Azure portal で既存 DCR を編集すると、ポータルでサポートされていない JSON 直接編集の内容が上書きされる可能性があると警告されています。たとえば、ポータルで作成できない transformation を JSON で追加している場合、後からポータル編集すると削除される可能性があります。(Microsoft Learn)
実務では、次のように運用を分けると事故を減らせます。
| DCRの使い方 | 推奨する管理方法 |
|---|---|
| 標準的なイベントログ、Perf 収集のみ | Azure portal で作成・編集してもよい |
| transformation を使う | JSON、ARM/Bicep、Terraform など IaC 管理を優先 |
| 多数サーバーへ同じ設定を適用 | Azure Policy や IaC で関連付けを標準化 |
| 部門ごとに異なるログを収集 | DCR を用途別に分け、命名規則を決める |
| コスト最適化が必要 | DCR のフィルター、収集間隔、対象ログレベルを明示的に設計する |
DCR は柔軟ですが、柔軟だからこそ「誰が、どの DCR を、どのサーバーに関連付けたか」を追える状態にしておくことが重要です。
管理者・開発者向けチェックリスト
トラブル対応や展開前レビューでは、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| Arc 接続 | azcmagent show で himds、gcarcservice、extensionservice が running |
| 拡張機能 | Azure portal で AzureMonitorWindowsAgent が Succeeded |
| 再起動要否 | AMA のインストール、更新、アンインストールでは通常マシン再起動は不要 |
| ディスク容量 | Windows Arc の AMA キャッシュ領域として十分な空き容量があるか |
| DCR | 対象 Arc サーバーが DCR の Resources に入っている |
| リージョン | Log Analytics workspace 宛先の場合、DCR とワークスペースの物理リージョンを確認 |
| Heartbeat | Log Analytics 宛先がある場合、Heartbeat を KQL で確認 |
| Perf | DCR JSON に performanceCounters、ローカル構成に CounterSet |
| Windows Event Logs | DCR JSON に windowsEventLogs、ローカル構成に Subscription |
| ログ保存場所 | Windows Event Log ファイルがローカルディスク上にある |
| Custom Metrics | azureMonitorMetrics 宛先、MSI トークン、関連 JSON を確認 |
| ネットワーク | 必要な 443/TCP 宛先を許可し、HTTPS inspection を無効化 |
| 旧エージェント | Log Analytics agent との二重収集がないか確認 |
ディスク容量については、Azure Monitor Agent requirements で Windows Arc のエージェントキャッシュとして C:\Resources\Directory\AMADataStore.{DataStoreName} に 10.5GB、拡張機能ログに 100MB、インストールパッケージに 500MB が目安として示されています。また、AMA のアップグレード中は一時的に 2 つのバージョンが共存するため、ディスク使用量が増える点にも注意が必要です。(Microsoft Learn)
まず取るべき次の行動
Windows Arc-enabled server の Azure Monitor agent トラブルは、DCR の JSON だけを見ても解決しません。まず azcmagent show と Azure portal で Arc 接続・拡張機能の状態を確認し、次に Heartbeat、DCR 関連付け、mcsconfig.latest.xml、configchunks を確認してください。
そのうえで、収集できないデータの種類ごとに、パフォーマンスカウンターなら performanceCounters と CounterSet、Windows イベントログなら windowsEventLogs と Subscription、Custom Metrics なら azureMonitorMetrics と MSI 関連ファイルを確認します。今回の更新で特に見落とせないのは、Windows イベントログがローカルディスク上にある場合のみサポートされる点です。
移行中の環境では、Log Analytics agent との二重収集や、未移行サーバーの残存も同時に確認しましょう。DCR の関連付け、ログ保存場所、ネットワーク、旧エージェントの有無を棚卸しすれば、障害対応だけでなく、今後の Azure Monitor Agent 展開も安定させやすくなります。
コメント