テックブログ

rsyslogの概要とログサーバ構築でお遊び

初めまして。今春入社いたしました、SIです。
入社半年も目前の今日この頃、資格取得に向けて勉強を進めております。
最近では、インフラエンジニアの入門的資格試験であるLinuC Level1の対策をしています。

ちょうどブログのバトンも回ってきましたので、最近自分が勉強したrsyslogについて書いていきます。
これはLinuC 102試験の範囲ですので、復習にちょうどいいですね。

本記事ではまずrsyslogの概要を説明した後に、その設定や構成に触れます。最後にログサーバを構築して簡単なお遊びをしたいと思います。

概要

▼rsyslogとは?
 今回お話しするrsyslogとは、その名の通りログを管理するソフトウェアです。
ログを司るデーモンプログラムの一種で、syslogの改良版でもあります。
多くの拡張機能を備えており、今回お遊びとして検証するログサーバを構築する機能も
その一つです。

▼設定について
主に以下二つのファイルによってその動作を決定します。

  • /etc/rsyslog.conf
  • /etc/rsyslog.d/以下のファイル

大本の設定はrsyslog.confで、その他別個の設定はrsyslog.d以下で行う
イメージですね。これらの設定ファイル内で、先に述べた拡張機能である”モジュール”の有効・無効化を行ったり、ログを記録するルール、あるいはログファイルのローテーションなどの設定を行ったりするわけです。

なお、設定を変更した場合にはファイルの再読み込みが必要なので、rsyslogの再起動を忘れないようにしましょう。

▼ルール設定
ログのルールとは、どこからのどんなログをどこへ記録するかの設定です。
主に次の三つの要素から成り立っています。

・ファシリティ
メッセージの出力元です。
これには主にカーネルや実行中プロセスなどが設定されており、主なものとしては下記が上げられます。

 auth, authpriv: 認証システム関連
 cron: cronによる出力
 daemon: 各種デーモンによる出力
 etc…

・プライオリティ
メッセージの重要度を表します。すべてのメッセージを記録していてはどれだけストレージがあっても足りませんから、運用に支障のない一般的な通知や些末な警告なんかはこの設定ではじく訳です。

重要度説明
emerg緊急事態
alert早急に対処が必要
critシステムは継続可能だが、深刻な事態
err一般的なエラー
warning一般的な警告
notice一般的な通知
info一般的な情報
debugデバック情報
noneログを記録しない
『LinuC レベル1 Version 10.1対応』396項より

・出力先
メッセージの出力先です。
指定のファイル以外にも、コンソールや外部サーバ、特定ユーザの端末等にも出力ができます。

・書式
設定ファイルに記述する際には、下記の形式となります。

ファシリティ.プライオリティ 出力先
例:daemon.crit /var/log/daemon.log

ファシリティ・プライオリティについては*を指定することで全てを対象とすることができます。また、出力先として外部サーバを選択する際には、下記の書式で出力先サーバを指定します

@@(tcp))/@(udp)ホスト名/IP:ポート(デフォルト514)
例:@@192.168.0.2:514

ここで注意したいのは、プライオリティの指定についてです。プライオリティは、指定した以上のものが出力されます。debugを指定すればemergまでのすべてが、逆に、emergを指定すればこれのみが記録されます。

例: cron.crit /var/log/cron.log
 →cron関連のメッセージのうち、crit,alert,emergのプライオリティのものを
  /var/log/cron.logに記録します。

*.info;mail.none;authpriv.none;cron.none /var/log/messages
 →実際にサーバ内にあるmessagesファイルの設定です。
  mail、authpriv、cron以外のすべてのファシリティのうち、
  info以上のプライオリティのメッセージを記録します。

上のmessagesのように、ルールの間に”;”を挟むことで複数ルールを設定できます。特定ファシリティのみを記録したい場合やその逆に特定のファシリティ外のすべてを記録したい場合などに活用できます。

rsyslogサーバの実践

ここまでの復習も兼ねて、実際にrsyslogサーバを作成して遊んでみます。やることとしては、下記環境内で行うログのキャッチボールです。

・構成
サーバ 2台(rsyslog01,rsyslog02)
スイッチ 1台

rsyslog01 - スイッチ - rsyslog02

まず、用意するサーバ2台ともで相互にログを転送するように設定します。rsyslog01にて記録したログAをrsyslog02へ転送。rsyslog02においても、ログAを記録した際にはrsyslog01へ転送するように設定します。そうすると、たった一回記録されただけのログAがサーバ間で永遠に転送され続ける想定です。

特に終了条件も定めないので、サーバ同士でログを投げ合い続け、記録も膨れ上がっていくことになります。まるでキャッチボールですね。

▼設定内容
 やることはそうありません。
ログ転送をするモジュールを有効化、ルールの追記とログファイルの作成。
以上三点となります。

・モジュール有効化
rsyslog01
# Provides TCP syslog reception
# for parameters see http://www.rsyslog.com/doc/imtcp.html
module(load="imtcp") # needs to be done just once
input(type="imtcp" port="514")
 →下2行の#を外して有効化

rsyslog02
# Provides TCP syslog reception
# for parameters see http://www.rsyslog.com/doc/imtcp.html
module(load="imtcp") # needs to be done just once
input(type="imtcp" port="514")
 →下2行の#を外して有効化

設定ファイルにデフォルトで記載されているモジュールです。
3行目の記述でtcp通信受信の有効化、4行目の記述でtcp通信を514ポートで受ける旨を設定しています。

コメントアウトされているだけなので、#を外すだけで有効化ができます。

・ルール追記
rsyslog01
user.notice /var/log/catchball
user.notice @@192.168.0.2:514

rsyslog02
user.notice @@192.168.0.1:514
user.notice /var/log/catchball

検証はloggerコマンドを用いて実施します。
loggerコマンドで出力されるログは、デフォルトではuser.noticeになりますので、
confファイルでもこの組み合わせのログが転送されるように追記します。

・ファイル作成
# ll /var/log/catchball
ls: '/var/log/catchball' にアクセスできません: そのようなファイルやディレクトリはありません
# touch /var/log/catchball
# ll /var/log/catchball
-rw-rxxrxx. 1 root root 0 MM dd hh:mm catchball

上で指定したログの出力先を作成します。
転送されてきたuser.noticeのメッセージを記録して、
実際に転送設定が想定通りできているか確認します。

▼検証結果
syslog01でloggerコマンドを”一回”実施します

# logger test from1

syslog02サーバで確認すると…

# tail /var/log/catchball
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1
MM dd hh:mm:ss user root[3023]: test from1

# wc -l /var/log/catchball
36496366 /var/log/catchball

永遠にログを吐き出し続けてます。
あっという間に8桁行にまで膨れ上がりました…

上手く動作していますね。動きの流れとしては下記の通りになります。

rsyslog01でメッセージ検知 > catchballへ記録&rsyslog02へ転送 > rsyslog02でメッセージ検知 > catchballへ記録&syslog01へ転送
以下繰り返し

まとめ

以上のように、rsyslogはモジュールの利用とルールの設定によって、ログサーバの構築を行うことができます。rsyslogの基本的な設定には複雑な操作が必要なく、今回はモジュールの適用とルールの追記のみで実現することができました。

この他にもログローテートの設定やログフォーマットの調整をすることができますが、これらも単純な操作で実現可能です。それぞれの詳細については業務・興味に従って調べていただければ幸いです。

また、今回は意図して膨大なログを出力するように設定しましたが、もしこれが想定外の挙動であった場合にはサーバのリソースを圧迫するようなミスとなりますので、実際にrsyslogをいじる際には注意したいですね!

今回は以上となります。
それでは!

参考

・中島能和・濱野健一郎『LinuC レベル1 Version 10.1対応』(昭和情報プロセス株式会社、2023年)

・多機能なログ管理システム「rsyslog」の基本的な設定
https://knowledge.sakura.ad.jp/8969/

・CentOS7のログ転送設定
https://qiita.com/daisuke0115/items/1e8eeb1d2b0f87bda8c7

この記事をシェアする

  • facebook
  • twitter
  • hatena
  • line
URLとタイトルをコピーする

実績数30,000件!
サーバーやネットワークなど
ITインフラのことならネットアシストへ、
お気軽にご相談ください