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

Azure Monitor の Linux 用 Log Analytics エージェントで発生する可能性のあるエラーのトラブルシューティングのヘルプを提供し、それらを解決するための考えられる解決策を提案します。

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

Log Analytics エージェントの Linux トラブルシューティング ツールは、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

対象となるシナリオ

トラブルシューティング ツールによって確認されるシナリオの一覧を次に示します。

  1. エージェントが異常で、ハートビートが正常に機能していない
  2. エージェントが起動せず、Log analytics サービスに接続できない
  3. エージェント syslog が機能していない
  4. エージェントの CPU/メモリ使用率が高くなっている
  5. エージェントのインストールに問題がある
  6. エージェントのカスタム ログが機能してしない
  7. エージェントのログを収集する

詳細については、GitHub のドキュメントをご覧ください。

Note

問題が発生した場合は、ログ コレクター ツールを実行してください。 ログを最初に用意することは、サポート チームが問題を迅速にトラブルシューティングするのに役立ちます。

Linux エージェントの消去と再インストール

エージェントのクリーン再インストールによってほとんどの問題が解決されることがわかりました。 実際、エージェントを修復するために試す方法として、サポート チームが、この方法を最初に提案する場合もあります。 トラブルシューティング ツールを実行し、ログを収集し、クリーン再インストールを試行することで、問題をより迅速に解決できます。

  1. 消去スクリプトをダウンロードします。
  • $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh
  1. (sudo アクセス許可で) 消去スクリプトを実行します。
  • $ sudo sh purge_omsagent.sh

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

ファイル Path
Linux 用 Log Analytics エージェントのログ ファイル /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Log Analytics エージェントの構成のログ ファイル /var/opt/microsoft/omsconfig/omsconfig.log

トラブルシューティングでは、または GitHub の問題を送信する前に、ログ コレクター ツールを使用して重要なログを取得することをお勧めします。 ツールの詳細と実行方法については、こちらをご覧ください。

重要な構成ファイル

カテゴリ ファイルの場所
syslog /etc/syslog-ng/syslog-ng.conf または /etc/rsyslog.conf または /etc/rsyslog.d/95-omsagent.conf
パフォーマンス、Nagios、Zabbix、Log Analytics の出力および汎用エージェント /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
追加の構成 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Note

Azure portal でワークスペースに対する Log Analytics の [詳細設定] の [データ] メニューからコレクションを構成した場合、パフォーマンス カウンターおよび Syslog に関する構成ファイルの編集が上書きされます。 すべてのエージェントの構成を無効にするには、Log Analytics の [詳細設定] でコレクションを無効にします。1 つのエージェントの場合は、次を実行します。

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

エラー コード 意味
NOT_DEFINED 必要な依存関係がインストールされていないため、auoms auditd プラグインはインストールされません。 auoms のインストールが失敗しました。パッケージ auditd をインストールします。
2 シェル バンドルに提供されたオプションが無効です。 使用方法については sudo sh ./omsagent-*.universal*.sh --help を実行してください
3 シェル バンドルにオプションが提供されていません。 使用方法については sudo sh ./omsagent-*.universal*.sh --help を実行してください。
4 パッケージの種類またはプロキシの設定が無効です。omsagent-rpm.sh パッケージは RPM ベースのシステムにのみインストールでき、omsagent-deb.sh パッケージは Debian ベースのシステムにのみインストールできます。 最新リリースのユニバーサル インストーラーを使うことをお勧めします。 また、プロキシの設定を確認してください。
5 シェル バンドルはルートとして実行する必要があります。または、オンボード中に 403 エラーが返されました。 sudo を使用してコマンドを実行してください。
6 パッケージのアーキテクチャが無効であるか、または、オンボード中に 200 エラーが返されました。omsagent-*x64.sh パッケージは 64 ビット システムにのみインストールでき、omsagent-*x86.sh パッケージは 32 ビット システムにのみインストールできます。 アーキテクチャに合った適切なパッケージを、最新リリースからダウンロードしてください。
17 OMS パッケージのインストールが失敗しました。 コマンド出力で根本的な障害を調べてください。
18 OMSConfig パッケージのインストールに失敗しました。 コマンド出力で根本的な障害を調べてください。
19 OMI パッケージのインストールが失敗しました。 コマンド出力で根本的な障害を調べてください。
20 SCX パッケージのインストールが失敗しました。 コマンド出力で根本的な障害を調べてください。
21 プロバイダー キットのインストールが失敗しました。 コマンド出力で根本的な障害を調べてください。
22 バンドルされているパッケージのインストールが失敗しました。 コマンド出力で根本的な障害を調べてください
23 SCX または OMI パッケージは既にインストールされています。 シェル バンドルをインストールするには、--install の代わりに --upgrade を使用してください。
30 バンドルの内部エラー。 出力の詳細情報を添えて GitHub の問題を提出してください。
55 サポートされていない openssl バージョンか、Azure Monitor に接続できないか、または dpkg がロックされているか curl プログラムがありません。
61 Python ctypes ライブラリが不足しています。 Python ctypes ライブラリまたはパッケージ (python-ctypes) をインストールします。
62 tar プログラムがありません。tar をインストールしてください。
63 sed プログラムがありません。sed をインストールしてください。
64 curl プログラムがありません。curl をインストールしてください。
65 gpg プログラムがありません。gpg をインストールしてください。

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

エラー コード 意味
2 omsadmin スクリプトに提供されたオプションが無効です。 使用方法については sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h を実行してください。
3 omsadmin スクリプトに提供された構成が無効です。 使用方法については sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h を実行してください。
4 omsadmin スクリプトに提供されたプロキシが無効です。 プロキシを確認し、HTTP プロキシの使用方法に関するドキュメントを参照してください。
5 Azure Monitor から受信された 403 HTTP エラー。 詳細については、omsadmin スクリプトの完全な出力を参照してください。
6 Azure Monitor から受信された 200 以外の HTTP エラー。 詳細については、omsadmin スクリプトの完全な出力を参照してください。
7 Azure Monitor に接続できません。 詳細については、omsadmin スクリプトの完全な出力を参照してください。
8 Log Analytics ワークスペースへのオンボードでエラーが発生しました。 詳細については、omsadmin スクリプトの完全な出力を参照してください。
30 スクリプトの内部エラーです。 出力の詳細情報を添えて GitHub の問題を提出してください。
31 エージェント ID の生成でエラーが発生しました。 出力の詳細情報を添えて GitHub の問題を提出してください。
32 証明書の生成でエラーが発生しました。 詳細については、omsadmin スクリプトの完全な出力を参照してください。
33 omsconfig のメタ構成の生成でエラーが発生しました。 出力の詳細情報を添えて GitHub の問題を提出してください。
34 メタ構成生成スクリプトが存在しません。 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> でオンボードを再試行してください。

デバッグ ログの有効化

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 のディストリビューションで多く発生しています。 この問題の詳細については、次のドキュメントを参照してください。バグ 1667121 の libcurl のパフォーマンス低下に関するページを参照してください。

パフォーマンスに関連したバグは常に発生するわけではなく、再現するのは非常に困難です。 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 メッセージング デーモン (rsyslogsyslog-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 サービスを開始しなおします。

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

考えられる原因

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

解像度

  1. Linux Diagnostic Extension (LAD) をアンインストールします。
  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 のソースとフィルターの/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.confがコメント解除されていることを確認します。

    <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 リソースにより、"クラスが見つからない" というエラーが ログ ファイルに記録されています
  • Log Analytics エージェントのデータがバックアップされています
  • DSC ログ現在の構成が存在しません。構成Start-DscConfigurationを指定し、最初に現在の構成を作成するには、-Path パラメーターを指定してコマンドを実行します。 ログ ファイルに含まれますが、操作に関するログ メッセージは PerformRequiredConfigurationChecks 存在しません。

解像度

  1. auditd パッケージのようなすべての依存関係をインストールします。
  2. ファイル /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf が存在するかどうかをチェックして、Azure Monitor へのオンボードに成功したかどうかを確認します。 成功しなかった場合は、omsadmin.sh コマンド ラインの指示を使用して再オンボードします。
  3. プロキシを使用している場合は、上記のプロキシのトラブルシューティング手順を確認します。
  4. 一部の Azure ディストリビューション システムでは、仮想マシンの再起動後に、omid OMI サーバー デーモンが開始しません。 これにより、Audit、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 を再起動し、エージェントを復旧します。
  1. DSC リソースの "クラスが見つからない" というエラーが omsconfig.log に記録されている場合は、 を実行します。

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

    Note

    この問題は、エージェント バージョン 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/CeonOS

    # 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 エージェントで最新の構成が選択されていません
  • ポータルで変更された設定が適用されていません

解像度

背景知識: は 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 へのオンボードに成功したことを確認します。 成功していない場合は、次のいずれかを行います。

  2. omsadmin.sh コマンド ラインの指示を使用して再オンボードします。

  3. Azure portal の [詳細設定] で、設定 [Apply the following configuration to my Linux Servers]\(次の構成を Linux サーバーに適用する\) が有効になっていることを確認します。

  4. コマンド 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 と通信して最新の構成を取得させます。

背景: 特権ユーザー として実行される 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. 次のコマンドを実行してエージェントを再起動します。sudo /opt/microsoft/omsagent/bin/service_control restart
  • 数分待つと、プロビジョニングの状態がプロビジョニング成功に変わります。

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

考えられる原因

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

解像度

問題を修正するには次の手順を実行します。

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

  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