こんにちは、かつコーチです。
今回はLinuxのログの見方を解説します。
サーバーで何かトラブルが起きたとき、まず見るべきなのがログです。
「エラーは出ているけど、どこに記録があるのか分からない」という状態から抜け出せるように、/var/logとjournalctlの使い方を順番に整理します。
検証環境はUbuntu 26.04 LTSです。
Linuxのログとは？
ログとは何か
ログとは、システムやアプリケーションが「いつ・何をしたか」を時系列で記録したファイルのことです。
サーバーが再起動した、SSH接続が失敗した、サービスが落ちた、といった出来事はすべてログに残ります。
障害対応では「ログを見れば原因が分かる」ケースがほとんどなので、まずログの場所を知ることが第一歩です。
なぜログの確認が必要なのか
初心者のうちは、エラーが起きても画面に表示されたメッセージだけで判断しがちです。
しかし実際のサーバー運用では、画面には出ない裏側のエラーがログにだけ記録されていることがよくあります。
たとえばWebサーバーが起動しない、SSHで接続できない、といったトラブルは、ログを確認しないと原因の見当すらつきません。
/var/logの構成と見方
主要なログファイルの場所
Ubuntuでは、システムのログの多くが/var/logディレクトリに集約されています。
$ ls /var/log
alternatives.log auth.log boot.log dpkg.log journal/ kern.log syslog ufw.log
代表的なファイルの役割は以下の通りです。
| ファイル | 内容 |
|---|---|
/var/log/syslog | システム全般のログ（Ubuntu系の中心的なログ） |
/var/log/auth.log | ログイン・認証・sudo実行の記録 |
/var/log/kern.log | カーネル関連のログ |
/var/log/dpkg.log | パッケージのインストール・削除履歴 |
/var/log/nginx/、/var/log/apache2/ | 各ミドルウェアのアクセスログ・エラーログ |
catやtailで中身を確認する
これらはただのテキストファイルなので、L07で紹介したcat・less・tailがそのまま使えます。
# 最新のシステムログをリアルタイムで追いかける
$ sudo tail -f /var/log/syslog
# 認証まわりのログだけを確認する
$ sudo less /var/log/auth.log
tail -fは新しく追記された行をリアルタイムで表示し続けるオプションで、障害発生中の様子を観察するときによく使います。
grepと組み合わせて絞り込む
ログは行数が多いので、L08のgrepと組み合わせると効率的です。
# authログの中から「Failed」を含む行だけを抽出
$ sudo grep "Failed" /var/log/auth.log
Sep 1 09:12:03 web01 sshd[2831]: Failed password for invalid user admin from 203.0.113.10 port 51422 ssh2
このように、SSHへの不正ログイン試行などもauth.logから確認できます。
journalctlの使い方
journalctlとは
journalctlは、systemdが管理するjournal（ジャーナル）と呼ばれるログを閲覧するコマンドです。
Ubuntuではsystemdが標準のサービス管理の仕組みになっているため、/var/logのテキストログに加えて、journalctlでの確認が欠かせません。
L17で解説したsystemdのサービス管理と合わせて理解しておくと、トラブルシューティングの幅が広がります。
基本のコマンド
# 全ログを新しい順に表示
$ journalctl -r
# 直近のログをリアルタイムで追いかける
$ journalctl -f
# 起動時から今までのログをまとめて見る
$ journalctl -b
サービス単位でログを絞り込む
特定のサービスのログだけを見たいときは-uオプションを使います。
# nginxサービスのログだけを表示
$ journalctl -u nginx.service
# 直近30分のnginxログを表示
$ journalctl -u nginx.service --since "30 minutes ago"
--sinceと--untilを組み合わせれば、時間帯を指定してログを絞り込むこともできます。
$ journalctl --since "2026-09-01 09:00:00" --until "2026-09-01 10:00:00"
ログレベルで絞り込む
-pオプションでログレベル（優先度）を指定すると、エラー以上の重要な行だけに絞れます。
# エラー以上のログだけを表示
$ journalctl -p err
よくあるつまずきポイント・エラー対処
つまずき1：journalctlの結果が「No entries」になる
私が実際に検証環境でハマったのがこのケースです。
サービスのログを見ようとして-uを実行したところ、次のように返ってきました。
❌ Before
$ journalctl -u myapp.service
-- No entries --
原因はサービス名のタイプミスでした。myapp.serviceではなく実際にはmyapp-worker.serviceという名前で登録されていたのです。systemctl list-unitsでサービス名を確認してから指定すると解決しました。
✅ After
$ systemctl list-units --type=service | grep myapp
myapp-worker.service loaded active running MyApp Worker
$ journalctl -u myapp-worker.service
Sep 1 10:03:12 web01 myapp-worker[4021]: Started worker process
サービス名は自己流の推測ではなく、必ずsystemctl list-unitsで確認するクセをつけると無駄な調査時間を減らせます。
つまずき2：journalctlのログが再起動で消えている
デフォルト設定ではjournalのログがメモリ上（揮発性）にしか保存されず、再起動すると過去のログが消えてしまうことがあります。
❌ Before
$ journalctl -b -1
-- No entries --
これはログの永続化設定がされていないためです。/var/log/journalディレクトリを作成して永続化を有効にすると、再起動をまたいでログが残るようになります。
✅ After
$ sudo mkdir -p /var/log/journal
$ sudo systemctl restart systemd-journald
$ journalctl -b -1
Sep 1 08:00:01 web01 systemd[1]: Reached target Multi-User System.
サーバー運用では、障害の前日にどんなログが出ていたかを確認したい場面が多いので、本番環境では永続化を有効にしておくのがおすすめです。
応用・一歩先の使い方
ログのローテーション（logrotate）を知っておく
/var/logのファイルは放置すると際限なく肥大化するため、Ubuntuではlogrotateという仕組みで自動的に古いログを圧縮・削除しています。
設定は/etc/logrotate.d/以下にサービスごとのファイルとして置かれています。
$ cat /etc/logrotate.d/nginx
ディスク容量が急に圧迫されたときは、まずlogrotateの設定と/var/log配下の肥大化したファイルを疑うとよいでしょう。
journalctlのディスク使用量を管理する
journalのログもディスクを消費するため、上限を決めておくと安心です。
# journalのディスク使用量を確認
$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
# 使用量を200Mまでに制限
$ sudo journalctl --vacuum-size=200M
まとめ
この記事のポイント
/var/logにはシステムやミドルウェアのテキストログが集約されているsyslog・auth.log・kern.logなど、目的別にファイルが分かれている- systemd環境では
journalctlがログ確認の主役になる -uでサービス単位、--since/--untilで時間帯、-pでログレベルを絞り込める- journalのログはデフォルトで消える場合があるため、永続化設定を確認しておく
次に読むべき記事
- L17「systemdの基本：サービスを管理する仕組み」でサービス管理の全体像を押さえる
- L23「よくあるLinuxエラーとトラブルシューティング」で具体的なエラー対処のパターンを学ぶ
- L08「grepでテキストを検索する基本」でログの絞り込みをさらに深める
タグ: Linux, 中級者向け, トラブルシューティング, systemd