Linuxで問題が起きると「ログを確認してください」と言われます。正しいのですが、ログは一冊の答え合わせではありません。systemd、カーネル、認証、Webサーバー、アプリケーションなど、複数の場所に別々の視点で記録されます。
最初から全部読むのは現実的ではありません。先に事象を言葉にし、時刻と対象を絞るところから始めます。
出力先そのものの仕組みは当時のメモにあります（標準入力・標準出力・標準エラー出力ってなんぞ？ / リダイレクトとパイプ）。ここで扱うのは、その出力先が複数ある状況でどれから開くかです。
ログを見る前に三つ決める
最低限、次の三つを整理します。
- 何が起きたか：接続失敗、処理遅延、認証失敗、プロセス停止など
- いつ起きたか：最初の発生、最後の正常、再現した時刻
- どこで起きたか：対象ホスト、サービス、ユーザー、リクエスト
「動かない」だけでは検索範囲が広すぎます。「10時15分ごろから、このホストのnginxへ接続すると502になる」まで絞れると、見るログと時間帯が決まります。
systemd管理ならjournalctlから始める
対象サービスがsystemdで管理されているなら、ユニット単位で確認できます。
journalctl -u nginx --since "2026-07-21 10:00:00" --until "2026-07-21 10:30:00"
journalctl -u nginx -p warning --since today直近だけなら-n、追跡するなら-fを使えます。ただし、本番環境で流れ続けるログを眺めるだけでは必要な行を見失います。まず時間帯を区切り、その後に再現操作をしながら追跡するほうが整理しやすくなります。
アプリケーション固有のログを確認する
Webサーバーならアクセスログとエラーログ、データベースならエラーログやスロークエリログなど、ソフトウェア固有の記録があります。
確認する場所はディストリビューション、パッケージ、コンテナ構成、設定で変わります。「Linuxなら必ずこのパス」と決めつけず、実際に読み込まれている設定を確認します。
nginx -T
systemctl cat nginx設定を表示すると、ログの出力先だけでなく、起動オプションやinclude関係も追えます。覚えている標準パスより、現在動いている設定が正本です。
OS・カーネル側の異常を見る
プロセスが突然終了した、ディスクI/Oの異常が疑われる、ネットワークインターフェースが不安定といった場合は、カーネルの記録も確認します。
journalctl -k --since "1 hour ago"
dmesg -TOOM Killer、ファイルシステム、デバイス、NICなどの情報が見つかることがあります。ただしdmesgの表示権限や時刻表現は環境によって異なります。クラウド環境では、OS内だけでなくプラットフォーム側のイベントやメトリクスも合わせて確認します。
grepする前に前後関係を残す
キーワード検索は便利ですが、エラー行だけを抜き出すと原因と結果を逆に読むことがあります。
grep -n -C 5 "error" application.log前後の行を含め、同じリクエストID、プロセスID、ユーザー、接続元などで関連づけます。複数システムをまたぐ場合、相関IDや一貫した時刻があると調査が大幅に楽になります。
「error」という文字がないエラーもあります。HTTP 500、終了コード、timeout、killed、deniedなど、事象に応じて探す語を変えます。逆に、ログレベルがerrorでも利用者影響のない記録はあります。文字列の強さではなく、発生時刻と挙動の一致で判断します。
ログを証拠として保存する
ローテーションや再起動でログが消える可能性があります。必要な範囲を、取得条件とともに保存します。
- 取得したホストとサービス
- タイムゾーン
- 取得コマンド
- 対象期間
- 調査時点の設定やバージョン
秘密情報、トークン、個人情報が含まれる可能性もあるため、そのままチャットやIssueへ貼り付けないよう注意します。ログは便利な証拠ですが、機密情報まで親切に記録していることがあります。
今回の要点
- 最初に事象、時刻、対象を絞る
- systemdのサービスはユニット単位で確認する
- 標準パスを決めつけず、実際の設定から出力先を調べる
- OS異常が疑われる場合はカーネルログも見る
- エラー行だけでなく前後関係と識別子を追う
- 取得条件を残し、秘密情報を除いて共有する
ログをたくさん読んだことより、必要な記録へ短く到達できたことのほうが大切です。全部読む作戦は、ログより先に人間の集中力がローテーションします。