Como investigar o desligamento inesperado do servidor Linux?

Em um novo servidor Xeon 55XX com 4xSSD no raid 10 do Debian 6, experimentei dois desligamentos aleatórios dentro de duas semanas após a construção do servidor. Observar os logs de largura de banda antes do desligamento não indica nada de incomum. Geralmente, a carga do servidor é muito baixa (cerca de 1) e é colocada muito longe. Parece não haver queda de energia enquanto o servidor foi desativado.

Sei que olho para / var / log, mas não tenho certeza de quais logs devo investigar e o que devo procurar. Então, aprecie suas dicas.

Primeiro, devo perguntar: "desligamentos"? Você quer dizer que a máquina reinicia ou realmente pára? Se parar, está mal configurado (talvez no BIOS) ou algo está desligando ativamente a máquina (ou seja, init 0).

Caso contrário, seu candidato principal seria / var / log / syslog e /var/log/kern.log, pois seu problema parece um pânico no kernel ou uma falha de hardware acionada por software. Obviamente, se o servidor executar algum serviço (por exemplo, apache) também poderá lhe dar uma pista.

Frequentemente, em situações como essa, são geradas entradas de log, mas como a máquina está tendo dificuldades, ela não consegue gravar as entradas no disco. Se a caixa estiver colocada, as chances são de que esteja conectada a um console serial pelo parceiro colo. É aí que eu procuraria se não encontrasse nada suspeito nos logs acima.

Se a máquina não estiver conectada a um console serial e não houver nada no log, convém enviar o syslog para uma caixa diferente via rede. Talvez a interface de rede sobreviva um pouco mais e as mensagens de log possam ser lidas no servidor syslog. Dê uma olhada no rsyslog ou syslog-ng.

ATUALIZAR:

Eu concordo com @Johann abaixo. A causa mais provável de interrupção é o watchdog de temperatura do processador. Tente verificar / plotar a temperatura na caixa via lmsensors ou smartctl (geralmente o mais fácil). Acho que collectd é incomparável em acompanhar um grande número de variáveis ​​ao longo do tempo. Ele pode fazer IPMI e lm-sensores e hddtemp. Além disso, alguns BIOS: es registram eventos de parada de temperatura.

Primeiro, você deseja verificar /var/log/syslog. Se você não tem certeza o que procurar, você pode começar por olhar para as palavras error, panice warning.

grep -i error /var/log/syslog

Se você tiver gráficos do sistema disponíveis (por exemplo, Munin). Verifique-os e procure padrões anormais. Se você não possui o munin instalado, pode ser uma ideia instalá-lo ( apt-get install munin munin-node)

Você também deve verificar se há mensagens interessantes no root-mail relacionadas à falha do sistema.

Outros arquivos de log que você deve verificar são os logs de erros do aplicativo. Por exemplo, /var/log/apache2/error.logou similar. Eles podem conter informações que levam ao problema.

Na minha experiência, uma "parada inesperada" é quase sempre causada por superaquecimento. Verifique suas temperaturas e velocidades do ventilador via lm_sensors e verifique se estão boas.

Recentemente, tivemos o mesmo padrão: um servidor parou cerca de uma hora depois que o suporte o iniciou manualmente. Após essas horas, a temperatura da CPU atingiu o limite configurado no BIOS (iirc 60 ou 70 ° C) e interrompeu o sistema. Todos esses problemas foram causados ​​por um ventilador quebrado da CPU. Depois de substituir o ventilador, tudo voltou ao normal.

Há vários arquivos de log no diretório / var / log (e seus subdiretórios), incluindo

/var/log/boot

e

/var/log/boot.log

Comece com os arquivos acima.

Existem duas maneiras de verificar o desligamento acionado. Primeiro, verifique o console de gerenciamento fora de banda para verificar se há algum problema no hardware. Sugiro configurar o SNMP e receber emails ou adicionar os traps em um software de monitoramento para qualquer alerta.

Depois, através do sistema operacional, você pode verificar /var/log/messages(distribuições baseadas em RedHat) ou /var/log/syslog(distribuições baseadas em Debian).

O subsistema de disco é complicado o suficiente para ser afetado quando ocorre um problema, porque você dificilmente obterá algo em seus arquivos de log.

Tente fazer logon no console serial. Isso precisa de alguns cabos e um outro sistema para captar as linhas, mas você tem melhores chances de realmente pegar o problema.

Obviamente, se o seu nó tiver um sistema de gerenciamento interno semelhante ao ALOM / ILOM do Oracle, você também poderá verificar possíveis problemas e arquivos de log lá.

Você pode descobrir se o sistema sabe do fato de que ele estava inoperante com os próximos comandos

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

Se nenhuma informação =>, pode haver perda de poder ou outra coisa externa

se você tiver info => pesquisar nos logs em torno do tempo de reinicialização / desligamento