rsyslogとsystemd-journaldの関係整理

Linux環境でログを扱っていると、

• rsyslog と journald の違いがよく分からない
• どちらがログを管理しているのか曖昧
• 二重取得や重複送信が起きる

といった疑問やトラブルに必ず直面します。

これは多くの場合、rsyslog と systemd-journald の役割関係を正しく理解していないことが原因です。

本記事では、

• rsyslog と journald の役割の違い
• ログの流れ（どこからどこへ行くか）
• 二重取得・重複の発生ポイント
• 実務での正しい設計パターン

を体系的に整理します。

まず結論：rsyslogとjournaldは役割が違う

この2つは競合するものではなく、レイヤーが違います。

項目	systemd-journald	rsyslog
役割	ログの収集・一時保存	ログの加工・振り分け・転送
保存形式	バイナリ（journal）	テキスト（/var/log）
転送機能	限定的	強力（条件分岐・キュー）

journald は「受け口」、rsyslog は「流通・加工担当」と考えると分かりやすいです。

ログの基本的な流れ

systemd 環境では、ログは次のように流れます。

1. アプリ / カーネル / サービスがログ出力
2. systemd-journald が受信
3. journald → rsyslog に転送
4. rsyslog がファイル保存・転送

この「journald → rsyslog」の部分が、トラブルの温床です。

journaldからrsyslogへの連携方法

imjournal モジュール

rsyslog 側で journald を読む場合、以下が使われます。

module(load="imjournal")

これにより、journald のログが rsyslog に渡されます。

imuxsock モジュール

もう1つの入力が imuxsock です。

module(load="imuxsock")

これは /dev/log を通じた従来型の入力です。

systemd 環境では、この2つが同時に有効だと二重取得が起きます。

よくあるトラブル1：ログの二重取得・重複送信

原因

• imjournal 有効
• imuxsock も有効

同じログを journald と /dev/log の両方から取り込むためです。

確認方法

grep -R "imjournal" /etc/rsyslog*
grep -R "imuxsock" /etc/rsyslog*

対処

• imjournal のみに統一する（推奨）
• もしくは片方を明示的に無効化

よくあるトラブル2：ログが欠落する

原因

• journald の保持期間が短い
• rsyslog 停止中にログが溜まりきらない

確認ポイント

journalctl --disk-usage

journald のログがローテートされていないか確認します。

対処

• journald の Storage 設定を persistent に
• rsyslog 停止時間を最小化

実務で推奨される設計パターン

パターン1：journald＋rsyslog（王道）

• journald：ログ受信・短期保持
• rsyslog：フィルタ・転送・長期保存

最も一般的で事故が少ない構成です。

パターン2：journaldのみ（最小構成）

• 小規模・検証環境向け
• ログ転送要件がない場合

本番環境ではあまり推奨されません。

正しい状態の判断基準

• 同じログが1回だけ記録される
• logger のテストログが想定通り流れる
• rsyslog 再起動後も挙動が変わらない

切り分け時の思考順

1. どこでログを受けているか（journald）
2. rsyslog がどこから読んでいるか
3. 二重経路が存在しないか
4. 保持・転送設計は妥当か

まとめ

• journaldは収集、rsyslogは流通
• 役割を混同すると事故が起きる
• imjournal と imuxsock の併用に注意

rsyslog と systemd-journald は、

「どちらが悪い」ではなく「どう使い分けるか」

を理解すれば、ログ運用は一気に安定します。