次の方法で共有


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 エージェントの最新バージョンをトラブルシューティングするには、次の手順に従います。

  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/ にある拡張機能のログにエラーが表示されているかどうかを確認します
  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. DCR が存在し、仮想マシンに関連付けられていることを確認します:

    1. 宛先として Log Analytics ワークスペースを使用している場合は、DCR が Log Analytics ワークスペースと同じ物理リージョンに存在することを確認します。
    2. Azure portal を開き、お使いのデータ収集ルールを選択します。左側のウィンドウから [構成: リソース] を開きます。ここに仮想マシンがリストされます。
    3. 表示されていない場合は、[追加] をクリックし、リソース ピッカーから仮想マシンを選択します。 すべての DCR で繰り返します。
  5. エージェントが関連付けられている DCR を AMCS サービスからダウンロードできたことを確認します:

    1. 最新の DCR が次の場所にダウンロードされているかどうかを確認します /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/

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.errmdsd.warnmdsd.info を調査して、構成エラーがないか確認します。
  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. syslog デーモンのキューがオーバーフローしてアップロード失敗の原因になっていないことを確認します。そのためには、次のガイダンスを参照してください。AMA Linux エージェントのディスク領域がいっぱいになる問題が原因で rsyslog データがアップロードされない
  4. syslog イベントのインジェストをさらにデバッグするために、ファイル /etc/default/azuremonitoragentMDSD_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 を必ず削除してください。これは、大量のトレース ステートメントを生成するため、ディスクをより早くいっぱいにしたり、ログ ファイルの視覚的な解析を困難にしたりする可能性があります。

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