サーバー管理をしていて「複数台のログを一か所でまとめて確認できたら便利なのに」と思ったことはありませんか。
障害発生時に各サーバーへログインして、/var/log/messages や secure を一台ずつ確認するのは手間がかかりますし、情報が分散していると原因の切り分けも遅れがちです。
そんな場面で役立つのが rsyslog のログ転送機能です。rsyslog は Linux に標準搭載されているログ管理デーモンであり、ログの収集・分類・保存だけでなく、ネットワーク越しに他のサーバーへ転送する仕組みを備えています。
例えば、社内にログサーバーを立てておけば、アプリケーションサーバーやDBサーバーのログをまとめて収集し、一元的に監視することが可能になります。
セキュリティ監査や障害対応だけでなく、長期的なログ保管や分析基盤との連携にも有効です。
本記事では、rsyslogを使ったログ転送の基本から応用設定、活用の注意点までを解説していきます。
Linuxの基礎知識 🟡 ログ・監視系
📌 システムの健全性を保つためのログ活用と監視テクニック
└─【Linuxの基礎知識】ログ・監視系でよくあるトラブルと解決の入口
├─ 【Linuxの基礎知識】リソース監視ツールの使い方を徹底解説！
├─ 【Linuxの基礎知識】journalctlの具体的な使い方を初心者向けに解説
├─ 【Linuxの基礎知識】Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法
├─ 【Linuxの基礎知識】dmesgの読み方とハードウェアトラブル対応
├─ 【Linuxの基礎知識】vmstatとiostatでボトルネックを見抜く
├─ 【Linuxの基礎知識】sarコマンドでサーバー性能を長期監視する方法
├─ 【Linuxの基礎知識】top / htopの違いと使い分け｜リアルタイム監視の基本
└─ 【Linuxの基礎知識】rsyslogでログを転送する方法と設定例
rsyslogとは
rsyslogはLinuxで広く利用されているログ管理システムで、システムやアプリケーションが出力するログを収集・分類・保存するためのデーモンです。
標準的なsyslog機能を拡張しており、ログをローカルに保存するだけでなく、リモートサーバーへの転送やフィルタリング、フォーマット変換など多機能に対応しています。
基本概要
rsyslogは、/etc/rsyslog.confや/etc/rsyslog.d/以下の設定ファイルをもとに動作します。ログを受け取ると、その内容に基づいてフィルタリングし、指定されたファイルやリモート先へ出力します。
rsyslogはサービスとして動作しているため、systemctlでの制御が可能です。
systemctl status rsyslog
【出力例:】
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
Active: active (running) since Fri 2025-09-05 10:12:34 JST; 1h 23min ago
Main PID: 1123 (rsyslogd)
Tasks: 3 (limit: 11000)
Memory: 5.8M
CGroup: /system.slice/rsyslog.service
└─1123 /usr/sbin/rsyslogd -n
このように、rsyslogが起動していればログ収集がバックグラウンドで継続されます。
収集できるログの種類
rsyslogはカーネルやシステム全般、各種サービス、ユーザー操作ログなど幅広い種類のログを取り扱うことができます。
ログは「ファシリティ」と呼ばれる分類で区別され、用途に応じて保存先や転送方法を柔軟に制御できます。
代表的なログの種類は以下の通りです。
| ファシリティ | 対象ログ |
|---|---|
| auth, authpriv | 認証関連（ログイン、sudoなど） |
| cron | cronジョブの実行記録 |
| daemon | システムサービスのログ |
| kern | カーネルメッセージ |
| メール関連ログ | |
| user | ユーザープロセスのログ |
| local0-local7 | 管理者が任意に利用できるカスタムログ |
これらを利用することで、サービスごとにファイルを分けたり、特定のログだけを別サーバーへ転送したりすることが可能です。
利用するメリット
rsyslogを利用するメリットは、単なるログ保存にとどまりません。
大規模環境では集中管理の役割を果たし、セキュリティ監査や障害調査の効率を大幅に高めることができます。さらに、TLSによる暗号化通信やJSONフォーマットでの出力など、最新のセキュリティや分析環境への対応も可能です。
具体的なメリットは以下の通りです。
| メリット | 詳細 |
|---|---|
| ログの集中管理 | 複数サーバーのログを一元的に収集できる |
| 柔軟なフィルタリング | 必要なログだけを抽出し、保存や転送が可能 |
| 高い拡張性 | モジュールを追加して機能を拡張できる |
| セキュア通信 | TLSを用いた暗号化転送が可能 |
| 多様な出力形式 | ファイル、データベース、外部システムへ出力可能 |
これにより、システム運用の効率化だけでなく、セキュリティと可観測性の向上も実現できます。
rsyslogの導入手順
rsyslogは多くのLinuxディストリビューションで標準搭載されていますが、環境によってはインストール作業が必要です。
ここではRHEL系を前提とした導入手順と、サービスの有効化・起動確認方法について解説します。
インストール方法
RHEL系の環境では、dnfやyumを用いてrsyslogをインストールできます。すでにインストール済みの場合でも、最新パッケージに更新しておくことを推奨します。
dnf install -y rsyslog
【出力例:】
Installed: rsyslog.x86_64 0:8.2102.0-15.el9 Complete!
この出力が表示されれば、rsyslogが正常にインストールされています。
サービスの有効化と起動確認
インストール後は、systemctlコマンドでrsyslogサービスを有効化し、起動状態を確認します。
systemctl enable rsyslog
systemctl start rsyslog
systemctl status rsyslog
【出力例:】
● rsyslog.service - System Logging Service
Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled)
Active: active (running) since Fri 2025-09-05 10:12:34 JST; 1h 23min ago
Main PID: 1123 (rsyslogd)
Tasks: 3 (limit: 11000)
Memory: 5.8M
CGroup: /system.slice/rsyslog.service
└─1123 /usr/sbin/rsyslogd -n
「active (running)」と表示されていれば、rsyslogは正常に稼働しています。これでログ収集と転送のための準備が整います。
rsyslogの基本設定
rsyslogを導入した後は、どのログをどの場所へ出力するかを設定する必要があります。基本的な設定はテキストファイルで行い、細かい制御が可能です。
ここでは設定ファイルの仕組みから、フィルタリング方法、そしてリモートへの転送設定までを確認します。
設定ファイルの構成
rsyslogの設定は「/etc/rsyslog.conf」と「/etc/rsyslog.d/」ディレクトリに分けられています。
rsyslog.confはメインの設定を記述する場所であり、rsyslog.d配下には追加のルールファイルが格納されます。初期状態では最低限のファイルしか存在せず、環境によって内容は異なります。
ls /etc/rsyslog.d/
【出力例:】
21-cloudinit.conf user.conf
このように、導入直後はわずかな設定ファイルしか含まれていません。必要に応じて任意のファイルを作成し、ログ転送やカスタムルールを追加していきます。
ログ出力とフィルタリングの基本
rsyslogは「ファシリティ」と「優先度」を指定することで、どのログをどこへ出力するかを決定します。
設定は「ファシリティ.優先度 出力先」という形式で記述します。
authpriv.* /var/log/secure
mail.err /var/log/mail.err
*.info;mail.none;authpriv.none /var/log/messages
上記の例では、認証関連のログを/var/log/secureへ、メール関連のエラーを/var/log/mail.errへ、そして全般的な情報ログを/var/log/messagesに保存しています。優先度は「info」「warn」「err」などで調整可能です。
転送設定の基本例
rsyslogではログをリモートサーバーへ転送することが可能です。転送先は「ホスト名またはIPアドレス」と「ポート番号」で指定し、プロトコルは @ の数で区別されます。
リモート転送設定
- @ を1つ指定すると UDP での転送になります。
- @ を2つ指定すると TCP での転送になります。
UDPは軽量で処理が速い一方、パケットロスの可能性があります。TCPは信頼性が高く、ログの欠損を防げますが、通信負荷はやや高くなります。運用環境に応じて選択してください。
*.* @192.168.1.100:514 # UDP転送
*.* @@192.168.1.100:514 # TCP転送
この設定では、すべてのログを192.168.1.100の514番ポートへ転送します。UDPは速度重視、TCPは信頼性重視の用途で使い分けると効果的です。
設定ファイルを分割して管理する仕組み
rsyslogのメイン設定は /etc/rsyslog.conf に記載されていますが、この中にはあらかじめ以下の記述が含まれています。
$IncludeConfig /etc/rsyslog.d/*.conf
この行によって、/etc/rsyslog.d/ 配下にあるすべての .conf ファイルが自動的に読み込まれる仕組みになっています。
つまり、細かい転送設定やサービスごとの出力ルールは、/etc/rsyslog.d/ に独立したファイルとして保存するのが推奨されます。
例として、リモート転送用に forward.conf を作成する場合は次のようになります。
vi /etc/rsyslog.d/forward.conf
*.* @@192.168.1.100:514
このように分割管理することで、rsyslog.conf を最小限に保ちつつ、設定の追加や変更が容易になります。これはApache httpd の httpd.conf と conf.d/*.conf の関係と同じ考え方です。
rsyslogの応用設定
基本的な設定だけでもログの収集や保存は可能ですが、実際の現場では「リモートにまとめたい」「通信を暗号化したい」「保存場所や期間を調整したい」といった要望が出てきます。
ここでは一歩踏み込んだ応用設定として、リモート転送、セキュア通信、保存期間やディレクトリ構成のカスタマイズについて解説します。
TCP/UDPによるリモート転送
rsyslogを使うと、ログを別のサーバーへ直接送ることができます。これにより、障害発生時も一か所にまとまったログを確認できるため、調査のスピードが格段に上がります。
転送の方法は「UDP」と「TCP」があり、設定ファイルは /etc/rsyslog.d/ に forward.conf などを作成して記述します。
vi /etc/rsyslog.d/forward.conf
転送設定の書き方は以下のようになります。
*.* @192.168.1.100:514 # UDP転送
*.* @@192.168.1.100:514 # TCP転送
ここで注意が必要です。
この2行を同時に書くと、同じログがUDPとTCPの両方に送られ、受信側では二重に記録されてしまいます。したがって通常はどちらか片方を選択してください。
２種類の転送ブロとコル
- UDP（@）：軽量で高速だが、パケットロスの可能性がある
- TCP（@@）：信頼性が高く欠損しないが、負荷がやや大きい
もし「普段はTCPで送りたいが、TCPが切れたときはUDPでもよい」というケースでは、failover構成を利用します。
以下のように設定すれば、まずTCPで送信を試み、失敗した場合のみUDPへ切り替えます。
*.* @@192.168.1.100:514
action.resumeRetryCount -1
action.type omfwd
action.protocol udp
action.target 192.168.1.100
action.port 514
このように設定することで、通常時はTCPの信頼性を享受し、万一の障害時にはUDPでログを飛ばし続けることが可能になります。
| 設定項目 | 内容 |
|---|---|
| *.* @@192.168.1.100:514 | まずはTCP（@@）で192.168.1.100:514へ全ログを送信する |
| action.resumeRetryCount -1 | TCP接続が切れた場合、無限に再試行を続ける |
| action.type omfwd | ログ転送に利用するモジュールを指定（omfwd＝forward） |
| action.protocol udp | フォールバック時の通信プロトコルをUDPに指定 |
| action.target 192.168.1.100 | フォールバック先の送信先サーバーを指定 |
| action.port 514 | フォールバック時の送信ポート番号を指定 |
セキュア転送（TLS/加密）
外部へ転送する場合はTLSを有効化するのが安全です。TLS転送を設定するには証明書を用意し、専用の設定ファイルを作成します。
vi /etc/rsyslog.d/forward-tls.conf
内容例は以下の通りです。
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/rsyslog.d/ca.crt
$DefaultNetstreamDriverCertFile /etc/rsyslog.d/client.crt
$DefaultNetstreamDriverKeyFile /etc/rsyslog.d/client.key
*.* @@(o)192.168.1.100:6514
設定後にサービスを再起動します。
systemctl restart rsyslog
@@(o) とすることで、暗号化されたTCP通信でログを送信できます。
保存期間やディレクトリ構成の指定
大量のログを扱うと「どのくらい保存するか」「どこに保管するか」が問題になります。rsyslog自体には保存期間の制御機能はなく、ログローテーション機能（logrotate）と組み合わせて管理するのが一般的です。
logrotateの設定例は以下の通りです。
/var/log/secure {
weekly
rotate 12
compress
missingok
notifempty
}
この例では「毎週ローテーション」「12世代保持」「古いログは圧縮」というルールになります。さらにrsyslogの設定側で出力先を分けておくと、サービスごとに整理されたディレクトリ構成を実現できます。
authpriv.* /var/log/secure
mail.* /var/log/mail/mail.log
cron.* /var/log/cron/cron.log
このように整理しておけば、監査対応や障害解析の際に目的のログへ素早くたどり着けます。
rsyslogの活用例
基本設定や転送設定を行っただけでも十分便利ですが、実際の運用現場ではさらに応用的な活用が求められます。特に複数台のサーバーをまとめて監視する仕組みや、障害解析の切り札、さらには分析基盤との連携など、rsyslogは幅広く役立ちます。
複数サーバーからの集中管理
運用しているサーバーが増えると、それぞれのログを個別に見て回るのは現実的ではありません。rsyslogを利用してログサーバーへ集約することで、すべての記録を一か所にまとめることができます。
*.* @@192.168.1.100:514
【出力例（集中管理サーバー側のログ）:】
Sep 08 13:01:11 web01 httpd[1321]: Started worker process
Sep 08 13:01:15 app01 java[1843]: Connection pool initialized
Sep 08 13:01:18 db01 postgres[2201]: Autovacuum started
このように複数サーバーの動きを一画面で追えるようになり、障害対応の初動が早くなります。
トラブルシュートでの活用
突然サービスが落ちたり、レスポンスが極端に遅くなったりすることがあります。そのとき頼りになるのがrsyslogに蓄積されたログです。どのタイミングで異常が発生したか、どのサービスが連鎖的に影響を受けたかを把握する材料になります。
grep "error" /var/log/messages
【出力例:】
Sep 08 13:22:09 app01 java[1867]: ERROR Failed to connect to database
Sep 08 13:22:09 app01 java[1867]: ERROR Retrying in 30 seconds
このようにエラーメッセージを即座に検索できるため、原因究明までの時間を大きく短縮できます。
他ツール（journalctlやELK）との組み合わせ
rsyslogは単体で完結させるだけでなく、他のツールと組み合わせることでさらに効果を発揮します。
systemd環境では journalctl が事実上の標準ログ参照ツールですが、rsyslog経由で扱うと柔軟に転送やフィルタリングが可能です。
また、ELKスタック（Elasticsearch、Logstash、Kibana）と組み合わせれば、集めたログを検索・可視化する強力な分析基盤が構築できます。
rsyslogからLogstashへ転送することで、グラフ化やダッシュボード表示も簡単に行えるようになります。
| ツール | 組み合わせのメリット |
|---|---|
| journalctl | systemdログを詳細に確認可能、rsyslogと合わせて出力先を柔軟に制御 |
| ELKスタック | 収集したログを検索・可視化、ダッシュボード化して傾向分析に利用可能 |
| 外部SIEM製品 | セキュリティイベントの検知や監査証跡として活用できる |
このように、rsyslogを中心に据えることで、単なるログ収集から「分析と活用」へと発展させることができます。
rsyslog利用時の注意点
rsyslogは非常に便利なログ管理システムですが、運用する際には気をつけるべき点も多く存在します。
ここでは特に重要な「ログ容量とディスク管理」「パフォーマンスへの影響」「設定変更時の落とし穴」について解説します。
これらを理解していないと、想定外のトラブルに直面する可能性があります。
ログ容量とディスク管理
ログは日々増え続けるため、容量管理を怠るとあっという間にディスクが埋まってしまいます。
特にrsyslogでリモート転送とローカル保存を併用している場合、無駄に同じログが蓄積されやすい点に注意が必要です。 容量管理には logrotate を組み合わせ、世代数や圧縮を適切に設定します。
vi /etc/logrotate.d/messages
/var/log/messages {
daily
rotate 7
compress
missingok
notifempty
}
この例では「毎日ローテーション」「7世代保持」「古いログは圧縮保存」となります。これによりディスク枯渇のリスクを軽減できます。
パフォーマンスへの影響
rsyslogは便利な反面、すべてのログを無条件に保存・転送してしまうとディスクやネットワークの負荷が大きくなります。
特に高トラフィックな環境ではログ処理がボトルネックになることもあります。
そのため「必要なログだけを残す」設定を追加して、余計な処理を避けることが重要です。 フィルタリングの設定は /etc/rsyslog.conf または /etc/rsyslog.d/任意のファイル.conf に1行単位で記述します。
例えば以下のように記載すると、情報レベル以上のログを保存しつつ、mail・authpriv・cronのログは対象外にできます。
*.info;mail.none;authpriv.none;cron.none /var/log/messages
これは1行で完結するルールです。設定を保存した後は、反映のためにrsyslogを再起動してください。
systemctl restart rsyslog
【出力例:】
Sep 09 10:45:01 app01 CRON[2456]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Sep 09 10:45:02 app01 systemd[1]: Started Session 1024 of user root.
Sep 09 10:45:05 app01 sshd[2480]: Accepted password for user1 from 192.168.1.50 port 55912 ssh2
このようにルールを調整することで、不要なログを削減し、システム全体のパフォーマンスを安定させることができます。
大規模環境で実際に発生した帯域不足の事例
ある大規模システムの設計に関わった際、ログサーバーをクラウド環境に構築したものの、想定以上にログ転送が集中してしまい、ネットワーク帯域がボトルネックとなって運用に耐えられなくなった事例がありました。rsyslogそのものは正しく動いていても、下支えするネットワークが限界を迎えた形です。
この課題を解決するために、最終的にはオンプレミス環境へ移行し、高速インターフェースをリンクアグリゲーションで束ねる構成を採用しました。これにより帯域不足の問題を解消し、安定した集中ログ基盤を実現することができました。
この教訓から得られるのは、ログサーバーを設計する際にはネットワークと同時にストレージ設計にも目を向けることの重要性です。十分なディスク本数とI/O帯域を確保して初めて、安定したログ処理が可能になります。
設定変更時の落とし穴
rsyslogは設定の自由度が高い反面、ちょっとした書き間違いが原因でログが保存されなかったり、転送が止まってしまうことがあります。
ファイルのパスや「@ と @@ の違い」を誤解しただけでも、意図通りに動作しません。そのため、設定を編集したあとには 反映前に構文チェックを行う ことが推奨されます。
rsyslogには設定ファイルを検証するオプションが用意されており、以下のように実行します。
rsyslogd -N1
【出力例:】
rsyslogd: version 8.2102.0, config validation run (level 1), completed with 0 errors.
このようにエラーが出なければ設定内容は正しく解釈されています。
すぐにサービスを再起動してしまうのではなく、まず構文チェックを通す習慣を持つことで、運用トラブルを未然に防げます。
まとめ
rsyslogはLinux環境で欠かせないログ管理の中核であり、単純な保存だけでなく、転送・フィルタリング・暗号化・分析基盤との連携など多彩な機能を持っています。本記事では導入方法から基本設定、リモート転送やTLSによるセキュア通信、さらに保存期間やディレクトリ構成の調整、そして運用上の注意点までを解説しました。
ログはシステムの「証拠」とも言える重要な情報です。rsyslogを適切に運用すれば、障害対応やセキュリティ監査にかかる時間を大幅に短縮でき、安心してサービスを提供できる環境につながります。特に複数台のサーバーを管理する場合には集中管理が有効であり、必要に応じてELKなどの外部ツールと組み合わせることで、より高い可視性を実現できます。
最後に強調すべきは「適切なフィルタリング」と「定期的な設定確認」です。不要なログでディスクを圧迫しないよう調整しつつ、rsyslogd -N1 で設定を検証し、安定したログ基盤を維持してください。これにより日々の運用負荷が軽減され、万一のトラブルにも素早く対応できる体制を整えることができます。
