Olá comunidade, neste artigo gostaria de trazer um caso real de resolução de problemas com o ThousandEyes (parte da Cisco).
Introdução
Nesta oportunidade, vamos ver como um teste de servidor Web - HTTP funciona em um ambiente de produção e os benefícios, como acelerar a resolução de problemas, encontrar a causa raiz muito rapidamente, que traz para a empresa.
Conforme definido na documentação oficial, "O teste do servidor HTTP mede a disponibilidade e o desempenho de um serviço HTTP. Qualquer serviço HTTP que esteja exposto à internet (ou intranet, se os Agentes Corporativos estiverem implantados em sua rede interna) pode ser testado". Documentação oficial.
Agora vamos demonstrá-lo na prática.
Tipo de Métricas
Para o Teste da Web HTTP, podemos ver diferentes tipos de métricas, abaixo a lista.
- Availability (Disponibilidade) - irá mostrar como está a Disponibilidade do serviço HTTP.
- Network (Rede) - dividida em três categorias
- Loss
- Latency
- Jitter
- Roteamento
- Path Changes (Mudanças de Caminho)
- Acessibilidade
- Atualizações
- Web
- Response Time (Tempo de Resposta)
- Throughput (Taxa de Transferência)
Nota: Neste artigo, vamos focar em Disponibilidade, Loss, Latency e Jitter.
Para ver cada uma das métricas, basta clicar no topo e selecionar a métrica que deseja investigar o desempenho, ou você pode apenas marcar a caixa para selecionar mais de uma métrica simultaneamente.
A Configuração Básica para este teste é:
- Tempo limite de 5 segundos
- Intervalo de 2 minutos
- Agente - 1 selecionado, Rio de Janeiro-Brasil
- Visualização habilitada para este teste
- Web - Servidor HTTP
- Network - Visão Geral e Visualização de Caminho
- BGP - Visualização de Roteamento
Troubleshooting
Para a resolução de problemas, como demonstrado na Figura 01, foram selecionadas as subcategorias Availability and Loss, Latency e Jitter da Rede.
Também foi selecionado um intervalo de tempo para as últimas 24 horas, para uma visualização mais fácil dos gráficos e da linha do tempo.
Em uma perspectiva geral, quando olhamos o Gráfico, podemos ver que a aplicação tem um bom desempenho, no entanto, em certos momentos do dia, há picos para todas as métricas, disponibilidade, loss, latência e jitter.
Para ter uma melhor visualização dos problemas, você pode diminuir o intervalo de tempo pelas duas barras verticais brancas na barra cinza, ou arrastar o mouse sobre os picos.Para uma melhor dinâmica no processo de investigação, vamos dividir isso em três problemas. Lembre-se de que o intervalo de tempo no teste está definido para 2 minutos, o que significa que cada bloco representa 2 minutos.
Problema 1
No primeiro bloco, mostra que a disponibilidade está verde (100%), no entanto, existe uma alta perda de pacotes, latência e jitter.
Na primeira tela é possível ter algumas informações valiosas, no entanto, para entender melhor e descobrir quais são os responsáveis pelos números ruins, vamos mudar para a opção Agent to Server no canto superior esquerdo da página.Na tela Agent to Server / Network na tab MAP, mostra o resultado do teste e a geolocalização do agente.
Movendo-se para a guia Path Visualization, mostra todo o caminho pelo qual o tráfego flui do agente (origem) até a aplicação (destino), fornecendo uma visão geral dos pontos ruins da rede, destacados em vermelho.O administrador pode aplicar filtros como, Forwarding Loss% (1), Link Delay (2), IP address or prefix (3), e outros.
- indica que existe um nó com mais de 10% de perda.
- indica que existem dois links com latência superior a 100ms.
- se desejar criar um filtro específico.
Para mais detalhes, passe o mouse sobre os caminhos, e é possível ver um MIn.Delay de 186 ms.
Para o primeiro caminho, o problema ocorre devido à latência entre dois nós na Rede Microsoft, entre Rio de Janeiro <> São Paulo, e a resposta média para o nó de SP é de 187ms.
Para o segundo caminho, ele apresenta um Atraso de 283 ms, no entanto, esse problema ocorre devido a 100% de Forwarding Loss. Olhe para a imagem, perda de 19 de 19 pacotes. Esse nó está baseado em Amsterdam.
Assim, conclui-se que a aplicação foi afetada por dois caminhos ruins na Internet, e não importa o caminho pelo qual o tráfego está fluindo, a aplicação é impactada negativamente por ambos.
Problema 2 e 3
Nos segundos e terceiros blocos, há um problema muito semelhante. Note que a Availability (Disponibilidade) para a aplicação é 0%.
Enquanto no Problema 1 os usuários teriam lentidão para acessar a aplicação, nos Problemas 2 e 3 o usuário não tem acesso à aplicação, visto que a disponibilidade é de 0%. Vamos continuar e entender o porquê.
Na imagem abaixo, é possível ver quatro problemas simultâneos para o mesmo fluxo, em diferentes links e nós na Internet.
- Alto Atraso Mínimo - 186 ms
- Alto Atraso Mínimo - 484 ms
- Perda de Encaminhamento - 93%
- Alto Atraso Mínimo - 301 ms
Movendo-se para o Servidor HTTP - Web no canto superior esquerdo da página, na guia Map, Erros e Avisos mostram Operação expirada do agente do Rio de Janeiro para a aplicação. Este é o tempo limite configurado para este teste, e significa que em 4999 ms (5s) o agente não recebeu resposta para este fluxo, e por isso a Availability é considerada 0%.
E o mesmo acontece para o Problema 3. Abaixo da visualização de caminho, porém sem os detalhes (isso é apenas para mostrar o caminho, a ideia do teste é a mesma demonstrada para o Problema 2).
Problema 4
Também há algo muito interessante que o ThousandEyes conseguiu captar enquanto o teste web estava em execução. Olhando para a Figura 13, é possível ver que há um alarme de Certificado SSL para a Aplicação Web. Este alarme significa que a data do certificado está próximo de expirar. Dessa forma, o administrador pode receber proativamente uma notificação e renovar o certificado SSL, evitando o impacto na aplicação.
Conclusão
O ThousandEyes permite uma análise profunda, podendo identificar precisamente como o desempenho da aplicação é afetado por terceiros e identificar a causa raiz do problema.
Esta ferramenta agiliza significativamente a fase de resolução de problemas para Engenheiros de Rede, direcionando-os eficientemente para a origem do problema. Neste caso, demonstrou que o problema não está na rede local ou na aplicação em si, mas sim nos links da Internet. Dessa forma, se sendo possível, pode prosseguir com a substituição do link ou até mesmo escalando a provedora para melhorar a qualidade do serviço de acordo com os SLA definidos em contrato.
Espero que tenha aproveitado a leitura, compartilhe e deixe seu like!
Obrigado!
Jonas Resende
