Linux 上の Azure Monitor Agent に関する syslog の問題のトラブルシューティング

この記事を使用して、Linux VM 上の syslog イベントが Azure Monitor エージェントによってLog Analytics ワークスペースに収集または転送されない問題を診断して解決します。

インストール時に、Azure Monitor エージェントはシステムの syslog デーモンの出力構成をインストールします。 この構成では、デーモンから Azure Monitor エージェントにイベントを転送する方法を定義します。 次の情報を確認できます。

  • /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf rsyslog の場合 (ほとんどの Linux ディストリビューション)
  • /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf syslog-ng の場合

Azure Monitor エージェントは TCP ポート (/etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port でログに記録) をリッスンして、rsyslog または syslog-ng からイベントを受信します。 これらのイベントは、 /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/にあるデータ収集規則 (DCR) で定義されている機能または重大度の値に基づいてフィルター処理されます。 エージェントは、DCR 構成と一致しないイベントを削除します。

注

バージョン 1.28 より前のバージョンでは、Azure Monitor エージェントは TCP ポートではなく Unix ドメイン ソケットを使用して rsyslog からイベントを受信しました。 omfwd の出力モジュールは、信頼性を向上させるためにスプールと再試行のメカニズムを提供します。

Azure Monitor エージェントは、RFC3164 および RFC5424 に従って受信 syslog メッセージを解析し、その他の形式もサポートします。 DCR から各イベントの宛先エンドポイントを決定し、それに応じてイベントのアップロードを試みます。

注

  • Azure Monitor エージェントに到達できない場合、または遅延が発生した場合、syslog デーモンは内部キューを使用してイベントをバッファーします。
  • Azure Monitor エージェントは、rsyslog または syslog-ng から受信したイベントのアップロードに失敗した場合、ローカル永続化メカニズムを使用して /var/opt/microsoft/azuremonitoragent/events にキューに入れます。

syslog アップロードエラーを診断する

Azure Monitor エージェントが rsyslog または syslog-ng から syslog イベントを正常に受信したが、データが Log Analytics ワークスペースに表示されない場合、最も一般的な原因は接続、構成、または認証に関連しています。ローカル ディスクの使用状況ではありません。

一般的な原因には、次のようなものがあります。

  • データ収集規則 (DCR) がコンピューターに関連付けられていない
    DCR を関連付けない場合 (または間違った DCR を関連付ける場合)、Azure Monitor エージェントはデータの送信先を認識しません。

  • DCR に syslog データ ソースが含まれていないか、ファシリティ/重大度が一致しない
    この場合、Azure Monitor エージェントはイベントを受信した後に破棄します。

  • マシンはAzure Monitorインジェスト エンドポイントに到達できません
    この状態は、一般的に次の原因で発生します。

    • 送信方向のファイアウォール制限
    • プロキシの構成ミス
    • 制限付きネットワークにサービス タグまたは必要なエンドポイントがない

  • TLS またはプロキシの構成によって送信接続が禁止される
    プロキシが必要であり、Azure Monitor エージェント用に構成されていない場合、アップロードの試行は失敗します。

  • エージェントによって使用されるマネージド ID またはAzure資格情報は認証できません
    この状態は、エージェント拡張機能が正しくプロビジョニングされていない場合に発生する可能性があります。

アップロードと接続の問題をトラブルシューティングするには、次のガイダンスを参照してください。

Azure Monitor エージェントは syslog イベントを受信しているがアップロードできない場合、通常、接続または認証に関連するエラーを次に記録します。

/var/opt/microsoft/azuremonitoragent/log/mdsd.err

ディスク領域がいっぱいのため、Rsyslog データがアップロードされない

症状

Syslog データがアップロードされていません: /var/opt/microsoft/azuremonitoragent/log/mdsd.errでエラー ログを調べると、 ローカル永続ストアに項目を挿入しているときにエラーに関するエントリが表示されます。デバイスにスペースが残っていません... 次のスニペットに似ています。

2021-11-23T18:15:10.9712760Z: Error while inserting item to Local persistent store syslog.error: IO error: No space left on device: While appending to file: /var/opt/microsoft/azuremonitoragent/events/syslog.error/000555.log: No space left on device

原因

Azure Monitor Agent for Linux は、インジェストの前にイベントを /var/opt/microsoft/azuremonitoragent/events にバッファーします。 既定の Azure Monitor Agent for Linux インストールでは、このディレクトリはアイドル状態で約 650 MB のディスク領域を使用します。 ログ記録の負荷が持続する状況では、ディスク上のこのサイズが大きくなります。 約 60 秒ごとにクリーンアップされ、負荷がアイドル状態に戻ると約 650 MB に戻ります。

ディスクがいっぱいになる問題の確認

df コマンドは、次の出力に示すように、/dev/sda1 上に使用可能な領域がほとんどないことを示します。 ログ ディレクトリに関連付けられる行項目 ( /var/log、 /var、 /など) を調べる必要があります。

df -h

Filesystem Size  Used Avail Use% Mounted on
udev        63G     0   63G   0% /dev
tmpfs       13G  720K   13G   1% /run
/dev/sda1   29G   29G  481M  99% /
tmpfs       63G     0   63G   0% /dev/shm
tmpfs      5.0M     0  5.0M   0% /run/lock
tmpfs       63G     0   63G   0% /sys/fs/cgroup
/dev/sda15 105M  4.4M  100M   5% /boot/efi
/dev/sdb1  251G   61M  239G   1% /mnt
tmpfs       13G     0   13G   0% /run/user/1000

du コマンドを使用してディスクを検査し、どのファイルがディスクをいっぱいにしているかを特定できます。 次に例を示します。

cd /var/log
du -h syslog*

6.7G    syslog
18G     syslog.1

場合によっては、du では大きなファイルやディレクトリが報告されないことがあります。 ( 削除済み) としてマークされたファイルが領域を占有している可能性があります。 この状況は、あるプロセスがファイルを削除しようとしても、別のプロセスでファイルが開かれている場合に発生する可能性があります。

lsof コマンドを使用してそのようなファイルがないかを確認できます。 次の例では、 /var/log/syslog は削除済みとしてマークされていますが、最大 3.6 GB のディスク領域が必要です。 PID 1484 のプロセスでもファイルが開いているため、削除されません。

sudo lsof +L1

COMMAND   PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK  NODE NAME
none      849   root  txt    REG    0,1       8632     0 16764 / (deleted)
rsyslogd 1484 syslog   14w   REG    8,1 3601566564     0 35280 /var/log/syslog (deleted)

rsyslog の既定の構成では、すべての機能のログは /var/log/ に記録されます

Ubuntu 18.04 LTS などの一般的なディストリビューションでは、rsyslog には既定の構成ファイル (/etc/rsyslog.d/50-default.conf) が付属しています。 この構成では、ほぼすべての機能から /var/log/syslogのディスクへのイベントがログに記録されます。 RedHat ファミリ Syslog イベントは、 /var/log/ の下に保存されますが、別のファイル ( /var/log/messages) に格納されます。

Azure Monitor エージェントは、/var/log/ にログに記録される Syslog イベントに依存しません。 代わりに、イベントを TCP ポート経由で azuremonitoragent サービス プロセス (mdsd) に直接転送するように、rsyslog サービスを構成します。

rsyslog の既定の構成から大量の機能を削除する

rsyslog を通して大きいログ ボリュームを送信していて、システムがこれらの機能のイベントをログに記録するように設定されている場合は、ログ記録と /var/log/ の下への保存を止めるように既定の rsyslog 構成を修正することを検討してください。 rsyslog は、/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf に配置された転送に別の構成を使用するため、この機能のイベントは引き続き Azure Monitor Agent に転送されます。

  1. local4または/var/log/syslogでログに記録/var/log/messagesイベントを削除するには、次のスニペットの/etc/rsyslog.d/50-default.confで次の行を変更します。

    *.*;auth,authpriv.none          -/var/log/syslog

    次のスニペットに (local4.none; を追加します):

    *.*;local4.none;auth,authpriv.none          -/var/log/syslog

  2. sudo systemctl restart rsyslog

次のステップ

この記事の手順で問題が解決しない場合は、次を参照してください。

  • Last updated on