Qual é a primeira coisa que você verifica quando um servidor unix intocado começa a ficar frenético?

Question

Então você tem esse servidor unix bem organizado e é super rápido e funciona muito bem e tudo é ótimo por meses, e de repente todos os tipos de erros estranhos começam a aparecer para uma variedade de serviços diferentes e nenhum deles faz muito sentido por conta própria, muito menos juntos.

Quais são as coisas baratas que você deve verificar assim que tiver sua sessão ssh na máquina?

Eu estou especialmente interessado em histórias de trauma que destacam comandos não óbvios e situações raras, mas eu acho que o que é óbvio varia de pessoa para pessoa, então podemos apenas listá-las livremente.

    

Answer 1

Primeiro pedido: é responsivo?

Se você não conseguir fazer login, haverá problemas maiores em andamento. Isso geralmente vem em dois tipos: falha de hardware e falha de software. Ambos são potencialmente catastróficos. Para evitar erros do DFA, verifique primeiro a integridade geral do hardware - um simples retorno geralmente será suficiente.

Segunda ordem: as estruturas subjacentes do sistema estão em boa saúde e ordem?

Verifique a "Golden Triad" dos sistemas:

• Tempo suficiente da CPU é gratuito para processamento
• O espaço em disco suficiente é gratuito para armazenamento
• A memória suficiente é gratuita para cargas de trabalho

Nas últimas décadas, a tríade expandiu-se para um "quad" que inclui comunicações (networking):

• A conectividade é funcional, responsiva e tem capacidade

Terceira ordem: qual é a gravidade do problema?

Quais programas ou serviços são afetados? Em ordem decrescente de gravidade, é sistêmica (em todo o sistema), agrupada (um grupo de programas) ou isolada (um programa específico)? Geralmente, os clusters de programas estão desativados porque um serviço subjacente específico falhou ou não respondeu. Questões sistêmicas às vezes são relacionadas a isso (pense em conflitos de DNS ou IP), mas saber onde procurar é geralmente a chave.

Quarta ordem: as ferramentas de diagnóstico fornecem dados úteis relevantes para o problema? Agora que você tem informações sobre a integridade do sistema (segunda ordem) e quais partes dele estão com problemas (terceira ordem), isso deve facilitar a localização do problema.

Mensagens de erro ou arquivos de log devem ser um ponto de referência comum nessa jornada.

Problemas da CPU:

• loadav
• top
• strace

Problemas de espaço em disco / IO:

• df
• du
• lsof
• iostat
• vmstat

Problemas de memória:

• grátis

Problemas de conectividade:

• ping
• route (e arp e rarp e amigos)
• iptables, ipchains, ipfw (para aqueles caras do BSD por aí)
• traceroute ou mtr
• hosts, nslookup ou dig
• netstat

Queixa mais comum (que ouço):

O e-mail não está sendo entregue rápido o suficiente (mais de um minuto, do envio ao recebimento pelo destinatário) ou, o e-mail está rejeitando minha tentativa de envio. Isso geralmente se resume ao limitador de taxa no Postfix que entra em ação durante uma tempestade de spam, o que afeta a capacidade de aceitar entregas internas.

Um exemplo da vida real:

No entanto, isso nem sempre é o caso. Uma vez, o problema persistiu independentemente das reinicializações do serviço; Então, depois de 3 minutos, era hora de começar a olhar em volta. A CPU estava ocupada, mas abaixo de 100%, mas a carga subiu para 15 em uma caixa de apenas 2 núcleos, e estava ameaçando subir mais. O comando de cima revelou que o sistema de e-mail estava em overdrive, junto com o verificador de e-mail, mas não havia processos filho do amavis para serem vistos. Essa foi a pista - o comando de fila de mensagens (mailq) mostrou mais de 150 mensagens não entregues, mais de 80% das quais eram spam , nos últimos 20 minutos. Um ajuste rápido para reduzir o limitador de taxa (que reduziu a taxa de ingresso da tempestade de spam) enquanto aumentava o número de processos de verificação de e-mail filho (para ajudar a processar o backlog), seguido por uma reinicialização de serviço, resolveu o problema e o sistema conseguiu para completar as entregas em um curto espaço de tempo.

A causa do problema foi que o processo pai do amavis tinha sido desativado, e os processos-filhos acabaram sendo executados (eles terminam automaticamente depois de tantas varreduras para evitar vazamentos de memória). Então, havia processos SMTP no postfix tentando entrar em contato ... thin air ... para fazer a varredura de spam / vírus que era necessária. A distro que eu estava usando tinha pacotes desatualizados que nunca seriam atualizados; Como a instalação deveria ser substituída em um ano ou mais, eu "subestimei" manualmente a instalação para a versão mais recente, que incluía várias correções de bugs. Eu não tive o mesmo problema desde então.

    

Answer 2

geralmente "quem" seguido por "último"

um monte de problemas em máquinas que eu gerenciei por vezes tem sido por causa de uma definição muito solta de "intocável" - muitas vezes alguém fez alguma coisa:)

    

Answer 3

Bem, eu vou começar.

Este aqui me mordeu uma vez, passei horas tentando milhares de coisas diferentes, desabilitando serviços aqui e ali, reiniciando, etc. Qual era o problema? Totalmente sem espaço em disco.

Então, aqui está a primeira coisa que eu digito ao depurar um servidor com problemas de repente:

df -h

Eu nunca esqueço isso agora. Apenas me poupou muito esforço desperdiçado. Pensei em compartilhar.

    

Answer 4

topo (ou htop)

    

Answer 5

Se você puder, eu sempre tentaria desligar todas as NICs que estiverem gerenciando a placa de gerenciamento.

    

Answer 6

Verificando o dmesg em busca de algum erro - geralmente eu começo com dmesg | tail , porque as chances são de que as coisas ainda estão dando errado e o servidor ainda está tentando fazer o que está causando o erro.

    

Answer 7

A primeira coisa que eu verifico é 'top' (existem processos estranhos, aqueles que armazenam memória ou tempo de CPU).

Se não aparecer nada lá, vou verificar "quem" para ver se alguém mais está na minha máquina por algum motivo.

Talvez um sistema de arquivos tenha sido desmontado; cheque com uma chamada para 'cat / etc / mtab' e depois 'fstab' para ter certeza de que tudo vai aparecer na inicialização.

Verifique o tempo de atividade para certificar-se de que o número de usuários na caixa seja razoável (deve ser apenas você) e, em seguida, examine o var / log / auth.log para ver se algo está errado.

Estes são pega-tudo. Dependendo dos erros que sua caixa está gerando, talvez seja necessário examinar processos específicos que estão causando o problema.

    

Answer 8

topo df -h e SEMPRE marque / var / log para se certificar de que a partição não foi preenchida. Isso causou um derreter total em mim algumas vezes.

    

Answer 9

df -ha

para verificar se os discos rígidos estão cheios e alguém não recebeu avisos

htop ou superior

para verificar o uso da memória e da CPU não é anormalmente alto.

Como alternativa, se a caixa não estiver respondendo, eu vou para o cliente vm-ware e verifico o cpu / ram a partir dali.

    

Answer 10

Executar algo como (at) sar no host é quase obrigatório. A utilidade de poder obter instantâneos históricos de I / O de CPU, rede, memória e disco (entre outros) não pode ser subestimada.

Houve muitas ocasiões em que eu consegui diagnosticar uma falha examinando o que o host estava fazendo nas últimas 24 horas e vendo quando as coisas começaram a dar errado.

    

Answer 11

No linux, costumo verificar o dmesg e / var / log / messages ou / var / log / syslog. O dmesg indicará se é uma falha repentina de hardware; muitos outros problemas aparecerão nos registros do sistema.

    

Answer 12

Suponho que a primeira coisa que faço é uma verificação de espaço em disco (como outros já mencionaram). Se as verificações simples não revelarem um problema "comum", então investigarei mais.

Uma coisa que gosto de fazer é capturar um instantâneo do sistema. Eu posso falar com eles mais tarde para procurar qualquer coisa que me chamou a atenção.

lsof > /tmp/lsof.tmp &
ps auxfw > /tmp/ps.tmp &
netstat -anp > /tmp/netstat.tmp &

De lá, é a solução de problemas 101, mas eu acho um pouco mais rápido para grep os logs salvos e se a condição limpa, enquanto estou logado, eu tenho algo para ir ou procurar por alterações.