Como investigar o encerramento inesperado do servidor Linux?

Question

Em um novo servidor Xeon 55XX com 4xSSD no ataque 10 com o Debian 6, eu experimentei dois desligamentos aleatórios dentro de duas semanas após o servidor estar sendo construído. Observar logs de largura de banda antes de desligar não indica nada incomum. A carga do servidor é geralmente muito baixa (cerca de 1) e é colocada longe. Parece não haver falta de energia enquanto o servidor caiu.

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

    

Answer 1

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

Se não, seu candidato principal seria / var / log / syslog e /var/log/kern.log, pois seu problema parece um kernel panic ou um software acionado por falha de hardware. É claro que, se o servidor executar algum serviço (por exemplo, apache), você poderá ter uma pista também.

Geralmente, em situações como essa, há entradas de log geradas, mas como a máquina está com dificuldades, ela não consegue gravar as entradas no disco. Se a caixa estiver colocada, é provável que ela esteja conectada a um console serial pelo parceiro de cores. É onde eu procuraria se não encontrasse nada de suspeito nos registros acima.

Se a máquina não estiver conectada a um console serial e não houver nada no log, talvez você queira considerar o envio de 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 no syslog-ng.

ATUALIZAÇÃO:

Concordo com @Johann abaixo. A causa mais provável de parada é o watchdog de temperatura do processador. Tente verificar / traçar a temperatura na caixa via lmsensors ou smartctl (geralmente o mais fácil). Eu acho que collectd é inigualável em manter o controle de grande número de variáveis ao longo do tempo. Ele pode fazer tanto o IPMI quanto o lm-sensors e o hddtemp. Além disso, alguns eventos de parada de temperatura do BIOS: es são interrompidos.

    

Answer 2

Primeiro, você deseja verificar /var/log/syslog . Se você não tem certeza do que procurar, pode começar procurando as palavras error , panic e 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 tem munin instalado, pode ser uma idéia instalá-lo ( apt-get install munin munin-node )

Você também deve verificar o correio-raiz em busca de mensagens interessantes que possam estar relacionadas à falha do seu sistema.

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

    

Answer 3

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 elas são boas.

Recentemente, tivemos o mesmo padrão: um servidor parou cerca de uma hora após o início manual do suporte. Após esse horário, a temperatura da CPU atingiu o limite configurado no BIOS (60 ou 70 ° C) e interrompeu o sistema. Todos esses problemas foram causados por um ventilador da CPU quebrado. Depois de substituir o ventilador, tudo voltou ao normal.

    

Answer 4

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

/var/log/boot

e

/var/log/boot.log

Comece com os arquivos acima.

    

Answer 5

Existem duas maneiras de verificar o que foi acionado, primeiro verifique o console Out-Of-Band Management para qualquer problema no hardware, sugiro configurar o SNMP e receber emails ou adicionar as armadilhas em um software de monitoramento para qualquer alerta .

Em seguida, 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).

    

Answer 6

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

Tente fazer o logon no console serial. Isso precisa de um pouco de cabeamento e de um outro sistema para pegar as linhas, mas você tem mais chances de pegar o problema.

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