¿Es la red o es la aplicación? Cómo separar el problema con métricas
Quien administra redes conoce la escena. Un usuario reporta que el sistema va lento, el equipo de desarrollo dice que el código no cambió y el ticket termina en la cola de redes. El enlace está arriba, el ping responde y las interfaces no muestran errores, pero ninguna de esas pruebas demuestra que la red no sea la causa.
Separar los dos dominios requiere medir la misma transacción desde los dos lados. Este es un método de diagnóstico en cuatro pasos.
Paso 1: Pasar del promedio a los percentiles
Un promedio de latencia de 300 ms puede esconder que el 5% de las solicitudes tarda 4 segundos. Si los usuarios se quejan y el promedio se ve sano, conviene mirar el percentil 95 (p95) y el 99 (p99).
El patrón también orienta el diagnóstico:
- Todas las solicitudes empeoran por igual: apunta a algo común, como un enlace saturado o un servidor sin recursos.
- Solo empeora una parte: apunta a una ruta específica, a una consulta pesada o a una dependencia.
- Solo una sede sufre: apunta a la red de esa sede o a su camino hasta el servicio.
Paso 2: Descomponer el tiempo de la conexión
El tiempo que percibe el usuario suma varias etapas, y cada una acusa a un sospechoso distinto:
| Etapa | Qué mide | Si está alta, revisar |
|---|---|---|
| Resolución DNS | Traducir el nombre a una IP | Servidores DNS, reenviadores |
| TCP handshake | Establecer la conexión; tarda cerca de un RTT | Ruta, congestión, distancia |
| TLS handshake | Negociar el cifrado | RTT, carga del balanceador |
| Tiempo hasta el primer byte | Desde la petición hasta la primera respuesta | Sobre todo, el servidor y sus dependencias |
| Descarga | Recibir la respuesta completa | Ancho de banda, pérdida de paquetes, tamaño |
La lectura clave está en comparar el handshake TCP con el tiempo hasta el primer byte. Un handshake de 20 ms seguido de 3 segundos hasta el primer byte indica que la red entregó bien la petición y que la demora ocurrió después. Un curl con la opción -w y sus variables time_namelookup, time_connect, time_appconnect y time_starttransfer da esta medición en segundos, desde cualquier sede. Por ejemplo:
curl -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n" https://app.ejemplo.com
Los valores se acumulan desde el inicio de la petición: el handshake TCP es time_connect menos time_namelookup; el TLS, time_appconnect menos time_connect, y la espera hasta el primer byte después del cifrado, time_starttransfer menos time_appconnect.
Paso 3: Buscar las huellas propias de la red
Si los datos siguen apuntando a la red, estas señales la confirman:
- Retransmisiones TCP. Un aumento indica pérdida de paquetes. Una captura con Wireshark en ambos extremos muestra en qué tramo se pierden. El filtro
tcp.analysis.retransmissionlas separa del resto del tráfico, y la guía oficial explica cómo Wireshark marca una retransmisión. - Discards en las interfaces. Un puerto con descartes en la cola de salida revela saturación por ráfagas, aunque el promedio de uso se vea bajo. En un equipo Cisco se ve en el contador
Total output dropsdeshow interfaces. El contador es acumulado desde el últimoclear counters, así que lo que importa es si sube durante el incidente. Las muestras SNMP cada cinco minutos esconden esos picos, y la telemetría de mayor resolución ayuda a verlos. - Problemas de MTU. Las transferencias pequeñas funcionan y las grandes se cuelgan. Es común en túneles VPN, donde el encabezado adicional reduce el tamaño útil. Un ping con el bit DF activado lo comprueba:
ping -n 1 -f -l 1472 <destino>en Windows oping -c1 -M do -s 1472 <destino>en Linux. Los 1472 bytes de datos más 20 del encabezado IP y 8 del ICMP suman 1500; si falla, se baja el tamaño hasta que pase y así se obtiene la MTU real del camino. Si no responde ningún tamaño, el ICMP está filtrado y la prueba no sirve. - Cambios de ruta. Un
tracerouteomtrdurante el problema, comparado con uno de un momento sano, muestra saltos nuevos o pérdida sostenida. Una pérdida que aparece en un salto intermedio pero no en los siguientes ni en el destino suele ser limitación de ICMP de ese router, no pérdida real.
Si ninguna de estas huellas aparece y el problema se concentra en el tiempo hasta el primer byte, el caso ya tiene evidencia suficiente para pasar al equipo de aplicaciones.
Paso 4: Seguir la transacción dentro de la aplicación
Aquí terminan las herramientas de red. Una aplicación moderna responde con una cadena de llamadas: el frontend consulta una API, que consulta una base de datos y un servicio externo. El tráfico entre esos componentes suele viajar por redes virtuales y mallas de servicio que el monitoreo tradicional de infraestructura no descompone.
Esa visibilidad la aporta el APM (Application Performance Monitoring) mediante trazas distribuidas. Cada traza sigue una solicitud por todos los servicios que toca y registra el tiempo de cada salto, de modo que una espera aparece atribuida a un componente concreto. Si el tramo entre dos servicios tarda mucho más que lo que cada uno declara haber trabajado, el sospechoso vuelve a ser la red, ahora con un punto exacto que revisar. OpenTelemetry, el estándar abierto de instrumentación, facilita recoger estas trazas sin atarse a un fabricante.
Otra métrica útil para la conversación entre equipos es el Apdex. Se fija un umbral T de tiempo aceptable y se calcula: (satisfechas + toleradas / 2) / total. Las solicitudes bajo T cuentan como satisfechas, y las de hasta 4T, como toleradas. El resultado va de 0 a 1 y da a redes, desarrollo y gerencia un mismo número para discutir.
Una regla para el equipo
Cuando el ticket llegue a redes, conviene devolver datos en vez de opiniones: el p95 por sede, el desglose de la conexión, las retransmisiones del período y un mtr del momento. Con eso, la reunión cambia de quién tiene la culpa a qué tramo revisar.
Quien quiera profundizar en las métricas del lado de la aplicación y en cómo se integran con la observabilidad puede consultar esta guía de monitoreo APM, publicada por Netprovider, empresa de ciberseguridad y observabilidad.
