💡

Linux ログを調査するときはどこを見ればいいのか

2024/04/15に公開

Linux

想定している状況

通常は、コマンド実行時に問題が発生したとき、コマンドのエラーを見て調査を進めるかと思います。しかし、以下のように、コマンドのエラーが漠然としていて問題が特定できないときがあります。

# postgres psql -c "insert into persons(name) values ('comfortzone nakamura');" -d dt
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

psql: エラー: サーバーへのソケット "/var/run/postgresql/.s.PGSQL.5432" の接続に失敗しました: ファイルやディレクトリが存在しません
サーバーはローカルで実行され、そのソケットへの接続を受け付けていますか？

上の例は、Postgresが何らかの理由で起動できず、Postgresに接続できないというエラーが起きています。この場合、Postgresに接続できないというエラーを見ても、Postgresが起動できていない理由に当たりを付けることができません。

今回は、このような「うまくいかない原因がわからない」場合に、どこのログを探しに行けばいいのかご紹介します。

※以下内容は、systemd環境(AmazonLinux, CentOS7以降, RHEL7以降等)を前提としています。

まず見るところ

/var/log/messages

システム関連のメッセージのログ。何かあったらまずここを見ます。rsyslogdというデーモンが出力します。

出力形式

[日時] [ホスト名] [出力元]: [内容]

出力例

Apr 14 14:26:04 localhost systemd[1]: Starting OpenSSH server daemon...

テキスト形式で保存されているので、tail、less、grepが使えます。(lessの場合は、Shift + Gでログの終端までジャンプすると便利です。)

必要な情報が見つからない場合

/var/log/配下には、messages以外にも複数のログが保存されています。apacheなど、自分で追加したアプリケーションのログが/var/log配下に保存されることもあります。

参考:RHEL9の/var/log配下にデフォルトで存在するログファイル

/var/log
├─ README -> ../../usr/share/doc/systemd/README.logs
├─ audit
├─ btmp
├─ choose_repo.log
├─ chrony
├─ cloud-init-output.log
├─ cloud-init.log
├─ cron
├─ dnf.librepo.log
├─ dnf.log
├─ dnf.rpm.log
├─ hawkey.log
├─ insights-client
├─ kdump.log
├─ lastlog
├─ maillog
├─ messages
├─ private
├─ rhsm
│  ├─ rhsm.log
│  └─ rhsmcertd.log
├─ secure
├─ spooler
├─ sssd
├─ tallylog
├─ tuned
│  └─ tuned.log
└─ wtmp

wtmp, btmp, lastlog, tallylogはバイナリ形式、それ以外のログはテキスト形式で保存されています。

/var/log/messagesに探しているログがない場合、当たりがついていれば他の/var/log/配下のログを見てもいいと思いますが、当たりがついていなければ、次項目「次に見るところ」で全てのログを探す方が手っ取り早いと思います。

参考:他の /var/log/ 配下のログ

/var/log/audit.log
- パーミッション関連のログが出力される。監査デーモンauditdによって収集されるログ。
/var/log/secure
- セキュリティ関連のログが出力される。
/var/log/dmesg
- Linux起動~syslogデーモン起動まで(つまり /var/log/messages に出力される前)のログが出力される。

次に見るところ

journalログ

/var/log配下のログは、すべてのログが出力されているわけではなく、内容が絞られています。
もしも/var/log配下のログに必要な情報がない場合は、journalctlコマンドですべてのログを見ることができます。

# journalctl

出力形式は/var/log/messagesと同じなので割愛します。

よく使うオプション

ユニット名で絞り込み

特定のユニットに関するログだけを見たい場合は、-uオプションでユニット名を指定すると便利です。

# journalctl -u <ユニット名>

緊急度で絞り込み

一定以上のプライオリティ(緊急度)のログだけを見たい場合は、-pオプションでプライオリティを指定すると、指定したプライオリティ以上のログが出力されます。プライオリティはいくつかありますが、トラブルシューティングの際はerrを指定しておけばいいと思います。

# journalctl -p <プライオリティ>

備考：それぞれのログの仕組み

journaldがすべてのイベントをバイナリ形式で保存していて、rsyslogdがログを分類しテキストとして保存しなおしています。

以下、備忘録も兼ねて表に整理しました。

比較項目	systemd-journald	rsyslog
デーモン	journald	rsyslogd
ファイル形式	バイナリ	テキストorバイナリ
保存場所	/run/log/journal※1	/var/log配下
ログの確認方法	`journalctl`コマンド	テキストファイル閲覧コマンド (`cat`、`less`など)
再起動しても保存されるか	×※1	〇
設定ファイルのパス	/etc/systeld/journald.conf	/etc/rsyslog.conf

※1 手動で/var/log/journalファイルを作成することで、ログの保存先が揮発性の/run/配下から/var/log/journalに変わり、再起動してもログが失われないようになります。

ちなみに、systemctl status <サービス名>で下の方に出力されるサービスのログは、実はjournalctlの内容です。