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

Então você tem esse servidor unix perfeitamente configurado e é super rápido, funciona muito bem e tudo fica ótimo por meses. De repente, todos os tipos de erros estranhos começam a aparecer em 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 colocar sua sessão ssh na máquina?

Estou especialmente interessado em histórias de trauma que destacam comandos não óbvios e situações raras, mas acho que o óbvio varia de pessoa para pessoa, para que possamos listá-las todas livremente.

Primeira ordem: É responsivo?

Se você não conseguir fazer login, existem problemas maiores em andamento. Isso geralmente ocorre 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 - geralmente basta uma simples olhada.

Segunda ordem: as estruturas subjacentes do sistema estão em boas condições de saúde e ordem?

Verifique a "Tríade de Ouro" dos sistemas:

• Tempo de CPU suficiente para processamento
• Espaço em disco suficiente disponível para armazenamento
• Memória suficiente disponível para cargas de trabalho

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

• 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)? Clusters de programas normalmente estão disparando porque um serviço subjacente específico falhou ou deixou de responder. Às vezes, problemas sistêmicos estão relacionados 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 enfrentando problemas (terceira ordem), isso deve facilitar a identificação de onde está o problema.

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

Problemas de CPU:

• loadav
• topo
• traço

Problemas em espaço em disco / E / S:

• df
• du
• lsof
• iostat
• vmstat

Problemas de memória:

• livre

Problemas de conectividade:

• ping
• rota (e arp e rarp e amigos)
• iptables, ipchains, ipfw (para o pessoal do BSD por aí)
• traceroute ou mtr
• hosts, nslookup ou escavação
• netstat

Queixa mais comum (que eu ouvi):

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

Um exemplo da vida real:

No entanto, esse nem sempre é o caso. Uma vez, o problema persistiu, independentemente da reinicialização do serviço; então, após 3 minutos, era hora de começar a olhar em volta. A CPU estava ocupada, mas abaixo de 100%, mas a carga havia subido para 15 em uma caixa de apenas 2 núcleos e ameaçava subir mais. O comando top revelou que o sistema de correio estava com overdrive, junto com o scanner de correio, mas não havia processos filhos do amavis à vista. Essa foi a pista - o comando de fila de correio (mailq) mostrou mais de 150 mensagens não entregues, mais de 80% das quais eram spam, nos últimos 20 minutos. Um rápido ajuste para reduzir o limitador de taxa (que reduziu a taxa de entrada da tempestade de spam) e ao mesmo tempo aumentar o número de processos filho do scanner de email (para ajudar a processar o backlog), seguido de uma reinicialização do serviço, resolveu o problema e o sistema pôde para concluir entregas em pouco tempo.

A causa do problema foi que o processo pai do amavis havia morrido e os processos filhos finalmente acabaram (eles terminam após tantas varreduras para evitar vazamentos de memória). Portanto, havia processos SMTP no postfix tentando entrar em contato com ... o nada ... para fazer a verificação de spam / vírus necessária. A distribuição 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 "substitui" 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.

geralmente "quem" seguido de "último"

um monte de problemas nas máquinas que eu gerenciei ao longo do tempo foram por causa de uma definição muito vaga de "intocado" - geralmente alguém fez algo :)

Bem, eu vou começar.

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

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

df -h

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

top (ou htop)

Se você puder, eu sempre tentaria desligar todas as placas de rede, exceto a de gerenciamento.

Verificando se há erros no dmesg - geralmente começo com a dmesg | tail, porque é provável que as coisas ainda estejam dando errado e o servidor ainda esteja tentando fazer o que está causando o erro.

A primeira coisa que verifico é 'top' (existem processos estranhos; que consomem muita memória ou tempo de CPU).

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

Talvez um sistema de arquivos tenha sido desmontado; verifique com uma chamada para 'cat / etc / mtab' e depois 'fstab' para garantir que tudo ocorra na inicialização.

Verifique o tempo de atividade para garantir que o número de usuários na caixa seja razoável (só deveria ser você) e, em seguida, navegue através de var / log / auth.log para ver se algo está errado lá.

Estes são atrativos. Dependendo dos erros que sua caixa está lançando, pode ser necessário examinar processos específicos que estão causando o problema.

top df -h e SEMPRE verifique / var / log para garantir que a partição não tenha sido preenchida. Isso causou um derretimento total em mim algumas vezes.

df -ha

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

htop ou top

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

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

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

Houve várias vezes em que 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.

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

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", investigarei mais adiante.

Uma coisa que eu gosto de fazer é capturar um instantâneo do sistema. Posso cumprimentá-los 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 &

A partir daí, é a solução de problemas 101, mas acho um pouco mais rápido saudar os logs salvos e se a condição desaparecer enquanto estou conectado, tenho algo para continuar ou procurar alterações.