rsyslogd (syslogd) 設定


rsyslogd (syslogd) とは

syslogとは、システムメッセージの送受信を行ったりファイル記録を行ったりする仕組みです。Linuxサーバでは、syslogdという常駐プログラムによって制御されます。デフォルト設定では/var/log/messages, /var/log/secureなどを出力するように設定されていますが、設定次第ではLinuxサーバ群のログを収集したり、ネットワーク機器のログを受信したりする事ができます。

rsyslogの語源は、reliable syslogで文字通り信頼性ある(reliable)ログ転送を実現します。CentOS 6.X以降は、デフォルトでsyslogdではなくrsyslogdがインストールされるようになりました。rsyslogdはsyslogと互換性があるように作られており、syslogと同じように使う事も可能です。

このページではLinuxサーバにおけるrsyslogd ( syslogd )の設定方法について説明します。

ちょっとした豆知識ですが、rsyslogはもともとreliable syslogの略称でした。RFC 3195を見ると、確かに”Reliable Delivery for syslog”という言葉が見つかります。しかし、rsyslog v5 documentを見ると、いつの間にかrsyslogの略称がrocket-fast system for log processingに変わってしまいました。略称を変えたのは、私の勝手な推測ですが、fluentdに比べてバッファリング時間が短く素早いログ転送ができる事を全面にアピールしたいからかもしれません。

ネットワーク機器からの受信設定

ネットワーク機器からの受信設定 – rsyslog.conf 設定

/etc/rsyslog.confを以下のように編集します。”$ModLoad imudp”, “$UDPServerRun 514″のコメントアウトを外す事によって、UDP 514でlistenするようになります。

次に適当なFACILITYで受信したログをファイルに書き出すように設定します。以下は、LOCAL0で受信したログを/var/log/network.logに書き出す設定です。

rsyslogdを再起動させ、設定を反映させます。

ネットワーク機器からの受信設定 – firewall 設定

UDP 514 による疎通が可能になるように設定します。多くの環境ではfirewallにおけるUDP 514許可設定が必要になるでしょう。具体的な設定方法は環境によって異なるはずですが、ここではiptablesの設定例を紹介します。

ネットワーク機器からの受信設定 – ネットワーク機器側の設定

ネットワーク機器からrsyslogd(syslog)サーバへログ転送するように設定します。以下は、Cisco IOS 15.4Tの場合の設定例です。

ネットワーク機器からの受信設定 – 動作確認

rsyslogサーバにおいて、確かにネットワーク機器のログを受信できている事を確認します。

ネットワーク機器からの受信設定 – ログローテーション

rsyslog.confに新たに追加したログファイルは自動的にローテーションされません。/etc/logrotate.d/syslogを以下のように編集し、ログローテーションが行われるようにします。

/etc/logrotate.d/syslogの設定を確認するため、logrotateコマンドを用いてログローテーションを強制的に実行します。

コマンド実行後、ログローテーションされた事を確認します。

ログローテーションがどうしても想定通りに動かない場合は、logrotate 設定方法等を参考にデバッグを行なって下さい。

rsyslogd 転送設定

rsyslogd 送信側の設定

以下のようにログの転送先を指定する事によってログを転送する事ができます。@(アットマーク)が1つならばUDPによる通信を、2つならばTCPによる通信を行ないます。ポート番号を省略した場合は514が使用されます。

簡単な設定例を紹介します。/etc/rsyslog.confを以下のように編集すると、/var/log/messagesと同じログを192.168.0.1にTCPで転送します。

設定を反映させるために、rsyslogdの再起動を行ないます。

rsyslogd 受信側の設定

rsyslogdによるメッセージを受信するにはモジュールの有効化とListenするポートの指定が必要になります。UDPによるsyslogを受信する場合は、/etc/rsyslog.confをテキストエディタで開き”$ModLoad imudp”と”$UDPServerRun 514″のコメントアウトを削除します。

TCPによるrsyslogを受信する場合は、/etc/rsyslog.confをテキストエディタで開き”$ModLoad imtcp”と”$InputTCPServerRun 514″のコメントアウトを削除します。

設定を反映させるために、rsyslogdを再起動します。

通信経路上に、ファイアウォール等が存在する場合は口開けも忘れずに行なってください。また、TCPを使用するかUDPを使用するかにも注意を払って下さい。以下は、iptablesの口開け設定例です。

以上がログ転送の最低限の設定です。適当なログをtailし、複数サーバのログが存在する事を確認します。

Action Queue パラメタ説明

rsyslogdは、ログをQueueingする仕組みを備えています。巷では、”rsyslogと違って、fluentdはバッファリング機能を備えているからログの再送制御に強い”との主張を見かけますが、rsyslogも立派なQueueing機能を備えています。

rsyslogを使うにしろ、fluentdを使うにしろ、Queueingのパラメタ設定はスピードとデータ保全のトレードオフなので、設定の意味を理解しメリット/デメリットを理解した上で使用する事が大切です。

設定項目説明
WorkDirectoryQueueingされたログを格納するディレクトリです。
ActionQueueFileNameQueueingされたログを格納するファイル名です。
ActionQueueMaxDiskSpaceQueueに格納する最大データサイズを指定します。0を指定した場合は上限なしとなります。
ActionQueueSaveOnShutdownrsyslogのshutodown時に、メモリ上のログメッセージをディスクに格納するかどうかです。
ActionQueueTypeQueueing方式を指定します。
ActionResumeRetryCountsyslogの転送先ホストがダウンしていた場合、何回まで再送を試みるかの指定です。0を指定した場合は、無限に再送を試みます。
WorkDirectory

Queueingされたログを格納するディレクトリです。

ActionQueueFileName

Queueingされたログを格納するファイル名です。

ActionQueueMaxDiskSpace

Queueに格納する最大データサイズを指定します。1g, 1mのようにギガバイト、メガバイト単位の指定が可能です。

ActionQueueSaveOnShutdown

rsyslogdのシャットダウン時に、メモリ上のログをディスクに保存するかどうかです。データロスを防ぎたい場合は、onをお勧めします。

ActionQueueType

ログのキューイング方式を指定します。FixedArray, LinkedList, Disk, Directの4つが指定可能です。

ActionQueueType – メモリキューイング

メモリを使用したキューイングを行なう場合は、ActionTypeにFixedArray, LinkedListのいずれかを指定します。FixedArrayが省CPUの処理で、LinkedListが省メモリの処理になります。

ActionQueueType – ディスクキューイング

ActionTypeにDiskを指定すると、ディスク上にキューイングされます。最も処理が遅い方式ですが、データロスを嫌う要件ならば、Diskにしておきましょう。

ActionQueueType – キューイングなし

ActionTypeにDirectを指定するとキューイングされません。

もし、syslogの転送先サーバが複数存在する構成で、主系ダウン時にすぐに待機系に切り替えたい場合は、Directの一択です。キューイングありの場合は、主系がダウンするとキューにログを格納し、再送を試みる挙動になります。

ActionResumeRetryCount

syslogの転送先ホストがダウンしていた場合、何回まで再送を試みるかの指定です。0を指定した場合は、無限に再送を試みます。

Action Queue 設定例

Action Queueの設定例を紹介します。以下はディスクキューに格納しながらログ転送を行なう設定例です。なお、/etc/rsyslog.confを書く時は記述順に十分注意して下さい。/etc/rsyslog.confは上から順に評価されますので、もしディスクキューの設定を使用したいならば “$ActionQueueType Disk”の後に”*.* @@192.168.0.1″と記述しなければなりません。

動作確認のため、rsyslog受信側のサーバのrsyslogdを停止させます。

しばらくすると、rsyslog送信側のディスクキューにログが溜まっている事が確認できます。あまり知られていませんが、rsyslogも設定をちゃんと行なえばfluentd同様の信頼性ある再送制御ができるようです。

rsyslog RDBMS 保存

rsyslogはログをRDBMSに保存する事ができます。単純なログ出力に比べてRDBMSは処理が遅いので、中小規模や一部監査データのみならば、RDBMS保存を検討しても良いと思います。

rsyslog RDBMS – モジュールのインストール

ログをRDBMSに保存するには、rsyslogの追加モジュールをインストールする必要があります。以下のようなyumコマンドで追加モジュールをインストールして下さい。

以下、MySQLを前提として設定方法を紹介します。PostgreSQLの場合は省略しますが、MySQLとほぼ同じ手順で構築する事ができます。

rsyslog RDBMS – データベースの作成

yumコマンドでrsyslog-mysqlをインストールすると、テーブル作成のSQL文が一緒にインストールされます。データベース作成SQLの配置場所は今後のバージョンアップで変わる可能性がありますが、恐らく/usr/share/doc/配下を探すと見つかるでしょう。rsyslog-mysql-5.8.10の場合ならば、以下ディレクトリにデータベース作成SQLが格納されています。

rsyslog-mysql-5.8.10の場合は、データベース作成SQLにはデータベース作成とテーブル作成の処理が書かれています。この類のツールは、バージョンによってテーブルスキーマが変わる事がありますので、必ず実行前に中身を確認しておくと良いでしょう。

データベース作成SQLを実行します。

データベース作成SQL内にMySQLユーザ作成の処理は含まれていなかったようなので、syslog用のMySQLユーザを作成します。作成例は以下の通りです。

rsyslog RDBMS – rsyslog.conf 基本的な設定

syslogをRDBMSに読み込ませるにはデータベース用モジュールをロードする必要があります。/etc/rsyslog.confに以下のような設定を加筆します。MySQLを使用するか、PostgreSQLを使用するかによって読み込ませるモジュールが異なる事に注意して下さい。

どのようなログをRDBMSに保存するかの設定を記述します。書式は以下の通りです。

設定例は以下のようになります。

rsyslogを再起動し設定を反映させます。

/var/log/messagesを確認し、特にエラーがない事を確認します。もし、データベース接続に失敗している場合ならば、以下のように”Access denied for user”と明らかなエラーメッセージが出力されるはずです。

データベースにログが格納されている事を確認します。

rsyslog RDBMS – データベース パーティショニング

ログのように定期的な改廃が必要となるデータをRDBMSに格納する場合は、パーティショニングが非常に有効です。パーティショニングの詳細な解説は他のサイトにお任せします。パーティショニング解説のお勧めは漢(オトコ)のコンピュータ道 – パーティショニングの使用例 – http session情報です。

パーティションの設定例は以下の通りです。なお、他サイトの記事を見ると、日付を利用したパーティショニングの例が多いです。しかし、現時点(2014/08/12)のrsyslog-mysql-5.8.10はSystemEventsPropertiesテーブルに日付列が存在しないため、日付によるパーティショニングは非常に困難となります。

パーティション単位の削除、パーティション追加の操作例は以下のようになります。

logger

loggerとは、syslogへメッセージを転送するインターフェースです。最も簡単に操作できるのは、コマンドラインのloggerです。loggerの使い方を理解すると、rsyslogのデバッグが容易になったりアプリケーションのログをsyslogへ転送する事ができるようになります。

logger – 基本的な使い方

loggerは標準入力を受け取り、syslogへメッセージを転送します。-pでファシリティ名, 重大度(シビアリティ)を指定し、-tでタグを指定します。操作例は以下の通りです。

rsyslog.confデフォルト設定の場合、重大度(シビアリティ)がinfoであるログは/var/log/messagesに出力されます。/var/log/messagesに先ほど、loggerコマンドで送ったメッセージが出力されている事を確認します。

logger – apache syslog 転送例

loggerを使用すると、様々なアプリケーションログをsyslogへ転送する事ができます。

apache httpd.confのCustomLog句は、実はコマンドラインを設定する事ができます。コマンドラインを記述するとログ出力が標準出力として渡されます。以下のように設定すると、ログファイルとsyslogの双方にログを送る事ができます。

httpdを再起動させ、設定を反映させます。

httpdのアクセスログが/var/log/messageにも記録されている事を確認します。

logger – コードによる実装例

多くのプログラミング言語はloggerの仕組みを備えています。このページではrubyによる実装例を紹介します。

コマンドライン版rubyであるirbを用いて、syslog出力ができる事を確かめます。rubyのインストールはやや手間ですので、このサイトではtd-agentに同梱されているirbを利用します。

syslogへ転送された事を確認します。

プログラミングに関する仕様を調べる際は、ロガーという言葉の意味に注意して下さい。多くの場合は、プログラミングの文脈でロガーと言うと、重大度(ERROR, WARNING等)を分けてファイルにログ出力する仕組みを指します。Linuxのloggerコマンドに相当する概念は、syslogユーティリティと呼ぶ事の方が多いかもしれません。

Tips

syslog パケットフォーマット

仕様理解のためにsyslogのパケットを観察してみましょう。着目すべきは、9, 10行目です。ファシリティ名, 重大度(シビアリティ)を合わせて、わずか8ビットしかない事が読み取れます。

ファシリティ名はわずか5bitのフィールドしか持たないので、最大でも32種類の値しか設定する事ができません。また、多くのファシリティ名はシステム用途として予約されていて、実質使用できるのはLOCAL0からLOCAL7までの8種類です。

ファシリティ名と実際の数値の対応関係は、以下のようになります。以下の表を見ると、設定できるファシリティの数が非常に限られている事が読み取れるでしょう。この設定できる値の少なさがsyslogの柔軟性の限界であり、fluentdのようなプロダクトが生まれた背景になります。

数値用途
0kernカーネルメッセージ (ユーザプロセスから生成することはできない)
1user一般的なユーザレベルメッセージ
2mailメール・サブシステム
3daemon特定の facility 値を持たないシステムデーモン
4authセキュリティ/認証 メッセージ
5syslogsyslogd(8) によって内部的に発行されるメッセージ
6lprラインプリンタ・サブシステム
7newsUSENET ニュース・サブシステム
8uucpUUCPサブシステム
9cronクロックデーモン (cron と at)
10authprivセキュリティ/認証 メッセージ (プライベート)
11ftpftp デーモン
12ntpntp デーモン
13securityセキュリティ用途
14consoleコンソール出力
16 - 23local0 - local7ローカルな使用のためにリザーブされている

重大度(シビアリティ)については3bitが予約されています。重大度(シビアリティ)の名前と数値の対応関係は以下のようになります。

数値用途
0emergシステムが使用不可
1alert直ちに行動を起こさなければならない
2crit危険な状態
3errエラーの状態
4warningワーニングの状態
5notice通常だが重要な状態
6infoインフォメーションメッセージ
7debugデバッグレベルのメッセージ

ファシリティ名 重大度(シビアリティ) の指定

rsyslog.conf(syslog.conf)におけるファシリティ名, 重大度(シビアリティ)の指定書式は、以下のようになります。なお、資料によっては、重大度という言葉はシビアリティ, severity, プライオリティ, priorityなどの表記揺れが存在します。

例えば、ファシリティがcronで重大度がinfo以上であるログを/var/log/cronに出力する設定は以下のようになります。重大度(シビアリティ)としてinfoを指定すると、info以上の重大さのログ(info, notice, warn, error, crit, alert, emerg)が出力されます。

ファシリティ名, 重大度(シビアリティ)の組み合わせは、セミコロン(;)区切りで複数指定する事ができます。例えば、local0, local2のnotice以上のログを出力する設定例は以下のようになります。

rsyslog.confはファシリティ名, 重大度(シビアリティ)の組み合わせが一致した全てのログファイルにログが出力されます ( 一方、fluentdは最初にマッチしたタグが処理対象となります。この辺りの挙動は混同しないように注意しましょう。 ) 。例えば、以下のような設定ならば、cron.infoのログは2つのログファイルに出力されてしまいます。

このような二重出力の挙動を回避するには、重大度(シビアリティ)にnoneというキーワードを指定します。noneを指定する事によって、対象となるファシリティのログが全て出力されなくなります。設定例は以下の通りです。

imuxsock begins to drop messages from pid XXXXX due to rate-limiting

多くのログ出力にはrate limitというログ出力量の制限機能が備わっています。rsyslogd 5.8のデフォルト設定は、5秒間で200メッセージを超えるログ出力があった場合はログを破棄します。これは大量のログ出力による性能劣化を避けるための配慮です。

ログ出力の上限を超えてしまった場合は、”imuxsock begins to drop messages from pid XXXXX due to rate-limiting”とのメッセージが出力されます。このメッセージが見えた場合は、ログの取りこぼしが発生している事を意味します。

ログ出力量を調整できるパラメータは以下の3つです。

 デフォルト値説明
SysSock.RateLimit.Interval5ログ出力量を計測する期間を「秒」で指定します。もし0秒を指定した場合は、rate limitが無効化されます。
SysSock.RateLimit.Burst200ログ出力を抑制するメッセージ数の閾値を指定します。
SysSock.RateLimit.SeverityなしSeverity毎に、ログ出力を抑制するメッセージ数の閾値を指定します。

もし、rate limitを無効化 (全てのログを出力するように) する場合は、/etc/rsyslog.confに”$SystemLogRateLimitInterval 0“を加筆します。設定ファイルの読みやすさを考えて、MODULESに関する設定の一番下に記述するのが良いでしょう。

rate limitを無効化するのではなくrate limitを緩めたいならば、/etc/rsyslog.confを以下のように設定します。Intervalの値をデフォルト値の5秒より小さくするか、Burstの値をデフォルトの200メッセージより大きしくます。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする