Azure Monitor Agent Linuxでログが届かない場合、最初に見るべきポイントは「エージェントが入っているか」だけではありません。実務では、DCRが対象VMに関連付いているか、エージェントがDCRを取得できているか、Syslogや送信先の設定がDCRと一致しているかを順番に確認するのが最短です。Azure Monitor AgentはDCRに従ってゲストOSの監視データを収集し、収集対象・処理方法・送信先をDCRで管理します。2026年5月20日に更新された公式のAzure Monitor Agent概要でも、AMAはAzure MonitorでゲストOSデータを収集するためのサポート対象エージェントとして整理されています。(Microsoft Learn)
なお、Linux VM/VMSS向けのトラブルシューティングページ自体は、Microsoft Learn上では2026年4月10日更新として表示されています。したがって本記事では、2026年5月20日更新のAzure Monitor Agent概要と、Linux仮想マシン・スケールセット向けトラブルシューティング公式情報を合わせて、管理者・開発者が確認すべき変更点、影響範囲、展開時の注意点を実務目線で整理します。(Microsoft Learn)
Azure Monitor Agent Linuxトラブルシューティングで何が重要になったのか
今回押さえるべきポイントは、新しい監視機能が追加されたというよりも、Linux VM/VMSSでAMAが動かないときの切り分け手順がDCR中心に整理されていることです。
従来の感覚で「エージェント拡張機能がProvisioning succeededなら正常」と判断すると、原因を見落とします。Azure Monitor Agentは、エージェント本体が入っていても、DCRが関連付いていない、DCRをAMCSから取得できない、Syslogのfacility/severityがDCRと一致しない、といった状態では期待したログを送れません。公式手順でも、拡張機能、サービス稼働、Heartbeat、DCR関連付け、DCRキャッシュ、AMCS到達性、Syslog構成の順に確認する流れが示されています。(Microsoft Learn)
| 観点 | これまで見落としやすかった点 | 実務での確認ポイント |
|---|---|---|
| エージェント導入 | 拡張機能の成功だけで正常と判断する | systemctl status azuremonitoragentとHeartbeatも確認する |
| DCR | VMにDCRが関連付いていない | DCRのResourcesに対象VMがあるか確認する |
| AMCS | DCRをダウンロードできない | config-cache/configchunks/とAMCSへのTLS接続を確認する |
| Syslog | rsyslog/syslog-ngは動いているがDCRと不一致 | facility、severity、転送設定、mdsd.qosを確認する |
| VMSS | 自動アップグレード設定が既存インスタンスへ反映されない | Manualポリシーなら最新モデルをインスタンスへ適用する |
影響範囲：対象はLinux VM、VMSS、Arc対応サーバー
このトラブルシューティングの対象は、Azure上のLinux仮想マシンだけではありません。Azure Monitor AgentはAzure VM、他クラウド、オンプレミスのAzure Arc対応サーバーでも利用され、LinuxではSyslog、パフォーマンス、ファイルベースログなどの収集に関係します。(Microsoft Learn)
特に影響を受けやすいのは、次のような環境です。
| 環境 | 影響が出やすい症状 | 優先して確認する項目 |
|---|---|---|
| Linux単体VM | Log AnalyticsにHeartbeatやSyslogが来ない | 拡張機能、サービス、DCR関連付け |
| VMSS | 一部インスタンスだけエージェント更新が反映されない | アップグレードポリシー、最新モデル適用、インスタンス保護 |
| Azure Arc対応サーバー | 認証エラー、MSIトークン取得失敗 | syslogユーザーとhimdsグループ |
| 閉域・プロキシ環境 | DCR取得やログ送信に失敗する | サービス タグ、443番アウトバウンド、HTTPS検査、プロキシ設定 |
| Microsoft Sentinel連携環境 | 重複収集や想定外の課金 | DCR重複、従来Log Analyticsエージェント併用 |
まず理解すべきAMAとDCRの関係
Azure Monitor Agentを理解するうえで重要なのは、AMA単体では「何を、どこへ送るか」が決まらない点です。DCRが収集対象、処理方法、送信先を定義し、エージェントは関連付けられたDCRを取得して適用します。DCRによって複数エージェント・複数環境の収集設定を一元管理できるため、運用では「エージェントの状態」と「DCRの状態」を分けて確認する必要があります。(Microsoft Learn)
| 用語 | 役割 | 障害時に見るポイント |
|---|---|---|
| AMA | Linux VM上で動作するAzure Monitor Agent | サービス稼働、拡張機能ログ、mdsd.*ログ |
| DCR | 収集対象・処理・送信先を定義するルール | VMとの関連付け、リージョン、データソース、宛先 |
| AMCS | エージェントがDCRを取得する構成サービス | global.handler.control.monitor.azure.comへの到達性 |
| Log Analytics workspace | ログの送信先 | DCRとのリージョン整合性、データ受信状況 |
| IMDS/HIMDS | VM/Arcサーバーのメタデータや認証に関係 | Arc環境のMSIトークン取得エラー |
DCRは、Log AnalyticsワークスペースやAzure Monitorワークスペースを宛先にする場合、基本的に宛先ワークスペースと同じリージョンに作成する必要があります。また、柔軟なオーケストレーションのVMSSはDCRのリソースとしてスケールセット全体を追加できず、含まれる各VMを追加する必要があります。(Microsoft Learn)
基本の切り分け手順：ログが来ないときはこの順番で確認する
Azure Monitor Agent Linuxのトラブルシューティングは、次の順番で進めると無駄がありません。いきなりSyslogやLog Analytics側を疑うのではなく、エージェント、DCR、ネットワーク、データソースの順に切り分けます。
| 手順 | 確認内容 | 正常な状態 | 問題がある場合の見方 |
|---|---|---|---|
| 1 | 拡張機能 | AzureMonitorLinuxAgentが表示され、プロビジョニング成功 | 拡張機能ログ、Azure到達性、再インストール |
| 2 | サービス | azuremonitoragentが稼働 | systemd、mdsd.*ログを確認 |
| 3 | Heartbeat | Log AnalyticsにAMAのHeartbeatが出る | DCR、ネットワーク、送信先を確認 |
| 4 | DCR関連付け | DCRのResourcesに対象VMがある | DCR関連付け漏れ、リージョン不一致 |
| 5 | DCRキャッシュ | configchunksにDCR JSONがある | AMCS到達不可、DNS、DCR未関連付け |
| 6 | Syslog | DCRにSyslogデータソースがあり条件が一致 | facility/severity、rsyslog/syslog-ng設定 |
| 7 | VMSS更新 | 既存インスタンスにも最新モデルが適用済み | Manualポリシー、インスタンス保護を確認 |
拡張機能とサービスの確認
Azureポータルで対象VMを開き、設定 > 拡張機能 + アプリケーションにAzureMonitorLinuxAgentが表示され、ステータスがプロビジョニング成功になっているか確認します。表示されない場合は、対象リージョンで拡張機能を取得できるか確認します。(Microsoft Learn)
az vm extension image list-versions \
--location <machine-region> \
--name AzureMonitorLinuxAgent \
--publisher Microsoft.Azure.Monitor次に、VMへSSH接続してサービス状態を確認します。
systemctl status azuremonitoragent拡張機能ログとコアエージェントログは、以下を確認します。
sudo ls -l /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/
sudo ls -l /var/opt/microsoft/azuremonitoragent/log/
sudo tail -n 100 /var/opt/microsoft/azuremonitoragent/log/mdsd.errここで重要なのは、拡張機能のプロビジョニング成功は「パッケージが配置された」ことの確認に近く、Log Analyticsにデータが届いていることの保証ではない点です。サービス稼働とDCR適用、送信先への到達まで確認して初めて、監視が成立します。
Heartbeatの確認
Log Analytics workspaceで、Azure Monitor AgentからHeartbeatが出ているか確認します。DCRの送信先がCustom Metricsのみの場合はHeartbeat確認をスキップするケースがありますが、Log Analyticsを使っているなら最初に見るべきクエリです。(Microsoft Learn)
Heartbeat
| where Category == "Azure Monitor Agent"
| where Computer == "<computer-name>"
| take 10より直近の確認には、次のように時間範囲を絞ります。
Heartbeat
| where Category == "Azure Monitor Agent"
| where TimeGenerated > ago(5m)
| project Computer, TimeGenerated, Category, OSType
| order by TimeGenerated descHeartbeatがない場合は、エージェント未稼働、DCR未関連付け、ネットワーク遮断、認証エラーを疑います。HeartbeatはあるのにSyslogだけ来ない場合は、エージェント全体ではなくSyslogデータソースやDCR条件の問題に絞り込めます。
DCR関連付けとconfig-cacheを確認する
Azure Monitor Agent Linuxのトラブルでは、DCRの関連付け漏れが非常に多い原因です。DCRの画面で構成 > リソースを開き、対象VMが表示されているか確認します。Log Analytics workspaceを宛先にしている場合は、DCRがLog Analytics workspaceと同じ物理リージョンにあるかも確認します。(Microsoft Learn)
VM側では、DCRがAMCSからダウンロードされているかを確認します。
ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/DCRが正しく取得されていれば、dcr_*.jsonのようなファイルが存在します。中身には、dataSourcesやdestinations、Log Analytics workspaceのリソースIDなどが含まれます。ファイルが空、欠落、または不正な形式の場合、エージェントはデータを収集またはアップロードできません。(Microsoft Learn)
cat /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/dcr_*.jsonconfigchunksがない場合は、次の3つを優先して確認します。
| 状況 | 疑う原因 | 対応 |
|---|---|---|
| ディレクトリがない | エージェントがDCRを取得できていない | DCR関連付けとAMCS到達性を確認 |
| JSONにSyslogがない | DCRにSyslogデータソースがない | DCRのデータソースを修正 |
| 宛先が想定外 | 別DCRまたは誤った送信先 | DCR関連付けとJSONを照合 |
AMCSへの接続は、VM上で次のように確認します。
curl -v https://global.handler.control.monitor.azure.comTLS接続が成功すれば、少なくともAMCSのグローバル制御サービスへ到達できることを確認できます。失敗する場合は、DNS、プロキシ、ファイアウォール、NSG、Azure Firewall、Private Link構成を確認します。
Syslogが来ない場合の確認ポイント
Syslogの問題は、「エージェントが動いていない」のではなく、SyslogイベントがAMAに渡っていない、DCR条件に一致していない、またはLog Analyticsへアップロードできていないという3層に分けて考えると切り分けやすくなります。
公式情報では、Azure Monitor Agentはインストール時にSyslogデーモンの出力構成をインストールし、rsyslogでは/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf、syslog-ngでは/etc/syslog-ng/conf.d/azuremonitoragent-tcp.confを確認対象として示しています。また、AMAは/etc/opt/microsoft/azuremonitoragent/config-cache/syslog.portに記録されたTCPポートでrsyslogまたはsyslog-ngからイベントを受信し、DCRのfacility/severity条件に一致しないイベントは破棄します。(Microsoft Learn)
sudo cat /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port
sudo ls -l /etc/rsyslog.d/
sudo ls -l /etc/syslog-ng/conf.d/バージョン1.28より前のAMAでは、rsyslogからの受信にTCPポートではなくUnixドメインソケットが使われていたため、古い環境では/run/azuremonitoragent/default_syslog.socketの確認が必要になる場合があります。バージョン差によって見るファイルが変わるため、運用手順書には「AMAバージョン」と「確認するSyslog転送方式」をセットで書いておくと事故を防げます。(Microsoft Learn)
mdsd.qosでSyslogの処理状況を見る
Syslogが取り込まれているかを確認するには、mdsd.qosが役立ちます。このファイルには、15分単位の処理イベント数などがCSV形式で記録され、Syslogイベントのドロップやアップロード状況の追跡に使えます。(Microsoft Learn)
sudo tail -n 50 /var/opt/microsoft/azuremonitoragent/log/mdsd.qos判断の目安は次の通りです。
| 状態 | 可能性が高い原因 | 次の確認 |
|---|---|---|
mdsd.qosにSyslog処理が出ない | rsyslog/syslog-ngからAMAへ渡っていない | Syslog転送設定、ポート、ソケット |
| 処理はあるがLog Analyticsに出ない | アップロード失敗、認証、宛先不一致 | mdsd.err、DCR宛先、ネットワーク |
| 特定facilityだけ来ない | DCRのfacility/severity不一致 | DCR JSONとSyslog発生元を照合 |
| 大量ログ後に止まる | ディスク逼迫、キュー滞留 | /var、/var/log、events配下 |
ディスク不足もSyslog停止の原因になる
Syslogアップロード失敗時にmdsd.errへNo space left on deviceのようなエラーが出る場合、ローカル永続ストアや/var配下の容量不足を疑います。公式情報では、AMA for Linuxは取り込み前のイベントを/var/opt/microsoft/azuremonitoragent/eventsにバッファーし、既定インストールではアイドル状態で約650MBを使用すると説明されています。(Microsoft Learn)
df -h
sudo du -h /var/opt/microsoft/azuremonitoragent/events 2>/dev/null
sudo du -h /var/log/syslog* 2>/dev/null
sudo lsof +L1duで大きなファイルが見つからないのにディスクが逼迫している場合、削除済みだがプロセスが開いたままのファイルが容量を使っていることがあります。その場合はlsof +L1で確認し、必要に応じて対象サービスを再起動します。
ネットワーク・プロキシ・Private Link環境の注意点
閉域環境では、DCRやSyslog設定が正しくても送信できないことがあります。Azure Monitor Agentのネットワーク構成では、直接プロキシ、Log Analyticsゲートウェイ、Private Linkがサポートされています。仮想ネットワークではAzureMonitorとAzureResourceManagerのサービス タグが必要で、ファイアウォールでは各エンドポイントへの443番アウトバウンド通信を許可し、HTTPS検査を無効にする必要があります。(Microsoft Learn)
特に確認すべきエンドポイントは次の通りです。
| 用途 | エンドポイント例 | 失敗時の症状 |
|---|---|---|
| 制御サービス | global.handler.control.monitor.azure.com | DCR取得失敗、configchunksなし |
| リージョン別DCR取得 | <region>.handler.control.monitor.azure.com | 特定リージョンVMでDCR取得失敗 |
| Log Analytics取り込み | <workspace-id>.ods.opinsights.azure.com | HeartbeatやSyslogが送信されない |
| DCE取り込み | <dce>.<region>.ingest.monitor.azure.com | DCE利用時のログ送信失敗 |
| カスタムメトリック | management.azure.comなど | メトリック送信失敗 |
Private Linkを使う場合は、DCRがDCEを使用する構成になっているか確認します。カスタムログやIISログなど一部シナリオではDCEのパブリックIP許可が必要になる可能性もあるため、ネットワークチームに「AzureMonitorタグだけ開けたから十分」と伝えるのではなく、DCE、Private Link、プロキシ、HTTPS検査の有無まで確認することが重要です。(Microsoft Learn)
VMSSの自動アップグレードで確認すべき点
Virtual Machine Scale SetsでAzureMonitorLinuxAgentの自動拡張機能アップグレードを有効にしても、アップグレードポリシーがManualの場合、まずスケールセットモデルが更新されるだけで、既存インスタンスには最新モデルが反映されません。既存インスタンスへ反映するには、Azureポータルで「最新モデルを適用」するか、Azure CLIやPowerShellでインスタンス更新を実行します。(Microsoft Learn)
Azure CLIでは次のコマンドを使います。
az vmss update-instances \
-g <resource-group> \
-n <vmss> \
--instance-ids "*"PowerShellでは次の通りです。
Update-AzVmssInstance `
-ResourceGroupName <resource-group> `
-VMScaleSetName <vmss> `
-InstanceId "*"今後のモデル変更を自動的に反映したい場合は、アップグレードポリシーをRollingに変更する選択肢があります。
az vmss update \
-g <resource-group> \
-n <vmss> \
--set upgradePolicy.mode=Rolling一部インスタンスだけ更新されない場合は、インスタンス保護が有効になっていないかも確認します。VMSSでは「拡張機能の設定を変えたのに、なぜか既存台数に効かない」というトラブルが起きやすいため、運用手順にはモデル更新とインスタンスへの適用を別工程として明記しておくべきです。
Arc対応サーバーではhimdsグループを確認する
Azure Arc対応サーバーで、基本手順を確認してもログが出ない場合や、mdsd.errにMSIトークン取得失敗のエラーが見える場合は、syslogユーザーがhimdsグループに所属しているか確認します。公式手順では、syslogユーザーがhimdsグループのメンバーでない場合は追加し、必要に応じてsyslogユーザーやグループを作成するよう案内されています。(Microsoft Learn)
id syslog
getent group himdssyslogユーザーがhimdsに含まれていない場合の例です。
sudo usermod -aG himds syslog
sudo systemctl restart azuremonitoragent
sudo systemctl restart rsyslog変更後は、Heartbeat、mdsd.err、Syslogテーブルの順に再確認します。Arc環境ではAzure VMと異なり、ネットワーク、プロキシ、Arcエージェント、HIMDSまわりが絡むため、Azure VMの手順をそのまま当てはめるだけでは不十分です。
管理者・開発者が展開前に確認すべき設定
Azure Monitor Agentを新規展開または移行する前に、次の項目をチェックリスト化しておくと、展開後の「データが来ない」をかなり減らせます。
| チェック項目 | 判断基準 | 失敗しやすいポイント |
|---|---|---|
| DCRリージョン | 宛先ワークスペースと同じリージョン | VMのリージョンだけ見てDCRを作る |
| DCR関連付け | 対象VMがDCRのResourcesにある | エージェントだけ入れてDCR未関連付け |
| VMSS flexible orchestration | 各VMをDCRに追加 | VMSS全体を追加しようとする |
| マネージドID | システム割り当て/ユーザー割り当てを明確化 | ポータル追加時に意図せずシステム割り当てになる |
| データソース | LinuxならSyslog、Perf、Text/JSONログなどを適切に選択 | Syslog facility/severityが実ログと不一致 |
| 宛先 | Log Analytics、Azure Monitor workspaceなど | 複数宛先で重複送信し課金増 |
| ネットワーク | 443アウトバウンド、サービス タグ、DCE、HTTPS検査 | プロキシやSSLインスペクションで失敗 |
| 移行 | 旧Log Analyticsエージェントとの重複を避ける | 同じデータを二重収集する |
DCRでは、複数のデータソースを同じDCRに含められ、VMには任意の数のDCRを関連付けられます。ただし、同じデータソースを持つ複数DCRを同じVMに関連付けると、重複データが発生し課金増につながる可能性があります。従来のLog AnalyticsエージェントとAMAを同じマシンで併用する場合も、同じテーブルに重複して保存される可能性があるため注意が必要です。(Microsoft Learn)
DCRをJSONやIaCで管理する場合の注意点
開発者やプラットフォームチームがBicep、ARMテンプレート、Terraform、Azure CLIなどでDCRを管理している場合、Azureポータル編集との混在に注意が必要です。公式情報では、既存DCRをポータルで編集すると、ポータルでサポートされていないJSON側の変更が上書きされる可能性があると説明されています。たとえば、変換をJSONで追加した後にポータルで編集すると、その変換が削除される可能性があります。(Microsoft Learn)
実務では、次のルールを決めておくと安全です。
| 運用方針 | 推奨される管理方法 |
|---|---|
| 基本的なSyslogやPerf収集のみ | Azureポータル中心でもよい |
| 変換、複雑なデータフロー、複数環境展開 | JSONまたはIaCで一元管理 |
| 本番環境 | ポータル手動編集を原則禁止し、変更履歴を残す |
| 障害対応時 | DCR JSON、VM関連付け、config-cacheの3点を記録する |
障害調査では、DCRの画面キャプチャだけでなく、対象VMのconfigchunksに実際に落ちてきたDCR JSONを保存しておくと、クラウド側の設定とVM側の適用状態を比較できます。
Linux AMA Troubleshooterを使うタイミング
手動確認で原因が絞れない場合は、Linux用Azure Monitor Agent Troubleshooterを使います。このツールはAMA関連の問題特定や正常性評価、ログ収集を支援するもので、Linuxの1.25.1より新しいエージェントに付属します。実行にはPython 2.6以降または任意のPython 3が必要で、最新のAMAバージョン情報を取得するためのパブリックエンドポイントへの送信接続も必要です。(Microsoft Learn)
ツールの存在確認です。
ls -ltr /var/lib/waagent | grep "Microsoft.Azure.Monitor.AzureMonitorLinuxAgent-*"ログモードで実行する例です。{version}は実際のインストールバージョンに置き換えます。
cd /var/lib/waagent/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent-{version}/ama_tst/
sudo sh ama_troubleshooter.sh -L対話モードで画面に結果を出したい場合は、次のように実行します。
cd /var/lib/waagent/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent-{version}/ama_tst/
sudo sh ama_troubleshooter.sh -Aサポート問い合わせ前には、Troubleshooterのログ、mdsd.err、mdsd.warn、mdsd.info、DCR JSON、Heartbeatクエリ結果、対象VMのリージョンとDCRリージョンをまとめておくと、初動のやり取りを減らせます。
よくある失敗と対処
エージェントは入っているのにログが来ない
最も多いのは、DCRが対象VMに関連付いていないケースです。VM拡張機能としてAMAをインストールしただけでは、データ収集は始まりません。DCRを作成し、対象VMに関連付け、さらにVM側でconfigchunksにDCRが取得されているか確認します。
HeartbeatはあるがSyslogが来ない
この場合、エージェント全体は動いている可能性が高いため、Syslogデータソースに絞ります。DCR JSONにsyslogが含まれているか、facility/severityが実際のイベントと一致しているか、rsyslogまたはsyslog-ngからAMAへ転送されているかを確認します。mdsd.qosにSyslog処理が出ているかも有効な判断材料です。
VMSSで一部インスタンスだけ古いまま
Manualアップグレードポリシーでは、モデル変更が既存インスタンスへ自動適用されません。az vmss update-instancesまたはポータルの「最新モデルを適用」を実行し、それでも反映されない場合はインスタンス保護を確認します。
閉域環境で突然DCR取得に失敗する
ネットワーク側の変更、HTTPS検査、プロキシ認証、DCE設定、Private Link構成を確認します。curl -v https://global.handler.control.monitor.azure.comでAMCS到達性を見たうえで、Log Analytics取り込みエンドポイントやDCEへの443番通信も確認します。
移行後にコストが増えた
従来のLog AnalyticsエージェントとAMAが同じデータを収集している、または同じデータソースのDCRを複数関連付けている可能性があります。VMに関連付いているDCR一覧を確認し、重複する収集条件を整理します。
Get-AzDataCollectionRuleAssociation -resourceUri <vm-resource-id>まとめ：次にやるべきこと
Azure Monitor Agent Linuxのトラブルシューティングでは、エージェントだけを見るのではなく、DCR、AMCS、Syslog、ネットワーク、VMSSモデル反映まで含めて確認することが重要です。まず対象VMでHeartbeatを確認し、次にDCRの関連付けとconfig-cache/configchunks/を見ます。Syslogだけが来ない場合は、DCRのfacility/severity、rsyslog/syslog-ngの転送設定、mdsd.qos、mdsd.errを確認します。
管理者は、DCRリージョン、マネージドID、VMSSのアップグレードポリシー、閉域ネットワークのエンドポイント許可を展開前チェックリストに入れてください。開発者やプラットフォームチームは、DCRをポータルで手動編集する範囲と、JSON/IaCで管理する範囲を明確に分けるべきです。最初の一手として、対象VMで次の3つを実行し、結果を記録しておくと調査が進めやすくなります。
systemctl status azuremonitoragent
ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
sudo tail -n 100 /var/opt/microsoft/azuremonitoragent/log/mdsd.err
コメント