journalctlコマンドでsystemdのログを確認する方法｜日時指定・ユニット絞り込み・リアルタイム監視も

ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ ＞ journalctlコマンドでsystemdのログを確認する方法｜日時指定・ユニット絞り込み・リアルタイム監視も

この記事の監修：宮崎智広（Linux教育歴15年以上・受講者3,100名超）
「サーバーが突然再起動した原因をログから調べたいけど、どのファイルを確認すればいいかわからない」
「journalctlで大量のログが出てきて、目的の情報にたどり着けない」
systemd環境のLinuxでは、従来の /var/log/ 配下のテキストファイルに加えて、journald（ジャーナルデーモン）がシステム全体のログをバイナリ形式で一元管理しています。このログを閲覧・検索するのが journalctl コマンドです。

この記事では、journalctl コマンド の実践的な使い方を解説します。
日時指定やユニット別の絞り込み、優先度フィルタ、リアルタイム監視（-f）、ログの永続化設定まで、障害調査で必要な操作をすべてカバーします。動作確認環境は RHEL 9.4 / Rocky Linux 9.4 です。

この記事のポイント

・journalctl でsystemdが管理する全ログを一括確認できる
・-u と --since/--until で目的のログだけを素早く絞り込める
・-p で優先度（err/warning等）を指定してエラーだけ抽出できる
・ログの永続化設定をしないと再起動でログが消える

「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／ 詳細はこちら

journalctlとは？従来のログ管理との違い

journalctl は、systemdのジャーナル（systemd-journald）が収集したログを閲覧するコマンドです。カーネルメッセージ、サービスの標準出力・標準エラー出力、syslog経由のメッセージなど、システム上のあらゆるログが一箇所に集約されています。

従来の /var/log/messages や /var/log/secure は、rsyslogが受け取ったテキストファイルベースのログです。journaldはこれとは別のバイナリ形式で保存しており、構造化されたメタデータ（PID、ユニット名、優先度など）を使って高速に検索できるのが強みです。

・従来のログ（rsyslog）：テキストファイル（/var/log/messages等）。grepで検索する。ファイルが分散している
・journald：バイナリ形式（/var/log/journal/等）。journalctlで検索する。全ログが一元管理されている

RHEL 9 / Rocky Linux 9 では、rsyslog と journald の両方が動作しています。journald が受け取ったログの一部が rsyslog に転送され、従来のテキストファイルにも書き出される仕組みです。つまり、journalctl を使えばすべてのログにアクセスでき、/var/log/ 配下のファイルはその一部という関係になっています。

※journalctlを覚えたからといって、/var/log配下のログが不要になるわけではありません。rsyslogとjournaldの両方を使えるようにしておきましょう。

journalctlの基本的な使い方

まずは基本的なログの閲覧方法を押さえましょう。

1. 全ログを表示する

引数なしで実行すると、古いログから順にすべて表示されます。ページャー（less）で表示されるため、スペースキーで進み、qで終了です。


$ sudo journalctl
-- Journal begins at Tue 2026-03-01 00:00:01 JST, ends at Tue 2026-04-15 10:23:45 JST. --
 3月 01 00:00:01 sv01.linuxmaster.jp systemd[1]: Starting Daily Cleanup of Temporary Directories...
 3月 01 00:00:01 sv01.linuxmaster.jp systemd[1]: Started Daily Cleanup of Temporary Directories.
...
ログ量が膨大な場合、全件表示は実用的ではありません。以降で紹介する絞り込みオプションを組み合わせて使うのが基本です。

2. 最新のログから表示する（-e）

-e オプションを付けると、ログの末尾（最新）から表示が始まります。障害調査で最初に実行するコマンドとして覚えておくと便利です。


$ sudo journalctl -e

3. 直近のログを指定行数だけ表示する（-n）

-n で表示行数を指定できます。デフォルトは10行です。


# 直近20行を表示する
$ sudo journalctl -n 20
 4月 15 10:20:01 sv01 CROND[12345]: (root) CMD (/usr/lib64/sa/sa1 1 1)
 4月 15 10:22:33 sv01 sshd[12400]: Accepted publickey for testuser from 192.168.1.xxx port 52341 ssh2
 4月 15 10:23:45 sv01 sudo[12410]: testuser : TTY=pts/0 ; PWD=/home/testuser ; USER=root ; COMMAND=/usr/bin/systemctl status httpd
...

# sshdの最新50行を表示
$ sudo journalctl -u sshd -n 50
「最近のログだけサッと確認したい」ときに便利です。-f と似ていますが、-n は表示して終了、-f は監視し続けるという違いがあります。

4. リアルタイムでログを監視する（-f）

-f オプションは tail -f と同じ動作で、新しいログが出力されるたびにリアルタイムで画面に表示されます。


# 全ログをリアルタイム監視
$ sudo journalctl -f

# 特定のユニット（httpd）のログだけをリアルタイム監視
$ sudo journalctl -f -u httpd

# 複数サービスを同時にリアルタイム監視
$ sudo journalctl -f -u httpd -u php-fpm
サービスの起動テストやネットワーク接続のデバッグ中に、別ターミナルで journalctl -f を流しておくのは現場の定番です。Ctrl+C で監視を終了します。

5. ページャーを使わずに出力する（--no-pager）

パイプやリダイレクトと組み合わせる場合は --no-pager を付けます。


# grepで特定の文字列を検索する
$ sudo journalctl --no-pager | grep "Failed password"

# ファイルに出力する
$ sudo journalctl --no-pager > /tmp/full-journal.log

日時を指定してログを絞り込む（--since / --until）

障害調査では「いつ発生したか」がわかっている場合がほとんどです。--since と --until で時間範囲を指定すると、該当時刻のログだけを効率よく確認できます。

1. 日時を指定する


# 2026年4月15日の9:00以降のログを表示
$ sudo journalctl --since "2026-04-15 09:00:00"

# 2026年4月14日の18:00から4月15日の06:00までのログを表示
$ sudo journalctl --since "2026-04-14 18:00:00" --until "2026-04-15 06:00:00"
日付のフォーマットは YYYY-MM-DD HH:MM:SS です。時刻を省略すると 00:00:00 として扱われます。

2. 相対時間で指定する

「1時間前から」「昨日から」といった相対指定も使えます。


# 1時間前からのログを表示
$ sudo journalctl --since "1 hour ago"

# 昨日のログを表示
$ sudo journalctl --since yesterday --until today

# 30分前からのログを表示
$ sudo journalctl --since "30 min ago"
「障害が起きたのは30分ほど前」という曖昧な状況でも、すぐに該当範囲のログを取り出せます。

ユニット（サービス）でログを絞り込む（-u）

-u オプションで systemd のユニット名（サービス名）を指定すると、そのサービスに関するログだけが表示されます。

1. 特定サービスのログを確認する


# httpdのログを確認する
$ sudo journalctl -u httpd
 4月 15 09:00:01 sv01 systemd[1]: Starting The Apache HTTP Server...
 4月 15 09:00:02 sv01 httpd[1234]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name
 4月 15 09:00:02 sv01 systemd[1]: Started The Apache HTTP Server.

# sshdのログを確認する
$ sudo journalctl -u sshd

# cronのログを確認する
$ sudo journalctl -u crond
サービス名は .service を省略できます。httpd.service と httpd は同じ結果です。

【注意】サービス名が分からない場合は、systemctl list-units --type=service で一覧を確認してください。

2. 複数のユニットを同時に確認する

-u を複数回指定すると、該当するすべてのユニットのログがまとめて表示されます。


# httpdとmariadbのログを同時に確認する
$ sudo journalctl -u httpd -u mariadb
WebアプリケーションのエラーがWebサーバー側かDB側かを切り分けるとき、両方のログを時系列で並べて確認できるので便利です。

3. 日時指定と組み合わせる

ユニット指定と日時指定を組み合わせることで、ピンポイントでログを取り出せます。


# 昨日18:00以降のhttpdのログを確認する
$ sudo journalctl -u httpd --since "2026-04-14 18:00:00"

# 直近1時間のsshdログだけを確認する
$ sudo journalctl -u sshd --since "1 hour ago"

優先度（重要度）でログを絞り込む（-p）

-p オプションでログの優先度（syslogの重要度レベル）を指定できます。エラーだけを抽出したいときに強力です。

優先度レベルは以下の8段階です。数字が小さいほど重大なメッセージです。

レベル 名前 意味
0 emerg システム使用不能
1 alert 即時対応が必要
2 crit 致命的な状態
3 err エラー
4 warning 警告
5 notice 通常だが重要
6 info 情報
7 debug デバッグ

1. エラー以上のログだけを表示する


# err（レベル3）以上のログを表示する（emerg, alert, crit, err）
$ sudo journalctl -p err
 4月 14 23:15:22 sv01 httpd[5678]: [core:error] [pid 5678] AH00135: HTTP/1.1 400 Bad Request
 4月 15 02:30:01 sv01 kernel: EXT4-fs error (device sda1): __ext4_find_entry: reading directory lblock 0

# warningも含めて表示する
$ sudo journalctl -p warning
まず -p err でエラーを確認し、手がかりがなければ -p warning に範囲を広げる、という流れが障害調査の定石です。

2. 今回の起動以降のエラーだけを確認する

-b オプションと組み合わせると、現在の起動セッション内のエラーだけを抽出できます。


# 今回のブート以降のエラーだけを表示
$ sudo journalctl -b -p err

ブート（起動）単位でログを確認する（-b）

-b オプションを使うと、起動（ブート）単位でログを絞り込めます。サーバーが突然再起動した原因を調べるとき、前回起動時のログが決定的な手がかりになります。

1. 現在の起動以降のログを表示する


# 現在のブートセッションのログを表示する
$ sudo journalctl -b

2. 前回起動時のログを確認する


# 前回（1つ前の）ブートのログを表示する
$ sudo journalctl -b -1

# 2つ前のブートのログを表示する
$ sudo journalctl -b -2
サーバーが突然再起動した場合、journalctl -b -1 で前回起動セッションの末尾を確認すると、OOM Killer やカーネルパニックの痕跡が見つかることがあります。

3. 起動一覧を表示する


$ journalctl --list-boots
-2 abc123def456... Sat 2026-04-12 03:00:01 JST—Sat 2026-04-13 02:59:59 JST
-1 789012abc345... Sun 2026-04-13 03:00:01 JST—Mon 2026-04-14 02:59:59 JST
 0 def678ghi901... Mon 2026-04-14 03:00:01 JST—Tue 2026-04-15 10:30:00 JST
0 が現在の起動、-1 が前回の起動を表しています。ログの永続化が有効でないと、前回起動分のログは表示されません（永続化の設定は後述）。

特定のプロセスやカーネルのログを確認する

ユニット名以外にも、PIDやコマンド名、カーネルメッセージでフィルタできます。

1. カーネルメッセージだけを表示する（-k）


# dmesgと同等のカーネルメッセージを表示する
$ sudo journalctl -k

# 今回起動時のカーネルメッセージだけ
$ sudo journalctl -k -b
dmesg コマンドと同じ情報を表示しますが、journalctl なら日時指定やブート指定との組み合わせが可能です。

2. PIDを指定してログを絞り込む


# PID 12345 のプロセスのログだけを表示する
$ sudo journalctl _PID=12345
プロセスのPIDは systemctl status サービス名 や ps aux | grep プロセス名 で確認できます。

3. コマンド名やユーザーIDで絞り込む


# sudoコマンドの実行ログだけを表示する
$ sudo journalctl _COMM=sudo

# sshd関連のログだけを表示する
$ sudo journalctl _COMM=sshd

# 特定ユーザー（UID 1000）のログだけを表示する
$ sudo journalctl _UID=1000
_COMM はログを出力したプロセスの実行ファイル名、_UID はユーザーID、_GID はグループIDを指定するフィールドです。ユニット名が不明なときに便利です。

出力フォーマットを変更する（-o）

デフォルトの表示形式では情報が足りない場合、-o で出力フォーマットを変更できます。

1. JSON形式で出力する


# JSON形式で出力する（スクリプトでの加工に最適）
$ sudo journalctl -u httpd -n 1 -o json-pretty
{
    "__CURSOR" : "s=abc123...",
    "_HOSTNAME" : "sv01.linuxmaster.jp",
    "_COMM" : "httpd",
    "MESSAGE" : "AH00558: httpd: Could not reliably determine the server's fully qualified domain name",
    "PRIORITY" : "5",
    ...
}

2. 詳細表示（verbose）


# メタデータをすべて表示する
$ sudo journalctl -u sshd -n 1 -o verbose
Tue 2026-04-15 10:22:33.123456 JST [s=abc123...]
    _TRANSPORT=syslog
    _UID=0
    _GID=0
    _COMM=sshd
    _PID=12400
    MESSAGE=Accepted publickey for testuser from 192.168.1.xxx port 52341 ssh2
    PRIORITY=6
    SYSLOG_FACILITY=10
    ...
-o verbose で表示されるフィールド名（_COMM、_PID、_UID など）は、そのまま絞り込み条件として使えます。

3. その他の出力形式


# 短縮表示（デフォルト）
$ sudo journalctl -o short

# ISO 8601形式のタイムスタンプで出力（スクリプトの解析に便利）
$ sudo journalctl -o short-iso
ログをスクリプトで自動解析する場合は -o json、目視で全フィールドを確認したい場合は -o verbose が便利です。JSON出力は jq コマンドと組み合わせることで、特定のフィールドだけを抽出する高度なフィルタリングが可能です。

ジャーナルのディスク使用量を確認・制御する

ジャーナルはバイナリ形式でディスクに保存されるため、放置するとディスクを圧迫します。使用量の確認と制限の設定方法を押さえておきましょう。

1. 現在のディスク使用量を確認する


$ sudo journalctl --disk-usage
Archived and active journals take up 256.0M in the file system.

2. 古いログを手動で削除する


# 2日以上前のログを削除する
$ sudo journalctl --vacuum-time=2d

# ジャーナルの合計サイズを500MBに制限する
$ sudo journalctl --vacuum-size=500M

# 直近3回分の起動ログだけ残す
$ sudo journalctl --vacuum-files=3
本番サーバーでは、cronやsystemd timerで定期的に --vacuum-time を実行する運用がよくあります。

3. 設定ファイルで上限を恒久的に設定する

/etc/systemd/journald.conf で最大サイズや保持期間を設定できます。


$ sudo vi /etc/systemd/journald.conf

[Journal]
# ジャーナルの最大サイズを1GBに制限
SystemMaxUse=1G
# 個々のジャーナルファイルの最大サイズ
SystemMaxFileSize=100M
# ログの最大保持期間
MaxRetentionSec=3month

# 設定を反映する
$ sudo systemctl restart systemd-journald

ログを永続化する設定（再起動後もログを保持する）

RHEL 9 のデフォルト設定では、ジャーナルのログは /run/log/journal/（tmpfs上）に保存されます。つまり、サーバーを再起動するとログが消えてしまいます。

障害調査で前回起動時のログを確認するには、ログの永続化設定が必須です。

1. 現在の保存先を確認する

まず、現在のジャーナルがどこに保存されているかを確認しましょう。


# ジャーナルの保存先を確認
$ journalctl --header | grep "File path"

# /run/log/journal/ → 揮発性（再起動で消える）
# /var/log/journal/  → 永続化済み
/run/log/journal/ と表示された場合は、以下の手順で永続化を設定してください。

2. 永続化ディレクトリを作成する


# 永続化ディレクトリを作成する
$ sudo mkdir -p /var/log/journal

# 適切なパーミッションを設定する
$ sudo systemd-tmpfiles --create --prefix /var/log/journal

# systemd-journaldを再起動して永続化を有効にする
$ sudo systemctl restart systemd-journald

# ログが永続化されていることを確認する
$ ls -la /var/log/journal/
drwxr-sr-x. 3 root systemd-journal 60  4月 15 10:30 .
drwxr-xr-x. 9 root root          4096  4月 15 10:30 ..
drwxr-sr-x+ 2 root systemd-journal 4096  4月 15 10:30 abc123def456789...
/var/log/journal/ ディレクトリが存在するだけで、journald は自動的に永続化モードに切り替わります。

3. journald.confで明示的に設定する


$ sudo vi /etc/systemd/journald.conf

[Journal]
# persistent（永続化）を明示的に指定
Storage=persistent
Storage の設定値は以下のとおりです。

・auto（デフォルト）：/var/log/journal/ が存在すれば永続化、なければ揮発（/run/log/journal/）
・persistent：常に /var/log/journal/ に保存する（ディレクトリがなければ自動作成）
・volatile：常に /run/log/journal/（メモリ上）に保存する
・none：ログを保存しない

本番サーバーでは Storage=persistent を明示的に設定しておくのが安全です。

【注意】永続化を有効にすると、ログがディスクに蓄積され続けます。必ず前述の SystemMaxUse や MaxRetentionSec を設定し、ディスク容量を圧迫しないようにしてください。特に / パーティションの容量が小さいサーバーでは、ログがディスクフルの原因になることがあります。

「journalctl: No entries」が出た時の対処法

journalctl を実行して何も表示されない場合、いくつかの原因が考えられます。

1. 権限不足

一般ユーザーで journalctl を実行すると、自分のプロセスのログしか表示されません。システム全体のログを見るには sudo を付けるか、ユーザーを systemd-journal グループに追加します。


# systemd-journalグループに追加する（再ログインが必要）
$ sudo usermod -aG systemd-journal testuser

2. ログが永続化されていない

再起動後に journalctl -b -1 で前回起動時のログを見ようとして「No entries」になる場合は、ログの永続化が設定されていません。前述の手順で永続化を有効にしてください。

3. 時刻指定の書式ミス

--since や --until の日時フォーマットが正しくないと、該当するログが見つからず空の結果になることがあります。YYYY-MM-DD HH:MM:SS のフォーマットか、yesterday、"1 hour ago" などの相対表現を使いましょう。

ジャーナルの容量が肥大化した時の対処

ジャーナルが数GBに膨れ上がってディスク容量を圧迫している場合は、以下の手順で対処します。


# 1. 現在の使用量を確認
$ sudo journalctl --disk-usage

# 2. 古いログを削除して500MBまで縮小
$ sudo journalctl --vacuum-size=500M

# 3. 削除後の使用量を確認
$ sudo journalctl --disk-usage

# 4. 再発防止のため、journald.confに上限を設定
$ sudo vi /etc/systemd/journald.conf
# SystemMaxUse=1G を追記

# 5. 設定を反映
$ sudo systemctl restart systemd-journald
再発防止には、journald.confで SystemMaxUse を設定しておくことが重要です。サーバーのディスク容量に応じて、500M～2G程度を目安に設定してください。

本記事のまとめ

journalctl コマンドの基本操作からフィルタリング、ログの永続化設定まで解説しました。

やりたいこと コマンド
全ログを表示する sudo journalctl
最新のログから表示する sudo journalctl -e
直近N行を表示する sudo journalctl -n 20
リアルタイムで監視する sudo journalctl -f
特定サービスのログを確認する sudo journalctl -u httpd
複数サービスのログを同時確認する sudo journalctl -u httpd -u mariadb
日時範囲を指定する sudo journalctl --since "2026-04-15 09:00"
エラー以上のログだけ表示する sudo journalctl -p err
現在の起動以降のログを表示する sudo journalctl -b
前回起動時のログを確認する sudo journalctl -b -1
カーネルメッセージを表示する sudo journalctl -k
コマンド名で絞り込む sudo journalctl _COMM=sudo
ディスク使用量を確認する sudo journalctl --disk-usage
古いログを削除する（日数指定） sudo journalctl --vacuum-time=2d
古いログを削除する（容量指定） sudo journalctl --vacuum-size=500M
起動ログの回数で削除する sudo journalctl --vacuum-files=3

journalctl はシステム全体のログを一元的に検索できる強力なツールです。-u（ユニット）、--since（日時）、-p（優先度）の3つの絞り込みオプションを覚えるだけで、障害調査のスピードが格段に上がります。

ログ管理の基本を押さえたら、ログファイルのローテーション設定についても確認しておきましょう。「logrotateでログファイルを自動ローテーションする方法」では、/var/log/ 配下のテキストログの肥大化を防ぐ設定を解説しています。カーネルメッセージの詳しい読み方は「dmesgコマンドでカーネルメッセージを確認する方法」もあわせてご覧ください。

ログの読み方はわかった。次はサーバー構築全体の流れを押さえませんか？

journalctl でログを読むスキルは、サーバー管理の基本中の基本です。しかし、障害を未然に防ぐには構築段階からの設計が欠かせません。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒） ＞＞ 図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。


暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

宮崎 智広

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

関連記事

  • この記事の属するカテゴリ：へ戻る
図解60pのLinux無料マニュアル
登録10秒／自動返信でDL
無料で受け取る