「ログサーバーが止まったら、各サーバーのログ書き込みまで遅くなりました」
「ログサーバーの再起動の間のログが、ごっそり抜けています」
rsyslogは、Linuxのログの書き出しと転送を担う中心的なソフトウェアです（第3回）。設定はシンプルに見えますが、キューの仕組みを知らないと、転送先の障害が送信側全体を止めたり、ログが静かに消えたりします。
第4回（前編）では、rsyslogの内部構成と、受信・転送の設定、そしてログサーバーが止まっても欠損させない方法を扱います。第5回（後編）では、テンプレート・振り分け・TLS・RELPなどを扱います。
rsyslogの内部構成
rsyslogは、ログを「受け取る」「振り分ける」「書き出す」処理を、モジュールと呼ぶ部品の組み合わせで行います。
- 入力モジュール（名前がimで始まる）が、journal、ローカルのソケット、ネットワーク（UDP・TCP・RELP）、テキストファイルなどからメッセージを受け取る
- パーサーで、PRI、時刻、ホスト名などに分解される
- キューに入る
- キューから取り出されたメッセージに、ルールセットに書かれたフィルター（条件）が上から順に当てはめられ、合えばアクションが実行される
- アクションの実体は出力モジュール（omで始まる）で、ファイルへの書き込み、別のサーバーへの転送、HTTPでの送信などを行う。加工用のモジュール（mm）もある
設定ファイルは、この「入力 → ルールセット → 出力」を書き並べたものだと考えると、読みやすくなります。
メインキューとアクションキュー
冒頭の「ログサーバーが止まったら各サーバーまで遅くなった」の原因が、ここにあります。
- rsyslogには2種類のキューがある。すべての入力はまず1つのメインキュー（既定はメモリ上に10万件）に入り、ワーカースレッドがルールセットを実行する
- 一方、各アクションは既定ではキューを持たないDirectモードで、メインキューのスレッドがその場で書き込みや送信を行う
- ここに落とし穴がある。TCPで転送する先が応答しなくなると、そのアクションで処理が止まり、メインキューがたまり続け、やがてローカルのファイルへの書き込みや入力の受け付けまで滞る
そこで、遅くなりうるアクション（リモートへの転送、HTTP、データベース）にはアクションキューを付けて切り離します。種類は必要な分だけメモリを使うLinkedListを選び、ファイル名を与えてディスクにも退避できるようにします（この後の転送の設定）。
ポイント
詰まりを、1つのアクションの中に閉じ込める。転送のアクションには必ずキューを付ける。
主なモジュールとパッケージ
| モジュール | 役割 | RHEL 9／10 のパッケージ |
|---|---|---|
| imjournal | journal から読む（RHEL の既定の入力。第3回） | rsyslog |
| imuxsock | /dev/log から読む（Ubuntu の既定。RHEL は SysSock.Use=”off”） | rsyslog |
| imudp・imtcp | UDP・TCP で受信する。TLS は imtcp に TLS ドライバーを組み合わせる | rsyslog（TLS は rsyslog-gnutls か rsyslog-openssl） |
| imrelp・omrelp | RELP で受信・送信する（第5回） | rsyslog-relp |
| omfile・omfwd | ファイルに書く・UDP／TCP／TLS で転送する（組み込み） | rsyslog |
| omhttp | HTTP(S) で送る（ログ基盤・SIEM の API） | rsyslog（Ubuntu は提供なし） |
| omkafka | Kafka へ送る | rsyslog-kafka |
| omelasticsearch | Elasticsearch・OpenSearch へ送る | rsyslog-elasticsearch |
RHELでは、TLS（rsyslog-gnutlsかrsyslog-openssl）とRELP（rsyslog-relp）が別パッケージで、入れずに設定だけ書くとモジュールを読み込めず、起動に失敗します（sudo dnf install rsyslog-gnutls rsyslog-relp）。Ubuntuも同様です。ほかに、テキストファイルを読むimfile、メールを送るommail（第5回）があります。GSSAPIは今はほぼ使われません。
現行版と設定の検査（rsyslogd -N1）
| 環境 | rsyslog の版（2026年9月） | 備考 |
|---|---|---|
| 開発元（rsyslog.com） | 8.2610.0（2026年10月） | 偶数月に定期リリース。次は 8.2612.0（12月予定）。この行は2026年11月に確認 |
| RHEL 9.8 | 8.2510 系 | 同じ v8 系の中で、マイナーリリースごとに版が上がる |
| RHEL 10.2 | 8.2510 系 | 同上 |
| Ubuntu 24.04 LTS | 8.2312.0 | |
| Ubuntu 26.04 LTS | 8.2512.0 | 下の出力例はこの版 |
| Amazon Linux 2023 | 既定では入っていない | journald だけ |
$ rsyslogd -v | head -1
rsyslogd 8.2512.0 (aka 2025.12) compiled with:
$ sudo rsyslogd -N1
rsyslogd: version 8.2512.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
$ sudo rsyslogd -N1 # 誤りがある場合
rsyslogd: error during parsing file /etc/rsyslog.d/90-forward.conf, on or before line 9: parameter 'target' required but not specified - fix config [v8.2512.0 try https://www.rsyslog.com/e/2207 ]-N1は起動せずに設定を検査し、構文、パラメーター名のつづり、必須の項目を確かめる- 証明書の読み込みや接続までは検査しないため、再起動後に
systemctl status rsyslogとjournalctl -u rsyslogでエラーが無いかも確かめる - 変更したら必ず「-N1 → 再起動 → 確認」の順で進める。版番号の8.YYMMは、リリースの年月
3つの書式の見分け方
| 書式 | 見分け方 | 扱い |
|---|---|---|
| sysklogd 形式 | 行頭が facility.severity、続けて出力先 | 単純な振り分けなら今も使える。RHEL の既定はセレクターと action() の組み合わせ |
| レガシー形式 | 行頭が $（$ModLoad、$ActionQueueType 等） | 新しくは書かない。次のアクションだけに効く指令が多く、順番の誤りに気付きにくい |
| RainerScript | module()・input()・action()・if … then | 推奨。パラメーター名を -N1 で検査できる |
# ① sysklogd 形式：セレクター と 出力先
authpriv.* /var/log/secure
# ② レガシー形式：行頭が $
$ModLoad imudp
$UDPServerRun 514
# ③ RainerScript：名前="値" で書く（①②と同じ意味）
module(load="imudp")
input(type="imudp" port="514")
authpriv.* action(type="omfile" file="/var/log/secure")Ubuntu 26.04の既定の設定には、今もレガシー形式（$FileOwnerなど）が残っています。混在しても動きますが、自分で書くファイルはRainerScriptにそろえます。Webで拾った例は、どの書式・どの版向けかを確かめてから使います。引用符は必ず半角の"（全角や曲がった引用符はパースエラーになります）。
受信の設定（imudp・imtcp）
# /etc/rsyslog.d/10-remote.conf（ログサーバー logsv01）
module(load="imudp")
module(load="imtcp" MaxSessions="1000") # 既定は 200 セッション
ruleset(name="remote") {
action(type="omfile" file="/var/log/remote/all.log")
}
input(type="imudp" port="514" ruleset="remote")
input(type="imtcp" port="514" ruleset="remote")
module()は1つのモジュールにつき1回だけ書く。待ち受けはinput()を必要な数だけ並べるruleset="remote"で、受信したログを専用のルールセットに流す。ローカルのログ（/var/log/messages）と混ざらず、受信側の振り分けを1か所にまとめられる- ポートは514/udp、514/tcp（慣習。IANAでは514/tcpはshellに割り当て）、TLSは6514/tcp（第2回・第5回）
- 送信元が多いときは、TCPの同時セッションの上限（
MaxSessions、既定200）を超えないようにする - 振り分けと保存先のファイル名は、このルールセットの中に書く（第5回）
受信側のOSの設定（firewalld・SELinux）
$ sudo firewall-cmd --permanent --add-service=syslog # 514/udp
$ sudo firewall-cmd --permanent --add-port=514/tcp
$ sudo firewall-cmd --permanent --add-service=syslog-tls # 6514/tcp・udp
$ sudo firewall-cmd --reload
$ sudo semanage port -l | grep syslog # （抜粋）
syslog_tls_port_t tcp 6514, 10514
syslog_tls_port_t udp 6514, 10514
syslogd_port_t tcp 601, 20514
syslogd_port_t udp 514, 601, 20514
$ sudo semanage port -a -t syslogd_port_t -p tcp 30514 # 既定外のポートを使うとき
$ sudo ss -tulnp | grep rsyslogd # 待ち受けの確認
PS> Test-NetConnection logsv01.corp.example.jp -Port 6514 # Windows から TCP の到達を確認
- RHELのSELinuxでは、rsyslogが使えるポートが決まっている。一覧に無いポートで待ち受けると、設定が正しくてもbindが拒否されて起動時にエラーになる
- 514/tcpは一覧では
rsh_port_tだが、rsyslogが使うことはポリシーで許可されている - Windowsの
Test-NetConnectionが確かめられるのはTCPだけ（TcpTestSucceeded : Trueなら到達）。UDPは届いたかを送信側で確かめられないため、受信側のtcpdumpで見る（第10回）
転送の設定（omfwd）とアクションキュー
# /etc/rsyslog.d/90-forward.conf（送信側 web01）
action(type="omfwd" name="fwd_logsv01"
target="logsv01.corp.example.jp" port="514" protocol="tcp"
template="RSYSLOG_SyslogProtocol23Format"
queue.type="LinkedList"
queue.filename="fwd_logsv01"
queue.maxDiskSpace="1g"
queue.saveOnShutdown="on"
action.resumeRetryCount="-1"
action.resumeInterval="30")target（必須）・port・protocol：送り先。targetを書き忘れると、起動時にエラーになる（上の-N1の誤りの例）template：RFC 5424形式で送る（第5回）。省略すると、RFC 3164風のRSYSLOG_TraditionalForwardFormatqueue.type="LinkedList"：このアクション専用のキューを作り、メインキューから切り離すqueue.filename：名前を付けると、あふれた分をディスク（/var/lib/rsyslog）へ退避する。転送先ごとに別の名前にするqueue.maxDiskSpace：退避に使うディスクの上限。queue.saveOnShutdown="on"：停止時にメモリ上の未送信分を保存するaction.resumeRetryCount="-1"：送れるまで再試行し続ける。既定の0では、失敗したメッセージは捨てられる
ログサーバーが止まっても欠損させない
冒頭の「再起動の間のログが抜けた」への答えです。ログサーバーの再起動や回線の断は、必ず起きます。欠損させないには、送信側で「送れなかった分をためて、戻ったら送る」仕組みが要ります。
- 前の節の設定では、転送先が応答しないとアクションが一時停止し、メッセージはアクションキューにたまる。メモリがいっぱいに近づくと/var/lib/rsyslogの下のファイルへ退避され、rsyslogを止めるときも保存される
- 転送先が戻ると、定期的な再試行で気付き、たまった分を古い順に送る
ただし、限界もあります。
- UDPは、相手が止まっても送信側でエラーにならないため、ためる仕組みが働かない
- TCPでも、切断の直前に送った分が失われることがあり、確実に届けるにはRELP（第5回）を使う（第2回の「到達保証と暗号化は別のもの」）
queue.maxDiskSpaceを超えた分は捨てられるため、想定する停止時間 × ログの量から容量を見積もる（第7回）
送信側のディスクが、止まっている間の受け皿になるのです。
考えてみよう
- 担当のサーバーのrsyslogで、転送のアクションにキューは付いていますか。転送先が1時間止まったら、何が起きますか。
- ログの量が1秒あたり200件・1件300バイトのサーバーで、ログサーバーの4時間の停止に耐えるには、
queue.maxDiskSpaceをどれくらいにしますか。 - ネットワーク機器からUDPで受けているログは、ログサーバーの再起動の間、どうなりますか。どう減らせますか。
ヒント：この記事のメインキューとアクションキューの図、転送の設定の各パラメーター、欠損させない仕組みの図が手がかりです。2問目は200 × 300 × 14,400秒 ≒ 864MBです。
まとめ
- rsyslogは入力（im）→ パーサー → キュー → ルールセット → 出力（om）。設定ファイルはこの流れの書き並べ
- アクションは既定でDirect。転送先が止まるとメインキューごと詰まる。転送にはアクションキューを付ける
- TLS・RELPは別パッケージ。変更は「-N1 → 再起動 → 確認」
- 自分で書く設定はRainerScriptに。引用符は半角
- 受信は
input()ごとに専用のルールセットへ。RHELではfirewalldとSELinuxの関門も確かめる - 転送は
queue.type="LinkedList"・queue.filename・resumeRetryCount="-1"でためて送る。UDPはためられない
次回（後編）は、テンプレート、振り分け、TLS、RELP、メール発報、レート制限を扱います。
連載「syslog入門」全11回
全回の目次と、読む順番・目的別の読み方は、syslog入門の入口のページにまとめています。
- ログとは・なぜ集めるか
- syslogの基本
- Linuxのログの仕組み
- rsyslog 前編（この記事）
- rsyslog 後編
- Windows・ネットワーク機器のログ
- ログ集約基盤の設計
- 分析と監視・SIEM
- クラウドのログ
- syslogのトラブルシュート
- ログ管理の設計演習
コメント