Come investigare lo spegnimento imprevisto del server Linux?

In un nuovo server Xeon 55XX con 4xSSD al raid 10 con Debian 6, ho riscontrato 2 arresti casuali entro due settimane dalla creazione del server. Osservare i registri della larghezza di banda prima dell'arresto non indica nulla di insolito. Il carico del server è generalmente molto basso (circa 1) ed è collocato lontano. Non sembra esserci alcuna interruzione di corrente mentre il server è inattivo.

So che guardo / var / log ma non sono sicuro di quali log dovrei investigare e cosa dovrei cercare. Quindi apprezzo i tuoi suggerimenti.

Innanzitutto, devo chiedere: "arresti"? Vuoi dire che la macchina si riavvia o si ferma effettivamente? Se si interrompe, è configurato in modo errato (forse nel BIOS) o qualcosa sta arrestando attivamente la macchina (ovvero init 0).

Altrimenti, il tuo candidato principale sarebbe / var / log / syslog e /var/log/kern.log poiché il tuo problema sembra un panico del kernel o un errore hardware attivato dal software. Naturalmente, se il server esegue un servizio (ad es. Apache) può darti anche un indizio.

Spesso, in situazioni come queste, vengono generate voci di registro, ma poiché la macchina ha difficoltà, non riuscirà a scrivere le voci sul disco. Se la scatola è colocata, è probabile che sia connessa a una console seriale dal partner colo. È qui che vorrei cercare se non trovassi nulla di sospetto nei registri di cui sopra.

Se la macchina non è connessa a una console seriale e non c'è nulla nel registro, è possibile prendere in considerazione l'invio di syslog a una casella diversa tramite la rete. Forse l'interfaccia di rete sopravvive un po 'più a lungo e i messaggi di registro possono essere letti sul server syslog. Dai un'occhiata a rsyslog o syslog-ng.

AGGIORNARE:

Sono d'accordo con @Johann di seguito. La causa più probabile di arresto è il watchdog della temperatura del processore. Prova a controllare / tracciare la temperatura nella scatola tramite lmsensors o smartctl (di solito il più semplice). Trovo che collectd non abbia eguali nel tenere traccia di un gran numero di variabili nel tempo. Può fare sia IPMI che lm-sensor e hddtemp. Inoltre, alcuni BIOS: es registrano gli eventi di arresto della temperatura.

Innanzitutto, vuoi controllare /var/log/syslog. Se non siete sicuri di cosa cercare, si può iniziare con la ricerca di parole error, panice warning.

grep -i error /var/log/syslog

Se sono disponibili grafici di sistema (ad esempio Munin). Controllali e cerca schemi anormali. Se non hai installato munin, potrebbe essere un'idea installarlo ( apt-get install munin munin-node)

È inoltre necessario controllare la posta root per eventuali messaggi interessanti che potrebbero essere correlati al crash del sistema.

Altri file di registro che dovresti controllare sono i log degli errori dell'applicazione. Ad esempio /var/log/apache2/error.logo simile. Potrebbero contenere informazioni che portano al problema.

Nella mia esperienza, un "arresto inatteso" è quasi sempre causato dal surriscaldamento. Controlla le temperature e la velocità della ventola tramite lm_sensors e assicurati che siano buone.

Recentemente abbiamo avuto lo stesso modello: un server si è arrestato circa un'ora dopo l'avvio manuale del supporto. Dopo queste ore la temperatura della CPU ha raggiunto la soglia configurata nel BIOS (iirc 60 o 70 ° C) e ha arrestato il sistema. Tutti questi problemi sono stati causati da una ventola della CPU rotta. Dopo aver sostituito la ventola, tutto è tornato alla normalità.

Esistono numerosi file di log nella directory / var / log (ed è sottodirectory), incluso

/var/log/boot

e

/var/log/boot.log

Inizia con i file sopra.

Esistono 2 modi per verificare cosa ha provocato l'arresto, per prima cosa controllare la console di gestione fuori banda per qualsiasi problema nell'hardware, suggerirei di configurare SNMP e ricevere e-mail o aggiungere le trap in un software di monitoraggio per qualsiasi avviso.

Quindi, attraverso il sistema operativo, è possibile selezionare /var/log/messages(distribuzioni basate su RedHat) o /var/log/syslog(distribuzioni basate su Debian).

Il sottosistema del disco è abbastanza complicato da essere interessato quando si verifica un problema, a causa della difficoltà di ottenere nulla nei file di registro.

Prova ad accedere tramite la console seriale. Ciò richiede un po 'di cablaggio e un altro sistema per raccogliere le linee, ma hai maggiori possibilità di individuare il problema.

Naturalmente se il tuo nodo ha un sistema di gestione integrato simile a Oracle ALOM / ILOM, puoi anche verificare eventuali problemi e file di registro lì.

Puoi scoprire se il sistema è a conoscenza del fatto che stava andando giù con i comandi successivi

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

Se nessuna informazione => allora potrebbe essere una perdita di potenza o qualcos'altro esterno

se hai info => cerca nei log intorno al tempo di riavvio / spegnimento