rsyslog を使ってログ転送をしている環境で、
- ログが急に飛ばなくなった
- サービスは起動している
- エラーも出ていない
という状況に遭遇したことはないでしょうか。
rsyslog は「動いているように見えて、実は送っていない」状態が非常に多いのが特徴です。
本記事では、
- rsyslog がログを送信しない典型パターン
- 確認すべきポイントと判断基準
- 異常が出た時の具体的な解決策
- 復旧したと判断できる状態
を、実務トラブルシューティング視点で解説します。
まず押さえる：rsyslogの送信フロー
rsyslog のログ転送は、以下の流れで動作します。
- ログ発生（systemd / アプリ）
- rsyslog が入力として受信
- フィルタ条件に一致
- 出力アクション（omfwd等）で送信
どこか1つでも止まると「送られない」状態になります。
確認ポイント1：rsyslogサービスは本当に正常か
systemctl status rsyslog確認すべき点：
- active (running) になっているか
- 再起動を繰り返していないか
異常の判断基準：
active だが再起動回数が多い
異常時の対処：
設定エラーやキュー詰まりを疑い、次の項目へ進む
確認ポイント2：設定ファイルが正しく読み込まれているか
rsyslogd -N1設定の構文チェックを行います。
異常の判断基準：
warning / error が表示される
異常時の対処：
特に以下を重点的に確認します。
- if / then の書き方
- action 定義漏れ
- include ファイルの順序
確認ポイント3：ログがrsyslogに届いているか
送信以前に「入力できていない」ケースも多いです。
確認
logger test_from_rsyslogローカルログに出るか確認します。
tail /var/log/messages異常の判断基準：
logger のログが出ない
異常時の対処：
imuxsock / imjournal の設定を確認
確認ポイント4：フィルタ条件で落ちていないか
rsyslog は条件に一致しないログは黙って捨てます。
よくある例
- facility / severity 指定ミス
- tag 条件不一致
確認方法：
一時的に条件を外し、全送信にして挙動を見る
異常時の対処：
フィルタ条件を最小構成から作り直す
確認ポイント5：送信先への通信は成立しているか
rsyslog は送信先に繋がらなくても即エラーを出さないことがあります。
確認
ss -ant | grep 514または、
tcpdump -nn host 送信先IP and port 514異常の判断基準：
SYN が出ているが ACK が返らない
異常時の対処：
FW・ネットワーク経路・受信側rsyslogを確認
確認ポイント6：キューが詰まっていないか
送信失敗が続くと、rsyslog はキューに溜め続けます。
確認
ls /var/spool/rsyslog異常の判断基準：
キューファイルが増え続けている
異常時の対処：
送信先復旧後、rsyslog を再起動して解消確認
確認ポイント7：送信プロトコル（TCP / UDP / TLS）
送信方式不一致も多い原因です。
- 送信側は TCP
- 受信側は UDP
など。
異常時の対処：
送信側・受信側の omfwd / imtcp / imudp を一致させる
解決したと判断する基準
- logger のログが送信先に到達する
- tcpdump で定常的な送信が見える
- キューが増えない
実務的な切り分けフロー
- rsyslog が起動しているか
- 設定が正しく読み込まれているか
- 入力されているか
- フィルタで落ちていないか
- 通信できているか
- キューが詰まっていないか
まとめ
- rsyslogは「静かに失敗する」
- 送信・入力・条件を分けて考える
- 確認後にどう動くかが重要
rsyslog が送信しない時は、
「どこまで届いているか」
を1段ずつ確認すれば、原因に辿り着けます。