|
システム管理者は、サーバの状態にたえず目を光らせ、順調に稼働しているかどうかを確かめる必要がある。問題が見つかった場合には、その発端がいつだったのか、そこで何が起こったのかを詳しく調べることになる。そのためには、定期的にログをとり、そのデータをすばやく分析できる手段が必要だ。この記事では、Webインタフェースから1台または複数のサーバを監視できるツールをいくつか紹介する。
それぞれのツールは、ねらいどころが少しずつ違っている。以降ではすべてを順に説明していくので、自分の環境に合ったものを見つけてほしい。どんな言語と方法でデータのロギングを行っているかによって、システムの処理効率は大きく変わってくる。たとえばcollectdは、C言語で書かれたデーモンなので、システム情報を収集するために新しいプロセスを生成する必要がない。一方、Perlで記述され、cronによって定期的に生成されるものもある。こうした収集プログラムで使われるPerlインタプリタやPerlモジュールはディスクキャッシュに格納される可能性が高いが、システム側はシステム情報の定期的な収集のために1つ以上のプロセスを新たに生成する必要がある。
RRDtool
この記事で紹介するツールのほとんどは、RRDtoolなど、ほかのツール群を活用している。このRRDtoolには、時系列のデータを保存してグラフ化するためのツール群が含まれる。
RRDtoolプロジェクトでは、マシンのディスクサブシステムに与える影響を最小限に抑えつつ新たな時系列データを保存することに注力している。そんなことがなぜ重要なのかと思う人もいるだろう。いくつかのデータ値を5～10秒おきに取得し、その結果をファイルに追加していくだけなら、サーバへの影響はそれほど大きくないはずだ。だが、実際に監視を始めてみると、データの数は意外に多い。具体的には、CPU（コア別の負荷や数値など、おそらく16項目ほどのデータ）、メモリ（スワップやキャッシュサイズのほかに5項目程度）、ディスク空き容量（20項目くらいか）、それにUPS（無停電電源装置）に関する指標（特に重要なものは10種類）などがある。ネットワークトラフィックによる負荷を別にしても、50ものデータ値を10秒おきに取り続けることになりうるのだ。
RRDtoolでは、これらの値のディスクへの書き込みを4ないし8バイト単位ではなく、4KBのブロック単位で行う。そのため、ディスクサブシステムはデータ取得のたびに書き込みを行わずに済む。一方、RRDtoolのデータを必要とする外部のツールは、フラッシュによって、RRDtoolがキャッシュしているすべてのデータをディスクに書き出させることができる。また、Linuxカーネルに対して自らのファイルで使用するキャッシュポリシーを伝えるあたりも気が利いている。RRDtoolでは一度に4KBのデータが書き込まれるので、データをキャッシュに残しておいても意味がなく、そうしたデータは（RRDtoolのグラフコマンドの利用などによって）解析でも行わない限り再び必要になることはない。
システム監視ツールはファイルへの書き込みを頻繁に行うため、そうしたファイルの保存先を最適化するという手もある。従来の回転式ディスクの場合、ファイルシステムのシークのほうが多数のブロックの連続読み取りよりも時間がかかる。そのため、Linuxカーネルは、あるブロックの読み取り時についでに後続のブロックも読み取ってキャッシュしておき、あとでアプリケーション側で必要になった場合にシークを行わずに済ませようとする。だが、RRDtoolファイルに対する操作はほとんどが書き込みで、しかも通常は1ディスクブロックサイズの小さな単位でしか行われないため、RRDtoolファイルの保存先パーティションについては、こうした先読みの機能を無効にしておいてもよい。たとえば、デバイスの先読みブロック数を2にするには、util-linux-ngのblockdevプログラムを使って「blockdev --setra 16 /dev/sdX 」のようにする（--setraには先読みブロック数を512バイトブロックを1単位として指定する）。また、atime更新の無効化や、ファイルシステムおよびRAIDでのwritebackモードの利用もパフォーマンスの向上につながるだろう。RRDtoolのサイトには、ラウンドロビンデータベース（RRD：Round Robin Database）向けにシステムをチューニングするための情報が掲載されている。