Linux 仮想マシンとスケール セット上の Azure Monitor エージェントのトラブルシューティング ガイダンス

Azure Monitor エージェントの概要

詳細を確認する前に、Azure Monitor エージェントとデータ収集ルールについて理解しておく必要があります。

用語

基本的なトラブルシューティングの手順

Linux 仮想マシンで実行されている Azure Monitor エージェントの最新バージョンをトラブルシューティングするには、次の手順に従います。

1. 前提条件をこちらで注意深く確認します。

2. 拡張機能が正常にインストールされ、プロビジョニングされたことを確認します。これにより、マシンにエージェント バイナリがインストールされます。

   1. Azure portal を開き、仮想マシンを選択します。左側のウィンドウから [設定: 拡張機能とアプリケーション] を開きます。'AzureMonitorLinuxAgent' が [プロビジョニング成功] の状態で表示されます。
   2. 拡張機能が一覧に表示されない場合は、マシンが Azure に到達できるかどうかを確認し、次のコマンドを使用してインストールする拡張機能を見つけます。

      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
      

   3. 拡張機能が移行中の状態の場合があるので、10 分から 15 分待ちます。 まだ上のように表示されない場合は、拡張機能をアンインストールして再度インストールします。
   4. マシンの /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ にある拡張機能のログにエラーが表示されているかどうかを確認します
   5. 上のいずれの方法でも問題が解決しない場合は、概要を "AMA 拡張機能のインストールまたはプロビジョニングに失敗しました" とし、問題の種類を "Azure Monitor Linux エージェントに関するヘルプが必要です" としてチケットを提出します。

3. エージェントが実行されていることを確認する:

   1. 次のクエリを使用して、エージェントが Log Analytics ワークスペースにハートビート ログを出力しているかどうかを確認します。 "カスタム メトリック" が DCR の唯一の宛先の場合はスキップします。

      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
      

   2. エージェント サービスが実行されているかどうかを確認します

      systemctl status azuremonitoragent
      

   3. マシンの /var/opt/microsoft/azuremonitoragent/log/mdsd.* にあるコア エージェントのログにエラーが表示されているかどうかを確認します
   4. 上のいずれの方法でも問題が解決しない場合は、概要を "AMA 拡張機能がプロビジョニングされたが実行されない" とし、問題の種類を "Azure Monitor Linux エージェントに関するヘルプが必要です" としてチケットを提出します。

4. DCR が存在し、仮想マシンに関連付けられていることを確認します:

   1. 宛先として Log Analytics ワークスペースを使用している場合は、DCR が Log Analytics ワークスペースと同じ物理リージョンに存在することを確認します。
   2. Azure portal を開き、お使いのデータ収集ルールを選択します。左側のウィンドウから [構成: リソース] を開きます。ここに仮想マシンがリストされます。
   3. 表示されていない場合は、[追加] をクリックし、リソース ピッカーから仮想マシンを選択します。 すべての DCR で繰り返します。
   4. 上のいずれでも解決しない場合は、概要を "DCR が見つからないか関連付けられていない" とし、問題の種類を "VM からのデータ収集の構成で支援が必要です" としてチケットを提出します。

5. エージェントが関連付けられている DCR を AMCS サービスからダウンロードできたことを確認します:

   1. 最新の DCR が次の場所にダウンロードされているかどうかを確認します /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
   2. されていない場合は、概要を "AMA で DCR 構成をダウンロードできない" とし、問題の種類を "Azure Monitor Linux エージェントに関するヘルプが必要です" として、チケットを提出します。

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
  

トラブルシューティングの手順

1. 最初に、一般的な Linux AMA のトラブルシューティング手順を確認します。 エージェントがハートビートを出力している場合は、手順 2 に進みます。
2. 解析された構成は、/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ に格納されています。 Syslog の収集が定義され、ログの宛先が DCR UI または DCR JSON で構築されたのものと同じであることを確認します。
   1. 確認できたら、手順 3 に進みます。 そうでない場合、問題は構成ワークフローにあります。
   2. /var/opt/microsoft/azuremonitoragent/log にある mdsd.err、mdsd.warn、mdsd.info を調査して、構成エラーがないか確認します。
   3. 上のいずれでも解決しない場合は、概要を "Syslog の DCR が見つからない" とし、問題の種類を "VM からのデータ収集の構成で支援が必要です" としてチケットを提出します。
3. Syslog 収集ワークフローのレイアウトを検証して、必要なすべての部分が適切に配置され、アクセス可能であることを確認します。
   1. rsyslog ユーザーの場合、/etc/rsyslog.d/10-azuremonitoragent.conf ファイルが存在し、空ではなく、rsyslog デーモン (syslog ユーザー) からアクセスできることを確認します。
      1. /etc/rsyslog.conf と /etc/rsyslog.d/* で rsyslog の構成を確認し、既定以外のルール セットにバインドされた入力があるかどうかを確認します。これらの入力からのメッセージは Azure Monitor エージェントに転送されないためです。 たとえば、input(type="imtcp" port="514" ruleset="myruleset") のように、既定以外のルール セットで構成された入力からのメッセージは転送されません。
   2. syslog-ng ユーザーの場合、/etc/syslog-ng/conf.d/azuremonitoragent.conf ファイルが存在し、空ではなく、syslog-ng デーモン (syslog ユーザー) からアクセスできることを確認します。
   3. ファイル /run/azuremonitoragent/default_syslog.socket が存在し、それぞれ rsyslog または syslog-ng でアクセスできることを確認します。
   4. /var/opt/microsoft/azuremonitoragent/log/mdsd.qos で、処理された syslog イベント数の対応するドロップを確認します。 そのようなドロップがファイルに示されていない場合は、概要を "パイプラインで Syslog データがドロップされる" とし、問題の種類を "Azure Monitor Linux エージェントに関するヘルプが必要です" としてチケットを提出します。
   5. syslog デーモンのキューがオーバーフローしてアップロード失敗の原因になっていないことを確認します。そのためには、次のガイダンスを参照してください。AMA Linux エージェントのディスク領域がいっぱいになる問題が原因で rsyslog データがアップロードされない
4. 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"
   

5. トレース フラグをオンにして問題を再現すると、追加のデバッグ情報を /var/opt/microsoft/azuremonitoragent/log/mdsd.info で確認できます。 解析、処理、構成、アップロードのエラーなど、syslog 収集の問題の考えられる原因がないかファイルを調べます。

   警告

   デバッグ セッション後にトレース フラグ設定 -T 0x2002 を必ず削除してください。これは、大量のトレース ステートメントを生成するため、ディスクをより早くいっぱいにしたり、ログ ファイルの視覚的な解析を困難にしたりする可能性があります。

6. 上のいずれの方法でも問題が解決しない場合は、概要を "AMA で syslog イベントを収集できない" とし、問題の種類を "Azure Monitor Linux エージェントに関するヘルプが必要です" としてチケットを提出します。

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 対応サーバーの認証要件を確認してください。

チケットを提出する

1. データ収集規則を開き、左側のメニューで [新しいサポート リクエスト] を選択します。 [ヘルプとサポート] ペインを開き、[サポート リクエストの作成] を選択することもできます。
2. 選択:
   • [問題の種類]: 技術的。
   • [サブスクリプション]: マシンが存在するサブスクリプションを選択します。
   • [サービスの種類]: データ収集規則と Azure Monitor エージェント。
   • [お客様の問題はリソースに関係していますか?]: はい。 リソース ピッカーを使用してマシンを選択します。
3. トラブルシューティングの手順で示されているように、概要と問題の種類を入力します。 正確な情報は、問題の迅速な解決につながります。
4. [次へ] を選択し、推奨される解決策が役に立つかどうかを確認します。
5. 役に立たない場合は、[次へ] を選択し、詳細の次のセットを入力します。
6. [次へ] を選択し、最終的な詳細を確認して、[作成] を選択します。