rsyslogとは？Linuxのログ収集・転送の仕組みとrsyslog.conf設定・導入判断を実装目線で解説

rsyslogとは、Linuxサーバーの各所から出力されるログを集め、種類ごとに仕分けてファイルに保存したり、別のサーバーへ転送したりする、ログ管理の中核を担うデーモンです。多くのディストリビューションに標準で組み込まれており、SSHの認証記録からWebサーバーのアクセス記録、カーネルのメッセージまで、システムのあらゆる出来事を1か所に束ねる「ログの交通整理役」として動きます。この記事では、rsyslogが何を集めてどこへ出すのかという定義から、journaldとの関係やimjournalを起点としたログの流れ、FacilityとSeverityによる分類、rsyslog.confを構成するモジュール・グローバルディレクティブ・ルールの3つのパートと書き方、複数サーバーのログを1台に集めるリモート転送とログサーバー構築、そしてjournald単体やクラウドのマネージドなログ基盤との使い分けと、どんなときにrsyslogを採用しどんなときに見送るかまでを、Linuxサーバーを運用する実装者と発注者の双方が判断に使える形で整理します。

まとめ｜rsyslogの正体とログ基盤で押さえる要点

rsyslogは、サーバー内で発生したログを受け取り、Facility（ログの発生源の種別）とSeverity（深刻度）で仕分けて、決めた宛先へ書き出す「ログのルーター」です。動きは入口・処理・出口のモジュールで組み立てられています。多くのRHEL系ではjournaldが受けたログをimjournalという入力モジュールが取り込み、ルールに従って仕分けたうえで、omfileが/var/log/配下のファイルへ、omfwdが遠隔のサーバーへ書き出す流れです。設定は/etc/rsyslog.confと/etc/rsyslog.d/配下に書き、中身は「どのモジュールを読み込むか」「全体の既定動作」「どのログをどこへ出すか（セレクタとアクション）」の3つのパートに分かれます。

実務でまず押さえたいのは、rsyslogは単体のログ保存ツールではなく、複数サーバーのログを1台に集約する土台になる点です。UDPやTCP、信頼性の高いRELPでログを別サーバーへ転送でき、集めたログを監視ツールやSIEMへ渡して初めて、障害の追跡やセキュリティ調査に使えます。向くのは、自前で運用するLinuxサーバー群のログを一元管理したい場面です。ログをファイルに落とさず参照するだけならjournald単体で足りることもあり、クラウドのマネージドなログ基盤に集約する構成では、rsyslogを転送役に絞る判断もあります。以下で定義・仕組み・設定・集約・採否の判断を順に解説します。

rsyslogとは｜Linuxログの収集・仕分け・保存・転送を担うデーモンの定義

最初にrsyslogが何をするソフトなのかを固めます。ここが曖昧だと、後半のjournaldとの使い分けや、リモート集約の設計、採用するかどうかの判断が宙に浮きがちです。rsyslogは、システム各所が吐き出すログメッセージを受け取り、仕分けて、保存または転送する常駐プロセスとして動きます。

rsyslogが担う役割：ログの収集・分類・保存・転送の4工程

rsyslogの仕事は4つの工程に分けられます。第一に、カーネル・各種デーモン・アプリケーションが出すログを受け取る収集の工程です。第二に、受け取ったログを発生源の種別と深刻度で仕分ける分類を行います。第三に、仕分けた結果を/var/log/messagesや/var/log/secureといったファイルへ書き出す保存です。第四に、必要なログを別のログサーバーへ送り出す転送です。この4工程を1つのデーモンでまかなうため、rsyslogはサーバーごとにばらばらだったログ出力を、決めたルールで一貫して扱う基盤になります。rsyslogは「rocket-fast system for log processing」を名乗る実装で、旧来のsyslogdより高速な処理と、モジュールによる機能拡張、リモート転送やフィルタリングの柔軟さを備えているのが採用理由です。

syslog・syslogd・journaldとrsyslogの関係と違い

rsyslogを理解するには、周辺の用語との関係を整理すると早いです。「syslog」はログを記録・伝送するための仕組みや規格の総称で、特定のソフトを指しません。その規格を実装した最初期のデーモンが「syslogd（sysklogd）」で、rsyslogはその後継として機能を大幅に広げた実装にあたります。一方「journald（systemd-journald）」は、systemdが備えるログ収集の仕組みで、バイナリ形式のジャーナルにログを保管します。現在の多くのディストリビューションでは、まずjournaldがログを受け、それをrsyslogが取り込んで従来型のテキストログ（/var/log/配下）として残す、二段構えの構成が既定です。両者の違いを整理します。

journaldはローカルでの構造化検索に強く、rsyslogはテキストへの書き出しと複数サーバーへの集約に強い、と役割が分かれます。両者は競合ではなく、journaldが受けてrsyslogが配る組み合わせで使われるのが一般的です。

rsyslogを標準のログ基盤として使う理由：他ツールがログを前提にする

ログは、それ自体を眺めるためではなく、後段のツールに使わせるために整えます。たとえば認証失敗のログを見張って攻撃元IPを自動遮断するFail2banとは？SSH総当たり攻撃を自動遮断する仕組みと設定・導入判断を実装目線で解説で扱う仕組みは、rsyslogやjournaldがsecureログへ書き出した認証記録があって初めて機能します。監視ツールがログの特定パターンで警報を上げるのも、SIEMがサーバー横断でログを相関分析するのも、すべて土台にrsyslogのような一貫したログ出力があることが前提です。rsyslogを整えることは、その上に載る監視・防御・分析の精度をまとめて底上げする作業だと捉えると、位置づけがつかめます。

rsyslogの仕組み｜モジュール構成とjournaldからのログの流れ

rsyslogの動きは、入力・処理・出力を担うモジュールの連なりを見ると理解しやすくなります。全体像さえ押さえれば、どこに何を設定するソフトなのかは難しくありません。ここではモジュールの種類と、journaldからファイル出力までの流れ、そして仕分けの軸になるFacilityとSeverityを確認します。

Input・Output・Parserモジュールとログ処理パイプライン

rsyslogはモジュールの組み合わせで機能を組み立てる設計です。入口を担うInputモジュールには、journald経由でログを取り込むimjournal、/dev/logソケットから受け取るimuxsock、指定したファイルを追尾するimfile、ネットワークからログを受信するimudp・imtcpがあります。受け取ったログはParserやRuleset（規則の集合）を通って仕分けられ、出口のOutputモジュールへ渡されます。Outputには、ファイルへ書き出すomfileと、遠隔サーバーへ送るomfwdが代表格です。多くのRHEL系ではimjournalが既定の入口で、journaldが受けたログをrsyslogが取り込み、ルールに従って仕分けたうえでomfileが/var/log/配下へ書き出す、という一本のパイプラインが動いています。必要な入口と出口のモジュールを足し引きするだけで、ファイル保存だけの構成にも、集約サーバーへ転送する構成にも組み替えられます。

FacilityとSeverity：ログを仕分ける2つの分類軸

rsyslogがログを仕分ける物差しは、FacilityとSeverityの2軸です。Facilityはログの発生源の種別で、認証系のauth・authpriv、カーネルのkern、定期実行のcron、メールのmail、各種デーモンのdaemon、そして利用者が自由に使えるlocal0〜local7などがあります。Severityは深刻度で、緊急のemergから、alert・crit・err・warning・notice・info、詳細なdebugまで8段階です。この「どこから出たか（Facility）」と「どれだけ深刻か（Severity）」の組み合わせで、たとえば「認証系の警告以上は/var/log/secureへ」「メール関連はすべて別ファイルへ」といった仕分けを指定します。分類軸が2つに固定されているため、仕分けルールは簡潔に書け、後からログの行き先を変えるのも容易です。

rsyslogの設定｜rsyslog.confを構成する3パートとセレクタの書き方

ここまでの仕組みを、動く設定に落とします。rsyslogの設定は/etc/rsyslog.confを起点に、/etc/rsyslog.d/配下の分割ファイルへ書き足していきます。設定ファイルの中身は3つのパートに分かれており、この構造さえ掴めば読み書きに迷いません。

設定を構成するモジュール・グローバルディレクティブ・ルールの3パート

rsyslog.confは、役割の異なる3つのパートで構成されます。1つ目はモジュールの読み込みで、module(load="imjournal")のように、使う入力・出力モジュールを有効化する部分です。2つ目はグローバルディレクティブで、ログファイルの所有者や権限、ワークディレクトリ、状態ファイルの置き場所といった全体の既定動作を決めます。3つ目がルールで、実際に「どのログをどこへ出すか」を1行ずつ指定する中心部分です。設定を変えるときは、まずこの3つのどこに手を入れる話なのかを見分けると迷いません。ディストリビューションの更新でメインのrsyslog.confが上書きされる場合に備え、自分で足す設定は/etc/rsyslog.d/配下に個別ファイルとして置くと、更新の影響を受けにくく管理しやすくなります。

セレクタ（facility.priority）とアクションの書き方

ルール部分の1行は、「セレクタ」と「アクション」の組で書きます。セレクタはfacility.priorityの形式で対象のログを絞り込み、アクションでその宛先を指定する構造です。たとえばauthpriv.*なら認証系のすべての深刻度が対象になり、続けて書いたファイルパスへ書き出されます。priority側は「その深刻度以上」を意味し、.warningと書けばwarning以上が対象です。複数の条件を組み合わせたり、特定のFacilityだけ除外したりする書き方も可能です。アクションには、ファイルパスのほか、後述するリモート転送や、プログラムへの引き渡しなどを指定できます。まずは既定のルールを読み、「どのセレクタがどのファイルに対応しているか」を追うと、自分のサーバーのログがどこに落ちているかを把握できます。

RainerScriptと従来記法・rsyslog.dでの設定分割

rsyslogの設定記法には2系統があります。1つは旧来のsyslogd互換記法で、facility.priority　宛先という簡潔な1行形式です。もう1つが現行のRainerScriptで、module()やaction()、if文による条件分岐を使った、より表現力の高い記法です。単純な仕分けは互換記法で足り、条件分岐や高度なフィルタ、テンプレートによる整形が必要ならRainerScriptを使う、という住み分けになります。両者は1つの設定内に混在できますが、複雑な処理を互換記法で無理に書くと読みにくくなるため、込み入った条件はRainerScript側へ寄せるのが実装上の勘所です。設定は機能ごとに/etc/rsyslog.d/配下のファイルへ分けておくと、どのファイルが何を担っているかが一目で分かり、変更の影響範囲も絞り込めます。

rsyslogのログ集約｜リモート転送とログサーバー構築の設計

rsyslogの価値が最も出るのが、複数サーバーのログを1台に集める集約です。各サーバーにログが散らばったままでは、障害調査のたびに何台もにログインして突き合わせる手間がかかります。ここでは転送方式の違いと、集めたログを監視・分析へつなぐ設計を確認します。

UDP・TCP・RELPによるリモートログ転送方式の違いと選び方

ログの転送方式は主に3つあり、信頼性と手軽さのバランスで選びます。設定では従来記法の記号でも指定でき、UDPは@host:514、TCPは@@host:514のように表します。

UDPは負荷が軽い反面、ネットワークが混むとログが欠落します。TCPは再送があるぶん欠落しにくく、一般的なログ集約ではまずTCPを選べば外しません。監査ログのように1行の欠落も許されない用途では、rsyslog独自のRELP（imrelp／omrelp）を使うと、送信側と受信側で到達を確認しながら送れます。転送を受ける集約サーバー側では、imudpやimtcpを有効にして受信ポート（既定は514）を開け、送られてきたログを送信元ホストごとに仕分けて保存する設計にすると、後からの追跡が楽になります。

集約したログを監視・SIEM・自動防御へつなぐ連携設計の考え方

ログは集めただけでは価値になりません。集約したログを、後段の監視・分析・防御へ渡して初めて運用に効きます。異常なログのパターンで警報を上げる監視、複数サーバーのログを相関させて脅威を見つけるSIEM、特定のログを見て自動で遮断する防御が、代表的な渡し先です。セキュリティ面では、rsyslogが集めた認証ログを相関分析する先として、Google SecOpsを構成する主要コンポーネント：SIEMとSOARの解説で扱うSIEM/SOARのような基盤があり、サーバー横断でのログ調査や自動対応につながります。同じサーバー内で完結する防御なら、rsyslogやjournaldが書いたsecureログを監視するFail2banのようなツールが、ログを入力として攻撃元を締め出す仕組みです。rsyslogは、これら監視・分析・防御のどれにログを流すかを、セレクタと転送先の設計で決める土台になります。

rsyslogの採用判断｜自前運用・journald単体・マネージドの使い分け

rsyslogは万能ではなく、これ1つでログ運用が完結するわけでもありません。ここではjournald単体で足りる場面や、クラウドのマネージドなログ基盤との使い分けを整理したうえで、どんなときにrsyslogを採用し、どんなときに見送るかを条件付きで言い切ります。

rsyslogを採用すべき場面：自前運用のLinuxサーバー群のログ一元化

rsyslogが第一候補になるのは、次の条件が重なるときです。オンプレミスや自前で構築したクラウドVM上に複数のLinuxサーバーがあり、それらのログを1台に集約して横断的に追跡したい場合。加えて、監査や障害調査のためにテキスト形式でログを長期保存したい、あるいはFacilityごとに宛先を細かく仕分けたい場合。この条件がそろうなら、追加費用なしに導入でき、UDP/TCP/RELPで集約先を選べて、セレクタで柔軟に仕分けられるrsyslogは、費用対効果の高いログ基盤になります。まずは各サーバーのrsyslogに転送設定を加え、集約サーバー側で送信元ごとに保存する構成から始めると、無理なく一元化を進められます。

rsyslogを見送る・最小化すべき場面とインフラ設計を相談する判断軸

逆に、次の場合はrsyslogに頼りきらないほうが合理的です。第一に、単一のサーバーでログをその場で参照するだけなら、journald単体でも足り、rsyslogでテキストへ二重に書き出す必要性は下がります。ログをファイルに残さず、journalctlで検索できれば用が済む構成では、rsyslogの役割は限定的です。第二に、クラウドのマネージドなログ基盤へログを集める構成では、rsyslogは各サーバーからその基盤へ送り出す転送役に絞り、仕分けや長期保存はマネージド側へ寄せる判断が合理的です。ログはメトリクスやトレースと並ぶ観測の柱の一つで、その全体像はオブザーバビリティとは何か：その定義と重要性についてで整理したとおり、ログ単体でなく監視全体の設計として捉える必要があります。どこまでを自前のrsyslogで集約し、どこからをマネージドなログ基盤に任せるかは、サーバー台数・保存期間・監査要件から逆算する設計判断です。複数サーバーのログ集約を含む本番インフラの構成設計や構築に迷う場合は、可用性・運用設計を含めたインフラ構築（AWS/GCP/Azure）の受託で、ログ基盤の設計から相談できます。

rsyslogによるLinuxサーバーのログ管理に関するよくある質問

検索されることの多い疑問に、仕組みと運用の両面から簡潔に答えます。

rsyslogとは何ですか？

Linuxサーバーの各所が出力するログを受け取り、Facility（発生源）とSeverity（深刻度）で仕分けて、ファイルへの保存や別サーバーへの転送を行うログ管理デーモンです。多くのディストリビューションに標準搭載され、旧来のsyslogdの後継として高速な処理・モジュールによる拡張・リモート転送に対応します。監視やSIEM、自動防御といった後段のツールが使うログの土台を整える役割を担います。

rsyslogとjournaldはどう違い、どちらを使いますか？

journaldはsystemdが備えるログ収集の仕組みで、バイナリのジャーナルに保管し、その場での構造化検索に強みがあります。rsyslogは、テキストファイルへの書き出しと複数サーバーへの集約に強みがある実装です。現在の多くのディストリビューションでは、journaldが受けたログをrsyslogが取り込む二段構えが既定で、どちらか一方ではなく、ローカル検索はjournald、集約と長期保存はrsyslogと役割分担して併用します。

rsyslogの設定ファイルはどこにあり、どう書きますか？

メインは/etc/rsyslog.confで、追加の設定は/etc/rsyslog.d/配下の分割ファイルに書きます。中身はモジュールの読み込み・グローバルディレクティブ・ルールの3パートに分かれ、ルールはfacility.priority　宛先のセレクタとアクションの組で書く構造です。単純な仕分けは従来のsyslogd互換記法で足り、条件分岐やテンプレート整形が必要なら現行のRainerScript記法を使います。更新で上書きされないよう、自分の設定はrsyslog.d配下に置くのが安全です。

rsyslogで別サーバーへログを転送するには？

送信側のルールで宛先にリモートサーバーを指定します。従来記法ではUDPが@host:514、TCPが@@host:514で、欠落を許さない用途にはRELP（imrelp/omrelp）を使う形です。受信側の集約サーバーでは、imudpやimtcpを有効にして受信ポートを開け、送信元ホストごとに仕分けて保存する設計です。一般的な集約では、再送で欠落を抑えられるTCPを既定に選ぶと安定します。

rsyslogだけでログ運用は完結しますか？

完結しません。rsyslogはログを集めて仕分け・転送する土台で、その先の監視・分析・防御は別のツールが担います。集めたログを監視ツールで警報化し、SIEMで相関分析し、Fail2banのような仕組みで自動遮断する、という組み合わせで初めて運用に効きます。単体のログ保存で終えず、後段でログをどう使うかまで設計して、rsyslogのセレクタと転送先を決めるのが適切な使い方です。

関連記事

• Fail2banとは？SSH総当たり攻撃を自動遮断する仕組みと設定・導入判断を実装目線で解説：rsyslogやjournaldが書き出す認証ログを入力として攻撃元を自動遮断する、ログの代表的な利用先を解説しています。
• Google SecOpsを構成する主要コンポーネント：SIEMとSOARの解説：rsyslogで集約したログをサーバー横断で相関分析するSIEM/SOARの仕組みを整理しています。
• Zabbixとは？概要からインストール方法までわかりやすく解説：rsyslogが整えたログと並ぶ、サーバー監視の代表的なツールの概要を解説しています。
• オブザーバビリティとは何か：その定義と重要性について：ログを含むメトリクス・トレースを合わせた、監視全体の設計思想を整理しています。