Nginxログ監視：Webトラフィックとエラーを分析するための主要コマンド

Nginxログ監視は、インシデント発生時に「今、実際に何が起きているのか？」という質問に答える最も迅速な方法です。メトリクスは5xxエラーが増加したことを教えてくれます。ログは、失敗したリクエストのパス、アップストリーム、ステータスコード、クライアントIP、タイミングの詳細を示します。

ここで紹介するコマンドは、一般的なLinuxツール（tail、grep、awk、sort、uniq、less、およびそれらの圧縮ログ対応版）を使用します。これらは本格的なログプラットフォームの代わりにはなりませんが、サーバーにSSHアクセスがあり、迅速で確かな答えが必要な場合にまさに必要なものです。

Nginxログの種類を理解する

Nginxは通常、nginx.confまたは関連する設定ファイル内で設定される2つの主要なタイプのログを生成します。

アクセスログ（access.log）： サーバーが処理したすべてのリクエストを記録します。このログは、ユーザーの行動、トラフィック量、地理的分布、応答時間を理解するために不可欠です。デフォルトでは、フィールドにはIPアドレス、リクエストメソッド、URI、HTTPステータスコード、リクエストサイズ、ユーザーエージェントなどが含まれます。
エラーログ（error.log）： Nginx自体が遭遇した診断情報、警告、重大なエラー（設定の問題、アップストリームのタイムアウト、リソースの枯渇など）を記録します。このログは、サーバー側の障害をトラブルシューティングするための最初の参照先です。

標準的なログの場所

場所はカスタマイズ可能ですが、Nginxログは通常、ほとんどのディストリビューションで以下のディレクトリにあります。

ディストリビューションの種類	デフォルトのログパス
Debian/Ubuntu	`/var/log/nginx/`
RHEL/CentOS	`/var/log/nginx/`
カスタムインストール（ソース）	異なる場合あり、`nginx.conf`を確認

ここでは、/var/log/nginx/access.logと/var/log/nginx/error.logを主な例として使用します。

1. `tail`を使用したリアルタイム監視

tailコマンドは、現在のサーバーアクティビティをリアルタイムで監視するために不可欠です。-f（フォロー）フラグを使用すると、出力がリアルタイムでスクロールし続けます。

ライブアクセストラフィックの監視

サーバーに届く新しいリクエストを表示するには、アクセスログに対してtail -fを使用します。

tail -f /var/log/nginx/access.log

エラーの同時監視

設定変更やデプロイメントをテストする際には、エラーを同時に監視すると便利です。これは、2つの別々のターミナルセッションを実行するか、multitailのようなツール（インストールされている場合）を使用して行うことができます。

tail -f /var/log/nginx/error.log

ヒント： 新しいエントリを追跡する前に最後の100行を表示したい場合は、tail -n 100 -f /var/log/nginx/access.logを使用します。

2. `grep`を使用した検索とフィルタリング

grep（Global Regular Expression Print）は、ログファイル内の特定の行を見つけるための主力ツールです。ステータスコード、IPアドレス、メソッドなどに基づいてログを迅速にフィルタリングできます。

特定のHTTPステータスコードの検索

トラブルシューティング時には、特定のエラーが発生したすべてのリクエストを迅速に特定することが重要です。ステータスコードの前後にスペースを入れることで、類似した数字（例：2000内の200に誤って一致するのを防ぐ）による誤検出を防ぎます。

すべての404（Not Found）エラーを検索：

grep " 404 " /var/log/nginx/access.log

すべての5xxサーバーエラーを検索：

grep -E " 50[0-9] " /var/log/nginx/access.log

リクエストパスまたはIPアドレスによるフィルタリング

特定のクライアントIPアドレスからのすべてのリクエスト、または特定のパス（例：/admin）へのすべてのアクセス試行を表示するには：

# クライアントIPアドレスでフィルタリング
grep "192.168.1.10" /var/log/nginx/access.log

# 特定のURLへのアクセス試行でフィルタリング
grep "/wp-login.php" /var/log/nginx/access.log

リアルタイムフィルタリング

tail -fの出力をgrepにパイプすることで、特定のイベントのみをリアルタイムで監視できます。

# 5xxエラーのみのライブフィード
tail -f /var/log/nginx/access.log | grep -E " 50[0-9] "

3. 大規模およびローテーションされたログの処理

ログファイルは急速に巨大化する可能性があります。Nginxは通常、ログローテーションユーティリティ（logrotate）を使用して、古いログをgzipで圧縮します。

`less`を使用した大規模ファイルの確認

ファイル全体をメモリにロードする代わりに（ターミナルセッションがクラッシュする可能性があります）、lessを使用してページ単位で表示します。lessは後方ナビゲーションと効率的な検索も可能にします。

less /var/log/nginx/access.log
# less内で、'G'を押すと末尾に、'g'を押すと先頭に移動し、'/'で検索します。

`zgrep`を使用した圧縮ログの検索

手動で解凍せずにローテーションされたログ（.gzファイル）を検索するには、一般的なコマンドのzバリアント（zcat、zgrep）を使用します。

# 圧縮されたログファイル内の403エラーを検索
zgrep " 403 " /var/log/nginx/access.log.1.gz

4. `awk`、`cut`、`sort`を使用した構造化分析

Nginxログは、特に標準のcombined形式を使用する場合、スペースで構造化されています。この構造により、awkやcutなどのツールを使用して、統計分析のための特定のデータフィールドを抽出できます。

デフォルトのcombined形式では、主要なフィールドは通常次のとおりです。

$1：リモートIPアドレス
$7：リクエストされたURI
$9：HTTPステータスコード
$10：送信バイト数
$12：HTTPリファラー
$14：ユーザーエージェント

最もリクエストされたページの特定

このパイプラインは、awkを使用してURI（$7）を抽出し、sortで同一エントリをグループ化し、uniq -cでカウントし、sort -nrで数値の降順（カウントが多い順）にリストします。

awk '{print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr | head -10

ステータスコードのカウント

ログに記録されたすべてのステータスコードの内訳をすばやく取得するには：

awk '{print $9}' /var/log/nginx/access.log | \
sort | uniq -c | sort -nr

出力例：

高レイテンシリクエストの特定（ログに記録されている場合）

Nginx設定でアップストリーム応答時間（$upstream_response_time）がログに記録されている場合、awkを使用して遅いリクエスト（例：1秒より遅い）を見つけることができます。

注：応答時間が12番目のフィールド（$12）であることを前提としています。フィールド番号を信頼する前に、log_format設定を確認してください。

awk '($12 > 1.0) {print $12, $7}' /var/log/nginx/access.log | sort -nr

ログ分析のベストプラクティス

除外には`grep -v`を使用する

ヘルスチェックや既知の良性ボットなど、一般的なノイズを除外する必要がある場合があります。grepの-vフラグはマッチを反転させ、パターンに一致しない行を表示します。

# 成功した200応答をすべて除外してアクセスログを表示
grep -v " 200 " /var/log/nginx/access.log

# 既知のGooglebotユーザーエージェントを除外してログを表示
grep -v "Googlebot" /var/log/nginx/access.log

アクセスログとエラーログを比較する

502または504応答のスパイクが見られた場合は、同じ時間枠のエラーログを確認します。アクセスログはクライアント側の結果を示します。エラーログは多くの場合、プロキシ側の理由を説明します。

grep "upstream" /var/log/nginx/error.log | tail -50
grep -E "connect\\(\\) failed|upstream timed out|no live upstreams" /var/log/nginx/error.log

例えば、アクセスログの502とエラーログのconnect() failed (111: Connection refused)は、接続を受け入れていないアップストリームサービスを示します。504とupstream timed outは、そのリクエストパスに対して遅いアップストリームまたは低すぎるタイムアウト設定を示します。

フィールド番号に注意する

多くの例では、Nginxのcombinedログ形式を前提としています。実際の本番設定では、$request_time、$upstream_response_time、$host、$request_id、または転送されたIPフィールドが追加されることがよくあります。深刻な調査でawk '{print $9}'コマンドを使用する前に、アクティブな形式を確認してください。

nginx -T 2>/dev/null | grep -A3 "log_format"

ログ形式がリクエストを引用符で囲んでいる場合、スペース区切りのawkフィールドは単純なチェックには機能しますが、ユーザーエージェントやリファラーはスペースを含むため、誤って解釈しやすくなります。より詳細な分析には、ログをパーサーに送信するか、専用のアクセスログでJSONエスケープなどの形式を使用します。

安全な取り扱い

Nginxアクセスログには、IPアドレスやリクエストパラメータなどの機密データが含まれています。分析のためにログを転送する場合は、安全なプロトコル（SCP/SFTP）を使用し、ログディレクトリへのアクセスを許可された担当者（通常はrootまたはsyslogユーザー）に制限してください。

# パーミッションを確認
ls -l /var/log/nginx/

実用的なワークフロー

症状から始めます。ユーザーがエラーを報告した場合は、ステータスコードをカウントし、失敗しているパスを特定します。サーバーが遅いと感じられる場合は、リクエストタイミングフィールドを探すか、次のインシデントの前にログ形式に追加します。特定のIPがノイズが多い場合は、上位のクライアントアドレスをカウントします。

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

次に、広い範囲から狭い範囲へと移行します：ステータスコード、パス、アップストリームエラー、時間枠、クライアントパターン。インシデントノートに使用した正確なコマンドを記録しておきます。これにより、次回のレビューがはるかに容易になり、ログが「どのように見えたか」という曖昧な記憶に頼るのではなく、別のエンジニアがあなたの調査結果を再現できるようになります。

Nginxログはプレーンテキストであり、適切なツールが手元にあれば強力です。ログ形式を理解し、コピーしたフィールド番号を盲信せず、何が壊れたかを判断する前にアクセスログのパターンとエラーログのメッセージを組み合わせてください。