systemd-journaldのリモート転送設計｜journal-remote・TLS認証の本番構成と切り戻し

複数ホストのログを一元集約したい場面で、syslog リレーの代替として systemd-journal-remote / systemd-journal-upload の組み合わせが選ばれるケースが増えています。journal フォーマットのまま受け渡せるため、構造化フィールドや優先度を失わずに集約できる点が実用上の強みです。本記事では TLS 相互認証を前提とした本番向け構成を、手順・検証・切り戻しまで一続きで整理します。

設計の前提：push 型と pull 型の使い分け

リモート転送には大きく push 型（クライアントがサーバーへ送信）と pull 型（サーバーがクライアントへ問い合わせ）の2方式があります。

• push 型：各ホストで systemd-journal-upload が起動し、HTTPS でログサーバーへ継続送信する。ファイアウォールのインバウンドを最小化できるため、本番環境ではこちらが主流です。
• pull 型：systemd-journal-gatewayd をクライアント側で立て、サーバー側の systemd-journal-remote が HTTP で取得する。クライアント側のデーモン変更を避けたい場合に使われますが、ポート公開が必要になります。

本記事では push 型 + TLS 相互認証 を前提とします。利用するコンポーネントは以下の3点です。

• systemd-journal-remote：受信側デーモン。デフォルトでポート 19532/TCP を listen します。
• systemd-journal-upload：送信側デーモン。各クライアントホストで動かします。
• TLS 証明書セット：CA 証明書・サーバー証明書・クライアント証明書（ホストごと）。

ログの保存先はサーバー上の /var/log/journal/remote/ 以下に送信元ホスト名でサブディレクトリが作られます。journalctl --directory や -D オプションで参照できます。

パッケージ導入と証明書の準備

パッケージのインストール

Debian 12 / Ubuntu 24.04 系では systemd-journal-remote パッケージに両デーモンが同梱されています。

# ログサーバー・クライアント両方で実行
apt install systemd-journal-remote

RHEL 9 / Rocky Linux 9 / AlmaLinux 9 系は同名パッケージが標準リポジトリにあります。

dnf install systemd-journal-remote

証明書の準備（内部 CA を使う場合の想定例）

以下は内部 CA を openssl で用意する想定例です。既存の PKI や Vault があればそちらを利用してください。架空の手順例として参照してください。

# CA キーと自己署名証明書の生成
openssl genrsa -out /etc/ssl/private/internal-ca.key 4096
openssl req -x509 -new -key /etc/ssl/private/internal-ca.key \
  -days 3650 -out /etc/ssl/certs/internal-ca.crt \
  -subj "/CN=Internal Journal CA"

# サーバー証明書（ログ受信ホスト用）
openssl genrsa -out /etc/ssl/private/journal-remote.key 2048
openssl req -new -key /etc/ssl/private/journal-remote.key \
  -out /tmp/journal-remote.csr \
  -subj "/CN=logserver.internal"
openssl x509 -req -in /tmp/journal-remote.csr \
  -CA /etc/ssl/certs/internal-ca.crt \
  -CAkey /etc/ssl/private/internal-ca.key \
  -CAcreateserial -days 365 \
  -out /etc/ssl/certs/journal-remote.crt

# クライアント証明書（各送信ホスト用）
openssl genrsa -out /etc/ssl/private/journal-upload.key 2048
openssl req -new -key /etc/ssl/private/journal-upload.key \
  -out /tmp/journal-upload.csr \
  -subj "/CN=apphost01.internal"
openssl x509 -req -in /tmp/journal-upload.csr \
  -CA /etc/ssl/certs/internal-ca.crt \
  -CAkey /etc/ssl/private/internal-ca.key \
  -CAcreateserial -days 365 \
  -out /etc/ssl/certs/journal-upload.crt

証明書ファイルのパーミッションには注意が必要です。systemd-journal-remote は専用ユーザー systemd-journal-remote で動くため、秘密鍵への読み取り権限を付与します。

# サーバー側
chown root:systemd-journal-remote /etc/ssl/private/journal-remote.key
chmod 640 /etc/ssl/private/journal-remote.key

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

受信側の設定ファイルは /etc/systemd/journal-remote.conf です。TLS 相互認証を有効にするには以下のように記述します。

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

• SplitMode=host：送信元ホスト名ごとにファイルを分割して保存します。none にすると単一ファイルにまとまります。
• Seal=false：FSS（Forward Secure Sealing）を使わない場合は false のままで問題ありません。改ざん検知要件がある場合は有効化を検討します。
• TrustedCertificateFile に CA 証明書を指定することで、クライアント証明書の検証が有効になります（相互認証）。

サービスを有効化して起動します。

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

ファイアウォールが動いている場合はポートを開放します。

# firewalld の場合
firewall-cmd --permanent --add-port=19532/tcp
firewall-cmd --reload

送信側（クライアントホスト）の設定と起動

送信側の設定ファイルは /etc/systemd/journal-upload.conf です。

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

URL はサーバーの FQDN または IP アドレスを指定します。DNS 解決が確実でない環境では IP アドレスでも構いませんが、その場合はサーバー証明書の SAN に IP アドレスを含める必要があります。

systemctl enable --now systemd-journal-upload.service

systemd-journal-upload はカーソルポインタ（既送信位置）を /var/lib/systemd/journal-upload/state に保存します。再起動後も続きから送信が再開されるため、ネットワーク断による欠損は最小化されます。ただし、このファイルを削除すると再転送が始まる点に注意してください。

動作検証：転送状況の確認方法

サーバー側での受信確認

# 受信済みファイルの一覧（ホスト別）
ls /var/log/journal/remote/

# 特定ホストのログを参照
journalctl -D /var/log/journal/remote/ \
  --identifier=sshd \
  --since="1 hour ago"

クライアント側でのサービス状態確認

systemctl status systemd-journal-upload.service

# 転送エラーがないか確認
journalctl -u systemd-journal-upload.service -n 50

よくあるつまずきとして、TLS ハンドシェイク失敗（SSL_ERROR_RX_RECORD_TOO_LONG や certificate verify failed）がサービスログに出る場合があります。証明書の CN または SAN がサーバーの接続先 FQDN と一致しているか、CA 証明書のパスが正しいかを確認してください。

一般的には、サーバー証明書の有効期限切れや、クライアント側に CA 証明書を配布し忘れているケースが多いとされています。

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

クライアント側の切り戻し

リモート転送を止めるだけであれば、クライアントのサービスを無効化するだけで済みます。ローカルジャーナルへの記録は継続されます。

systemctl disable --now systemd-journal-upload.service

状態ファイルを保持したまま停止しておけば、後で再開したときに続きから送信されます。完全にリセットして最初から再転送させたい場合のみ、以下を実行します（ログ量が多い環境では帯域・負荷に注意してください）。

rm /var/lib/systemd/journal-upload/state

サーバー側の切り戻し

systemctl disable --now systemd-journal-remote.service
systemctl disable --now systemd-journal-remote.socket

受信済みのジャーナルファイルは /var/log/journal/remote/ に残ります。削除する場合は journalctl --vacuum-size や rm で対処できますが、コンプライアンス要件がある場合は保持期間のポリシーに従ってください。

証明書ローテーション時の注意

証明書を更新した際は、サービスの再起動が必要です。ExecReload は定義されていないため、systemctl restart で反映します。証明書の有効期限をあらかじめ監視に組み込んでおくことを推奨します。

2026年時点の環境差分と注意事項

systemd v256（2024年リリース）以降では、journal-remote.conf の SplitMode に host+ という拡張値が追加され、送信元ホスト名にフィールド識別子を付加したディレクトリ名で分割できるようになりました。大規模環境でホスト名衝突を防ぐ際に有効です。ディストリビューション同梱の systemd バージョンによって利用可否が異なります。

RHEL 9.x（systemd 252 ベース）では host+ は未対応です。Rocky Linux 9 / AlmaLinux 9 も同様です。Ubuntu 24.04 は systemd 255、Debian 12 は 252 を標準搭載しているため、機能差に注意してください。

また、SELinux が有効な RHEL 系環境では、journal-remote が証明書ファイルを読む際に AVC 拒否が発生する場合があります。ausearch -c journal-remote でログを確認し、必要に応じて restorecon でラベルを修正するか、適切なポリシーを適用してください。

Vector や Fluent Bit など OSS ログルーターとの比較では、journal-remote は追加エージェントなしで journal フォーマットのまま転送できる点が利点です。一方でフィルタリングやルーティング機能は持たないため、複雑な転送先振り分けが必要な場面では他のツールと組み合わせる構成も検討に値します。