Um deploy passa em todas as verificações de saúde e, logo a seguir, a latência p99 entre duas regiões dispara sem que ninguém saiba porquê. Os registos mostram timeouts, a consola da cloud mostra tudo a verde. A rede entre os seus serviços, seja peering de VPC, um transit gateway ou a Internet pública entre um nó CDN e a origem, é a parte que não controla e que nenhum painel lhe mostra. Um traceroute expõe-a salto a salto: que router, que rede e onde começa o atraso.
Um traceroute visual transforma essa lista de saltos em algo que uma equipa consegue ler durante um incidente: cada salto num mapa, com a latência, o jitter, a perda de pacotes e o ASN a que pertence. Executado a partir de várias origens, mostra se os utilizadores em Frankfurt e em São Paulo chegam ao mesmo nó, se o DNS os envia para a região certa e se o caminho mudou depois da última versão. Exporte, anexe ao ticket e acabe com a discussão sobre a rede.
Validar um deploy a partir de onde estão os utilizadores
Após um deploy numa região nova, não verifique apenas a partir do runner de CI. Trace até ao novo endpoint a partir de Falkenstein, Gravelines e de uma sonda Globalping próxima dos utilizadores. Primeiro o DNS: o nome resolve para o endereço esperado nessa região, ou o anycast ou o GeoDNS enviam o tráfego para outro lado? Depois o caminho: quantos ASN existem entre a sonda e a rede do fornecedor, e quanto custa o último salto? Um caminho que termina na região errada, ou um primeiro salto no fornecedor 40 ms mais longe que o previsto, é um problema de encaminhamento ou de DNS, não da aplicação. Se acabar em asteriscos, repita em TCP na porta 443: muitos balanceadores filtram ICMP mas respondem na porta que servem.
Distinguir um problema real de um router que o ignora
Os routers limitam as respostas ICMP que o traceroute usa, por isso um salto intermédio com 50% de perda e um destino a 0% é cosmético: o router encaminha os pacotes e apenas despriorita as respostas. A perda real começa num salto e persiste até ao destino. A latência lê-se da mesma forma: um salto a 200 ms seguido de saltos a 20 ms é um plano de controlo lento, não um caminho lento. Prefira o jitter à média: uma ligação a 30 ms com 25 ms de jitter prejudica mais uma chamada gRPC com timeout apertado que 60 ms estáveis. Observe a coluna ASN: quando o atraso salta onde o ASN muda, o problema está na passagem entre redes, a única coisa que pode escalar com provas.
Pôr a rede sob monitorização como tudo o resto
Uma rota que muda é um indicador antecipado: um fornecedor de trânsito em failover, uma CDN a mudá-lo para outro ponto de presença, uma alteração BGP a montante. Agende um traceroute para cada endpoint crítico, como a origem, uma base de dados noutra região ou uma API de terceiros, e defina alertas de latência, perda e mudança de rota. Quando um alerta dispara, abra o traceroute anterior e o novo lado a lado para perceber se uma regressão de 80 ms veio da sua versão ou de um novo caminho de trânsito. Pela API, execute um traceroute como passo pós-deploy e compare o destino e a latência do último salto com os seus limites. Exporte em CSV ou JSON para as ferramentas de incidentes, em PDF para o post-mortem.
Ler um traceroute: uma chamada entre regiões que ficou lenta
Exemplo pedagógico, não uma medição real. Um serviço em Frankfurt chama uma API na Virgínia. Os saltos 1 a 5 ficam na rede do fornecedor de cloud, a 1 a 3 ms. No salto 6 o ASN muda para uma operadora de trânsito: 12 ms; o salto 7 marca 95 ms e os saltos seguintes ficam perto dos 95 ms, sem perda. Como o aumento persiste até ao fim, é real, e 90 ms são apenas a travessia do Atlântico. Um segundo traceroute a partir de uma sonda Globalping em Nova Iorque chega em 8 ms: a API está saudável; o serviço em Frankfurt chama a região errada. Encaminhe a chamada para a réplica europeia ou conte com essa latência. Se os saltos depois do 7 tivessem voltado aos 12 ms, o pico seria ruído desse router, não do caminho.
Ferramentas que completam o quadro
O Ping durante um minuto dá jitter e perda sem o detalhe dos saltos, para confirmar uma regressão antes de traçar. O DNS Lookup mostra que endereço cada resolvedor devolve, o primeiro ponto a verificar quando uma região parece desaparecer. O HTTP/SSL Check segue os redirecionamentos e lê o certificado como um cliente, apanhando certificados expirados ou com nome errado que um health check deixa passar. O Port Check confirma uma regra de firewall do exterior. O BGP Viewer diz que ASN anuncia o prefixo onde o tráfego termina.
Perguntas frequentes
- Posso executar um traceroute a partir de um pipeline de CI?
- Sim, através da API, disponível nos planos Pro e Business. Chame-a depois de um deploy para traçar até ao novo endpoint a partir da origem que escolher e compare, no seu próprio script, os saltos, a latência e o endereço de destino devolvidos com o que espera. O resultado é o mesmo JSON que pode descarregar na interface, por isso anexa-se sem esforço a um relatório de deploy ou a um incidente.
- O meu traceroute acaba em asteriscos antes do balanceador de carga. O serviço está em baixo?
- Não necessariamente. Muitos balanceadores de carga e nós de cloud descartam ICMP e ignoram sondas UDP, por isso o traceroute fica em silêncio mesmo com o HTTPS a funcionar. Repita em modo TCP na porta que realmente serve e confirme com o HTTP/SSL Check. Se o traceroute TCP chegar ao destino e a verificação HTTP responder, o serviço está bem e os asteriscos são filtragem, não uma falha.
- Como sei se um problema de latência é meu ou do meu fornecedor?
- Veja onde o atraso aparece pela primeira vez e se persiste. Se começa dentro do ASN do fornecedor e se mantém até ao destino, o problema está na rede dele ou no seu peering. Se aparece exatamente onde o ASN muda, é uma passagem entre dois operadores. Execute o mesmo traceroute a partir de uma segunda origem: duas origens a concordar no mesmo salto são uma prova forte para anexar ao ticket.