daemontoolsによるロギングとプロセス監視：実用qmailサーバ運用・管理術（9）（1/3 ページ）
syslogを使ったロギングにはいくつかの欠点がある。そこで、ロギングやプロセス監視を行ってくれるdaemontoolsを導入しよう。これにより、システムをより強力なものにできる。
ログは、サーバの状態やプロセスの稼働状況を知るうえで欠かせない情報源です。管理者がコンソールに向かっていない間に発生した障害も、ログを頼りに復旧したり原因を探って再発を防ぐ手段を講じることができます。新たにインストールしたツールがうまく動作しない場合にも、ログを見ればどこの手順で間違ったのか、どこがうまくいっていないかを知ることができます。
Apacheをはじめとする最近のツールは、標準のコンフィグレーションでロギングが有効になっています。「ApacheによるWebサーバ構築」第14回 ログローテーションとAnalogの導入では、Apacheのログを分析ツール「Analog」を使用してグラフ化する方法が紹介されています。グラフ化ツールは、ネットワーク監視（参考：運用管理に必須のツール／コマンド群）では定石です。もちろん、qmailでも可能です。
まず、前回までのインストールで使用したログについて整理し、その後ロギングだけでなくプロセスの監視も行うDJBツール（注）のdaemontoolsを紹介します。
sploggerを使ったロギング
POPサーバを取り上げた第2回以降では、rc起動スクリプトに「splogger」を併用することで/var/log/messagesまたは/var/log/maillogにログを出力させていました。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
sploggerは、サーバにインストールされているsyslogdデーモンを利用しているため、ログの出力先は/etc/syslog.confで決定されます。ログが/var/log/maillogに出力されている場合は、/etc/syslog.confに次のような行があるはずです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
/etc/syslog.confの前半の識別子が「facility」と呼ばれるもので、後半が出力先ファイル名になります。sploggerのデフォルトfacilityが「mail facility (LOG_MAIL)」であるため、知らぬ間にログを蓄えていたわけです。qmail-smtpdやqmail-pop3dのログを分離したい場合は、sploggerの引数にfacilityを指定し、そのfacilityに対する出力先を/etc/syslog.confに指定します。例えば、上記のpop3dを起動するスクリプトではsploggerでfacility 3が指定されています。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
この場合、/etc/syslog.confで次の行が有効となり、/var/log/messagesに「pop3d」という目印付きで出力されます。facilityを数字で表した場合と「mail」などのニーモニックで表した場合の対比は/usr/include/syslog.hを参照してください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このように汎用性に優れたsyslogdですが、多用することはあまりお勧めできません。syslog機構はログメッセージが完全に記録されることを保証していないため、信頼できないことを考慮する必要があります。また、非常に遅いことも知られています。そこで、「daemontools」を導入しましょう
daemontoolsの活用
daemontoolsは、先に紹介したようにqmailの作者であるD. J. Bernstein氏により提供されているパッケージです。以前のバージョンでは、パッケージに含まれるロギングツール「cyclog」を使用したいがためにインストールする管理者を多く見受けました。バージョン0.61からはこれが「multilog」に置き換わり、さらにプロセス監視機能「svscan」が強化されました。最近ではsvscanをメインで使用することも多くなりつつあるようです。
daemontoolsには次のようなメリットがあります。
- syslogと異なりソケットの代わりにパイプを使用するため、ログが確実に取れる
- ログの容量を監視してくれる。ログのローテーションは日付ではなく、ある一定容量に達したかどうかによって行われる
- サービスの追加・削除が簡単にできる。システム起動時に自動的に開始するか否かも簡単に指定できる
- サービスを監視するためのロックファイルを作らなくて済む
- デーモンのPIDを直接調べなくてもシグナルが送れる。daemontoolsを使って走らせた各デーモンはPIDではなく名前で指定でき、複数のデーモンにシグナルを送ることも可能
- 起動するデーモンごとにlimitがかけられる。これにより、メモリ使用量やユーザー権限を制限できる参考：http://www.unixuser.org/~euske/doc/daemontools/myfaq/faq-1.html#3
daemontoolsのインストール
では、daemontoolsの導入を順に見ていきましょう。最新版であるdaemontools-0.76.tar.gzをhttp://cr.yp.to/daemontools/install.htmlからダウンロードし、適当な作業ディレクトリに保存します。また、インストールの際は/packageディレクトリを用意し、そのディレクトリ下で作業する必要があります。/（ルート）にディレクトリを作ることに抵抗を感じる方もいると思いますが、パッケージに含まれるinstallスクリプトを実行するためには避けられない作業です。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
次に、/packageディレクトリに対して適切なパーミションを設定します。その際、スティッキービット（注）も付加します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
パーミッションを設定したら/packageディレクトリに移動し、daemontools-0.76.tar.gzファイルを展開してその中に含まれるinstallスクリプトを実行します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
以上の作業で、以下のディレクトリとファイルが作成されます。
- 新たに作成されるディレクトリ
/service
/command - 作成されるファイルおよびそのシンボリックリンク
/package/admin/daemontools/command/下に実行ファイル
/command/下にそのシンボリックリンク
/usr/local/bin/下にさらにシンボリックリンク
また、/etc/inittabファイルの末尾に次の1行が追加されます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
inittabの変更を有効にするには「kill -HUP 1」を実行する必要がありますが、installスクリプトですでに実行されています。確認のため、svscan関連のコマンドが起動されているかどうかをpsコマンドで見ておきましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
これでインストールは完了です。次に、daemontoolsが適切に日付を処理できているかを確認します。出力の左と右で時間が同じであれば問題ありません。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
ここで、「TAI64N形式」のタイムスタンプについて説明する必要があります。先ほどの導入のメリットには加えませんでしたが、daemontoolsを使用することでナノ秒精度でのロギングが可能になります。実質的にはマシンクロックで制限されますが、それでもマイクロ秒の精度です。それを実現する基盤がTAI64Nです。ここで使用したtai64nとtai64nlocalコマンドは、通常私たちが認識できる日付フォーマットで出力させるためのものです。これについては後ほどあらためて紹介します。
参考：TAI「Temps Atomique International」（国際原子時間International Atomic Timeのフランス語）http://tehanu.hpcl.titech.ac.jp/time/utctai.html）
daemontoolsによるプロセス監視
併せて、プロセス監視の仕組みも理解しておきましょう。通常のrc起動スクリプトはサーバが起動される際に1度実行されるだけで、異常終了には関知しません。そのため、管理者はプロセスが起動しているかをpsコマンドで確認するか、cronを利用してプロセスが起動されていない場合は再立ち上げするようなスクリプトを作成して対処します。経験された方なら、そのために払われる労力が相当なものだと理解できると思います。商用サービスを展開しているところでは、専用監視ツールを導入することも少なくないと思います。しかし、実際の運用において、プロセスが毎日のように落ちることはまれです（注）。まれに発生する障害に対して並々ならぬ努力が払われているプロセス監視ですが、これらの煩わしい作業をsvscanプロセスが代行します。
daemontoolsの導入によってインストールされたsvscanプロセスは、常に/serviceディレクトリを5秒置きに監視します。/serviceディレクトリにサブディレクトリsubが存在する、または作成された場合、1つのsubに対し1つのsuperviseコマンドを立ち上げます。もし、superviseプロセスが終了していないサービスを発見した場合、そのsuperviseプロセスを再開させます。
superviseコマンドはサブディレクトリ（ここではsubとします）に移動して./runスクリプトを起動させ、プロセスを監視します。この./runにはサービスを実行するスクリプトを記述しておきます。subにスティッキービットが立っている場合は、さらにsub中のlogディレクトリに移動して、新しいsuperviseコマンドを立ち上げます。新しいsuperviseコマンドはlogディレクトリ中の./runスクリプトを起動して監視します。この./runスクリプトに、ログを記録するようにmultilogの実行を記述しておきます。2つのsuperviseコマンドは1組と見なされ、sub/runの出力とsub/log/runの入力はパイプでつながれます。これが、漏れのないログ記録を実現するゆえんです。
ここで注意しなければいけないのは、新規にsuperviseでプロセスを起動したい場合、/serviceディレクトリにサブディレクトリを作りスティッキービットを立てる作業を5秒以内（実際にはもっと短い間隔）で終了させる必要があることです。svscanはディレクトリの属性変更を感知しないため、最初にサブディレクトリを見つけた際の属性をその後も引き継ぎます。
これを回避するには、「mkdir /service/sub;chmod +t /service/sub」と一気に一連の作業を行うか、/service以外のディレクトリで起動のためのディレクトリやファイルを用意しておき、準備が完了した時点で/service下にシンボリックリンクを作成するかです。今回は、/var/qmail/service下で起動の準備を行い、シンボリックリンクを作成する方法を使います。
Copyright © ITmedia, Inc. All Rights Reserved.