ログは、それぞれの担当者の日記

ログは、プログラムが「いつ・何があったか」を書き残した記録です。1つのリクエストは、いくつもの担当者（層）を通ってから返ってきます。

ブラウザ → Webサーバ → アプリ → データベース

ログは、それぞれの担当者が、自分の見たことだけを書いています。だから、どの層で何が起きたかによって、見るべきログが変わります。

3種類のログ

ログ	書いてあること	分かること
Webサーバのログ（アクセスログ・エラーログ）	届いたリクエスト、返した状態コード（200・404・500など）	誰がどこへアクセスし、どう返したか
アプリのログ	処理の中身、エラーの種類と場所	アプリの中で何が起きたか
システムのログ	サービスの起動・停止、メモリ不足、定期処理	サーバそのものに何が起きたか

状態コードは、200 が成功、404 が「そのページは無い」、500 が「サーバ側で失敗した」です。障害のときは、まず 500 を探します。

置き場所の見当をつける

置き場所はサーバの作り方で違いますが、Linux でよくある場所は次のとおりです。

• Webサーバ（nginx の例）… /var/log/nginx/access.log と error.log
• アプリ … アプリのフォルダの中の log/ など。フレームワークの設定で決まる
• システム … 最近の Linux では journalctl というコマンドでまとめて読む

journalctl は、たとえば次のように使います（オプションは版によって違うことがあるので、man journalctl で確かめてください）。

journalctl -u サービス名 --since "1 hour ago"   # そのサービスの直近1時間
journalctl -u サービス名 -f                      # 新しい行を流し続ける
journalctl -p err --since today                  # 今日のエラー以上だけ

実例：アプリのログに、何も残っていなかった

naminori に、ボットが壊れた形式のデータを送ってきて、サーバが 500 を返したことがあります。ところが、アプリのログにはそのリクエストの行すらありませんでした。エラーが、アプリが記録を始めるより手前の部品で起きていたからです。

このときは、エラー追跡ツール（第5回）には届いていたので気づけました。あるログに無いことは、起きていない証拠にはなりません。 層を1つ外側（Webサーバのログ）や、別の記録も見ます。

古いログは、圧縮されて、やがて消える

ログは放っておくとディスクを埋めるので、多くのサーバでは古いものを日ごとに圧縮（.gz）し、一定の期間が過ぎたら消す設定にしています（ログのローテーション）。

圧縮されたログには、普通の grep が効きません。zgrep を使います（手元で確認）。

grep -c ERROR app.log.1.gz    # → 0（圧縮されたまま探すので見つからない）
zgrep -c ERROR app.log.1.gz   # → 4

ここで後から困ること

• 結果を捨てる設定にすると、失敗の証拠が最初から残らない。naminori の定期処理が6週間止まっていた件（第1回）がこれでした
• 残す期間が短いと、後で比べられない。naminori でも、エラーの対策をした後で件数を比べようとしたら、対策前のログがもう消えていて比べられなかったことがあります

時刻の「ものさし」をそろえる

ログやツールによって、時刻が協定世界時（UTC）のこともあれば、日本時間（JST、UTC より9時間進んでいる）のこともあります。違うものさしのまま並べると、原因と結果が逆に見えます。直すときは、たとえばこうします（手元で確認）。

# Linux（GNU の date）
TZ=Asia/Tokyo date -d '2026-10-24T01:13:05Z' '+%F %T %Z'
# → 2026-10-24 10:13:05 JST

macOS の date は -d が使えず、書き方が違います（date -j -f '%Y-%m-%dT%H:%M:%S%z' '2026-10-24T01:13:05+0000' など）。

• ログは層ごとに、自分の見たことだけを書く
• Webサーバ・アプリ・システムのログの違い
• あるログに無くても、起きていないとは限らない
• ローテーションと zgrep
• 結果を捨てる・すぐ消すと後から困る
• UTC と日本時間をそろえる