Linux 用 Log Analytics エージェントに関する問題のトラブルシューティング

この記事では、Azure Monitor の Linux 用 Log Analytics エージェントで発生する可能性のあるエラーのトラブルシューティングのヘルプを提供します。

Log Analytics のトラブルシューティング ツール

Linux 用 Log Analytics エージェントのトラブルシューティング ツールは、Log Analytics エージェントの問題の検出と診断に役立つように設計されたスクリプトです。 それは、インストール時にエージェントに自動的に含まれます。 このツールを実行することが、問題を診断するための最初の手順になります。

トラブルシューティング ツールを使用する

トラブルシューティング ツールを実行するには、Log Analytics エージェントがあるマシンのターミナル ウィンドウに次のコマンドを貼り付けます。

sudo /opt/microsoft/omsagent/bin/troubleshooter

手動のインストール

トラブルシューティング ツールは、Log Analytics エージェントのインストール時に自動的に含まれます。 インストールが何らかの理由で失敗した場合は、ツールを手動でインストールすることもできます。

1. トラブルシューティング ツールに必要であるため、GNU Project Debugger (GDB) をマシンにインストールしてください。
2. トラブルシューティング ツール バンドルをコンピューターにコピーします。wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
3. バンドルをアンパックします。tar -xzvf omsagent_tst.tar.gz
4. 手動インストールを実行します。sudo ./install_tst

対象となるシナリオ

トラブルシューティング ツールは、次のシナリオを確認します。

• エージェントが異常で、ハートビートが正常に機能していない。
• エージェントが起動しないか、Log Analytics に接続できない。
• エージェント Syslog が機能していない。
• エージェントの CPU またはメモリ使用率が高くなっている。
• エージェントにインストールの問題がある。
• エージェントのカスタム ログが機能してしない。
• エージェント ログを収集できない。

詳細については、GitHub のトラブルシューティング ツールのドキュメントを参照してください。

Linux エージェントの削除と再インストール

エージェントをクリーン再インストールすると、ほとんどの問題が修正されます。 エージェントを破損していない状態にする方法として、サポート チームがこのタスクを最初に提案することがあります。 トラブルシューティング ツールとログ コレクター ツールを実行し、クリーン再インストールを試みると、問題をより迅速に解決するのに役立ちます。

1. 消去スクリプトをダウンロードします。

   $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

2. (sudo アクセス許可で) 消去スクリプトを実行します。

   $ sudo sh purge_omsagent.sh

重要なログの場所とログ コレクター ツール

トラブルシューティングでは、または GitHub issue を送信する前には、ログ コレクター ツールを使用して重要なログを取得することをお勧めします。 ツールとその実行方法の詳細については、OMS Linux エージェント ログ コレクターに関するページを参照してください。

重要な構成ファイル

インストール エラー コード

オンボードのエラー コード

デバッグ ログの有効化

OMS 出力プラグインのデバッグ

FluentD はプラグイン固有のログ レベルに対応しており、入力と出力に対して異なるログ レベルを指定できます。 OMS 出力に異なるログ レベルを指定するには、/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf で汎用エージェントの構成を編集します。

OMS 出力プラグインでは、構成ファイルの末尾の前にある log_level プロパティを info から debug に変更します。

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

デバッグ ログを使用すると、バッチ処理された Azure Monitor へのアップロードを、種類、データ項目の数、および送信にかかった時間で区切って表示できます。

デバッグを有効にしたログの例を次に示します。

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

詳細出力

OMS 出力プラグインを使用する代わりに、データ項目を stdout に直接出力し、Linux 用 Log Analytics エージェントのログ ファイルで見ることができます。

/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf にある Log Analytics 汎用エージェントの構成ファイルで、各行の先頭に # を追加して、OMS 出力プラグインをコメントアウトします。

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

出力プラグインの下で、各行の先頭にある # を削除することにより、次のセクションをコメント解除します。

<match **>
  type stdout
</match>

問題点:プロキシ経由で Azure Monitor に接続できない

考えられる原因

• オンボード中に指定されたプロキシが正しくありません。
• Azure Monitor サービスと Azure Automation サービスのエンドポイントが、データセンター内にある承認されたリストに含まれていません。

解像度

1. オプション -v が有効になった次のコマンドを使用して、Linux 用 Log Analytics エージェントで Azure Monitor に再オンボードします。 これにより、プロキシ経由で Azure Monitor に接続しているエージェントの詳細出力が可能になります。/opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

2. 「プロキシ設定を更新する」セクションを参照して、プロキシ サーバー経由で通信するようにエージェントを正しく構成したことを確認します。

3. Azure Monitor のネットワーク ファイアウォール要件の一覧で示されているエンドポイントが許可リストに正しく追加されていることを再確認します。 Azure Automation を使用する場合に必要なネットワーク構成手順も、上記のリンクで示されています。

問題点:オンボードしようとすると 403 エラーが発生する

考えられる原因

• Linux サーバーで日付と時刻が正しくありません。
• ワークスペース ID とワークスペース キーが正しくありません。

解像度

1. date コマンドを使用して、Linux サーバーの時刻を確認します。 時刻が現在の時刻より 15 分後または前である場合、オンボードは失敗します。 この状況を修正するには、Linux サーバーの日付やタイム ゾーンを更新します。
2. 最新バージョンの Linux 用 Log Analytics エージェントをインストールしたことを確認します。 最新バージョンでは、時間の差によってオンボードが失敗する場合に通知するようになりました。
3. この記事の前述のインストール手順に従って、正しいワークスペース ID とワークスペース キーを使用して再オンボードします。

問題点:オンボードの直後にログ ファイルに 500 および 404 エラーが表示される

これは、Linux データを Log Analytics ワークスペースに最初にアップロードするときに発生する既知の問題です。 この問題は、送信されているデータやサービス エクスペリエンスには影響しません。

問題点:omiagent が 100% の CPU を使用している

考えられる原因

nss-pem パッケージ v1.0.3-5.el7 の回帰によって、重大なパフォーマンス上の問題が発生しました。 この問題は、Redhat/CentOS 7.x のディストリビューションで多く発生しています。 この問題の詳細については、libcurl でのパフォーマンスの回帰 (1667121)に関するページを参照してください。

パフォーマンスに関連したバグは常に発生するわけではなく、再現するのは困難です。 omiagent でそのような問題が発生した場合は、スクリプト omiHighCPUDiagnostics.sh を使用してください。これは、特定のしきい値を超えると、omiagent のスタック トレースを収集します。

1. スクリプトをダウンロードします。
   wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

2. 30% の CPU しきい値で 24 時間診断を実行します。
   bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

3. コールスタックが omiagent_trace ファイルにダンプされます。 多くの curl および NSS の関数呼び出しがある場合は、次の解決手順を実行してください。

解決方法

1. 次のように nss-pem パッケージを v1.0.3-5.el7_6.1 にアップグレードします。
   sudo yum upgrade nss-pem

2. nss-pem がアップグレードに使用できない場合 (多くの場合、CentOS で発生する)、curl を 7.29.0-46 にダウングレードします。 誤って "yum update" を実行すると、curl は 7.29.0-51 にアップグレードされ、問題が再度発生します。
   sudo yum downgrade curl libcurl

3. OMI を再起動します。
   sudo scxadmin -restart

問題: 転送された Syslog メッセージが表示されない

考えられる原因

• Linux サーバーに適用された構成で、送信されたファシリティやログ レベルの収集が許可されていません。
• Syslog が Linux サーバーに正しく転送されていません。
• 1 秒あたりに転送されるメッセージの数が多すぎて、Linux 用 Log Analytics エージェントの基本構成では処理できません。

解像度

• Log Analytics ワークスペースでの Syslog の構成にすべてのファシリティと正しいログ レベルが含まれていることを確認します。 Azure portal での Syslog コレクションの構成に関するページを確認してください。
• 転送されたメッセージをネイティブの Syslog メッセージング デーモン (rsyslog、syslog-ng) が受信できることを確認します。
• Syslog サーバーのファイアウォール設定をチェックして、メッセージがブロックされていないことを確認します。
• 次の logger コマンドを使用して、Log Analytics に対する Syslog メッセージをシミュレートします。
  logger -p local0.err "This is my test message"

問題: omsagent ログ ファイルで既に使用されている Errno アドレスを受け取る

omsagent.log で [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> が表示されます。

考えられる原因

このエラーは、Linux Diagnostic Extension (LAD) が Log Analytics Linux VM 拡張機能と共にインストールされていることを示します。 omsagent と同じポートを Syslog データ収集に使用しています。

解決策

1. root として次のコマンドを実行します。 25224 は例であり、お使いの環境では LAD が異なるポート番号を使用している可能性があることに注意してください。

   /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229
   
   sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
   

   その後、適切な rsyslogd または syslog_ng 構成ファイルを編集し、ポート 25229 に書き込むように LAD 関連の構成を変更する必要があります。

2. VM が rsyslogd を実行している場合、変更するファイルは /etc/rsyslog.d/95-omsagent.conf です (存在する場合。それ以外の場合は /etc/rsyslog)。 VM が syslog_ng を実行している場合、変更するファイルは /etc/syslog-ng/syslog-ng.conf です。

3. omsagent sudo /opt/microsoft/omsagent/bin/service_control restart を再起動します。

4. Syslog サービスを再起動します。

問題: purge オプションを使用して omsagent をアンインストールできない

考えられる原因

• Linux Diagnostic Extension がインストールされています。
• Linux Diagnostic Extension をインストールしてアンインストールしましたが、omsagent が mdsd によって使用されていることを示すエラーがまだ表示され、削除できません。

解決策

1. Linux Diagnostic Extension をアンインストールします。
2. Linux Diagnostic Extension のファイルが場所 /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ および /var/opt/microsoft/omsagent/LAD/ に存在する場合は、それらを削除します。

問題: Nagios データを表示できない

考えられる原因

• omsagent ユーザーが、Nagios ログ ファイルからの読み取りのアクセス許可を持っていません。
• Nagios のソースとフィルターが、omsagent.conf ファイルでコメント解除されていません。

解決策

1. こちらの説明に従って、Nagios ファイルから読み取るための omsagent ユーザーを追加します。

2. /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf にある Linux 用 Log Analytics エージェントの一般構成ファイルで、Nagios のソースとフィルターの両方がコメント解除されていることを確認します。

   <source>
     type tail
     path /var/log/nagios/nagios.log
     format none
     tag oms.nagios
   </source>
   
   <filter oms.nagios>
     type filter_nagios_log
   </filter>
   

問題: Linux データが表示されない

考えられる原因

• Azure Monitor へのオンボードに失敗しました。
• Azure Monitor への接続がブロックされています。
• 仮想マシンが再起動されました。
• Linux 用 Log Analytics エージェント パッケージによってインストールされたものより新しいバージョンの OMI パッケージに手動でアップグレードされました。
• OMI がフリーズし、OMS エージェントがブロックされています。
• DSC リソースにより、"クラスが見つからない" というエラーが omsconfig.log ログ ファイルに記録されています。
• Log Analytics エージェントのデータがバックアップされています。
• DSC ログ "現在の構成が存在しません。まず -Path パラメーターを使って Start-DscConfiguration コマンドを実行して構成ファイルを指定し、現在の構成を作成します。" が omsconfig.log ログ ファイルに含まれますが、PerformRequiredConfigurationChecks 操作に関するログ メッセージが存在しません。

解像度

1. auditd パッケージのようなすべての依存関係をインストールします。

2. ファイル /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf が存在するかどうかをチェックして、Azure Monitor へのオンボードに成功したかどうかを確認します。 成功しなかった場合は、omsadmin.sh コマンド ラインの指示を使用して再オンボードします。

3. プロキシを使用している場合は、上記のプロキシのトラブルシューティング手順を確認します。

4. 一部の Azure ディストリビューション システムでは、仮想マシンの再起動後に、omid OMI サーバー デーモンが開始しません。 この場合、監査、ChangeTracking、または UpdateManagement ソリューション関連のデータは表示されません。 回避するには、sudo /opt/omi/bin/service_control restart を実行して OMI サーバーを手動で開始します。

5. OMI パッケージを手動で新しいバージョンにアップグレードした後、Log Analytics エージェントが継続して機能するには、手動で再起動する必要があります。 この手順は、OMI サーバーがアップグレード後に自動的に起動しない一部のディストリビューションで必要です。 sudo /opt/omi/bin/service_control restart を実行して OMI を再起動します。

   場合によっては、OMI がフリーズすることがあります。 OMS エージェントは、OMI を待機するブロック状態になり、すべてのデータ収集がブロックされる可能性があります。 OMS エージェント プロセスは実行されますが、アクティビティは発生しません。これは、omsagent.log に新しいログ行 (送信されたハートビートなど) が存在しないことからもわかります。 sudo /opt/omi/bin/service_control restart を使用して OMI を再起動し、エージェントを復旧します。

6. DSC リソースの "クラスが見つからない" というエラーが omsconfig.log に記録されている場合は、sudo /opt/omi/bin/service_control restart を実行します。

7. 場合によっては、Linux 用 Log Analytics エージェントが Azure Monitor と通信できないときに、エージェントのデータが最大バッファー サイズ (50 MB) までバックアップされます。 /opt/microsoft/omsagent/bin/service_control restart コマンドを実行して、エージェントを再起動する必要があります。

   注意

   この問題は、エージェント バージョン 1.1.0-28 以降で修正されます。

   • PerformRequiredConfigurationChecks 操作がシステムで定期的に実行されていることが omsconfig.log ログ ファイルで示されていない場合、cron ジョブ/サービスに問題がある可能性があります。 /etc/cron.d/OMSConsistencyInvoker に cron ジョブが存在することを確認します。 必要な場合は、次のコマンドを実行して cron ジョブを作成します。

     mkdir -p /etc/cron.d/
     echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker
     

   • また、cron サービスが実行されていることを確認します。 Debian、Ubuntu、SUSE では service cron status を使用して、または RHEL、CentOS、Oracle Linux では service crond status を使用して、このサービスの状態を確認できます。 サービスが存在しない場合は、次の手順を使用して、バイナリをインストールし、サービスを開始できます。

     Ubuntu/Debian

     # To Install the service binaries
     sudo apt-get install -y cron
     # To start the service
     sudo service cron start
     

     SUSE

     # To Install the service binaries
     sudo zypper in cron -y
     # To start the service
     sudo systemctl enable cron
     sudo systemctl start cron
     

     RHEL/CentOS

     # To Install the service binaries
     sudo yum install -y crond
     # To start the service
     sudo service crond start
     

     Oracle Linux

     # To Install the service binaries
     sudo yum install -y cronie
     # To start the service
     sudo service crond start
     

問題: Syslog または Linux のパフォーマンス カウンターに対してポータルからコレクションを構成すると、設定が適用されない

考えられる原因

• Linux 用 Log Analytics エージェントが最新の構成を取得していません。
• ポータルで変更された設定が適用されていません。

解像度

背景知識: omsconfig は Linux 用 Log Analytics エージェントの構成エージェントであり、5 分ごとに新しいポータル側構成を検索します。 その後、この構成が、/etc/opt/microsoft/omsagent/conf/omsagent.conf にある Linux 用 Log Analytics エージェント構成ファイルに適用されます。

場合によっては、Linux 用 Log Analytics エージェント構成エージェントがポータル構成サービスと通信できないことがあります。 このシナリオでは、最新の構成が適用されません。

1. dpkg --list omsconfig または rpm -qi omsconfig を実行して、omsconfig エージェントがインストールされていることを確認します。 インストールされていない場合は、Linux 用 Log Analytics エージェントの最新バージョンを再インストールします。

2. コマンド sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' を実行して、omsconfig エージェントが Azure Monitor と通信できることを確認します。 このコマンドは、Syslog 設定、Linux のパフォーマンス カウンター、カスタム ログなど、エージェントがサービスから受け取った構成を返します。 このコマンドが失敗する場合は、sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py' コマンドを実行します。 このコマンドは、omsconfig エージェントに強制的に Azure Monitor と通信して最新の構成を取得させます。

問題: カスタム ログ データが表示されない

考えられる原因

• Azure Monitor へのオンボードに失敗しました。
• 設定 [Apply the following configuration to my Linux Servers](次の構成を Linux サーバーに適用する) がオンになっていません。
• omsconfig がサービスから最新のカスタム ログ構成を取得していません。
• Linux 用 Log Analytics エージェントのユーザー omsagent は、アクセス許可が見つからないため、カスタム ログにアクセスできません。 次のエラーが表示されることがあります。
  • [DATETIME] [warn]: file not found. Continuing without tailing it.
  • [DATETIME] [error]: file not accessible by omsagent.
• Linux 用 Log Analytics エージェント バージョン 1.1.0-217 で修正された競合状態に関する既知の問題。

解像度

1. ファイル /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf が存在するかどうかをチェックして、Azure Monitor へのオンボードに成功したことを確認します。 成功していない場合は、次のいずれかを行います。

   1. omsadmin.sh コマンド ラインの指示を使用して再オンボードします。
   2. Azure portal の [詳細設定] で、設定 [Apply the following configuration to my Linux Servers](次の構成を Linux サーバーに適用する) が有効になっていることを確認します。

2. コマンド sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py' を実行して、omsconfig エージェントが Azure Monitor と通信できることを確認します。 このコマンドは、Syslog 設定、Linux のパフォーマンス カウンター、カスタム ログなど、エージェントがサービスから受け取った構成を返します。 このコマンドが失敗する場合は、sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py' コマンドを実行します。 このコマンドは、omsconfig エージェントに強制的に Azure Monitor と通信して最新の構成を取得させます。

背景: 特権ユーザー root として実行される Linux 用 Log Analytics エージェントの代わりに、エージェントは omsagent ユーザーとして実行されます。 ほとんどの場合、特定のファイルを読み取るためには、明示的なアクセス許可をユーザーに付与する必要があります。 omsagent ユーザーにアクセス許可を付与するには、次のコマンドを実行します。

1. sudo usermod -a -G <GROUPNAME> <USERNAME> により、omsagent ユーザーを特定のグループに追加します。
2. sudo chmod -R ugo+rx <FILE DIRECTORY> により、必要なファイルへの汎用の読み取りアクセス許可を付与します。

1.1.0-217 より前のバージョンの Linux 用 Log Analytics エージェントには、競合状態に関する既知の問題があります。 最新のエージェントに更新した後、次のコマンドを実行して、出力プラグインの最新バージョンを取得します。sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf

問題: 新しいワークスペースに再オンボードしようとしている

エージェントを新しいワークスペースに再オンボードするときは、再オンボードの前に、Log Analytics エージェントの構成をクリーンアップする必要があります。 エージェントから古い構成をクリーンアップするには、--purge により、シェル バンドルを実行します。

sudo sh ./omsagent-*.universal.x64.sh --purge

または

sudo sh ./onboard_agent.sh --purge

--purge オプションを使用した後も、引き続き再オンボードできます。

問題: Azure portal の Log Analytics エージェント拡張機能がエラー状態 "プロビジョニング失敗" でマークされる

考えられる原因

• Log Analytics エージェントが、オペレーティング システムから削除されました。
• Log Analytics エージェント サービスが、ダウン、無効、または未構成になっています。

解決策

1. Azure portal から拡張機能を削除します。
2. 指示に従ってエージェントをインストールします。
3. 次のコマンドを実行してエージェントを再起動します。
   [https://login.microsoftonline.com/consumers/](sudo /opt/microsoft/omsagent/bin/service_control restart)
4. プロビジョニングの状態が [プロビジョニング成功] に変わるまで数分待ちます。

問題点:Log Analytics エージェントがオンデマンドでアップグレードする

考えられる原因

ホスト上の Log Analytics エージェント パッケージが期限切れです。

解像度

1. この GitHub ページで最新リリースを確認します。

2. 次のように、インストール スクリプトをダウンロードします (1.4.2-124 はバージョンの例です)。

   wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh
   

3. sudo sh ./omsagent-*.universal.x64.sh --upgrade を実行してパッケージをアップグレードします。

問題: インストールに失敗し、Python 3 を使用しているのに、Python 2 では Ctype をサポートしていないと表示される

考えられる原因

この既知の問題では、VM の言語が英語でない場合に、使用している Python のバージョンの確認時にチェックが失敗します。 この問題の結果、常に、Pyhon 2 が使用されているとエージェントによってみなされ、Pyhon 2 を使用していない場合にもエラーが発生します。

解決策

VM の環境言語を英語に変更します。

export LANG=en_US.UTF-8