syslogdの限界と次世代シスログデーモン：新世代syslogデーモン徹底活用（1）（2/3 ページ）
UNIX系OSのシステムロギングをおよそ20年の長きにわたって支えてきた「syslogd」にも、限界が見えつつあります。その限界を打ち破る機能を備えた新しいシスログデーモンを紹介します。（編集部）
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のようなソフトを導入する必要があります。
シスログが正常に取得されているか監視できない
ログの取りこぼしがないか監視することができません。
シスログに出力される日付情報が貧弱
TIMESTAMPを定期的に挿入することはできますが、日付フォーマットは「Mmm dd hh:mm:ss」以外に変更できません。
シスログをネットワーク経由で転送する際UDPを使用する
一般的に信頼性を必要とする通信にはTCPを用いますが、syslogdではUDPを用います。そのため帯域が限られたネットワークでの使用や、サーバの負荷が高い場合に、パケットの取りこぼしが発生します。UDPではパケットは再送されず、シスログの取りこぼしを引き起こします。
シスログを受ける側がダウンした場合、シスログが消失する
シスログを受け取る側が停止している間、出力側でバッファリングし、受け取る側が復旧した後でまとめてシスログを転送するといったことができません。
シスログを出力する側・受け取る側で認証手段が提供されていない
IPアドレスによる接続制限は可能ですが、転送先や転送元の信ぴょう性を確認するような認証方法が提供されていません。クライアントになりすまし、大量のシスログを送り付けられるなどの危険性があります。
送信データを暗号化できない
syslogdにはシスログを暗号化し、転送する手段がありません。別途SSLラッパーを導入する必要があります。
続いて、syslogdでは実現できなかった数々の機能を実装した、次世代シスログデーモンを紹介します。syslogdの設定など、詳細については次の記事を参考にしてください。
関連記事：
「システム管理の基礎 syslogdの設定をマスターしよう」
http://www.atmarkit.co.jp/flinux/rensai/root03/root03a.html
syslogをsyslog-ngに置き換えるには
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/898syslog2syslogng.html
安全性の高いログ・サーバへの乗り換えのススメ
http://www.atmarkit.co.jp/fsecurity/rensai/unix_sec09/unix_sec01.html
安全性の高いログ・サーバへの乗り換えのススメ（2）
http://www.atmarkit.co.jp/fsecurity/rensai/unix_sec10/unix_sec01.html
Copyright © ITmedia, Inc. All Rights Reserved.