【Nginx講座 第8回】ログ解析と運用監視。アクセスログのカスタム設定とDockerでの運用

「ログ」は、サーバーからの手紙です。読んでいますか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回にわたるNginx基本講座、ついに最終回です。

ここまで、高速で安全なWebサーバーを構築する技術を学んできました。
しかし、構築して終わりではありません。サーバーは24時間365日動き続ける生き物です。
「いつ誰が来たのか」「どこでエラーが起きているのか」「攻撃を受けていないか」。
これらを教えてくれる唯一の手がかりが「アクセスログ」と「エラーログ」です。

本記事では、Nginxのログフォーマットのカスタマイズ（LTSV/JSON）、リアルタイム解析ツール「GoAccess」の導入、ログローテーションの鉄則、そしてDockerコンテナによるNginx環境の構築までを徹底解説します。

---

第1章：デフォルトログの限界とカスタマイズ

Nginxのデフォルトのアクセスログ形式は combined と呼ばれるもので、Apache時代から使われている伝統的な形式です。

127.0.0.1 - - [20/Jan/2026:10:00:00 +0900] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0..."

これを見て、パッと「処理に何秒かかったか」や「どのバックエンドサーバーが応答したか」が分かりますか？
分かりませんよね。
現代のWeb運用では、「もっと詳細な情報を」「機械が読みやすい形式で」記録する必要があります。

log_format ディレクティブ

nginx.conf の http ブロック内で、独自のログ形式を定義できます。

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"';

これに、プロがよく追加する変数を加えてみましょう。

• $request_time: リクエストを受け取ってからレスポンスを返すまでの全時間（秒）。
• $upstream_response_time: バックエンド（APサーバー）が処理にかかった時間。
• $request_id: リクエストごとのユニークID（追跡調査に便利）。

---

第2章：最強のログ形式「JSON」を導入する

今のトレンドは、ログを JSON形式 で出力することです。
JSONなら、CloudWatch Logs、Datadog、Fluentdなどのログ収集ツールにそのまま食わせることができ、検索や集計が爆速になります。

設定例（nginx.conf）

http ブロックに以下を記述します。

log_format json_analytics escape=json '{'
    '"time": "$time_iso8601",'
    '"remote_addr": "$remote_addr",'
    '"host": "$host",'
    '"request": "$request",'
    '"status": $status,'
    '"body_bytes": $body_bytes_sent,'
    '"request_time": $request_time,'
    '"upstream_time": "$upstream_response_time",'
    '"ua": "$http_user_agent",'
    '"referer": "$http_referer",'
    '"req_id": "$request_id"'
'}';

そして、access_log ディレクティブでこの形式を指定します。

access_log /var/log/nginx/access.json.log json_analytics;

出力結果のイメージ:

{"time": "2026-01-20T10:00:00+09:00", "remote_addr": "192.168.1.1", "status": 200, "request_time": 0.032, ...}

これなら、「statusが500以上のログだけ抽出」や「request_timeが1秒以上の平均」といった集計が、プログラムで簡単にできるようになります。

---

第3章：ターミナルでグラフィカル解析「GoAccess」

「JSONログは機械にはいいけど、人間が見るには辛い…」
そんなあなたにおすすめなのが、ターミナル上で動くログ解析ツール「GoAccess（ゴーアクセス）」です。

インストール

# AlmaLinux / RHEL系
sudo dnf install epel-release
sudo dnf install goaccess

# Ubuntu / Debian系
sudo apt install goaccess

使い方

標準のログ形式（combined）なら、以下のコマンド一発で解析画面が立ち上がります。

goaccess /var/log/nginx/access.log --log-format=COMBINED

黒い画面に、ユニークビジター数、リクエストされたファイル、404エラーのリスト、OS・ブラウザの内訳などが、カラフルなグラフで表示されます。
HTMLレポートとして出力することも可能です。

goaccess /var/log/nginx/access.log --log-format=COMBINED -o /usr/share/nginx/html/report.html

これで http://あなたのサイト/report.html にアクセスすれば、綺麗な解析レポートが見られます（※Basic認証をかけて保護するのを忘れずに！）。

---

第4章：ログローテーションの鉄則

ログファイルは放置すると無限に肥大化し、最悪の場合ディスクを食いつぶしてサーバーを停止させます。
Linux標準の logrotate 機能が正しく設定されているか確認しましょう。

設定ファイルの確認

/etc/logrotate.d/nginx を確認します。

/var/log/nginx/*.log {
    create 0640 nginx root
    daily           # 毎日ローテーション
    rotate 10       # 10世代分保存
    missingok       # ログがなくてもエラーにしない
    notifempty      # 空ならローテーションしない
    compress        # 圧縮する（.gz）
    delaycompress   # 圧縮を1日遅らせる
    sharedscripts
    postrotate
        /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

特に重要なのが postrotate の部分です。
ログファイルをリネームした後、Nginxに対して USR1シグナル を送ることで、「新しいログファイルを作って書き込み始めてね」と通知しています。
これがないと、Nginxはリネームされた古いファイル（access.log.1）に永遠に書き込み続けてしまいます。

---

第5章：これからの常識「DockerでのNginx運用」

最後に、サーバー構築のモダンな手法である「Docker（コンテナ）」でのNginx運用について解説します。
OSに直接インストールするよりも、「環境の再現性」や「バージョンの切り替え」が圧倒的に楽になります。

公式イメージの選び方

Docker Hubには公式のNginxイメージがあります。
タグ（バージョン）の選び方がポイントです。

• nginx:latest: 最新版（Debianベース）。サイズは大きいがツールが揃っている。
• nginx:alpine: Alpine Linuxベース。サイズが極小（数十MB）でセキュリティリスクも低い。本番運用におすすめ。

Docker Composeでの構築例

docker-compose.yml を作成し、設定ファイルやコンテンツをマウントして起動します。

version: '3'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./html:/usr/share/nginx/html:ro  # コンテンツ
      - ./conf.d:/etc/nginx/conf.d:ro    # 設定ファイル
      - ./logs:/var/log/nginx            # ログ
    restart: always

コンテナ運用時の注意点

Dockerの流儀では、ログはファイルではなく「標準出力（stdout）と標準エラー出力（stderr）」に出すのが基本です。
公式イメージでは、デフォルトで以下のようなシンボリックリンクが貼られています。

• /var/log/nginx/access.log -> /dev/stdout
• /var/log/nginx/error.log -> /dev/stderr

これにより、docker logs web コマンドでログを確認できたり、AWS CloudWatch Logsなどにドライバ経由で直接転送できたりします。
ファイルに保存したい場合のみ、設定を変える必要があります。

---

第6章：講座総まとめ。エンジニアとしての次の一歩

全8回、本当にお疲れ様でした！
これまでの道のりを振り返ってみましょう。

1. 第1回: Nginxの構造を理解し、インストールしました。
2. 第2回: 設定ファイルを読み解き、バーチャルホストを立てました。
3. 第3回: 静的ファイルを正しく配信し、rootとaliasの違いを克服しました。
4. 第4回: アプリケーションサーバーへのリバースプロキシを構築しました。
5. 第5回: SSL/TLS化し、最新のHTTP/3に対応しました。
6. 第6回: セキュリティ設定で攻撃から身を守りました。
7. 第7回: パフォーマンスチューニングで爆速化を実現しました。
8. 第8回: ログを解析し、Dockerでの運用法を学びました。

あなたはもう、「なんとなくNginxを使っている人」ではありません。
「アーキテクチャを理解し、設計・構築・運用・チューニングまでできるエンジニア」です。

次に学ぶべきこと

Nginxの旅はここで一区切りですが、インフラエンジニアの道はまだまだ続きます。

• Kubernetes (K8s): Nginx Ingress Controllerを使って、クラスタへの入り口を管理する。
• Service Mesh (Istio/Linkerd): マイクロサービス間の通信を制御する（Nginx Service Meshもあります）。
• CDN (Cloudflare/CloudFront): Nginxの前段にキャッシュサーバーを置いて、さらに負荷を分散する。

この講座で得た知識は、これらの高度な技術を学ぶ上でも必ず役に立つ「揺るぎない土台」となります。
自信を持って、次のステップへ進んでください。

あなたの構築したサーバーが、世界中のユーザーに素晴らしい体験を届けることを願っています。
Good Luck, and Happy Hacking!