AlmaLinux 9 ログ管理 journalctl rsyslog

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

目次

1. コマンド早見表
2. 前提条件
3. 1. RHEL 9 系のログアーキテクチャ全体像
4. 2. ファシリティとプライオリティ
   1. ファシリティ一覧
   2. プライオリティ一覧
   3. logger コマンドによるテスト
5. 3. journalctl の実践的フィルタ
   1. 時間指定で絞り込む
   2. ユニット（サービス）で絞り込む
   3. プライオリティで絞り込む
   4. ブート単位で絞り込む
   5. カーネルメッセージの確認
   6. リアルタイム追跡
   7. 出力形式の変更
   8. フィールド指定による検索
   9. ディスク使用量の確認
6. 4. ジャーナルの永続化と容量管理
   1. journald.conf の主要パラメータ
   2. 容量管理の設定例
   3. 手動でのジャーナル削除
   4. ジャーナルの整合性検証
7. 5. rsyslog の基本設定
   1. rsyslog.conf の構造
   2. imjournal モジュール
   3. デフォルトのルーティングルール
   4. カスタムルールの追加
   5. 設定の文法チェックと反映
8. 6. rsyslog によるリモートログ転送
   1. UDP と TCP の違い
   2. 送信側（クライアント）の設定
   3. キューと信頼性の設定
   4. 受信側（ログサーバー）の設定
   5. firewalld でポート開放（受信側）
   6. 転送のテスト
9. 7. /var/log/ 配下の主要ログファイル
   1. バイナリログの閲覧方法
10. 8. logrotate の設定
    1. グローバル設定
    2. 個別設定の主要パラメータ
    3. カスタムアプリケーション用の設定例
    4. ドライランと強制実行
11. 9. journald と rsyslog のデータフロー
    1. journalctl で見えるのに /var/log/messages にない場合
    2. ForwardToSyslog の確認
12. 10. 障害調査のフロー
    1. 手順 1: いつ発生したかを特定する
    2. 手順 2: どのサービスかを特定する
    3. 手順 3: エラーレベルで絞り込む
    4. 手順 4: 再起動前のログを確認する
    5. 手順 5: テキストログで補完する
    6. 手順 6: 認証関連かどうかを確認する
    7. 手順 7: カーネルメッセージを確認する
    8. リアルタイム監視で障害を待ち受ける
13. 11. audit ログとの関係
    1. auditd の状態確認
    2. audit ログの検索
14. トラブルシューティング
    1. journalctl で過去のブートログが表示されない
    2. rsyslog でリモート転送されない
    3. /var/log/messages が肥大化する
    4. journalctl で「Suppressed N messages」と表示される
    5. ログのタイムスタンプがずれている
15. AlmaLinux 9 総合リファレンスガイド シリーズ一覧

コマンド早見表#

前提条件#

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

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

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

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

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

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

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

ファシリティ一覧#

プライオリティ一覧#

プライオリティは数値が小さいほど重要度が高くなります。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 オプションで出力形式を変更できます。

実行コマンド：

# 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 です。デフォルトではほぼすべてのパラメータがコメントアウトされています。

容量管理の設定例#

サーバーのディスク容量に応じて、ジャーナルの上限を設定します。以下は /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 モジュール#

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 に定義されているデフォルトのルールは以下の通りです。

/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 の違い#

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

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

設定ファイル（/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"
          )

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

ログサーバー側で 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/ 配下のファイルサイズ確認例：

実行コマンド：

# 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

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

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

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

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

設定ファイル（/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. バックアップ・リストア