syslogdの限界と次世代シスログデーモン：新世代syslogデーモン徹底活用（1）（2/3 ページ）

» 2008年07月15日 00時00分公開

syslogdの問題点

　UNIX系OSでは、syslogdがデフォルトインストールされていることに加え、ファシリティとプライオリティの組み合わせで出力を制御できる手軽さが相まって、シスログが広く利用され、そのデーモンにsyslogdがデファクトスタンダードとして普及しています。

　しかし、これほど広範囲に利用されているにもかかわらず、シスログがRFC3164（http://www.ietf.org/rfc/rfc3164.txt）として標準化されたのは2001年と比較的最近のことです。その間もsyslogdは使い続けられ、キャリアクラスの用途でない限り、見直されることはありませんでした。

　ところが最近になり、日本版SOX法に代表される内部監査の一環として、内外の通信記録、メールの送受信記録、ログイン記録など、シスログの用途が広がりを見せています。従来シスログは、障害の検知やその原因調査など、何かトラブルがあったときの備えとしての役割が主なものでした。ところが内部監査では、正常時の状態を確実に収集する必要があり、信頼性についても強い要望が上がっています。内部監査を実施するほどの規模でなくとも、単一ファイルに書き出すだけのログの在り方に、不満を持っているユーザーは少なくありません。

　syslogdの問題点は主に次のとおりです。

シスログを細かく分別できない

　シスログの分別は、ファシリティとプライオリティに基づいているため、組み合わせに限りがあります。シスログを生成したプログラムごとに出力先を分けたり、特定の文字列に一致したシスログだけ出力先を分ける、といったことができません。

シスログファイルのローテーションを行うことができない

　シスログファイルを容量や日付で分割することができないため、別途logrotateのようなソフトウェアを導入し、ログファイルを整理する必要があります。

ディスクI/Oを制御できない

　シスログを一元管理するような大規模運用では、書き込みタイミングを調整するなどディスクI/Oの制御が重要になりますが、syslogdにはI/Oに掛かる負荷を抑える手段がありません。

シスログを自動的に監査できない

　syslogdだけでは、シスログの中に特定のメッセージを見つけた場合に自動的に処理を行うような設定ができません。別途、logwatchやswatchのようなソフトを導入する必要があります。

シスログが正常に取得されているか監視できない

　ログの取りこぼしがないか監視することができません。

シスログに出力される日付情報が貧弱