予期しないLinuxサーバーのシャットダウンを調査する方法は？

Debian 6でraid 10に4xSSDを搭載した新しいXeon 55XXサーバーでは、サーバーの構築後2週間以内に2回のランダムなシャットダウンが発生しました。シャットダウンする前に帯域幅ログを確認しても、異常なことを示すものではありません。サーバーの負荷は通常非常に低く（約1）、遠くに配置されています。サーバーがダウンしている間は停電はないようです。

/ var / logを見ていることは知っていますが、どのログを調査すべきか、何を探すべきかはわかりません。だからあなたのヒントに感謝します。

まず、「シャットダウン」を尋ねる必要がありますか？マシンが再起動するのですか、それとも実際に停止するのですか？停止する場合は、構成が間違っているか（おそらくBIOSで）、何かがアクティブにマシンをシャットダウンしています（つまり、init 0）。

そうでない場合、問題はカーネルパニックまたはソフトウェアトリガーハードウェア障害のように聞こえるので、主な候補は/ var / log / syslogと/var/log/kern.logになります。もちろん、サーバーが何らかのサービス（例：apache）を実行している場合も、手がかりが得られます。

多くの場合、このような状況ではログエントリが生成されますが、マシンに問題があるため、エントリをディスクに書き込むことができません。ボックスが同じ場所にある場合、可能性としては、coloパートナーによってシリアルコンソールに接続されている可能性があります。上記のログで疑わしいものが見つからなかった場合に、ここで確認します。

マシンがシリアルコンソールに接続されておらず、ログに何もない場合は、ネットワーク経由でsyslogを別のボックスに送信することを検討できます。おそらく、ネットワークインターフェイスはもう少し長く生き残り、ログメッセージはsyslogサーバーで読み取ることができます。rsyslogまたはsyslog-ngをご覧ください。

更新：

以下の@Johannに同意します。停止の最も可能性の高い原因は、プロセッサ温度のウォッチドッグです。lmsensorsまたはsmartctl（通常は最も簡単です）を使用して、ボックス内の温度をチェック/プロットしてみてください。collectdは、長期にわたって多数の変数を追跡する点で比類のないものであることがわかりました。IPMIとlm-sensorsとhddtempの両方を実行できます。また、一部のBIOS：esは温度停止イベントを記録します。

まず、を確認し/var/log/syslogます。何を探すべきかわからない場合は、単語error、panicおよびを探すことから始めますwarning。

grep -i error /var/log/syslog

利用可能なシステムグラフがある場合（例：Munin）。それらを確認し、異常なパターンを探します。muninがインストールされていない場合は、インストールすることをお勧めします（apt-get install munin munin-node）

また、システムクラッシュに関連する可能性のある興味深いメッセージがないか、ルートメールを確認する必要があります。

チェックする必要がある他のログファイルは、アプリケーションエラーログです。例/var/log/apache2/error.logまたは類似。問題につながる情報が含まれている場合があります。

私の経験では、「予期しない停止」はほとんどの場合過熱が原因です。lm_sensorsを介して温度とファン速度をチェックし、それらが良好であることを確認します。

最近、同じパターンがありました。サポートが手動で開始してから約1時間後にサーバーが停止しました。この時間後、CPU温度はBIOSで設定されたしきい値（iirc 60または70°C）に達し、システムを停止しました。これらすべてのトラブルは、CPUファンの破損が原因です。ファンを交換すると、すべてが正常に戻りました。

/ var / logディレクトリ（およびそのサブディレクトリ）には、次のような多くのログファイルがあります。

/var/log/boot

そして

/var/log/boot.log

上記のファイルから始めます。

シャットダウンのトリガーを確認する方法は2つあります。まず、ハードウェアの問題について帯域外管理コンソールを確認します。SNMPを構成し、アラートを監視ソフトウェアにトラップを追加することをお勧めします。

次に、オペレーティングシステムを使用して、/var/log/messages（RedHatベースのディストリビューション）または/var/log/syslog（Debianベースのディストリビューション）を確認できます。

ディスクサブシステムは、問題が発生したときに影響を受けるほど複雑であるため、ログファイルにはほとんど何も記録されません。

シリアルコンソールを介してログインしてみてください。これには、ケーブル配線と回線をピックアップするための別のシステムが必要ですが、実際に問題をキャッチする可能性が高くなります。

もちろん、ノードにOracleのALOM / ILOMに似た組み込みの管理システムがある場合は、問題の可能性をチェックし、そこにログファイルを作成することもできます。

次のコマンドでシステムがダウンしているという事実をシステムが知っているかどうかを確認できます

sudo last -1x reboot
sudo last -1x shutdown

情報がない場合は、>>電源の喪失または外部の何かが発生する可能性があります

情報がある場合=>再起動/シャットダウン時間の前後にログを検索する