エラーログで障害原因を突き止めろ！

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

最後に、少し趣向を変え、OSではなくハードウエアが保持しているログについて説明します。

HDDに問題が発生した場合には、OS上のログに記録が残るため、対応は比較的容易です。ところが、問題がメモリの不良であった場合にはそうはいきません。この場合、現象としては、突然サーバーリセットがかかることが多いのですが、サーバーリセットは例えば電源ユニットの不良でも発生し得る現象です。そして、突然サーバーリセットがかかるような場合、OSのログには何も記録されていないことが普通です。

もちろん、疑わしい部品を一つ一つ交換して問題のある部品を突き止めればよいのですが、サービスの運用中であれば、長時間サーバーを停止させて障害の原因を追究することは困難です。

こうした場合に利用できるのが、IPMI（Intelligent Platform Management Interface）のシステムイベントログです。IPMIは、サーバーの温度や、電圧、ファン、バスなどの状態の監視や復旧、リモート制御を行うための標準インターフェース仕様で、主要なサーバーベンダのハードウエアのほとんどがIPMIをサポートしています。

IPMIの情報の参照には、OpenIPMI-toolsパッケージに含まれるipmitoolコマンドが使えます。図3-1はipmitoolを使ったシステムイベントログの表示例です。

また、サーバーが主要なサーバベンダの製品の場合には、ベンダが提供しているサーバー管理ツールを使っても、同様の情報を得ることができます。図3-2は、Dellが提供しているサーバー管理ツール（OpenManage Server Administrator）に付属しているomreportというコマンドで参照したものです。DellのサーバーではIPMIのシステムイベントログに相当する情報をESMログと呼んでいますが、出力フォーマットが違うだけで情報としては図3-1と同一であることが分かると思います。

また、マザーボードによってはIPMIに対応していなくともDMI（DesktopManagement Interface）テーブルにIPMIのシステムイベントログと同様の情報を保持している場合もあります。この場合には、dmidecodeというツールが利用できます。図3-3は、dmidecodeを使ったシステムイベントログの表示例です（図3-1、図3-2とは別のサーバーのログです）。

こうしたログを参照することで、ハードウエアに障害が発生したのか否かが分かる場合がありますので、状況に応じて参照してみるといいでしょう。

情報源の1つとしてログを活用する

ここまで、ログに的をしぼった説明を行ってきましたが、実際のサーバー運用においては、ログのほかにサーバーリソースやサーバーで稼働しているサービスの応答も監視するのが一般的です。どちらかというと、障害対応のトリガとなるのは、ログ以外の監視であることの方が多いかもしれません。

とはいえ、ひとたび障害が発生すれば、ログが貴重な情報源の1つであり、障害原因の究明に欠かせない存在であることは間違いありません。いざというときのために、ログを把握し、しっかりと管理してきましょう。本連載が、みなさんのサーバー管理の一助になれば幸いです。