Linux 講座 / Linux ログで障害原因を絞り込む

ログで障害の原因を探すには、失敗した時刻と対象サービスをまず特定し、同じ起動・時間帯の関連記録を集めて再現結果と照合する必要があります。ERRORの1行や最後のメッセージだけで原因を確定せず、前後の文脈や他のリソースの状態も確認してください。

サービス状態の基本的な意味については、systemd入門を参照してください。この記事では、時刻・状態・ログを結び付けて仮説を絞り込み、障害再現と復旧実習で同じ手順を制御された環境に適用します。

システム設定実習の基準は Ubuntu 26.04 LTS と Rocky Linux 9 系の一般インストール VM です。コンテナ・WSL・別のリリースでは、サービスやパッケージの構成が異なる場合があります。仮想マシン実習環境の作成で、コンソールの復旧とバージョン確認を最初に準備してください。

症状・時刻・変更履歴をまず記録する

「サーバが不調」ではなく、「クライアントAで14:03からHTTPSリクエストが502を返している」のように記録します。サーバ・クライアントの時刻とタイムゾーンを比較し、最後に正常動作した時刻、デプロイ・設定変更・再起動の時点を記録します。原因仮説と観察事実を分けて書くと、エラーメッセージに引きずられて軽率に変更することを減らせます。

date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-boots

前回のブートが一覧にない場合、その記録が保存されなかったか、すでに整理されている可能性があります。ジャーナルの揮発性・永続保存設定と保持制限を確認する必要があり、記録がないという理由で問題がなかったと判断することはありません。権限が不足している場合、一部の項目しか表示されないこともあります。

ユニット・ブート・時間範囲でジャーナルを絞り込む

次のNAME.serviceは実際の問題サービス名に置き換えます。まずstatusで概要を確認し、同じブートのログを読み取った後、必要な時間範囲で絞ります。全ログを長いターミナルに流すより、狭い範囲を保存して比較する方が効率的です。

systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager

-uはユニット、-bはブート、-kはカーネルメッセージです。-p warningは警告およびそれ以上の優先度を表示しますが、アプリケーションが優先度を誤って記録したりstdoutのみにメッセージを残すと、重要な手がかりが欠落することがあります。優先度で絞り込んだ後は、同じ時間のフィルターなしログも比較してください。

loggerで自分が作ったイベントを探す

次にサービス設定を変更せずに、実習用タグのメッセージを2つ記録します。loggerとジャーナル収集が接続された一般的なLinux環境が必要です。制限付きコンテナやsyslogソケットがない環境では記録が表示されない場合があるので、その違いを先に確認します。

tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pager

同じタグで繰り返すと、指定時間内の過去の実習メッセージも表示されます。2つのメッセージと記録時刻を確認し、-p warningを追加したときに一般の優先度メッセージが除外されるか比較します。sample-warningは意図的に作った実習用の記録であり、実際の障害ではありません。権限のために読めない場合は、許可された管理者権限で確認し、記録を見るために運用ログを消去したり収集サービスを再起動したりしないでください。

メッセージに合わせて他の証拠と照合する

ログの「ディスク不足」はログファイルがあるディスクではなく、アプリケーションが記録しようとしたパスの問題である可能性があります。「権限拒否」もファイル自体だけでなく、上位ディレクトリの探索権限やポリシーの問題である可能性があります。エラーが指摘した正確な対象で確認し、root実行や777権限で症状を隠さないでください。

ファイルログと保持ポリシーの確認

アプリケーションはジャーナル以外に /var/log 以下のファイルや中央のログ収集基盤に記録することがあります。実際の設定でパスを確認した後、tail -n 100、grep などで必要な部分を読みます。ローテートされたファイルや圧縮された過去の記録も確認し、タイムスタンプ形式・タイムゾーンを合わせます。journalctl --disk-usage はジャーナル保存領域を示します。

調査中にログ整理・vacuumを先に実行すると原因の手がかりを失う可能性があります。必要な区間をアクセス制限されたパスに保存し、共有する場合はトークン・クッキー・個人情報・内部アドレスを隠してください。原因・適用変更・同条件の再試験・残る不確実性を記録した後、保持ポリシーに従って資料を管理してください。

公式ドキュメント

• journalctl フィルタとストレージの確認
• ジャーナル保存・保持設定
• logger を提供する util-linux