Linuxのログ管理を担う rsyslog は、サーバー運用中に再起動が必要なシーンが多くあります。
この記事では、rsyslogのステータス確認・起動・停止・再起動の各コマンドを、CentOS 6以前(SysVinit)とCentOS 7以降(systemd)の両方で解説します。設定ファイル(/etc/rsyslog.conf)の読み方・リモートへのログ転送・カスタム設定例・トラブルシュートまで実践的にまとめています。
この記事のポイント
・systemctl start/stop/restart rsyslog でCentOS 7以降のrsyslogを起動・停止・再起動できる
・systemctl status rsyslog でrsyslogの現在の稼働状態を確認できる
・/etc/rsyslog.conf のファシリティ.プライオリティ書式でログの出力先を制御できる
・rsyslogd -N1 で設定ファイルの構文チェックを素早く実行できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
rsyslog とは
rsyslog は RHEL 6 / CentOS 6 から採用された、従来の syslog を大幅に強化したシステムロガーです。「Rocket-fast SYStem LOGger」の略称で、Ubuntu 8.04 以降・RHEL 6 以降で標準採用され、現在は事実上の Linux 標準ログデーモンとなっています。
syslog との主な違い:
・TCPによるログ転送に対応(syslog は UDP のみ)
・MySQL などの DB へのログ転送が可能
・TLS 暗号化転送をサポート
・マルチスレッド処理で高負荷環境でも取りこぼしが少ない
・syslogd との互換性あり
RHEL 7 以降は systemd の journald がカーネル/サービスログを最初に受け取り、rsyslog はそのデータをファイルに書き出す役割を担います。両者の関係を把握しておくことが、ログ管理の第一歩です。
# rsyslog のバージョン確認 rsyslogd -v # サービス状態確認 systemctl status rsyslog
rsyslog の操作(CentOS 7以降 / RHEL 7以降)
1. systemctl コマンドで操作する(推奨)
RHEL 7 / CentOS 7 以降ではsystemctl を使います。# ステータスを確認する systemctl status rsyslog # rsyslogを起動する systemctl start rsyslog # rsyslogを停止する systemctl stop rsyslog # rsyslogを再起動する systemctl restart rsyslog # OS起動時の自動起動を有効にする systemctl enable rsyslog
systemctl restart rsyslog で反映します。プロセスを維持したまま設定だけ再読み込みしたい場合は HUP シグナルを使います。# 設定ファイルのみ再読み込み(プロセスを維持) kill -HUP $(cat /var/run/rsyslogd.pid)
rsyslog の操作(CentOS 6 / RHEL 6)
2. /etc/init.d スクリプトで操作する(CentOS 6以前)
# ステータスを確認する /etc/init.d/rsyslog status # rsyslogを起動する /etc/init.d/rsyslog start # rsyslogを停止する /etc/init.d/rsyslog stop # rsyslogを再起動する /etc/init.d/rsyslog restart # 起動中のみ再起動する(停止中は何もしない) /etc/init.d/rsyslog condrestart
・condrestart(conditional restart):起動中のときだけ再起動し、停止中は何もしない
/etc/rsyslog.conf の設定ファイルを読み解く
rsyslog の設定ファイルは大きく3つのブロックに分かれています。# /etc/rsyslog.conf の基本構造 #### MODULES #### # モジュール読み込み(imuxsock, imjournal など) module(load="imuxsock") module(load="imjournal" StateFile="imjournal.state") #### GLOBAL DIRECTIVES #### global(workDirectory="/var/lib/rsyslog") #### RULES #### # ファシリティ.プライオリティ アクション(送信先) *.info;mail.none;authpriv.none;cron.none /var/log/messages authpriv.* /var/log/secure mail.* -/var/log/maillog cron.* /var/log/cron *.emerg :omusrmsg:*
3. ファシリティとプライオリティ
RULES セクションの書式は「ファシリティ.プライオリティ アクション」です。ファシリティ(ログの発生源)
・kern:カーネルメッセージ
・user:一般ユーザープロセス
・mail:メールシステム(Postfix 等)
・daemon:各種デーモン
・auth / authpriv:認証・セキュリティ(SSH 等)
・cron:cron デーモン
・local0~local7:アプリケーション用カスタム枠
・*:全ファシリティ
プライオリティ(重大度、上から降順)
・emerg:システムが使用不能(最高)
・alert:即時対応が必要
・crit:致命的なエラー
・err:エラー
・warning:警告
・notice:正常だが注意が必要
・info:情報メッセージ
・debug:デバッグ情報(最低)
・none:そのファシリティを除外
プライオリティを指定すると「そのレベル以上」が全てマッチします。
mail.err と書くと、err / crit / alert / emerg が対象になります。# authpriv の全レベルを /var/log/secure に書く authpriv.* /var/log/secure # mail を /var/log/messages から除外(none 指定) *.info;mail.none /var/log/messages # セミコロンで複数ファシリティを指定 *.emerg;kern.crit /var/log/important
4. ドロップイン設定:/etc/rsyslog.d/ の活用
rsyslog.conf の末尾には通常$IncludeConfig /etc/rsyslog.d/*.conf という行があり、/etc/rsyslog.d/ 以下の .conf ファイルを自動で読み込みます。メインの rsyslog.conf を直接編集するより、アプリケーション単位でファイルを分離するほうが管理しやすいです。
# Nginx のアクセスログを専用ファイルへ転送する例 # /etc/rsyslog.d/nginx.conf として作成 if $programname == 'nginx' then /var/log/nginx/rsyslog-access.log & stop
& stop を付けると、このルールにマッチしたログがそれ以降のルールで二重に書かれなくなります。設定を追加・変更したら必ず構文チェックを実行してください。
# 構文チェック(エラーがなければ終了コード 0) rsyslogd -N1 # 正常例の出力 # rsyslogd: version 8.2306.0, config validation run (level 1), master config /etc/rsyslog.conf # rsyslogd: End of config validation run. Bye.
よく使うカスタム設定例
5. 特定プログラムのログを別ファイルへ分ける
# /etc/rsyslog.d/sshd-separate.conf # SSHD のログを /var/log/sshd.log に分ける if $programname == 'sshd' then { action(type="omfile" file="/var/log/sshd.log") stop }
6. local0 ファシリティでアプリ固有ログを分離する
自社アプリやシェルスクリプトからlogger -p local0.info "メッセージ" でログを送り、rsyslog 側で受け取るパターンは実務でよく使います。# /etc/rsyslog.d/myapp.conf local0.* /var/log/myapp/myapp.log # アプリ側(シェルスクリプト等)から送信 logger -p local0.info "バッチ処理完了 at $(date)" logger -p local0.err "DB接続失敗"
リモートサーバーへのログ転送設定
複数台のサーバーからログを1箇所に集める「ログサーバー」構成は、セキュリティ・運用の両面で有効です。設定は「送信側(クライアント)」と「受信側(ログサーバー)」に分けて考えます。7. 送信側(クライアント)の設定
# /etc/rsyslog.d/forward-to-logserver.conf # UDP 転送(ポート 514 が標準) *.* @192.168.1.100:514 # TCP 転送(推奨:パケットロスを防ぐ) *.* @@192.168.1.100:514 # キュー付き TCP 転送(サーバー停止時に一時保存) action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp" action.resumeRetryCount="100" queue.type="linkedList" queue.size="10000")
8. 受信側(ログサーバー)の設定
# /etc/rsyslog.conf または /etc/rsyslog.d/receive.conf # UDP 受信を有効化 module(load="imudp") input(type="imudp" port="514") # TCP 受信を有効化 module(load="imtcp") input(type="imtcp" port="514") # 受信ログを送信元ホスト別にファイルへ分けて保存 $template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log" *.* ?RemoteLogs & ~
# UDP/TCP ポート 514 を許可(RHEL 系) firewall-cmd --permanent --add-port=514/udp firewall-cmd --permanent --add-port=514/tcp firewall-cmd --reload
トラブルシュート:rsyslog が動かないときの確認手順
9. サービス停止・起動失敗の確認
# サービス状態確認 systemctl status rsyslog # 詳細エラーをジャーナルで確認 journalctl -u rsyslog --no-pager -n 50
10. ログが期待したファイルに出ない
# 構文エラーがないか確認 rsyslogd -N1 # SELinux の AVC 拒否がないか確認(RHEL 系) ausearch -m avc -ts recent | grep rsyslog # ディレクトリが存在するか確認し、なければ作成 ls -la /var/log/myapp/ mkdir -p /var/log/myapp chown root:root /var/log/myapp chmod 755 /var/log/myapp
11. リモート転送が届かない
# TCP 疎通確認 nc -zv 192.168.1.100 514 # テスト送信(送信側で実行) logger -p user.info "rsyslog test from $(hostname)" # 受信側のログで確認 tail -f /var/log/remote/送信元ホスト名/user.log
本記事のまとめ
| やりたいこと | コマンド(RHEL 7以降) |
|---|---|
| ステータスを確認する | systemctl status rsyslog |
| 起動する | systemctl start rsyslog |
| 停止する | systemctl stop rsyslog |
| 再起動する | systemctl restart rsyslog |
| 自動起動を有効にする | systemctl enable rsyslog |
| バージョン確認 | rsyslogd -v |
| 設定ファイルの構文チェック | rsyslogd -N1 |
| 設定ファイルの再読み込み | kill -HUP $(cat /var/run/rsyslogd.pid) |
| UDP でログを転送する | *.* @192.168.1.100:514(rsyslog.conf に記載) |
| TCP でログを転送する | *.* @@192.168.1.100:514(rsyslog.conf に記載) |
Linuxのログ管理・サービス管理を体系的に学びたい方へ
rsyslogの操作はサーバー管理の基本です。systemctlの使い方とあわせて体系的に身につけておくと、現場での対応が速くなります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒/合わなければ解除3秒 / 詳細はこちら
- 次のページへ:tail -fでログをリアルタイム監視する方法|-F追跡・grepフィルタ・journalctl -f併用
- 前のページへ:サービスの状態を把握する|systemctl statusとjournalctl -uで現場の原因を切り分ける
- この記事の属するカテゴリ:Linuxtipsへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます