Guia de solução de problemas de rede

Este guia descreve as etapas colaborativas necessárias para diagnosticar e resolver problemas de desempenho da rede. Ele está organizado como um fluxograma priorizado, começando pelos problemas mais simples e comuns antes de passar para investigações mais complexas.

Pré-requisito: revisar as práticas recomendadas para aplicativos

Antes de prosseguir com uma investigação aprofundada da rede, é essencial garantir que seu aplicativo tenha sido projetado para um desempenho ideal. Muitos problemas de desempenho podem ser resolvidos ao se abordar o projeto do aplicativo, como chamadas de API de alta frequência ou gatilhos ineficientes.

Consulte o guia sobre projeto de aplicativos aqui.

Se seu aplicativo já segue essas diretrizes, prossiga com as seguintes fases de investigação de rede e etapas subsequentes:

Fase 1: Verificações básicas

Descartem rapidamente problemas locais, do lado do cliente e da camada física com o mínimo de esforço.

1. Execute diagnósticos atuais a partir da estação afetada

• Ação: Execute os seguintes comandos TANTO para o serviço de destino QUANTO para um endpoint público estável e de alta largura de banda (por exemplo, google.com ou cloudflare.com) para comparação.
• Ping prolongado (50 a 100 pings ou mais) para mostrar a latência mínima/média/máxima e a perda de pacotes.
• ping 1.1.1.1 (Cloudflare)
• ping 8.8.8.8 (Google)
• pathping (se estiver no Windows)
• Consultas de DNS: nslookup, dig, drill
• Motivo da prioridade: esses são os dados mais rápidos de coletar. O teste comparativo é fundamental e indica imediatamente se o problema é específico do caminho do serviço ou se trata de um problema geral de internet naquela estação.
• Ação — Use a ferramenta “Network Check” do Tulip
  • Opção 1 – Em uma janela do navegador, acesse https://{Seu Tulip Instance}.tulip.co/networkCheck
  • Opção 2 — No Tulip Player, clique no menu “Ferramentas” e selecione “Verificação de rede”.
  • Analise os resultados
    • Verifique se todos os testes foram aprovados. Caso não tenham sido, faça uma captura de tela dessa página e clique em “Baixar Diagnósticos”. Envie a captura de tela e o arquivo de diagnósticos para support.tulip.co, e um representante da Tulip poderá ajudá-lo.
    • Você também pode compartilhar esses arquivos com sua equipe interna de TI para que eles possam ajudá-lo a resolver o problema.

2. Realize uma inspeção física do hardware

• Ação: Realize uma inspeção física exaustiva do hardware nas estações afetadas. Verifique se há cabos Ethernet com defeito, placas de rede mal encaixadas ou problemas com a porta física do switch.Motivo da prioridade: Problemas na camada física são fundamentais e podem se assemelhar a problemas de rede mais complexos. Descartá-los primeiro evita perda de tempo com diagnósticos no nível do software.

3. Verifique a configuração da estação local

• Ação: Verifique as configurações de DNS da estação, as configurações de proxy local (para eventuais redirecionamentos), o software de segurança/firewall local e analise os logs do servidor DHCP para confirmar se a estação não está passando por renegociações frequentes de DHCP.
• Motivo da prioridade: essas são configurações específicas do cliente que podem causar problemas para um único usuário sem afetar a rede como um todo. É o próximo passo lógico a ser verificado após descartar problemas físicos e gerais de internet.

4. Analise os logs do sistema local em busca de eventos recentes

• Ação: Na estação afetada, verifique os logs de eventos do sistema (por exemplo, Visualizador de Eventos do Windows, Console do macOS ou journalctl/dmesg do Linux) em busca de erros, avisos ou alterações significativas recentes relacionados à rede que coincidam com o início do problema de desempenho. Procure eventos relacionados a alterações no estado do adaptador de rede, falhas na concessão de endereços DHCP, problemas de resolução de DNS ou alertas de firewall/software de segurança.
• Motivo da prioridade: isso ajuda a identificar se o problema é uma ocorrência nova ou está ligado a uma alteração recente de configuração ou a um problema de rede localizado anterior que possa ter deixado rastros na máquina do cliente.

Fase 2: Análise correlacionada da infraestrutura

Use dados de eventos específicos para investigar a infraestrutura de rede compartilhada. Esta fase requer acesso e colaboração da equipe de TI.

5. Identifique os carimbos de data/hora e analise os logs internos

• Ação: Correlacione os momentos de lentidão relatados pelos usuários com os logs internos dos dispositivos de rede. Procure por:
• Alto jitter de rede
• Perda de pacotes ou altas taxas de retransmissão
• Analise o diagrama da rede e forneça os registros
• Registros de rede durante o período em que o problema ocorreu (incluindo proxy, se relevante)
• Congestionamento da rede local ou eventos de saturação da largura de banda
• Motivo da prioridade: Isso concentra a investigação em momentos específicos, tornando-a muito mais eficiente do que vasculhar dias inteiros de registros. Isso deve ser feito antes de envolver terceiros.

6. Analise o desempenho do firewall e dos dispositivos de segurança

• Ação: Durante os horários em que o problema ocorreu, analise os logs do firewall/proxy em busca de conexões TCP/UDP bloqueadas e verifique os recursos dos dispositivos (CPU, RAM, conexões). Além disso, confirme se todos os endereços IP e domínios necessários da Tulip estão atualmente na lista de permissões e não estão sujeitos a inspeções excessivamente agressivas que possam aumentar a latência. Preste atenção a métricas específicas do proxy, como limites de conexão, sessões simultâneas e latência causada pela inspeção profunda de pacotes.
• Motivo da prioridade: os dispositivos de segurança são um gargalo comum. Isso verifica tanto regras de bloqueio explícitas quanto a degradação de desempenho causada por hardware sobrecarregado ou políticas de inspeção intrusivas.

7. Examine a configuração de Qualidade de Serviço (QoS)

• Ação: Se você tiver políticas de QoS implementadas, verifique como o tráfego de e para os serviços do aplicativo é categorizado. Certifique-se de que ele não esteja sendo acidentalmente despriorizado.
• Motivo da prioridade: a configuração incorreta de QoS é uma causa específica e frequentemente negligenciada de problemas de desempenho de aplicativos, especialmente durante períodos de alta atividade na rede.

8. Analise a largura de banda geral e os dados SNMP

• Ação: Analise o uso de pico de largura de banda em todo o local e verifique os dados SNMP de roteadores/switches para identificar alta utilização ou erros durante os períodos em que o problema ocorreu.
• Motivo da prioridade: Isso determina se o problema está relacionado à capacidade geral da rede ou à contenção.

9. Analise o caminho de rede do provedor de internet

• Ação: Entre em contato com seu ISP, fornecendo a ele os horários específicos em que ocorreu alta latência.
• Detalhes para o ISP: Peça que eles verifiquem se há roteamento subótimo, congestionamento nos pontos de peering, perda de pacotes/aumento da latência em seus segmentos ou caminhos de trânsito, ou quaisquer políticas de rede relevantes ativas durante esses horários específicos.
• Motivo da prioridade: isso envolve uma parte externa e é mais eficaz quando você pode fornecer a ela dados precisos e registros de data e hora da sua investigação interna.

Fase 3: Análise aprofundada avançada

Utilize métodos altamente técnicos e que exigem muitos recursos para identificar os problemas mais difíceis de detectar.

10. Análise aprofundada avançada no nível do pacote

• Ação: Realize uma captura completa de pacotes (pcap) em uma máquina afetada durante um evento de lentidão. O segredo está no foco específico na correlação de registros de data e hora em todas as camadas de análise. Analise a captura em busca de manipulação de pacotes (por exemplo, alterações de TTL), erros de protocolo (retransmissões TCP) ou mensagens específicas de erro ICMP.
• Motivo da prioridade: Esta é a etapa mais complexa. Ela fornece a verdade absoluta, mas é reservada para quando todas as outras investigações não conseguiram identificar a causa.