Como descobrir a causa do travamento do servidor linux após a reinicialização

Question

Aqui está o acordo,

vem trabalhar apenas para descobrir que um servidor não está respondendo, a máquina está ligada, mas a tela não mostra nada, não responde às entradas do teclado (não tenho sys chaves rq habilitadas).

O servidor precisa estar funcionando o mais rápido possível; então, eu fiz uma reinicialização do servidor e tudo está funcionando bem agora.

Agora meu chefe quer saber o que aconteceu e por quê.

Então, como eu começo a depurar o que deu errado antes da reinicialização? Quais logs devo prestar atenção especial, e existem alguns truques que você pode agora sobre como depurar um congelamento de servidor aleatório (isso não acontece com freqüência - esta é a primeira vez que eu vi isso)

Obrigado por quaisquer orientações e sugestões úteis.

Ps: estou executando o servidor Ubuntu 12.04.

    

Answer 1

Como provavelmente é uma falha de hardware, analiso alguns diagnósticos de hardware.

Se você tiver um controlador RAID de hardware, eu descobriria se você pode ler seu log (se 3Ware, use tw_cli). E, quer você tenha RAID de hardware ou software, você pode observar os parâmetros SMART dos discos (se os discos estiverem conectados a um controlador RAID, você pode precisar de comandos especiais para acessá-los. Consulte a smartctl manpage).

Se você fizer isso:

smartctl -a /dev/sdX

Eu sempre vejo principalmente:

• Contagem do setor realocado. É especialmente ruim quando está aumentando ao longo do tempo. E não confio totalmente em um disco que tenha setores realocados.
• Veja o log de erros da SMART. É complicado ler no início, mas o principal é ver se há eventos e a que horas (expressa em idade do disco em horas) eles ocorreram. Você pode ver a idade atual do disco como um dos parâmetros SMART. Se é recente, pode estar relacionado.

Além disso, fique de olho no dmesg e no syslog para ver se você tem erros ao longo do tempo. Por exemplo, erros de disco geralmente aparecem muito antes de ser um problema fatal como exceções de ata. Nós temos um servidor de registro central (usando rsyslog) que me notifica sobre exceções de ata. Um exemplo rápido de como configurar isso:

/etc/rsyslog.d/60-smtp.conf:

$ModLoad ommail
$ActionMailSMTPServer localhost
$ActionMailFrom [email protected]

/etc/rsyslog.d/70-mail-ata-errors:

$ActionMailTo [email protected]
$template mailSubjectATA,"ATA error on %hostname%"
$template mailBodyATA,"You have ATA errors. Mostly it's the disk and you get these errors before a possible mdraid setup kicks the drive.\r\nBEWARE: ata1.00 is first ata, first disk. Ata1.01 is first ata, second disk. Use the ata-to-device-names.sh script to identify devices.\r\n msg='%msg%'"
$ActionMailSubject mailSubjectATA
$ActionExecOnlyOnceEveryInterval 3600
:msg, regex, "ata.*exception" :ommail:;mailBodyATA

Consulte aqui para o script ata-to-devicenames .

Outra coisa que você pode fazer é um memtest. Os DVDs / CDs de instalação do Ubuntu têm aqueles no menu de inicialização, e eu acredito que qualquer servidor Ubuntu tenha um em seu menu de inicialização regular também. Vamos fazer pelo menos uma passagem, mais, se possível.

Você tem RAM ECC BTW? A RAM ECC é importante para a estabilidade a longo prazo e a integridade dos dados.

    

Answer 2

/var/log/syslog é um bom lugar para começar. Encontre as primeiras mensagens de log após a reinicialização. Eles vão dizer algo sobre o início do syslog e a versão do kernel que você está executando.

Em seguida, role para cima e encontre a última linha, que foi registrada antes que o sistema falhasse. Role mais para ver se você pode encontrar qualquer mensagem de log do próprio kernel.

Percorra outros registros em /var/log para ver se você pode encontrar linhas com um registro de data e hora entre a última linha de registro anterior à falha e a primeira a partir de depois.

É muito provável que todo esse esforço possa limitar o tempo do travamento, mas não informar nada sobre o motivo da falha do servidor. Em particular, se for uma falha de hardware, pode ser difícil obter mensagens de log adequadas.

Pode haver alterações na configuração, que podem ser feitas para ajudar a obter mais informações, caso o problema ocorra novamente. Ativar a chave Sys Rq é uma opção. Também pode valer a pena desligar a tela branca (suponho que você evite desperdiçar energia por não ter o monitor ligado, enquanto você não estiver usando). Além disso, o registro em log da rede em outro servidor pode ajudar, especialmente se a causa raiz for relacionada ao disco / sistema de arquivos.

    

Answer 3

Parte de mim quer dizer que o Linux não deve simplesmente travar ... Sistemas operacionais modernos sob padrões de uso normal devem ser razoavelmente estáveis. Quando eu começo a ver a instabilidade do servidor, é quase sempre uma interação de hardware ou driver. Eu recomendaria olhar bem de perto o servidor, suas condições e componentes relacionados (RAM, armazenamento, etc.).

Se você estiver usando hardware que não forneça ou não possa fornecer informações sobre a integridade do hardware (como uma máquina de classe de desktop), há pouca chance de você ver muito de qualquer coisa refletida no registro no nível do Linux.