log ファイルの読み方 - システムログ解析入門
この記事でできるようになること
- /var/log 配下から調査対象のログファイルを選べる
- tail・less・grep を目的に応じて使い分けられる
- syslog 形式の 1 行から発生源と時刻を読み取れる
前提知識（先に読むと理解しやすい記事）
この記事で解決できること
/var/log/配下から、症状に応じた調査対象のログファイルを選べる。tail・less・grepを目的に応じて使い分けられる。syslog・auth.log・kern.logなど代表的なログの役割の違いが分かる。- syslog 形式の 1 行から、発生源（プロセス名・PID）と時刻を読み取れる。
- 障害対応で使う実践的な調査パターンが身につく。
結論（ログ調査の基本型）
- まず
ls /var/log/で対象ファイルを特定する tail -n 100で末尾から確認、リアルタイム監視はtail -fgrepでエラーキーワードを絞り込むlessで前後の文脈をたどる
この記事で扱うコマンドはすべて「読むだけ」です
ls / tail / less / cat / grep はファイルの中身を表示するだけで、内容は書き換えない。
本番サーバでも安全に実行できる。
ただしログファイルの削除や切り詰めは別である。危険な操作は本文の警告で明示する。
/var/log ディレクトリとは何か
結論: Linux のシステムログは
/var/log/に集約され、障害対応はここを見ることから始まる。
Linux のシステムログはほぼすべて /var/log/ 以下に集約されている。カーネル・認証・アプリケーションが書き込んだ記録がここにあり、障害対応の出発点になる。
先に用語を整理する。
| 用語 | 一行の意味 | 混同されやすい言い方 |
|---|---|---|
| ログ | プログラムが「いつ何をしたか」を書き残した記録 | 「ログファイル」「履歴」も同じものを指す |
| デーモン | 画面を持たず裏で動き続けるプログラム | 「常駐プロセス」「サービス」とも呼ばれる |
| syslog | ログを 1 か所へ集める仕組みと、その形式の呼び名 | 同名のファイル /var/log/syslog とは別物 |
| rsyslog | 現在の Ubuntu で syslog の役割を担うデーモン | syslog-ng という別実装もある |
| PID | 動作中のプロセスに OS が振る番号 | 「プロセスID」も同義 |
| ログローテーション | ログが肥大化しないよう自動で分割・圧縮する仕組み | 退避後は .1、さらに古い世代は .2.gz で残る |
ls /var/log/
auth.log dpkg.log kern.log syslog ubuntu-advantage.log boot.log faillog lastlog ufw.log wtmp
/var/log/ に書き込む主体は syslog デーモン（rsyslog / syslog-ng）と各アプリケーション自身の2種類がある。
代表的なログファイルとその役割とは
結論: 用途別にファイルが分かれているため、症状から見るべきファイルを先に決めると早い。
/var/log/ 配下には用途別にファイルが分かれており、調査対象を素早く絞り込むためにそれぞれの役割を把握しておく必要がある。
| ファイル | 内容 | 調査用途 |
|---|---|---|
syslog |
システム全般のメッセージ | 原因不明の障害 |
auth.log |
認証・sudo・SSH | 不正ログイン・sudo 失敗 |
kern.log |
カーネルメッセージ | ハードウェア障害・OOM |
dpkg.log |
パッケージ管理履歴 | インストール・更新の追跡 |
ufw.log |
UFW ファイアウォール | 遮断された通信 |
boot.log |
起動時ログ | 起動失敗の原因特定 |
.1 や .gz が付いたファイルは、ローテーションで退避された過去分である。数日前の事象を追うときはこちらも対象になる。
ls /var/log/syslog*
/var/log/syslog /var/log/syslog.1 /var/log/syslog.2.gz
圧縮済みファイルは展開せずに zgrep / zless で読める。
zgrep -i "error" /var/log/syslog.2.gz
Ubuntu 20.04 以降は syslog が存在しない構成もある。その場合は journalctl でシステムログを確認する。
ログを読むための基本コマンドとは
結論: 末尾は
tail、前後の文脈はless、短いファイルだけcatと使い分けるのが基本。
ログファイルの閲覧には cat / less / tail の3つを状況に応じて使い分けるのが基本だ。
tail — 末尾から読む
# 末尾50行を表示 tail -n 50 /var/log/syslog # リアルタイムで追跡（Ctrl+C で終了） tail -f /var/log/syslog
-f（follow）は障害発生中にログの流れをリアルタイムで監視するときに使う。
-f はプロンプトが戻らないまま出力を待ち続ける。終了するには Ctrl+C を押す。読んでいるだけなので、途中で止めてもログやサービスには影響しない。
less — スクロールして読む
less /var/log/auth.log
less 内での主要操作:
G：末尾へジャンプg：先頭へジャンプ/キーワード：前方検索n：次のマッチへq：終了
cat — 全体を一気に流す（短いファイル向き）
cat /var/log/boot.log
ログが長いファイルに cat を使うと大量出力になるため、通常は less か tail を優先する。
ログファイルを消して容量を空けようとしない
ディスクが逼迫すると rm /var/log/syslog で消したくなるが、これは 2 つの理由で危険である。
- 書き込み中のプロセスがファイルを掴んだままなので、削除しても容量は解放されない。
- 削除したログは復元できず、障害の証拠が失われる。
容量を空けたい場合は、まず何が使っているかを確認する。次の 2 コマンドはどちらも表示するだけで、何も削除しない。
du -sh /var/log/* | sort -hr | head sudo lsof +L1
その上で、恒久対策は logrotate の設定で行う。手動で切り詰める必要がある場合も rm ではなく truncate -s 0 <file>（内容だけ空にする）を使い、実行前に対象ファイル名を必ず確認する。
grep でログをフィルタリングする方法とは
結論: 長大なログは
grepで絞り、-iや-A/-Bを足して文脈ごと確認する。
長大なログから目的の行を絞り込むには grep を使う。コマンド単体よりも tail や less との組み合わせが実務では多い。
エラー行を抽出する
grep -i "error" /var/log/syslog
-i で大文字小文字を区別しないマッチになる。
複数キーワードで絞り込む
grep -E "error|warn|failed" /var/log/syslog
-E は |（または）を使える拡張正規表現モードの指定である。
リアルタイムで grep する
tail -f /var/log/syslog | grep "error"
特定の日付だけ確認する
grep "May 31" /var/log/auth.log
前後の文脈も表示する
grep -A 5 -B 5 "Failed password" /var/log/auth.log
-A 5 はマッチした行の後5行、-B 5 は前5行を表示する。
sudo なしで読めないログファイルがある。Permission denied が出たら sudo less /var/log/kern.log のように実行する。
ログのフォーマットを読み解く方法
結論: syslog 形式は固定の並びなので、時刻・ホスト・プロセス・PID の順に読めばよい。
syslog 形式のログは固定したフォーマットで書かれており、パターンを知っていると素早く情報を抽出できる。
May 31 10:23:45 myserver sshd[12345]: Failed password for root from 192.168.1.100 port 22 ssh2
| フィールド | 値 | 意味 |
|---|---|---|
| タイムスタンプ | May 31 10:23:45 |
ログが記録された日時 |
| ホスト名 | myserver |
メッセージを発したホスト |
| プロセス名 | sshd |
ログを書き込んだプロセス |
| PID | [12345] |
プロセスID（追跡に使う） |
| メッセージ | Failed password... |
実際のログ内容 |
PID が分かれば、同じプロセスが出した行だけを追える。
grep "sshd\[12345\]" /var/log/auth.log
ログのタイムスタンプはサーバのローカルタイムで記録される。タイムゾーンが UTC の場合、表示と実際の時刻がずれていることに注意する。
現在の設定は timedatectl で確認できる（これも表示するだけのコマンドである）。
よくあるログ調査パターンとは
結論: 症状ごとに見るべきファイルと検索語はほぼ決まっており、型を覚えておくと調査が速い。
障害対応でよく使う実践的なパターンを一覧にまとめる。
| 症状 | 見るファイル | 検索する語 |
|---|---|---|
| SSH でログインできない | auth.log |
Failed password |
| 誰が何をしたか追いたい | auth.log |
COMMAND |
| サーバが不安定・突然落ちる | kern.log |
error / oops / panic |
| 更新後に動かなくなった | dpkg.log |
install |
| 起動に失敗した | boot.log |
（全体を less で読む） |
SSH ログイン失敗を確認する
sudo grep "Failed password" /var/log/auth.log | tail -20
sudo の使用履歴を確認する
sudo grep "sudo" /var/log/auth.log | grep "COMMAND"
カーネルエラーを確認する
sudo grep -iE "error|oops|panic" /var/log/kern.log | tail -30
パッケージのインストール履歴を確認する
grep " install " /var/log/dpkg.log
直近の起動時エラーを確認する
sudo less /var/log/boot.log
journalctl との使い分け方とは
結論: systemd 管理下のログは
journalctl、ファイルに直接書くログは/var/log/を見る。
Ubuntu 16.04 以降、systemd が採用されてから journalctl が主要なログ確認手段となった。/var/log/ のファイルと journalctl は並存する。
| 場面 | 使うべきツール |
|---|---|
| systemd サービスのログ | journalctl -u nginx |
| カーネルメッセージ | journalctl -k |
| 起動時のログ | journalctl -b |
| 伝統的なファイルに書かれたアプリのログ | tail -f /var/log/アプリ.log |
/var/log/auth.log の内容 |
どちらでも可 |
# journalctl でリアルタイム追跡 journalctl -f # 特定サービスのログを tail する journalctl -u nginx -f
journalctl は systemd の journal に蓄積されたログを読む。/var/log/ のテキストファイルとは別の仕組みだが、rsyslog の設定によっては両方に書き込まれることもある。
調査完了チェックリスト
結論: 時刻・発生源・再現性の 3 点を押さえられていれば、ログ調査は次の工程へ進んでよい。
- [ ] 事象が起きた時刻を特定し、その前後のログを読んだ
- [ ] 見たファイルが症状に対応している（認証なら
auth.log等） - [ ] ローテーション済みファイル（
.1/.gz）も必要なら確認した - [ ] タイムスタンプのタイムゾーンを確認した
- [ ] ログを削除・切り詰めせずに調査を終えた