rsyslogからjournaldへログ転送に切り替える｜既存フィルタ変換と集約確認の進め方

なぜ今、rsyslogからjournaldへの移行が注目されるのか

2026年時点で主要ディストリビューション（RHEL 9/10系・Ubuntu 22.04/24.04・Debian 12）はいずれも systemd を標準採用しており、ログ収集の一次窓口は事実上 systemd-journald に統一されています。従来の運用では「journald が受け取り → rsyslog が加工・転送」という二段構えが多く取られてきましたが、このアーキテクチャには重複によるオーバーヘッドとフィルタ管理の分散という課題があります。

systemd-journal-remote と systemd-journal-upload による journald ネイティブな転送が実用水準に達したこと、また rsyslog の設定ファイルが複雑化して保守負荷が高まっている実態から、journald 単体での転送に整理し直す動きが広がっています。本記事ではその具体的な手順を、既存フィルタの変換・集約確認・切り戻しまで含めて解説します。

移行前の棚卸し――現行rsyslog設定の整理

移行の最初の作業は rsyslog の設定ファイルを網羅的に洗い出すことです。設定は /etc/rsyslog.conf と /etc/rsyslog.d/ 以下に分散していることが多く、以下のコマンドで有効行（コメント行を除く）を一覧化できます。

grep -rn "^[^#]" /etc/rsyslog.conf /etc/rsyslog.d/

各ルールについて次の3点を記録します。

• 対象のファシリティ・セビリティ（例: kern.*、authpriv.warning）
• プログラム名・ホスト名による絞り込み条件（例: :programname, isequal, "sshd"）
• 出力先またはリモート転送先（ファイルパス、UDP/TCP アドレス）

この段階でルールをテキストや Markdown に一覧化しておくと変換漏れを防げます。あわせて /etc/systemd/journald.conf の ForwardToSyslog の値を確認してください。yes（またはデフォルト）になっていれば、rsyslog は /run/systemd/journal/syslog ソケット経由でジャーナルからログを受け取っています。

journaldのログ転送設定を組む

journald.confのForwardToSyslogを無効化する

移行の第一歩は journald から rsyslog へのフィードを停止することです。/etc/systemd/journald.conf（またはドロップインファイル /etc/systemd/journald.conf.d/99-local.conf）に以下を追記します。

[Journal]
Storage=persistent
ForwardToSyslog=no

設定を反映するには systemd-journald を再起動します。

systemctl restart systemd-journald

この時点で rsyslog はジャーナルからのリアルタイムフィードを失います。rsyslog 自体はまだ起動したままにしておくのが安全です。切り戻し時の保険として残しておく意味があります。

systemd-journal-remoteで集約サーバーを構成する

リモートへの集約は systemd-journal-remote（受信側）と systemd-journal-upload（送信側）のペアで実現します。まず集約サーバー側にパッケージをインストールします。

# RHEL/Rocky系（RHEL 10はsystemd本体に同梱のため不要）
dnf install systemd-journal-remote

# Debian/Ubuntu系
apt install systemd-journal-remote

受信側の /etc/systemd/journal-remote.conf を編集します。SplitMode=host を指定するとホストごとに .journal ファイルが分割され、後から特定ホストのログだけを参照しやすくなります。

[Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/ssl/private/journal-remote.key
ServerCertificateFile=/etc/ssl/certs/journal-remote.crt
TrustedCertificateFile=/etc/ssl/certs/ca.crt

systemctl enable --now systemd-journal-remote.socket

送信側（各ログ発生ホスト）では /etc/systemd/journal-upload.conf を設定します。

[Upload]
URL=https://log-aggregator.example.internal:19532
ServerKeyFile=/etc/ssl/private/journal-upload.key
ServerCertificateFile=/etc/ssl/certs/journal-upload.crt
TrustedCertificateFile=/etc/ssl/certs/ca.crt

systemctl enable --now systemd-journal-upload

TLS 証明書は本番環境では必須です。内部認証局（自己署名 CA でも可）を用意し、サーバー・クライアントそれぞれに証明書を発行してください。ポート番号は 19532 がデフォルトです。

既存rsyslogフィルタをjournald条件式に変換する

rsyslog のフィルタ記法と journald のフィールド体系は異なります。棚卸しで洗い出したルールを journald のフィールドに対応させていきます。

ファシリティ・セビリティによる絞り込み：rsyslog では kern.err のような表記を使いますが、journald では PRIORITY（0=emerg〜7=debug）と SYSLOG_FACILITY（0〜23）フィールドで表現します。照会時は以下の形式になります。

# rsyslog: kern.err 以上を対象にする場合の journald 相当照会
journalctl SYSLOG_FACILITY=0 PRIORITY=3

プログラム名による絞り込み：rsyslog の :programname, isequal, "sshd" は journald では _COMM または _SYSTEMD_UNIT フィールドで対応します。

journalctl _COMM=sshd
journalctl _SYSTEMD_UNIT=sshd.service

ホスト名による絞り込み：rsyslog の :hostname, isequal, "web01" は journald では _HOSTNAME フィールドです。集約サーバー上で参照する際に使います。

journalctl _HOSTNAME=web01

重要な注意点として、systemd-journal-upload は現時点で転送前フィルタリングを行わず全エントリを送信します。転送量を絞り込みたい場合は受信側の照会スクリプトで対応するか、特定用途に限り rsyslog を並走させるかを判断する必要があります。転送段階でのフィルタ機能は 2026 年時点でも上流での議論段階にあり、正式実装には至っていません。

移行後の集約確認と動作検証

集約サーバーにログが届いているかを確認するには、SplitMode=host で分割されたジャーナルファイルを参照します。

# 集約サーバー上で受信ファイルを確認
ls /var/log/journal/remote/

journalctl --file=/var/log/journal/remote/remote-web01.journal -n 50

送信側で意図的にログを生成し、集約サーバーで受信できるかを確認します。

# 送信側でテストメッセージを生成
logger -p auth.warning "migration test: $(hostname)"

# 集約サーバー側で数秒後に確認
journalctl --file=/var/log/journal/remote/remote-web01.journal -t logger -n 5

メタデータの欠損がないかは --output=json-pretty で確認します。

journalctl --file=/var/log/journal/remote/remote-web01.journal -t logger \
  --output=json-pretty -n 1

出力に PRIORITY・_HOSTNAME・_COMM・SYSLOG_IDENTIFIER が含まれていれば、構造化メタデータを欠損なく転送できています。逆にこれらが欠けている場合は、送信元ホストの journald バージョンや Storage=persistent の設定を再確認してください。

切り戻し手順と運用上の注意点

問題が発生した際の切り戻しは、journald.conf の ForwardToSyslog を yes に戻して journald を再起動するだけです。rsyslog を停止せず残しておいた理由はここにあります。

sed -i 's/^ForwardToSyslog=no/ForwardToSyslog=yes/' /etc/systemd/journald.conf
systemctl restart systemd-journald

切り戻し後は rsyslog が即座にジャーナルからの受信を再開します。journald 移行期間中は rsyslog を disabled ではなく stopped（systemctl stop rsyslog）の状態で保持しておくと、サービス定義を壊さずに素早く戻せます。

運用上で押さえておくべき点を以下に整理します。

ディスク容量の管理：集約サーバーでは SystemMaxUse と MaxRetentionSec を明示的に設定します。デフォルトでは全体の 10% という制限があり、大量ホストからの集約では想定外に早く上限に達することがあります。

# /etc/systemd/journald.conf（集約サーバー）
SystemMaxUse=20G
MaxRetentionSec=90day

ログ欠落リスクへの備え：systemd-journal-upload はネットワーク断時にカーソル位置を保持し、再接続後に再送を試みます。ただし、送信側のローカルジャーナルが MaxRetentionSec を超えてローテートされると、再送対象がなくなりその期間のログが欠落します。ネットワーク断が長引く環境では、ローカル保持期間の設定を長めにするか、rsyslog との併用を検討する価値があります。

SELinux 環境での確認：RHEL 9/10 では systemd-journal-remote に対する SELinux コンテキストが必要です。拒否ログが出ていないかを確認します。

ausearch -m avc -ts recent | grep journal

ディストリビューション別の差分（2026年時点）：Ubuntu 24.04 LTS および Debian 12 では systemd-journal-remote が標準リポジトリから直接インストール可能です。RHEL 10 では systemd 本体に同梱されており追加インストールは不要です。一方、RHEL 8 系では systemd のバージョンが低く、SplitMode=host の挙動が一部異なるほか、TLS オプションのサポートが限定的なため、バージョンを事前に確認してから着手することをお勧めします。