エラーが見つかったサーバーに対する対処法

サーバーのログではさまざまな情報がどんどん保存されていきます。

障害はいつ発生するのか予測できませんが、そのために管理者がコンソールの前に張り付いている訳にもいきません。また、仮に時間をかけたとしても、サーバー上に日々溜まるログファイルすべてに抜けもれなく目を通すことは不可能です。これは、障害を示すログを見逃さないことがいかに難しいかということでもあります。

そこで活躍するのがログ監視ツールです。例えば、パトロールクラリスのログ監視は、ESXi（サーバー仮想化ソフトウェア）とWindowsサーバーの両方に対応しており、日本語のログの監視も可能です。ログ種別、ログメッセージなどの監視が可能で、ホスト単位で日ごとのログも正規表現で検索できるなど機能に富んでいます。

しかし、ログを見るだけでは、サーバーの対応は充分ではありません。エラーが見つかった場合、どのような対応をしていくべきかを抑えていきましょう。

読み書きエラーは、物理的な故障が発生しているケースが多く見受けられます。読み書きエラーが発生している場合、HDDのヘッド故障が原因の可能性が高いでしょう。この場合は、物理的な故障なので、すぐに交換を行わなければなりません。

場合によってはHDDに保存されているデータを救出しなければならないこともあるでしょう。まずはddコマンドを利用して、ディスクイメージとしてファイル保存を行うことです。イメージを保存できてしまえば交換もスムーズに行うことができるでしょう。

メモリが枯渇した場合、重要なプロセスが強制的に終了されてしまう

サーバーを長期的に運用していくと必ず当たる壁がメモリ不足（Out Of Memory）です。このようなOOM Killerによってhttpdのような重要なプロセスが強制終了してしまうことがあります。OOM Killerは、Linuxカーネルの仕組みの一つで、メモリが足りなくなった際に、強制的に稼働中のプロセスを終了させてメモリを確保します。

このログが記録された場合、重要なプロセスであっても容赦なく強制終了してしまうことが多いので、サービス自体がうまく動かなくなってしまうこともあります。このような場合は、すみやかに重要なプロセスを復旧させる必要と、何が原因でメモリ不足に陥ったのかという原因究明を行っていくことが重対処の中心となります。

OSには記録されないログを参照する

OSのログは重要ですが、実はハードウエアが保持しているログもあります。それがIPMIのシステムイベントログです。IPMIはサーバー温度、電圧、ファンなどの状態監視、復旧、リモート制御を行うインターフェースで、主要なサーバーベンダはほとんどIPMIをサポートしています。

IPMIログの良い点はメモリ不良の場合でもログが記録されていることです。メモリの不良の場合、突然のサーバーリセットという形になりますが、サーバーリセットは例えば電源ユニットの不良でも発生し得る現象なので、メモリ不足かどうかは判断できません。また、OSログには何も記録されないので、IPMIログでしかメモリ不良は突き止められないのです。

もし、OSだけで障害原因が突き止めきれない場合は、ハードウェアに記録されたログを頼りにすることで原因特定が容易になるでしょう。

情報の一つとしてログを活用しよう

ログはサーバーのヘルプサインです。実務上は、サーバー運用の中心は、まずリソースや、サービスレスポンス監視からとなり、即応性がないログ以外の監視が多くなります。しかし、障害発生時の原因究明にはログは貴重な情報源の一つ。障害原因究明には欠かせない存在となるので、適切に管理していきましょう。