Un despliegue supera todas las comprobaciones de salud y luego la latencia p99 entre dos regiones se dispara, y nadie sabe por qué. Los registros muestran timeouts; la consola de la nube, todo en verde. La red entre sus servicios, ya sea peering de VPC, una pasarela de tránsito o la internet pública entre un nodo CDN y su origen, es la parte que no controla ni puede leer en un panel. Un traceroute la expone salto a salto: qué router, qué red y dónde empieza el retraso.
Un traceroute visual convierte esa lista de saltos en algo que un equipo puede leer durante un incidente: cada salto sobre un mapa, con su latencia, su jitter, su pérdida de paquetes y el ASN al que pertenece. Lanzado desde varias fuentes, muestra si los usuarios de Fráncfort y los de São Paulo llegan al mismo nodo, si el DNS los envía a la región correcta y si la ruta cambió tras su última versión. Expórtelo, adjúntelo al ticket y deje de discutir si la culpa es de la red.
Valide un despliegue desde donde están sus usuarios
Tras desplegar en una nueva región, no compruebe solo desde CI. Trace al nuevo punto de acceso desde Falkenstein, Gravelines y una sonda Globalping cercana a sus usuarios. Primero el DNS: ¿resuelve el nombre a la dirección esperada en esa región, o anycast o GeoDNS lo envían a otra parte? Después la ruta: ¿cuántos ASN separan la sonda de la red de su proveedor y cuánto cuesta el último salto? Una ruta que acaba en la región equivocada, o un primer salto en su proveedor 40 ms más lejos de lo previsto, es un problema de enrutamiento o DNS, no de la aplicación. Si la traza acaba en asteriscos, repítala en TCP por el puerto 443: muchos balanceadores de carga filtran ICMP, pero responden en el puerto que sirven.
Distinga un problema real de un router que le ignora
Los routers limitan las respuestas ICMP del traceroute, así que un salto intermedio con 50 % de pérdida y un destino al 0 % es cosmético: el router reenvía sus paquetes y solo relega sus respuestas. La pérdida real empieza en un salto y persiste hasta el destino. La latencia se lee igual: 200 ms en un salto seguidos de 20 ms en los siguientes es un plano de control lento, no una ruta lenta. Prefiera el jitter a la media: 30 ms de media con 25 ms de jitter dañan más a una llamada gRPC con timeout corto que 60 ms estables. Vigile la columna ASN: si el retraso salta donde cambia el ASN, el problema está en el traspaso entre redes, lo único que puede escalar con pruebas.
Ponga la red bajo supervisión, como todo lo demás
Una ruta que cambia es un indicador adelantado: un proveedor de tránsito que conmuta, un CDN que le mueve a otro punto de presencia, un cambio BGP aguas arriba. Programe una traza hacia cada punto crítico, como su origen, una base de datos en otra región o una API de terceros, con alertas de latencia, pérdida y cambio de ruta. Cuando salte una alerta, abra ambas trazas lado a lado para ver si una regresión de 80 ms viene de su versión o de una nueva ruta de tránsito. Con la API, lance una traza tras el despliegue y compare destino y latencia del último salto con sus umbrales. Exporte CSV o JSON para su herramienta de incidentes, y PDF para el análisis posterior.
Lectura de una traza: una llamada entre regiones que se volvió lenta
Es un ejemplo pedagógico, no una medición de cliente. Un servicio en Fráncfort llama a una API en Virginia. Los saltos 1 a 5 están en la red del proveedor de nube, entre 1 y 3 ms. En el salto 6 el ASN cambia a un tránsito: 12 ms; el salto 7 marca 95 ms, y los siguientes se mantienen cerca de 95 ms, sin pérdida. Como el aumento persiste hasta el final, es real, y 90 ms son el cruce del Atlántico. Otra traza desde una sonda Globalping en Nueva York llega en 8 ms: la API está sana; Fráncfort llama a la región equivocada. Redirija la llamada a la réplica europea o asuma el coste. Si tras el salto 7 se hubiera vuelto a 12 ms, el pico sería ruido del router, no un problema de ruta.
Herramientas que completan el cuadro
Ping durante un minuto le da jitter y pérdida sin el detalle por salto, para confirmar una regresión antes de trazar. DNS Lookup muestra qué dirección devuelve cada resolutor, lo primero a mirar cuando una región desaparece. HTTP/SSL Check sigue las redirecciones y lee el certificado como lo haría un cliente, y detecta certificados caducados o mal nombrados que una comprobación de salud pasa por alto. Port Check confirma una regla de cortafuegos desde fuera. BGP Viewer le dice qué ASN anuncia el prefijo en el que termina su tráfico.
Preguntas frecuentes
- ¿Puedo lanzar un traceroute desde una canalización de CI?
- Sí, mediante la API, disponible en los planes Pro y Business. Llámela tras un despliegue para trazar hacia el nuevo punto de acceso desde la fuente que elija y compare, en su propio script, los saltos, la latencia y la dirección de destino devueltos con lo que espera. El resultado es el mismo JSON que puede descargar desde la interfaz, así que se adjunta sin problemas a un informe de despliegue o a un incidente.
- Mi traza termina en asteriscos antes del balanceador de carga. ¿Está caído el servicio?
- No necesariamente. Muchos balanceadores de carga y nodos de nube descartan ICMP e ignoran las sondas UDP, de modo que la traza enmudece aunque HTTPS funcione. Repítala en modo TCP por el puerto que realmente sirve y confirme con HTTP/SSL Check. Si la traza TCP alcanza el destino y la comprobación HTTP responde, el servicio está bien y los asteriscos son filtrado, no una caída.
- ¿Cómo sé si un problema de latencia es mío o de mi proveedor?
- Mire dónde aparece el retraso por primera vez y si persiste. Si empieza dentro del ASN de su proveedor y se mantiene hasta el destino, el problema está en su red o en su peering. Si aparece justo donde cambia el ASN, es un traspaso entre dos operadores. Lance la misma traza desde una segunda fuente: que dos fuentes coincidan en el mismo salto es una prueba sólida para adjuntar a su ticket.