AlmaLinux 9 ログ管理 journalctl rsyslog

AlmaLinux 9 のサーバーで障害が発生したとき、最初に調べるのはログです。RHEL 9 系では systemd-journald（バイナリジャーナル）と rsyslog（テキストログ）の 2 つのログ基盤が共存しており、それぞれの役割と使い分けを理解しておく必要があります。本記事では journalctl によるフィルタ操作、rsyslog のルーティングとリモート転送、logrotate によるローテーション設定、そして障害調査の実践的なフローまでを、企業のサーバー運用チームで使えるリファレンスとしてまとめています。

コマンド早見表

やりたいこと	コマンド
今回ブートのログ全体	journalctl -b
特定サービスのログ	journalctl -u sshd.service
エラー以上を抽出	journalctl -p err -b
時間範囲で絞り込み	journalctl –since “2026-03-25 09:00” –until “2026-03-25 10:00”
リアルタイム監視	journalctl -f
前回ブートのログ	journalctl -b -1
カーネルメッセージ	journalctl -k
ジャーナルのディスク使用量	journalctl –disk-usage
古いジャーナルを容量で削除	journalctl –vacuum-size=500M
rsyslog 設定の文法チェック	rsyslogd -N 1
テストログ送信	logger -p local0.info “テストメッセージ”
logrotate ドライラン	logrotate -d /etc/logrotate.conf
認証ログの確認	tail -f /var/log/secure
ログイン履歴	last
失敗ログイン履歴	lastb

前提条件

項目	値
OS	AlmaLinux 9.6
systemd	252（journald）
rsyslog	8.2412.0
ジャーナル永続化	設定済み（初期設定編）
実行ユーザー	root 権限

1. RHEL 9 系のログアーキテクチャ全体像

AlmaLinux 9 では、ログは以下の流れで処理されます。

カーネル / サービス / アプリケーション
        │
        ▼
  systemd-journald（バイナリジャーナル）
        │
        ▼
     rsyslog（imjournal モジュールで journald から受信）
        │
        ▼
  /var/log/*.log（テキストファイル）
        │
        ▼
    logrotate（定期ローテーション）

systemd-journald と rsyslog はそれぞれ異なる役割を担っています。

項目	systemd-journald	rsyslog
データ形式	バイナリ	テキスト
保存場所	/var/log/journal/	/var/log/*.log
検索方法	journalctl（フィールド検索が高速）	grep / awk（テキスト処理）
リモート転送	単体では不可	TCP/UDP で転送可能
構造化ログ	対応（フィールド付き）	非対応（行ベース）

なぜ両方存在するのかというと、journald は構造化データによる高速検索を担い、rsyslog はテキスト形式での互換性とリモート転送を担うためです。企業環境では、ローカルでの障害調査には journalctl を使い、中央ログサーバーへの集約には rsyslog を使うという運用が一般的です。

2. ファシリティとプライオリティ

syslog の世界では、ログメッセージは「ファシリティ（発生源の分類）」と「プライオリティ（重要度）」の 2 つの属性で分類されます。rsyslog のルーティングルールはこの組み合わせで動作するため、ログ管理の基礎知識として押さえておく必要があります。

ファシリティ一覧

ファシリティ	説明
kern	カーネルメッセージ
user	ユーザープロセス
mail	メールシステム
daemon	デーモン（個別ファシリティを持たないもの）
auth	認証・セキュリティ（login など）
authpriv	認証・セキュリティ（sudo, sshd など非公開）
cron	cron / at
local0〜local7	自社アプリケーションやネットワーク機器で自由に使用

プライオリティ一覧

レベル	名前	説明
0	emerg	システムが使用不能
1	alert	即座に対処が必要
2	crit	致命的な状態
3	err	エラー
4	warning	警告
5	notice	注意すべき正常な状態
6	info	情報
7	debug	デバッグ情報

プライオリティは数値が小さいほど重要度が高くなります。rsyslog のルールで *.err と書くと、err（3）以上のすべてのメッセージ（err, crit, alert, emerg）が対象になります。

logger コマンドによるテスト

logger コマンドを使うと、任意のファシリティ・プライオリティでテストメッセージを送信できます。rsyslog のルーティング設定を確認する際に使います。

実行コマンド：

# logger -p local0.info "テストメッセージ from local0"

実行結果の確認：

# journalctl -t root --since "1 minute ago"

ファシリティを local0、プライオリティを info に指定してメッセージを送信しています。/var/log/messages にも記録されるため、tail /var/log/messages でも確認できます。

3. journalctl の実践的フィルタ

journalctl はバイナリジャーナルを検索するコマンドです。フィルタオプションを組み合わせることで、大量のログから必要な情報を素早く抽出できます。

時間指定で絞り込む

障害の発生時刻が分かっている場合、時間範囲で絞り込むのが最も効率的です。

実行コマンド（今日のログのみ）：

# journalctl --since today

実行コマンド（日時範囲を指定）：

# journalctl --since "2026-03-25 09:00:00" --until "2026-03-25 10:00:00"

実行コマンド（相対時間で指定）：

# journalctl --since "1 hour ago"

--since と --until は "YYYY-MM-DD HH:MM:SS" 形式のほか、today、yesterday、"1 hour ago" などの相対指定にも対応しています。

ユニット（サービス）で絞り込む

特定のサービスに関するログだけを確認する場合は -u オプションを使います。

実行コマンド：

# journalctl -u sshd.service -n 5

実行結果：

3月 25 00:17:50 alma-main sshd[7632]: Accepted publickey for developer from 192.168.1.100 port 50497 ssh2: ED25519 SHA256:W2DBHTgDj1dxfL1A8U9rxnmhPn9hN6Ru5sAbR9Ydgcc
3月 25 00:17:50 alma-main sshd[7632]: pam_unix(sshd:session): session opened for user developer(uid=1000) by developer(uid=0)

複数のサービスを同時に確認する場合は、-u を複数回指定します。

実行コマンド：

# journalctl -u httpd -u php-fpm --since "1 hour ago"

Web サーバーとアプリケーション実行環境のログを並行して確認できるため、リクエスト処理のエラー調査に有効です。

プライオリティで絞り込む

エラーレベル以上のログだけを確認したい場合は -p オプションを使います。

実行コマンド：

# journalctl -p err -b

実行結果：

3月 24 14:28:58 alma-main kernel: Warning: Unmaintained driver is detected: ip_set

範囲指定も可能です。warning から err までを対象にする場合は以下のように書きます。

実行コマンド：

# journalctl -p warning..err -b

ブート単位で絞り込む

再起動前のログを確認したい場合は -b オプションにオフセットを指定します。

実行コマンド（現在のブート）：

# journalctl -b 0

実行コマンド（前回のブート）：

# journalctl -b -1

記録されているブートの一覧を確認するには --list-boots を使います。

実行コマンド：

# journalctl --list-boots

実行結果：

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 a04060e274b64106ab4b2d55ab20daaa Tue 2026-03-24 14:28:51 JST Wed 2026-03-25 00:18:19 JST

IDX が 0 のみ表示されている場合、前回ブート以前のジャーナルは保存されていません。ジャーナルの永続化が未設定の可能性があるため、第 4 章の設定を確認してください。

カーネルメッセージの確認

ハードウェア障害やドライバーの問題を調査する際は、カーネルメッセージに絞り込みます。

実行コマンド：

# journalctl -k

-k は --dmesg と同じ意味で、カーネルリングバッファのメッセージのみを表示します。ディスク I/O エラーや OOM Killer の発動はこのログに記録されます。

リアルタイム追跡

サービスの動作をリアルタイムで監視するには -f オプションを使います。tail -f のジャーナル版です。

実行コマンド（全ログをリアルタイム監視）：

# journalctl -f

実行コマンド（httpd のログのみリアルタイム監視）：

# journalctl -f -u httpd.service

Ctrl+C で監視を終了します。障害の再現試験を行いながらログを確認する場面で使います。

出力形式の変更

-o オプションで出力形式を変更できます。

オプション	用途
-o short-iso	ISO 8601 形式のタイムスタンプ（他チームへの報告に便利）
-o short-precise	マイクロ秒精度のタイムスタンプ（タイミング調査）
-o json-pretty	JSON 形式で全フィールドを表示（スクリプト処理向き）
-o verbose	全フィールドを人間が読みやすい形式で表示

実行コマンド：

# journalctl -u sshd -n 1 -o json-pretty

JSON 出力では _PID、_UID、_COMM など、通常の出力では見えないフィールドが含まれます。これらのフィールドはフィルタ条件としても使用できます。

フィールド指定による検索

特定のプロセス ID やユーザー ID で絞り込む場合は、フィールドを直接指定します。

実行コマンド（プロセス ID で絞り込み）：

# journalctl _PID=1234

実行コマンド（コマンド名で絞り込み）：

# journalctl _COMM=sudo

sudo の実行履歴を確認できるため、誰がいつ root 権限を使用したかの監査に利用できます。

ディスク使用量の確認

ジャーナルが消費しているディスク容量を確認します。

実行コマンド：

# journalctl --disk-usage

実行結果：

Archived and active journals take up 8.0M in the file system.

この値が想定以上に大きい場合は、第 4 章で解説する容量管理の設定を見直してください。

4. ジャーナルの永続化と容量管理

ジャーナルの永続化は初期設定編（第 2 回）で設定済みのため、ここでは容量管理の設定に焦点を当てます。ジャーナルの容量を制限しないと、ディスク使用量が際限なく増え続ける可能性があります。

journald.conf の主要パラメータ

設定ファイルは /etc/systemd/journald.conf です。デフォルトではほぼすべてのパラメータがコメントアウトされています。

パラメータ	説明	推奨値の例
Storage	ジャーナルの保存方法。persistent で /var/log/journal/ に永続化	persistent
SystemMaxUse	ジャーナルが使用する最大ディスク容量	500M
SystemKeepFree	ジャーナル以外のために確保する空き容量	1G
SystemMaxFileSize	個々のジャーナルファイルの最大サイズ	50M
MaxRetentionSec	ジャーナルの最大保持期間	1month
Compress	ジャーナルデータを圧縮するかどうか	yes
RateLimitIntervalSec	レート制限の評価間隔	30s
RateLimitBurst	評価間隔内に許容するメッセージ数	10000

容量管理の設定例

サーバーのディスク容量に応じて、ジャーナルの上限を設定します。以下は /var パーティションが 20GB の場合の例です。

設定ファイル（/etc/systemd/journald.conf の [Journal] セクション）：

[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=1G
SystemMaxFileSize=50M
MaxRetentionSec=1month
Compress=yes

設定変更後は journald を再起動します。

実行コマンド：

# systemctl restart systemd-journald

手動でのジャーナル削除

ディスク逼迫時に古いジャーナルを手動で削除するには、以下のコマンドを使います。

実行コマンド（容量指定で削除）：

# journalctl --vacuum-size=500M

500MB を超える古いジャーナルファイルを削除します。

実行コマンド（期間指定で削除）：

# journalctl --vacuum-time=3months

3 か月より古いジャーナルファイルを削除します。

ジャーナルの整合性検証

ジャーナルファイルが破損していないか検証するには --verify を使います。

実行コマンド：

# journalctl --verify

エラーが報告された場合、該当のジャーナルファイルは破損しています。破損ファイルを削除して journald を再起動することで復旧します。

5. rsyslog の基本設定

rsyslog は、journald から受け取ったログメッセージをテキストファイルに書き出すデーモンです。設定ファイルは /etc/rsyslog.conf で、4 つのセクションで構成されています。

rsyslog.conf の構造

セクション	内容
モジュール	入力モジュール（imjournal など）の読み込み
グローバル設定	作業ディレクトリ、ファイル権限など
ルール	ファシリティ.プライオリティ → 出力先のルーティング定義
インクルード	/etc/rsyslog.d/*.conf の読み込み

imjournal モジュール

AlmaLinux 9 の rsyslog は、imjournal モジュールを通じて systemd-journald からログを受け取ります。/etc/rsyslog.conf の先頭付近で以下のように読み込まれています。

module(load="imuxsock"    # provides support for local system logging (e.g. via logger command)
       SysSock.Use="off") # Turn off message reception via local log socket;
module(load="imjournal"             # provides access to the systemd journal
       StateFile="imjournal.state") # File to store the position in the journal

デフォルトのルーティングルール

/etc/rsyslog.conf に定義されているデフォルトのルールは以下の通りです。

ルール	出力先	説明
*.info;mail.none;authpriv.none;cron.none	/var/log/messages	info 以上（mail, authpriv, cron を除く）
authpriv.*	/var/log/secure	認証関連ログ（sudo, sshd など）
mail.*	/var/log/maillog	メールシステムのログ
cron.*	/var/log/cron	cron ジョブのログ
*.emerg	:omusrmsg:*	全ユーザーの端末にメッセージを表示

/var/log/messages には、mail・authpriv・cron を除く info 以上のログが集約されます。障害調査で最初に確認するファイルです。

カスタムルールの追加

自社アプリケーション用にログの出力先を分けたい場合は、/etc/rsyslog.d/ ディレクトリにカスタム設定ファイルを作成します。rsyslog.conf 本体を編集するよりも管理しやすくなります。

設定ファイル（/etc/rsyslog.d/myapp.conf）：

local0.*    /var/log/myapp.log

ファシリティ local0 のすべてのプライオリティのメッセージを /var/log/myapp.log に出力します。アプリケーション側で local0 ファシリティを使ってログを送信する設定が必要です。

設定の文法チェックと反映

設定を変更したら、反映前に文法チェックを行います。文法エラーがあるまま rsyslog を再起動すると、ログの記録が停止する可能性があります。

実行コマンド：

# rsyslogd -N 1

エラーが報告されなければ、rsyslog を再起動して設定を反映します。

実行コマンド：

# systemctl restart rsyslog

6. rsyslog によるリモートログ転送

企業環境では、各サーバーのログを中央のログサーバーに集約するのが一般的です。rsyslog はログの送信（クライアント）と受信（サーバー）の両方に対応しています。

UDP と TCP の違い

プロトコル	rsyslog 記法	特徴
UDP	@（アットマーク 1 つ）	軽量だがログの欠損リスクがある
TCP	@@（アットマーク 2 つ）	到達保証があり、企業環境では推奨

送信側（クライアント）の設定

ログを転送するサーバー側に設定ファイルを作成します。

設定ファイル（/etc/rsyslog.d/remote.conf）：

*.* @@syslog.example.corp:514

すべてのファシリティ・プライオリティのログを TCP でログサーバー（syslog.example.corp）のポート 514 に転送します。

特定のファシリティだけを転送する場合は、以下のように記述します。

authpriv.* @@syslog.example.corp:514

認証関連ログのみを転送する設定です。転送するログ量を抑えたい場合や、セキュリティ監査に必要なログだけを集約したい場合に使います。

キューと信頼性の設定

ログサーバーが一時的にダウンした場合にメッセージを失わないよう、キュー設定を追加します。ログサーバーの障害中もメッセージをローカルに蓄積し、復旧後に自動的に再送します。

設定ファイル（/etc/rsyslog.d/remote.conf に追記）：

*.* action(type="omfwd"
          target="syslog.example.corp"
          port="514"
          protocol="tcp"
          queue.type="LinkedList"
          queue.filename="fwd_to_syslog"
          queue.saveonshutdown="on"
          action.resumeRetryCount="-1"
          )

パラメータ	説明
queue.type=”LinkedList”	メモリ上にリンクリスト形式のキューを作成
queue.filename=”fwd_to_syslog”	ディスクキューのファイル名（/var/lib/rsyslog/ 配下に作成）
queue.saveonshutdown=”on”	rsyslog 停止時にキューの内容をディスクに保存
action.resumeRetryCount=”-1″	再送を無制限にリトライ（-1 は無制限）

受信側（ログサーバー）の設定

ログサーバー側で TCP 514 ポートのリスニングを有効にします。

設定ファイル（/etc/rsyslog.conf に追記、または /etc/rsyslog.d/receive.conf）：

module(load="imtcp")
input(type="imtcp" port="514")

受信したログをホスト名別にディレクトリ分けする場合は、以下のテンプレートを追加します。

template(name="RemoteHost" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteHost

これにより、/var/log/remote/ホスト名/プログラム名.log というパスでログが保存されます。

firewalld でポート開放（受信側）

受信側のサーバーで TCP 514 ポートを開放します。ポートが閉じたままだとログが到達しません。

実行コマンド：

# firewall-cmd --add-port=514/tcp --permanent

# firewall-cmd --reload

転送のテスト

送信側で logger コマンドを実行し、受信側でログが記録されることを確認します。

送信側で実行：

# logger -p local0.info "remote test from $(hostname)"

受信側で確認：

# tail /var/log/remote/送信元ホスト名/root.log

テストメッセージが記録されていれば、転送設定は正常に動作しています。

7. /var/log/ 配下の主要ログファイル

rsyslog によって出力されるテキストログファイルの一覧です。journalctl で検索するだけでなく、テキストファイルを直接参照する場面も多いため、各ファイルの役割を把握しておきます。

ファイルパス	内容	確認コマンド
/var/log/messages	一般的なシステムログ（mail, authpriv, cron を除く）	tail -f /var/log/messages
/var/log/secure	認証・セキュリティ関連（sshd, sudo など）	tail -f /var/log/secure
/var/log/cron	cron ジョブの実行記録	tail /var/log/cron
/var/log/maillog	メールシステムのログ	tail /var/log/maillog
/var/log/boot.log	ブート時のサービス起動ログ	cat /var/log/boot.log
/var/log/dnf.log	dnf パッケージ管理の操作ログ	tail /var/log/dnf.log
/var/log/firewalld	firewalld の動作ログ	tail /var/log/firewalld
/var/log/audit/audit.log	auditd による監査ログ	ausearch -m USER_CMD
/var/log/wtmp	ログイン履歴（バイナリ）	last
/var/log/btmp	失敗したログイン試行（バイナリ）	lastb
/var/log/lastlog	各ユーザーの最終ログイン（バイナリ）	lastlog

/var/log/ 配下のファイルサイズ確認例：

実行コマンド：

# ls -lh /var/log/messages /var/log/secure /var/log/cron

実行結果：

-rw-------.  1 root   root   889156  3月 25 00:18 /var/log/messages
-rw-------.  1 root   root   194140  3月 25 00:17 /var/log/secure
-rw-------.  1 root   root     6709  3月 25 00:01 /var/log/cron

バイナリログの閲覧方法

wtmp、btmp、lastlog はバイナリファイルのため、cat や grep では読めません。専用のコマンドで閲覧します。

実行コマンド（ログイン履歴）：

# last

実行コマンド（失敗したログイン試行）：

# lastb

実行コマンド（各ユーザーの最終ログイン日時）：

# lastlog

lastb の出力が多い場合、SSH へのブルートフォース攻撃を受けている可能性があります。/var/log/secure と合わせて確認し、必要に応じて セキュリティ強化編の対策を検討してください。

8. logrotate の設定

logrotate は、テキストログファイルを定期的にローテーション（世代管理）するツールです。ローテーションを設定しないと、ログファイルが際限なく肥大化し、ディスクを圧迫します。

グローバル設定

logrotate のグローバル設定は /etc/logrotate.conf に定義されています。

設定ファイル（/etc/logrotate.conf）：

weekly
rotate 4
create
dateext
include /etc/logrotate.d

パラメータ	説明
weekly	週に 1 回ローテーションを実行
rotate 4	4 世代分のログを保持（それ以前は削除）
create	ローテーション後に新しい空のログファイルを作成
dateext	ローテーション済みファイルに日付を付与（例: messages-20260325）
include /etc/logrotate.d	個別設定ファイルを読み込む

個別設定の主要パラメータ

/etc/logrotate.d/ ディレクトリに配置する個別設定で使用する主なパラメータです。

パラメータ	説明
daily / weekly / monthly	ローテーション頻度
rotate N	保持する世代数
compress	ローテーション済みファイルを gzip 圧縮する
delaycompress	直前のローテーションファイルは圧縮しない（ログ参照のため）
missingok	ログファイルが存在しなくてもエラーにしない
notifempty	ログファイルが空の場合はローテーションしない
create MODE OWNER GROUP	新しいファイルの権限・所有者を指定
postrotate / endscript	ローテーション後に実行するコマンド

カスタムアプリケーション用の設定例

自社アプリケーションのログに対するローテーション設定例です。

設定ファイル（/etc/logrotate.d/myapp）：

/var/log/myapp.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root root
    postrotate
        /usr/bin/systemctl reload rsyslog > /dev/null 2>&1 || true
    endscript
}

毎日ローテーションし、30 世代分を圧縮保持します。postrotate で rsyslog を reload し、新しいログファイルへの書き込みに切り替えます。

ドライランと強制実行

設定を反映する前に、ドライラン（-d）で動作を確認します。

実行コマンド（ドライラン）：

# logrotate -d /etc/logrotate.conf

ドライランではログファイルの変更は行われず、ローテーションが実行された場合の動作が表示されます。

実行コマンド（強制実行）：

# logrotate -f /etc/logrotate.conf

ローテーションの実行状態は /var/lib/logrotate/logrotate.status に記録されています。最後にローテーションが実行された日時を確認する場合はこのファイルを参照してください。

9. journald と rsyslog のデータフロー

第 1 章でログアーキテクチャの全体像を示しましたが、ここでは journald と rsyslog の関係をもう少し詳しく見ていきます。「journalctl で見えるのに /var/log/messages にない」というケースが発生する仕組みを理解するためです。

┌─────────────────────────────────────────────────────────────┐
│  カーネル / サービス / アプリケーション                      │
└─────────────┬───────────────────────────────────────────────┘
              │ systemd のネイティブロギング
              ▼
┌─────────────────────────────────────────────────────────────┐
│  systemd-journald                                           │
│  ・バイナリジャーナルとして /var/log/journal/ に保存         │
│  ・journalctl で検索可能                                    │
│  ・構造化フィールド付き（_PID, _UID, _COMM など）           │
└─────────────┬───────────────────────────────────────────────┘
              │ imjournal モジュール（ForwardToSyslog=yes）
              ▼
┌─────────────────────────────────────────────────────────────┐
│  rsyslog                                                    │
│  ・ファシリティ.プライオリティのルールでルーティング         │
│  ・テキストファイルとして /var/log/ に書き出し               │
│  ・リモート転送（TCP/UDP）                                  │
└─────────────┬───────────────────────────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────────────────────────┐
│  /var/log/messages, /var/log/secure, /var/log/cron ...      │
│  ・テキスト形式（grep, awk で検索可能）                     │
└─────────────┬───────────────────────────────────────────────┘
              │ systemd timer / cron で定期実行
              ▼
┌─────────────────────────────────────────────────────────────┐
│  logrotate                                                  │
│  ・世代管理（rotate N）・圧縮（compress）                   │
└─────────────────────────────────────────────────────────────┘

journalctl で見えるのに /var/log/messages にない場合

以下のいずれかに該当すると、journalctl では表示されるが /var/log/messages には記録されないという状態になります。

• rsyslog のルーティングルールで除外されている：/var/log/messages のルールは mail.none;authpriv.none;cron.none で mail, authpriv, cron を除外しています。これらのファシリティのログは各専用ファイルに記録されます
• rsyslog が停止している：systemctl status rsyslog で動作状態を確認してください
• プライオリティが info 未満：/var/log/messages は *.info 以上のみ記録するため、debug レベルのログは対象外です

ForwardToSyslog の確認

journald から rsyslog へのログ転送は /etc/systemd/journald.conf の ForwardToSyslog パラメータで制御されます。AlmaLinux 9 のデフォルトではこのパラメータはコメントアウトされており、imjournal モジュールを通じて rsyslog がジャーナルを直接読み取る仕組みになっています。

そのため、通常は ForwardToSyslog を明示的に設定する必要はありません。rsyslog の imjournal モジュールが正常に動作していれば、journald のログは rsyslog に受け渡されます。

10. 障害調査のフロー

障害が発生した際に、ログから原因を特定するための実践的な手順です。以下の順番で調査を進めることで、必要な情報に効率よくたどり着けます。

手順 1: いつ発生したかを特定する

障害報告で得られた時刻情報をもとに、ログの時間範囲を絞り込みます。

実行コマンド：

# journalctl --since "2026-03-25 09:00:00" --until "2026-03-25 09:30:00"

手順 2: どのサービスかを特定する

影響を受けたサービスが分かっている場合は、ユニットで絞り込みます。

実行コマンド：

# journalctl -u httpd.service --since "2026-03-25 09:00:00"

手順 3: エラーレベルで絞り込む

大量のログから重要なメッセージを抽出します。

実行コマンド：

# journalctl -p err --since "2026-03-25 09:00:00"

手順 4: 再起動前のログを確認する

障害で OS が再起動した場合、前回ブートのログを確認します。

実行コマンド：

# journalctl -b -1

手順 5: テキストログで補完する

journalctl の結果を /var/log/ 配下のテキストログで裏付けます。

実行コマンド：

# tail -100 /var/log/messages | grep -i error

手順 6: 認証関連かどうかを確認する

不正アクセスや権限の問題が疑われる場合は、/var/log/secure を確認します。

実行コマンド：

# tail -100 /var/log/secure

手順 7: カーネルメッセージを確認する

ハードウェア障害やメモリ不足が疑われる場合は、カーネルメッセージを確認します。

実行コマンド：

# journalctl -k --since "2026-03-25 09:00:00"

リアルタイム監視で障害を待ち受ける

障害の再現を試みる際は、リアルタイム監視を併用します。

実行コマンド：

# journalctl -f -p warning

warning 以上のログをリアルタイムで監視します。別のターミナルで障害の再現操作を行い、どのログが出力されるかを確認します。

11. audit ログとの関係

AlmaLinux 9 では、auditd（監査デーモン）が独自のログ基盤として動作しています。auditd は journald や rsyslog とは独立しており、/var/log/audit/audit.log に監査ログを直接書き込みます。

auditd の状態確認

実行コマンド：

# systemctl status auditd

auditd は AlmaLinux 9 のデフォルトで有効化されています。active (running) と表示されれば正常です。

audit ログの検索

ausearch コマンドで audit ログをフィルタ検索できます。

実行コマンド（今日の sudo 実行を検索）：

# ausearch -m USER_CMD --start today

journalctl からも audit ログの一部を参照できます。

実行コマンド：

# journalctl _TRANSPORT=audit

ただし、journalctl で参照できる audit ログは一部に限られます。audit ログの詳細な分析やカスタムルールの設定については、セキュリティ強化編（第 12 回）で解説します。

トラブルシューティング

journalctl で過去のブートログが表示されない

ジャーナルの永続化が設定されていないと、再起動のたびにジャーナルが消失します。以下を確認してください。

• /var/log/journal/ ディレクトリが存在するか
• /etc/systemd/journald.conf で Storage=persistent が設定されているか

設定方法は初期設定編（第 2 回）を参照してください。

rsyslog でリモート転送されない

以下の順番で原因を切り分けます。

1. 送信側で設定の文法チェックを実行する：rsyslogd -N 1
2. 受信側の firewalld でポートが開放されているか確認する：firewall-cmd --list-ports
3. 受信側で rsyslog がリスニングしているか確認する：ss -tlnp | grep 514
4. 送信側からネットワーク到達性を確認する：nc -zv syslog.example.corp 514

/var/log/messages が肥大化する

logrotate が正常に動作していない可能性があります。

• logrotate -d /etc/logrotate.d/syslog でドライランを実行し、エラーがないか確認する
• systemctl status logrotate.timer で timer が有効かどうか確認する
• /var/lib/logrotate/logrotate.status で最終実行日時を確認する

journalctl で「Suppressed N messages」と表示される

journald のレート制限により、短時間に大量のメッセージを出力するサービスのログが抑制されています。/etc/systemd/journald.conf で以下のパラメータを調整してください。

[Journal]
RateLimitIntervalSec=30s
RateLimitBurst=10000

RateLimitBurst は 30 秒間に許容するメッセージ数です。値を大きくするか、RateLimitIntervalSec=0 でレート制限を無効化できます。変更後は systemctl restart systemd-journald を実行してください。

ログのタイムスタンプがずれている

サーバーの時刻が NTP と同期していない可能性があります。以下のコマンドで確認してください。

実行コマンド：

# timedatectl

System clock synchronized: no と表示される場合は、NTP 同期が機能していません。初期設定編（第 2 回）の時刻同期設定を参照してください。ログのタイムスタンプがずれていると、複数サーバー間でのログ突合が困難になり、障害調査に支障が出ます。

AlmaLinux 9 総合リファレンスガイド シリーズ一覧

1. システム基本情報の確認
2. 初期設定
3. ネットワーク設定（nmcli）
4. パッケージ管理（dnf）
5. ユーザー・グループ管理
6. ファイアウォール（firewalld）
7. SSH設定・鍵認証
8. systemd / サービス管理
9. ストレージ・LVM
10. ログ管理 journalctl / rsyslog（この記事）
11. cron / systemd timer
12. セキュリティ強化
13. パフォーマンス監視
14. コンテナ管理（Podman）
15. バックアップ・リストア