HOME > 技術ドキュメント > Webシステムのログ設計とトラブル調査入門

Webシステムのログ設計とトラブル調査入門

執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・運用改善）

「ログを見ればわかる」と言えるシステムは、設計段階からログの目的・内容・保存場所を決めています。 「ログが何もない」「ある時刻に何が起きたかわからない」という状態は、 トラブル調査を困難にし、障害の再発防止を妨げます。
本記事では、Webシステムのログ設計の考え方と、よくあるトラブルの調査アプローチを整理します。

1. ログ設計の 3 つの問い

ログを設計する際に「何を」「どこに」「どれだけ」の 3 点を明確にします。

問い	考え方	実務上のポイント
何を記録するか	トラブル調査・セキュリティ監査・ビジネス分析に必要な情報	個人情報・パスワードはログに書かない
どこに書くか	ファイル・syslog・外部ログ集約サービス	ディスクがいっぱいになるとサービス停止する
どれだけ残すか	保持期間・ローテーション設定	法的要件（個人情報保護法等）で保持期間が定まる場合がある

2. アクセスログ設計（Nginx / Apache）

アクセスログはトラブル調査・セキュリティ監査・アクセス分析の基礎です。 デフォルトのフォーマットでも十分な場合がありますが、以下の要素を含めると後の調査が楽になります。

• 含めるべき情報：日時（ミリ秒精度）・クライアント IP・HTTP メソッド・URL・レスポンスコード・レスポンスサイズ・処理時間（$request_time）・ User-Agent・Referer
• X-Forwarded-For の記録：リバースプロキシ経由の場合は実際のクライアント IP が X-Forwarded-For に入るため、これもログに含める。
• JSON フォーマット：ログ集約ツール（Loki・Elasticsearch 等）との連携を考える場合、JSON 形式でアクセスログを出力すると解析が容易になります。

個人情報の取り扱い注意：URL パラメータにユーザー ID・メールアドレスが含まれる場合、 アクセスログに個人情報が記録されます。ログの保管・アクセス権限を適切に管理してください。

3. アプリケーションログ設計

• ログレベルを使い分ける：DEBUG（開発時のみ）・INFO（通常の処理フロー）・WARN（想定内だが注意が必要）・ERROR（処理失敗）・FATAL（サービス継続不能）を明確に使い分ける。本番環境は INFO 以上を記録するのが一般的。
• 構造化ログ：ログを JSON 形式で出力することで、ログ集約ツールでのフィルタリング・集計が容易になります。
• リクエスト ID（トレース ID）：1 つのリクエストに関連するログを追跡できるよう、リクエストごとにユニークな ID を付与して全ログに含める。
• 書いてはいけないもの：パスワード・クレジットカード番号・セッショントークン・個人情報はログに書かない。

4. エラーログの収集と優先度

• Nginx エラーログ：/var/log/nginx/error.log に 502 Bad Gateway・upstream エラーなどが記録されます。バックエンドアプリの問題調査の起点になります。
• PHP エラーログ：php.ini の error_log 設定でファイルに出力。本番では display_errors = Off・log_errors = On が必須です。
• systemd / journald：journalctl -u nginx -f でサービスのリアルタイムログを確認できます。
• エラーアラートの設定：ERROR レベル以上のログが発生した場合に Slack・メールへアラートを送る仕組みを設ける。

5. ログ集約入門（複数サーバー・コンテナ環境）

サーバーが複数台ある場合や Docker 環境では、ログを中央に集約すると調査が効率的になります。

• Grafana Loki：Prometheus と相性が良いログ集約ツール。Promtail エージェントで各サーバーのログを収集し、Grafana で可視化。比較的軽量で中小規模に向いています。
• Elasticsearch + Kibana（ELK）：大規模・高機能だが、リソース消費が大きく運用コストも高い。数百台規模以上の環境に向いています。
• クラウドのログサービス：AWS CloudWatch Logs・Azure Monitor Logs・OCI Logging などのマネージドサービスを使うと運用コストを下げられます。

6. SSL/TLS エラーのトラブルシューティング

SSL 関連のエラーは種類が多く、エラーメッセージから原因を特定することが重要です。

エラー	主な原因と対処法
ERR_CERT_DATE_INVALID	証明書の有効期限切れ。証明書を更新する
ERR_CERT_AUTHORITY_INVALID	中間証明書が未設定。証明書チェーンを正しく設定する
ERR_SSL_VERSION_OR_CIPHER_MISMATCH	クライアントとサーバーの TLS バージョン/暗号スイートが不一致。TLS 1.2 以上を設定する
ERR_CERT_COMMON_NAME_INVALID	証明書のドメインが一致しない。正しいドメイン用の証明書を使用する
502 Bad Gateway（Nginx）	バックエンドへの接続失敗。バックエンドのプロセス死活・ポート番号・タイムアウト設定を確認する

証明書の現在の状態は SSL証明書インストールチェッカー で確認できます。
SSL証明書 FAQ /  SSL証明書の購入はこちら

7. よくあるトラブルパターンと調査手順

• 突然の 502 Bad Gateway：① Nginx エラーログを確認 → ② バックエンドのプロセスが起動しているか確認（systemctl status appname）→ ③ バックエンドのアプリログでエラーを確認 → ④ DB 接続・メモリ不足を確認
• 特定ページが遅い：① アクセスログの $request_time で遅いリクエストを特定 → ② アプリログでその時刻の処理を確認 → ③ DB のスロークエリログを確認
• ディスクが満杯：① df -h でディスク使用量確認 → ② du -sh /var/log/* でログサイズ確認 → ③ 大きなログをローテーション・削除 → ④ logrotate 設定を見直す
• 認証失敗の急増：① アクセスログで同一 IP からの POST /login を確認 → ② Fail2ban のログを確認 → ③ 必要に応じて IP をブロック

8. ログローテーション設定

ログを放置するとディスクが枯渇します。logrotate を使ったローテーション設定を必ず行います。

• /etc/logrotate.d/ にアプリ用の設定ファイルを作成する
• 日次または週次でローテーション、古いファイルは圧縮（compress）して保持期間（rotate 30 など）を設定する
• Nginx は postrotate で nginx -s reopen を実行し、新しいファイルに書き込むよう指示する

ログ設計チェックリスト

• □ アクセスログに処理時間（$request_time）を含めている
• □ アプリケーションログのログレベルを適切に設定している
• □ 本番環境で PHP の display_errors を Off にしている
• □ ログにパスワード・個人情報を書いていない
• □ logrotate（またはログドライバー設定）でローテーションを設定している
• □ エラーログの監視・アラートを設定している
• □ SSL 証明書エラーの調査手順を把握している

← 技術ドキュメント一覧へ戻る