Linux 仮想マシンとスケール セット上の Azure Monitor エージェントのトラブルシューティング ガイダンス
Azure Monitor エージェントの概要
詳細を確認する前に、Azure Monitor エージェントとデータ収集ルールについて理解しておく必要があります。
用語
| 名前 | 頭字語 | 説明 |
|---|---|---|
| Azure Monitor エージェント | AMA | 新しい Azure Monitor エージェント |
| データ収集ルール | DCR | エージェントによるデータの収集を構成するためのルール (収集対象、送信先など) |
| Azure Monitor 構成サービス | AMCS | Azure でホストされるリージョン サービス。このエージェントのデータ収集と Azure Monitor の他の部分を制御します。 エージェントは、このサービスを呼び出して DCR をフェッチします。 |
| ログ エンドポイント | -- | Log Analytics ワークスペースにデータを送信するためのエンドポイント |
| メトリック エンドポイント | -- | Azure Monitor メトリック データベースにデータを送信するためのエンドポイント。 |
| Instance Metadata Service とハイブリッド | IMDS と HIMDS | 現在実行中の仮想マシン、スケール セット (IMDS 経由)、Arc 対応サーバー (HIMDS 経由) に関する情報を提供する、Azure でホストされているサービス |
| Log Analytics ワークスペース | LAW | エージェントによって収集されたログを送信できる Azure Monitor の宛先 |
| カスタム メトリック | -- | エージェントによって収集されたゲスト メトリックを送信できる Azure Monitor の宛先 |
基本的なトラブルシューティングの手順
Linux 仮想マシンで実行されている Azure Monitor エージェントの最新バージョンをトラブルシューティングするには、次の手順に従います。
前提条件をこちらで注意深く確認します。
拡張機能が正常にインストールされ、プロビジョニングされたことを確認します。これにより、マシンにエージェント バイナリがインストールされます。
- Azure portal を開き、仮想マシンを選択します。左側のウィンドウから [設定: 拡張機能とアプリケーション] を開きます。'AzureMonitorLinuxAgent' が [プロビジョニング成功] の状態で表示されます。
- 拡張機能が一覧に表示されない場合は、マシンが Azure に到達できるかどうかを確認し、次のコマンドを使用してインストールする拡張機能を見つけます。
az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor - 拡張機能が移行中の状態の場合があるので、10 分から 15 分待ちます。 まだ上のように表示されない場合は、拡張機能をアンインストールして再度インストールします。
- マシンの
/var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/にある拡張機能のログにエラーが表示されているかどうかを確認します
エージェントが実行されていることを確認する:
- 次のクエリを使用して、エージェントが Log Analytics ワークスペースにハートビート ログを出力しているかどうかを確認します。 "カスタム メトリック" が DCR の唯一の宛先の場合はスキップします。
Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10 - エージェント サービスが実行されているかどうかを確認します
systemctl status azuremonitoragent - マシンの
/var/opt/microsoft/azuremonitoragent/log/mdsd.*にあるコア エージェントのログにエラーが表示されているかどうかを確認します
- 次のクエリを使用して、エージェントが Log Analytics ワークスペースにハートビート ログを出力しているかどうかを確認します。 "カスタム メトリック" が DCR の唯一の宛先の場合はスキップします。
DCR が存在し、仮想マシンに関連付けられていることを確認します:
- 宛先として Log Analytics ワークスペースを使用している場合は、DCR が Log Analytics ワークスペースと同じ物理リージョンに存在することを確認します。
- Azure portal を開き、お使いのデータ収集ルールを選択します。左側のウィンドウから [構成: リソース] を開きます。ここに仮想マシンがリストされます。
- 表示されていない場合は、[追加] をクリックし、リソース ピッカーから仮想マシンを選択します。 すべての DCR で繰り返します。
エージェントが関連付けられている DCR を AMCS サービスからダウンロードできたことを確認します:
- 最新の DCR が次の場所にダウンロードされているかどうかを確認します
/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
- 最新の DCR が次の場所にダウンロードされているかどうかを確認します
Syslog の収集に関する問題
Azure Monitor エージェントに関する syslog の問題をトラブルシューティングする方法の詳細については、こちらを参照してください。
サービスの品質 (QoS) ファイル
/var/opt/microsoft/azuremonitoragent/log/mdsd.qosは、処理されたイベントの CSV 形式の 15 分の集計を提供し、指定された時間枠内で処理された syslog イベントの量に関する情報を含みます。 このファイルは、Syslog イベントのインジェスト ドロップの追跡に役立ちます。たとえば、次のフラグメントは、2022-02-28T19:55:23.5432920Z より前の 15 分間に、エージェントが機能が daemon でレベルが info の 77 個の syslog イベントを受信し、アップロード タスクにこの 77 個のイベントを送信したことを示しています。 さらに、エージェントのアップロード タスクは 77 件を受信し、これらの daemon.info メッセージ 77 件すべてを正常にアップロードしました。
#Time: 2022-02-28T19:55:23.5432920Z #Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent ... MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77 MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0 MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0 ... MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77
トラブルシューティングの手順
最初に、一般的な Linux AMA のトラブルシューティング手順を確認します。 エージェントがハートビートを出力している場合は、手順 2 に進みます。
解析された構成は、
/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/に格納されています。 Syslog の収集が定義され、ログの宛先が DCR UI または DCR JSON で構築されたのものと同じであることを確認します。- 確認できたら、手順 3 に進みます。 そうでない場合、問題は構成ワークフローにあります。
/var/opt/microsoft/azuremonitoragent/logにあるmdsd.err、mdsd.warn、mdsd.infoを調査して、構成エラーがないか確認します。
Syslog 収集ワークフローのレイアウトを検証して、必要なすべての部分が適切に配置され、アクセス可能であることを確認します。
rsyslogユーザーの場合、/etc/rsyslog.d/10-azuremonitoragent.confファイルが存在し、空ではなく、rsyslogデーモン (syslog ユーザー) からアクセスできることを確認します。/etc/rsyslog.confと/etc/rsyslog.d/*で rsyslog の構成を確認し、既定以外のルール セットにバインドされた入力があるかどうかを確認します。これらの入力からのメッセージは Azure Monitor エージェントに転送されないためです。 たとえば、input(type="imtcp" port="514"ruleset="myruleset")のように、既定以外のルール セットで構成された入力からのメッセージは転送されません。
syslog-ngユーザーの場合、/etc/syslog-ng/conf.d/azuremonitoragent.confファイルが存在し、空ではなく、syslog-ngデーモン (syslog ユーザー) からアクセスできることを確認します。- ファイル
/run/azuremonitoragent/default_syslog.socketが存在し、それぞれrsyslogまたはsyslog-ngでアクセスできることを確認します。 - syslog デーモンのキューがオーバーフローしてアップロード失敗の原因になっていないことを確認します。そのためには、次のガイダンスを参照してください。AMA Linux エージェントのディスク領域がいっぱいになる問題が原因で rsyslog データがアップロードされない
syslog イベントのインジェストをさらにデバッグするために、ファイル
/etc/default/azuremonitoragentの MDSD_OPTIONS の最後にトレース フラグ -T 0x2002 を追加し、エージェントを再起動します。export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"トレース フラグをオンにして問題を再現すると、追加のデバッグ情報を
/var/opt/microsoft/azuremonitoragent/log/mdsd.infoで確認できます。 解析、処理、構成、アップロードのエラーなど、syslog 収集の問題の考えられる原因がないかファイルを調べます。警告
デバッグ セッション後にトレース フラグ設定 -T 0x2002 を必ず削除してください。これは、大量のトレース ステートメントを生成するため、ディスクをより早くいっぱいにしたり、ログ ファイルの視覚的な解析を困難にしたりする可能性があります。
Arc 対応サーバーでの問題のトラブルシューティング
基本的なトラブルシューティング手順を確認した後、ログを出力する Azure Monitor エージェントが表示されない場合、または /var/opt/microsoft/azuremonitoragent/log/mdsd.err ログ ファイルに "Failed to get MSI token from IMDS endpoint" というエラーがある場合は、syslog ユーザーが himds グループのメンバーではない可能性があります。 syslog ユーザーが himds グループのメンバーでない場合は、このグループにユーザーを追加します。 必要に応じて、syslog ユーザーと syslog グループを作成し、このユーザーがこのグループに含まれるようにします。 詳細については、こちらの Azure Arc 対応サーバーの認証要件を確認してください。