rsyslogからFluent Bitへのログパイプライン移行｜バッファ設計と本番切り替え手順

rsyslogからFluent Bitへ移行する背景

rsyslogはRed Hat系・Debian系を問わず長年の実績を持つsyslogデーモンです。しかし、コンテナ環境や大量ログの集約、クラウドネイティブなバックエンドへの転送といった用途では、設定の複雑さとメモリ消費の大きさが課題になりやすい点が指摘されています。

Fluent Bitは、CNCFのFluentdエコシステムから派生した軽量ログプロセッサです。C言語で実装されており、フットプリントが小さく、KubernetesのDaemonSetやIoTエッジデバイスでの利用実績が積み重なっています。2026年現在、多くのLinuxディストリビューションが公式リポジトリにパッケージを収録しており、オンプレミスのサーバーログ集約にも実用的な選択肢となっています。

移行の動機は「rsyslogが悪い」ではなく、「パイプライン全体の均質化」や「Loki・OpenSearch・S3といったモダンなバックエンドへの直接書き出し」を低い運用コストで実現したいケースが多数を占めます。本記事では、既存rsyslog環境を止めずにFluent Bitへ移行するための設計と手順を解説します。

Fluent Bitのアーキテクチャとrsyslogとの対比

rsyslogはルールセット・テンプレート・モジュールという3層で構成され、フィルタリングと転送を1つの設定ファイル群に記述します。対してFluent Bitは、Input → Parser → Filter → Buffer → Outputというパイプライン構造を明示的に定義します。データフローが可視化されるため、複数のバックエンドへの並列出力や条件分岐が見通しやすくなっています。

rsyslogのomfwd（転送）やomfile（ファイル書き出し）に相当するのがFluent BitのOutputプラグインです。Loki向けのlokiプラグイン、S3向けのs3プラグイン、syslogプロトコルでの転送に使うsyslogプラグインなどが標準で同梱されています。既存のsyslogコレクタやElasticsearchへの移行も、プラグインの差し替えで対応できます。

なお、rsyslogが担っていたローカルの/var/log/書き出しは、移行期間中は並行稼働で維持するか、journaldのForwardToSyslog設定を一時的に残す方法が現実的です。

バッファ設計の考え方

Fluent Bitのバッファはメモリバッファとファイルシステムバッファの2種類から選択できます。デフォルトはメモリバッファですが、本番環境ではファイルシステムバッファを強く推奨します。プロセス再起動やバックエンド障害時にメモリ上のデータが失われるリスクを避けるためです。

バッファの主要パラメータは以下のとおりです。

• storage.type：filesystem を指定するとチャンクをディスクに書き出します。
• storage.path：チャンクを格納するディレクトリ。tmpfsではなく永続ストレージを指定します。
• storage.max_chunks_up：メモリに展開するチャンクの上限数。デフォルトは128。ディスクIOを抑えたい場合は小さく設定します。
• storage.backlog.mem_limit：バックログがメモリを使い過ぎないよう上限を設定します（例：50M）。

Outputプラグイン側ではstorage.total_limit_sizeを設定し、バックエンド障害時にディスクが枯渇しないよう上限を決めておきます。想定例として、syslogイベントが秒間5,000行程度のホストで72時間分のバックログを保持したい場合、1行200バイト換算で約250GBが必要になる計算です（あくまで概算であり、実際の行サイズやフォーマットにより変わります）。

バッファディレクトリのパーミッションは、Fluent Bitの実行ユーザー（デフォルトはfluent-bitまたはroot）のみが書き込めるよう制限します。ログには平文の認証情報が含まれることがあるため、chmod 700相当の設定が無難です。

本番切り替え手順

移行は「並行稼働→トラフィック切り替え→rsyslog停止」の3ステップで進めるのが定石です。ここでは主要な操作を順に示します。

ステップ1：Fluent Bitのインストールと設定検証

パッケージマネージャーでインストール後、fluent-bit --dry-run -c /etc/fluent-bit/fluent-bit.conf で設定ファイルの構文を検証します。2024年以降のバージョンではYAML形式の設定ファイルが安定して使えるようになっており、従来のINI形式（.conf）と共存できます。新規構成であればYAMLを選ぶと可読性が高まります。

ステップ2：rsyslogとFluent Bitの並行稼働

まずFluent BitのInputにsyslogプラグインをUDPまたはTCPで待ち受けさせます（例：ポート5140）。rsyslogの設定にaction(type="omfwd" target="127.0.0.1" port="5140" protocol="tcp")を追記し、Fluent Bitへの転送を開始します。この段階ではrsyslogも従来どおり動作しているため、ログの欠落リスクは最小化されます。

ステップ3：journaldとの接続に切り替える（任意）

rsyslog経由ではなく、Fluent Bitのsystemdプラグイン（systemd Input）を使いjournaldから直接取得する構成も選択できます。この場合はrsyslogへの依存を完全に切れますが、journaldのカーソル管理が必要になります。DBパラメータでカーソルDBのパスを指定すると、再起動後の重複取得を防げます。

ステップ4：rsyslogの転送設定削除とFluent Bitの単独稼働確認

並行稼働を数日〜1週間程度継続し、Fluent Bitのメトリクスエンドポイント（デフォルト：http://localhost:2020/api/v1/metrics）でドロップ数がゼロであることを確認してからrsyslog側の転送設定を削除します。最終的にrsyslogを停止する際はsystemctl stop rsyslogではなくsystemctl disable --now rsyslogでサービスの自動起動も無効化します。

動作検証と切り戻し

検証ポイントは以下の3点を最低限確認します。

• ログの到達確認：バックエンド（LokiやElasticsearch等）で直近のログが正常に検索できること。
• タイムスタンプの整合性：Fluent Bitのパーサーが既存のsyslogフォーマットを正しく解釈しているか。stdout Outputプラグインで一時的にターミナルに出力し、タイムゾーンとフォーマットを目視確認します。
• ドロップ数のゼロ確認：メトリクスAPIのoutput.dropped.recordsが増えていないこと。継続的にバックエンド障害が発生している場合はここに現れます。

切り戻し手順は事前に文書化しておくことが重要です。rsyslogをdisableにした後でも、systemctl enable --now rsyslogで即座に再起動できます。rsyslogの設定ファイルはFluent Bit移行後も削除せず保持しておき、Fluent Bitへの転送行のみコメントアウトした状態にしておくと、切り戻しが設定ファイルの1行変更で完結します。

よくあるつまずきとして、Fluent Bitのファイルシステムバッファが残ったままrsyslogに切り戻すと、バックエンドが復旧したタイミングでFluent Bitが旧チャンクを再送するケースがあります。切り戻し後にFluent Bitを完全停止するまでの間、バックエンド側で重複エントリが増えていないか確認する習慣をつけておくと安心です。

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

Fluent Bit v3系（2024年リリース）ではYAML設定の正式サポートに加え、プロセッサー（Processors）という概念が導入されています。従来はFilterプラグインで行っていた変換処理の一部をOutput直前のプロセッサーに分離できるようになっており、パイプラインの役割分担がより明確になっています。既存のv2系設定ファイルはそのままv3で読み込めますが、非推奨になったオプションについては起動ログに警告が出るため確認が必要です。

セキュリティ面では、Fluent Bitのメトリクスエンドポイントがデフォルトで0.0.0.0にバインドされている点に注意が必要です。外部からアクセスされないようhttp_server_host 127.0.0.1を明示的に設定するか、ファイアウォールでポート2020を遮断してください。

RHEL9・Rocky Linux 9系ではrsyslogパッケージが引き続きデフォルトインストールされていますが、journaldが主要なログ収集基盤となっており、rsyslogはjournaldの補完的な位置づけになっています。この構成ではFluent Bitのsystemdプラグインを使う移行経路が最もシンプルです。Ubuntu 22.04以降も同様の傾向にあります。

Fluent BitはCNCFのGraduatedプロジェクトではなくIncubatingステータスであった時期が長いですが、2025年にGraduatedに昇格しており、長期的なメンテナンスの見通しは改善されています。一方でrsyslogも活発に開発が続いており、特定のユースケース（複雑なフィルタリングルールや既存スクリプトとの連携）では依然として有力な選択肢です。移行の判断はパイプライン全体の要件と照らして検討することが重要です。