Tutoriel Linux

Grepを使用してLinuxでログのエラーを見つける

DébutantPublié par Julien Macé le 2 min de lecture

アクティブなサーバーの cat /var/log/syslog は主に一つのことを示します：行が多すぎることです。サービスが停止したり、エラーが再発したときは、まずサービスの名前、時間、正確なメッセージを探します。 grep は音を減らし、何が起こったのかの説明が含まれている行を失うことなく行を絞り込むことができます。

この方法は、 /var/log 内のファイルや journalctl の出力で機能します。これは完全なログを置き換えるものではなく、信頼できる出発点を見つけてから、その周りを広げるためのものです。

TuxがLinuxのログ内の特定のエラーを虫眼鏡で検索している
特定のエラーを探し、その周囲の行を再確認してください。

読みやすい検索から始める

行番号を追加し、プログラムが Error、 ERROR、または error を混ぜる場合は大文字と小文字を無視します：

grep -n -i 'error' /var/log/mon-service.log

-n は行番号を表示します。これは less でファイルを再開したり、2つの検索を比較したり、チケットに抜粋をコピーする必要があるときに便利です。アポストロフィは、シェルがパターン内の特殊文字を解釈することを避けます。 grep のマニュアル では、検索オプションとコンテキストについて詳しく説明しています。

  • -i は大文字と小文字を区別せずに検索します。
  • -n は行番号を追加します。
  • -F はテキストをリテラル文字列として扱い、 .、 [、または ? を含むエラーメッセージに便利です。
  • -E は拡張正規表現を有効にします。
  • -C 3 は各一致の前後に3行を表示します。

正確なエラーには -F を優先してください。IPアドレス、パス、または括弧付きのメッセージは、そうでない場合、正規表現として解釈される可能性があります：

grep -n -F 'connection refused [127.0.0.1:5432]' /var/log/mon-service.log

エラーを説明する行を保持する

ERROR とマークされた行は、通常、その原因を単独で示すことは稀です。結論を出す前にコンテキストを表示してください：

grep -n -i -C 3 'error' /var/log/mon-service.log

grep -n -i -A 5 'failed' /var/log/mon-service.log

grep -n -i -B 5 'panic' /var/log/mon-service.log

-C 3 は両側に3行を保持します。 -A は後続の行のみを表示し、 -B は前の行のみを表示します。複数のエラーが離れている場合、 grep はグループを -- で区切ります。この区切りはログの一部ではありません。

いくつかの症状を知っている場合は、それらを -E で組み合わせてください：

grep -n -i -E 'error|failed|timeout|refused' /var/log/mon-service.log

このコマンドは必ずしもあなたのインシデントに関係のないメッセージも返します。無作為にキーワードリストを延長するのではなく、その後にプロセス名、ポート、またはリクエストIDを追加してください。

grepを使う前にjournalctlでフィルタリング

systemdを使用している場合、インシデントの単位と期間に日誌を制限することから始めます。他のサービスのメッセージを混ぜることを避けます：

journalctl -u nginx --since '30 minutes ago' --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager | grep -n -i -C 2 'error'

nginx を実際のユニット名、例えば postgresql、 docker、またはあなたのアプリサービスに置き換えます。インシデントが再起動に続く場合 -b を追加して現在の起動に留まることができます。 journalctlのマニュアル では、ユニットと期間によるフィルタについても説明しています。 journalctlと最後の起動のログに関する私たちのガイド は、このフィルタについて詳しく説明しています。

問題の時間を特定する前に、何年分ものログで検索を開始しないでください。14時12分に見たエラーは、14時12分周辺の短いウィンドウを持つ価値があります。原因が現れない場合は、広範囲に読み込むことができます。

再現中にサービスを追跡する

再現可能な問題の場合、2つ目のターミナルを開き、新しい行だけを表示します：

journalctl -fu nginx

tail -F /var/log/nginx/error.log | grep --line-buffered -i -E 'error|warn|failed'

journalctl -f はライブでログを追跡します。 tail -F はファイルのローテーション後も続行し、アプリケーションログの多くに対して tail -f より安全です。オプション --line-buffered は grep へのパイプの後にフローを読みやすく保ちます。

次に、失敗するアクションを一度だけトリガーします：HTTPリクエスト、制御された再起動、またはテスト接続などです。複数のテストを同時に実行すると、どの行がどの試みに属しているのか分からなくなります。通常のファイルを追う場合は、 tailの方法 も参照できます。

エラーを見つけたら、時間、対象のユニットまたはプロセス、およびメッセージの周囲の行を記録してください。これは千行のログをコピー＆ペーストするよりも有用で、問題のサービスを特定する前に設定を変更するのを避けられます。

n