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センサーおよびhddtempの両方を実行できます。また、一部のBIOS:は温度停止イベントを記録します。
まず、確認したいのは/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つあります。最初にハードウェアの問題についてOut-Of-Band管理コンソールを確認します。SNMPを構成してメールを受信するか、アラートを監視するソフトウェアにトラップを追加することをお勧めします。
次に、オペレーティングシステムを通じて、/var/log/messages
(RedHatベースのディストリビューション)または/var/log/syslog
(Debianベースのディストリビューション)。
ディスクサブシステムは、ログファイルにほとんど何も記録されないため、問題が発生したときに影響を受けるほど複雑です。
シリアルコンソール経由でログを記録してみます。これには、ケーブル配線と、回線をピックアップする他のシステムが必要ですが、実際に問題が発生する可能性が高くなります。
もちろん、ノードにOracleのALOM/ILOMに似た組み込みの管理システムがある場合は、考えられる問題やログファイルをそこで確認することもできます。