検索
連載

システム管理の基礎 syslogdの設定をマスターしようLinux管理者への道(3)(2/3 ページ)

syslogdによって記録されるログは、システムの運用・管理のための重要な手掛かりとなる。しかし、各環境固有の事情に合っていなければ、ログを取得する意味はない。syslogdやlogrotateの設定方法をマスターし、必要な情報を選別できるようにしよう。(編集局)

PC用表示 関連情報
Share
Tweet
LINE
Hatena

システムのログをつかさどるsyslogd

 ログには、アプリケーションが独自に出力するものと、syslogdを利用して出力するものの2種類があります。

 独自のログを出力する代表的なアプリケーションにはApacheやSquid、Sambaなどがあります。独自のログ設定を持つアプリケーションに関してはアプリケーションのマニュアルなどを読んでいただくとして、ほとんどのアプリケーションはsyslogdを利用してログを出力しています。以後は、syslogdを利用したログについて説明します()。

注:LinuxおよびUNIXでsyslogdがインストールされていないことは考えにくいため、特にインストール方法については言及しません。また、後述するlogrotateに関しても同様です。

 Linuxでは、主なログの出力先は/var/logディレクトリです。ディレクトリ内を確認すると分かりますが、前述したようにここには複数のファイルが存在します。この設定を行うファイルが/etc/syslog.confです。

syslog.confのフォーマット

 syslog.confの書式は、スペースあるいはタブで分けられた2つのフィールド「selector」と「action」で構成されています(フィールドを分けるための空白はOSによって異なります。マニュアルで確認してください)。

selector        action

取得するログの指定   取得したログの出力先


セレクタ(selector)

 selectorは「facility」と「priority」(label)を「.」(ピリオド)で接続します。特定のactionに対して複数のselectorを指定したい場合は、「;」(セミコロン)で接続します。

facility.priority{;facility.priority}

取得する情報の分類.どのレベルから出力


ファシリティ(facility)

 facilityはログの分類に当たるものです。syslogdを利用するプログラムは、「このログはこのfacilityに所属している」という情報をsyslogdに渡しています。syslogdの設定を行うことで、facilityに応じて扱い方を変更できます。

facility 対象のログ
auth(security) 認証サービスのメッセージ(現在はauthprivが推奨されている)
authpriv 認証サービス(カテゴリはauthと同じ。authとは出力結果が異なる)
cron cronのメッセージ
daemon デーモンのメッセージ
kern カーネルのメッセージ
lpr プリンタサービスのメッセージ
mail メールサービスのメッセージ
news ニュースサービスのメッセージ
syslog syslogのメッセージ
user ユーザープロセスのメッセージ
uucp uucp転送を行うプログラムのメッセージ
local0〜7 アプリケーションに依存する
facilityで指定できるキーワード

 複数のfacilityを指定したい場合は「,」(カンマ)で接続して、

mail,ftp.warn


のように書くこともできます。local0からlocal7は、特定のプログラムが所属するfacilityを既存のものと分けたいときに利用します。以下はRed Hat Linux7.3の/etc/xinetd.confの内容ですが、facilityがauthprivで設定されています。スーパーサーバ経由で動作するサービスはfacilityがauthprivということです。

defaults

{

instances = 60

log_type = SYSLOG authpriv

log_og_success = HOST PID

loc_on_failure = HOST

cps = 25 30

}

includedir /etc/xinetd.d


 例えば、特定のサービスをlocal0のfacilityにするには/etc/xinetd.d下の設定ファイルに以下の記述を追加します。telnetの例を挙げます。

service telnet

{

disable = no

flags = REUSE

socket_type = stream

wait = no

user = root

server = /usr/sbin/in.telnetd

log_on_failure += USERID

log_type = SYSLOG local0 ←追加

}


 設定ファイルの編集後、xinetdを再起動させればtelnetのログがlocal0のfacilityで出力されます。

 sshの場合、デフォルトでsshd_configに、

SyslogFacility AUTHPRIV


の記述があります。この「AUTHPRIV」の記述をほかのfacilityに変更すればよいのです。

プライオリティ(priority)

 priorityは、プログラムが出力するメッセージのうち、ログのレベルの重要度を設定します。

priority 内容
debug デバッグ情報
info 情報
notice 通知
warn 警告
err 一般的なエラー
crit 致命的なエラー
alert 緊急に対処すべきエラー
emerg システムが落ちるような状態
下になるほど重要度が高い

 通常の設定を行うと、指定したpriority以上のログが出力されます。例えば、「err」を指定すればcrit、alert、emergのレベルの出力もされます。すなわち、重要度の低いpriorityを選択すればするほど、出力されるメッセージは多くなります。逆に、指定したpriorityよりも重要度の低いメッセージのみを出力させたい場合は、

mail.*;mail.!warn


のように記述します。この設定では、メールに関するメッセージのdebugとinfoとnoticeが出力されます(ここでの「*」はすべてのメッセージの意味)。

 特定のpriorityのみを指定することも可能です。それには「=」を使用します。

kernel.=warn


のように記述すると、カーネルの警告メッセージだけが出力されます。これに「!」を合わせることで、特定のpriorityを除いたメッセージを出力することも可能です。

 これらのpriorityの指定以外に、「none」を利用するとそのfacirityの出力を行いません。

selector例 内容
kernel.=warn facilityがkernelでpriorityがwarnのみ出力
mail.*;mail.!=crit facilityがmailでpriorityがcrit以外のメッセージを出力
.;daemon.none facilityがdaemon以外の全メッセージを出力

 どのfacilityをどのpriorityにするかは、何を監視したいかによります。重要なデータを見逃さないように、必要なデータが取得できるpriorityに変更しましょう。

アクション(action)

 actionには、selectorで指定したメッセージをどこに、あるいはどのように出力するかを設定します。具体的には、

  • どのファイルに出力するか(ファイルのパスを記述する)
  • ほかのプログラムに渡す(「|」を利用)
  • 他ホストに渡す(「@ホスト名」)
  • ユーザーのコンソールに表示(システムに登録されているユーザー名)

になります。また、出力先のファイルとして/dev/consoleを指定することで、コンソールに表示させることも可能です。actionの設定例は以下のとおりです。

設定例 内容
/var/log/samplelog /var/log/samplelogへログを出力
| /usr/local/bin/*** ログをパイプでほかのプログラムへ渡す
/dev/console ローカルのコンソールへ出力
@remotehost リモートホストのsyslogdへ送信(
root,user1 rootとuser1に通知
* オンラインユーザーすべてに通知
注:詳細は後述

 以上の内容を踏まえて、デフォルトのsyslog.conf()を見てみましょう。

*.info;mail.none;authpriv.none;cron.none /var/log/messages 1.

authpriv.* /var/log/secure  2.

mail.* /var/log/maillog  3.

cron.* /var/log/cron   4.

*.emerg *          5.

uucp,news.crit /var/log/spooler   6.

local7.* /var/log/boot.log  7.

注:Red Hat Linux7.3のsyslog.confです。コメント行は除いています。

1.authprivとcronを除いたすべてのfacilityでinfo以上のメッセージを/var/log/messagesに出力
2.authprivのfacilityはすべてのメッセージを/var/log/secureに出力
3.mailのfacilityはすべてのメッセージを/var/log/maillogに出力
4.cronのfacilityはすべてのメッセージを/var/log/cronに出力
5.すべてのfacilityでemergのメッセージをオンラインユーザーのコンソールへ出力
6.uucpとnewsのfacilityでcrit以上のメッセージを/var/log/spoolerへ出力
7.local7のfacilityのすべてのメッセージを/var/log/boot.logへ出力

ログサーバによるログの一元管理

 以前、ログを数カ月から数年間保存することを法制化しようという動きがありました。これは不正アクセスの情報を残すためでしたが、まだ実際の法律としては存在していません。

 しかし、ログを残すことがネットワーク管理者の重要な作業の1つであることは間違いありません。不正アクセスを行う者にとって、ログには自分を特定する手掛かりとなる情報が記録されます。当然、ログを削除しようとするでしょう。これに対処するために、異なるホストをログサーバとして運用する方法があります。

 前述したように、syslog.confの設定でactionに@ホスト名(あるいはIPアドレス)を入力すると、そのホストにログを転送することができます。ただし、ログを受け取るホスト側でも設定が必要です。ログサーバとしてホストを設定するには、syslogdに-rオプションを指定して起動します。syslogdを停止してから、

# /sbin/syslogd -r


で再実行します。Red Hat系であれば/etc/sysconfig/syslogに、

SYSLOGD_OPTIONS="-m 0 -r"


のように追記してsyslogdを再起動すれば、ログサーバとして使用できます。

図1 各サーバからログサーバにログを転送して一元的に管理する
図1 各サーバからログサーバにログを転送して一元的に管理する

 ログサーバへ転送されたログは、ログサーバのsyslog.confの内容に従って処理されます。ここで注意すべき点は、ログサーバのユーザーとパスワードをほかのサーバと同じにしないことと、複数のサーバからログの転送を行うのであれば容量的に十分余裕を持たせておくことです。

 以上で、syslogdの主な機能については網羅できているはずです。複数のサーバから必要な情報を洗い出す作業を少しでも減らそうとするなら、ログサーバを1台用意して、例えばpriorityがwarn以上のものを1つのファイルに出力するように設定することも可能です。

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る