Razões para um servidor ficar inacessível, Como investigar?

Question

Um dos meus servidores que hospedam um mongoDB é, algumas vezes e "aleatoriamente" inacessível.

Depois de um tempo, ele volta, como se nada tivesse acontecido.

Durante esse período, é impossível abrir um túnel ssh (tempo limite, nem mesmo pedir uma senha), todas as conexões de aplicativos para a quebra do MongoDB hospedada, ...

Não tenho certeza se o servidor ainda está ativo, e esse problema pode ocorrer duas vezes ao dia, uma vez por semana.

Infelizmente, não consigo encontrar nenhum indício de desligamento / reinicialização vergonhoso ou de quaisquer outras pistas sobre o que está acontecendo nesse momento.

O que eu fiz até agora para investigar:

foo@bar:/var/log$ who -b
         system boot  Jun 22 09:25

Nada suspeito aqui, o servidor não inicializou em 1 mês.

Isso pode ser confirmado pelo boot.log:

foo@bar:/var/log# tail boot.log
2016/06/22 09:25:34 Processing completed for Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9001
2016/06/22 09:25:34 Finished processing ExtensionsConfig.xml
monit: /opt/foo/common/lib/libcrypto.so.1.0.0: no version information available (required by monit)
monit: /opt/foo/common/lib/libssl.so.1.0.0: no version information available (required by monit)
 * Starting daemon monitor monit
   ...done.
 * Stopping System V runlevel compatibility

Mais uma vez, verifiquei o último usuário registrado, nada parece estar errado:

foo@bar:/var/log# last -x
localadm pts/0        16.618.3.75      Tue Jul 19 14:37   still logged in
localadm pts/0        16.618.3.75      Tue Jul 19 13:59 - 14:36  (00:37)
localadm pts/0        16.618.3.75      Tue Jul 19 13:18 - 13:53  (00:35)
localadm pts/0        16.618.3.75      Tue Jul 19 07:45 - 09:15  (01:29)
localadm pts/3        16.618.3.75      Mon Jul 18 15:14 - 15:51  (00:37)
localadm pts/0        16.618.3.75      Mon Jul 18 14:57 - 15:22  (00:24)
localadm pts/0        16.618.3.75      Mon Jul  4 10:01 - 10:06  (00:05)
localadm pts/0        16.618.3.75      Mon Jul  4 09:03 - 09:19  (00:16)
localadm pts/0        16.618.3.75      Mon Jul  4 08:16 - 08:19  (00:03)
localadm pts/0        16.618.3.75      Mon Jul  4 08:07 - 08:14  (00:06)
localadm pts/0        16.618.3.75      Mon Jul  4 08:00 - 08:04  (00:04)

Também verifiquei as tarefas do cron, nenhuma delas parece afetar nenhum nível de execução:

foo@bar:/var/log$ cat syslog
Jul 20 07:02:01 bar CRON[28967]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D)
Jul 20 07:17:01 bar CRON[29489]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 20 08:02:01 bar CRON[30754]: (localadmin) CMD (cd /opt/foo/stats && ./agent.bin --run -D)

(Eu também verifiquei manualmente cada tabela CRON em nível global e nível de usuário: less /etc/crontab )

O servidor é, na verdade, parte do Azure Cloud (não sei se isso pode estar relacionado ao problema).

Você sabe o que mais poderia causar esse problema?

Alguma ideia de como posso investigar mais?

    

Answer 1

The server is actually part of Azure Cloud

O erro pode estar ocorrendo em qualquer lugar ao longo do caminho de rede entre o cliente ssh / mongo e o servidor. Isso pode representar um grande número de componentes aos quais você não terá acesso.

Seu próximo porto de escala (depois de verificar se há reinicializações) deve ser o suporte da Microsoft (boa sorte com isso).

Enquanto isso:

Verifique se há mensagens relacionadas aos seus dispositivos de rede nos registros do sistema.

Se isso não aparecer, você precisará configurar algum monitoramento remoto para rastrear as interrupções. Além de fornecer informações úteis para a equipe de suporte investigar o problema, ele também fornece um meio de sair do contrato e mudar para um provedor diferente.

    

Answer 2

Da sua pergunta, eu acho que não há problema de desempenho ou disponibilidade, e isso parece ser problema de conectividade de rede e pode estar relacionado a firewalls em seu cliente ou servidor de destino.

Pode haver várias maneiras de investigar.

Verifique a resposta do ping

Traceroute para o servidor do cliente e do cliente para o servidor traceroute and tracepath comandos

Tente se conectar ao FQDN e ao endereço IP e verifique as entradas do servidor de nomes em /etc/resolv.conf , verifique se eles são endereços ipv4.

Verifique a configuração do sshd no servidor

Verifique as configurações de tempo limite de conexão tcp

Desative o firewall e o se-linux por algum tempo e tente novamente, se estiver relacionado a isso.

Verifique algumas pistas em /var/log/messages e /var/log/secure ou /var/log/auth , /var/log/audit/audit.log etc

Use o tcpdump para inspecionar os pacotes, possivelmente, pode ser devido ao problema tcp keepalive.

Leia também este artigo