Descobrir o “quem, o que, quando e porquê” de uma falha no servidor

Question

Atualmente, sou o administrador do Moodle da minha universidade e uma das minhas responsabilidades é manter o servidor funcionando e funcionando o tempo todo. Às vezes, sem nenhum motivo aparente, o Apache ou o MySQL falham, causando caos total dentro da Universidade.

Em um sentido amplo, quais são as "diretrizes básicas" a seguir quando um servidor trava? O que devo fazer primeiro para descobrir o que aconteceu? Como sei quantos usuários estavam conectados no momento da falha (ou a qualquer momento)? Como eu sei quanta memória ou potência eu preciso para a demanda atual?

Existem muitas questões relacionadas umas com as outras, mas estas são as mais importantes. Obviamente, estou longe de ser um Sysadmin experiente. Eu conheço o Linux, se isso ajuda.

Nossas especificações de servidor:

• Intel Dual-Core Xeon @ 2,66 GHz (se bem me lembro)
• 2 GB de RAM
• HDD de 500 GB
• CentOS 5.4
• MySQL 5.0.45
• PHP 5.3.12

EDIT: Desculpe pela falta de informação.

Eu li os logs do Apache e do MySQL sem nenhum dado significativo aparecer. Apache é o mais informativo, dizendo quando ele caiu, mas não por outro motivo. Na verdade, o erro na falha do Apache não é na verdade um "erro", apenas a entrada de log dele reinicia - o pior cenário é o Apache dando "SIGTERM" ou "SIGKILL". Os logs do MySQL não informam absolutamente nada.

Eu costumo tentar acompanhar o que está acontecendo usando "top". Quando as falhas acontecem, raramente há todas (ou até metade) da memória do sistema consumida. Em situações realmente terríveis, o uso da CPU atingiu ... 80%?

O uso de disco e memória parece bom (du e show gratuito sem problemas). O acesso SSH geralmente está bem. Parece que o MySQL ou o Apache falham aleatoriamente, porque, mesmo quando a demanda não é tão alta, ela ainda trava.

O problema pode ser reduzido para "Quais logs devem ser verificados?" "Como verificar o número de conexões?"

    

Answer 1

Geralmente, você quer começar examinando os logs do sistema e do aplicativo, que podem ou não revelar algo. Se você tiver ferramentas sar em execução, você vai querer olhar para as estatísticas do sistema que levaram ao acidente. / p>

É claro que é sempre bom verificar coisas óbvias como disco cheio, interrupções de energia, logins de usuários recentes (talvez alguém tenha digitado 'reboot').

Dependendo da falha, talvez você queira examinar o console para ver se ainda há informações de despejo no visor.

Se você não encontrar nada óbvio nos logs, sua próxima etapa pode ser adivinhar o que você acha que é o problema e criar alguns scripts para monitorar esse aspecto do sistema, para que você possa obter informações mais úteis no futuro. Se você acha que o número de conexões pode ser o problema, então você pode querer coletar periodicamente o out of netstat ou algo do tipo.

    

Answer 2

Os arquivos de dump principal são extremamente úteis nessas situações. Quaisquer core dumps dos tempos de falha disponíveis? link