Observabilidad y diagnóstico en redes de computadoras

Qué es observabilidad en redes (y por qué no es solo “hacer ping”)

En administración de servidores, observabilidad es la capacidad de inferir qué está pasando en la red a partir de evidencias medibles: métricas (latencia, pérdida, retransmisiones), trazas (ruta y saltos), registros (logs) y capturas de paquetes. El objetivo no es “probar cosas al azar”, sino reducir incertidumbre hasta llegar a una causa verificable.

En este capítulo trabajaremos una metodología de troubleshooting por evidencias: recopilar síntomas → aislar capa → reproducir → medir → validar. Cada paso produce artefactos (salidas de comandos, capturas, logs) que permiten justificar decisiones y confirmar la solución.

Metodología de troubleshooting por evidencias

1) Recopilar síntomas (qué, quién, cuándo, cuánto)

Antes de ejecutar comandos, define el problema con precisión. Un síntoma útil es observable y acotado.

• Qué falla: “HTTP no responde”, “resuelve a veces”, “tarda 2–3 s”, “solo desde X red”.
• Quién: un cliente, varios, una VLAN, una región, un ISP.
• Cuándo: desde tal hora, intermitente, cada N minutos.
• Cuánto: porcentaje de fallos, latencia promedio/p95, pérdida.
• Cambios recientes: despliegues, reglas de firewall, cambios de DNS, balanceadores, rutas.

Convierte el síntoma en una hipótesis medible: “El servidor está vivo pero el puerto 80 no acepta conexiones” o “la resolución falla por timeouts hacia un resolver específico”.

2) Aislar capa (dónde buscar primero)

En vez de repasar teoría de capas, usa una regla práctica: empieza por lo más cercano al síntoma y verifica dependencias hacia abajo.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Aplicación: HTTP/DNS/SSH responde o devuelve error.
• Transporte: handshake TCP, resets, timeouts, puertos escuchando.
• Red: ruta, gateway, MTU, ICMP, asimetrías.
• Enlace: ARP/NDP, MAC, errores de interfaz, duplex.

Un buen aislamiento produce una frase tipo: “La ruta llega, pero el servicio no escucha” o “el servicio escucha, pero hay pérdida en el salto 3”.

3) Reproducir (hacer el fallo repetible)

Si no puedes reproducir, no puedes medir. Define un test mínimo y repítelo.

• Un comando repetible: curl, dig, ping con conteo fijo.
• Un origen controlado: misma máquina, misma red, mismo resolver.
• Un criterio de fallo: timeout > 2 s, NXDOMAIN, HTTP 502, etc.

4) Medir (capturar evidencia)

Mide con herramientas que generen datos comparables: latencia, pérdida, ruta, estado de sockets, tablas (ARP/ND), y si hace falta, paquetes.

5) Validar (confirmar causa y solución)

Validar no es “ya funciona”; es demostrar que el cambio corrige el síntoma y que no introduce regresiones. Repite el test mínimo, compara métricas antes/después y guarda evidencia (salidas, timestamps, capturas).

Herramientas esenciales (qué responde cada una)

ping: alcance y latencia básica

Útil para saber si hay respuesta ICMP y estimar latencia/pérdida. No prueba puertos ni aplicación.

ping -c 5 203.0.113.10

• Éxito: 0% pérdida, RTT estable.
• Señales: pérdida alta (congestión/filtrado), RTT variable (colas), “Destination Host Unreachable” (ruta/ARP/gateway).

traceroute / tracepath: ruta y salto problemático

Identifica por dónde viaja el tráfico y dónde aparecen demoras o pérdidas. Recuerda: algunos routers limitan respuestas ICMP/UDP y pueden “parecer” lentos sin serlo para el tráfico real.

traceroute -n 203.0.113.10

En Linux, tracepath además puede sugerir MTU efectiva:

tracepath 203.0.113.10

ip / route: estado de interfaces y rutas

Base para verificar IP, máscara, gateway y rutas específicas.

ip addr show dev eth0 ip route show ip route get 203.0.113.10

• Éxito: interfaz UP, IP correcta, ruta coherente, gateway alcanzable.
• Señales: ruta inesperada, política de routing, salida por interfaz equivocada.

arp / ndp (vecinos): resolución L2 (IPv4/IPv6)

Si no hay vecino resuelto, no hay comunicación local. En Linux se consulta con ip neigh.

ip neigh show

• Estados: REACHABLE, STALE, DELAY, FAILED.
• Señales: muchas entradas FAILED (problema L2/VLAN/ARP), MAC cambiante (flapping/duplicados).

ss / netstat: sockets, puertos y conexiones

Confirma si el servicio escucha y cómo se comportan las conexiones (SYN-SENT, ESTAB, TIME-WAIT).

ss -lntp ss -antp | head

• Éxito: proceso escuchando en 0.0.0.0:80 o IP correcta.
• Señales: escucha solo en 127.0.0.1:80 (no accesible remoto), muchas conexiones en SYN-RECV (posible SYN flood o backlog), TIME-WAIT excesivo (patrones de cierre).

curl: prueba de aplicación (HTTP/HTTPS) con detalle

Permite ver DNS, conexión TCP, TLS y tiempos.

curl -v http://203.0.113.10/ curl -vk https://example.com/ curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

La línea de tiempos ayuda a separar: DNS lento vs conexión lenta vs servidor lento.

dig: diagnóstico de resolución DNS

Verifica respuesta, tiempos y qué servidor respondió.

dig example.com A +stats dig @1.1.1.1 example.com A +tries=1 +time=2 +stats dig example.com AAAA +stats

• Éxito: status: NOERROR, tiempo bajo, respuesta consistente.
• Señales: timeout (conectividad/UDP/53), respuestas distintas entre resolvers (propagación/split-horizon), SERVFAIL (fallo upstream/DNSSEC).

tcpdump / Wireshark: evidencia definitiva (paquetes)

Cuando los síntomas no se explican con comandos de alto nivel, captura tráfico. Regla: captura lo mínimo necesario, con filtro, y guarda un archivo.

Captura básica (Linux):

tcpdump -i eth0 -nn -s 0 -w captura.pcap host 203.0.113.10

Filtros útiles (BPF):

• HTTP (sin TLS): tcp port 80
• HTTPS: tcp port 443
• DNS: udp port 53 (y a veces tcp port 53)
• Solo SYN: tcp[tcpflags] & tcp-syn != 0
• ICMP: icmp o icmp6

Qué buscar en una captura:

• TCP: SYN sin SYN-ACK (filtrado/ruta), RST (puerto cerrado/firewall activo), retransmisiones (pérdida/congestión), MSS/MTU raros.
• DNS: consultas repetidas sin respuesta, respuestas truncadas (TC=1), cambios de IP entre respuestas.

En Wireshark, filtros de visualización típicos: tcp.analysis.retransmission, dns, tcp.flags.reset==1, icmp.

Lectura de logs: correlación por tiempo

Los logs convierten “parece que” en “a las 10:32:15 ocurrió X”. En Linux con systemd:

journalctl -u nginx --since '10 minutes ago' journalctl -u systemd-resolved --since '1 hour ago'

En servicios web, revisa códigos 4xx/5xx, tiempos de respuesta, errores de upstream. En DNS, revisa timeouts, fallos de validación, saturación.

Árbol de decisión general (rápido para incidentes)

Caso guiado 1: “Servidor no accesible por HTTP”

Escenario: usuarios reportan que http://app.ejemplo no carga. Objetivo: determinar si es DNS, red, puerto, o aplicación.

Test mínimo (reproducible)

curl -v http://app.ejemplo/

Criterio de éxito: HTTP 200/301/302 en < 1 s desde el cliente afectado.

Árbol de decisión

• A) Falla en resolución (curl muestra “Could not resolve host”)
  • Prueba: dig app.ejemplo A +stats
  • Si timeout: probar resolver explícito: dig @1.1.1.1 app.ejemplo A +tries=1 +time=2
  • Evidencia: tiempos y servidor que responde en +stats
  • Acción típica: revisar resolvers configurados en el cliente/servidor, reachability a UDP/TCP 53, logs del resolved.
• B) Resuelve, pero no conecta (timeout en “connect”)
  • Pruebas: ping -c 3 IP, traceroute -n IP, ip route get IP
  • Si ping falla pero traceroute muestra salto inicial: sospecha ACL/ICMP filtrado; valida con captura TCP al puerto 80.
  • Captura en cliente: tcpdump -i eth0 -nn host IP and tcp port 80
  • Interpretación: SYN sale, no vuelve SYN-ACK → firewall/ruta/servicio no escuchando en esa IP.
• C) Conecta, pero recibe RST
  • Evidencia en curl -v: “Connection reset by peer”.
  • En servidor: ss -lntp | grep ':80'
  • Si no hay listener: servicio caído o escuchando en otra IP/puerto.
  • Si hay listener: revisar firewall local o proxy que resetea; confirmar con tcpdump en servidor.
• D) Conecta y responde 5xx o tarda mucho
  • Medición: curl -o /dev/null -s -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' http://app.ejemplo/
  • Si connect bajo y ttfb alto: problema en aplicación/upstream, no en red.
  • Logs: journalctl -u nginx --since '30 minutes ago' (o servicio equivalente).

Checklist de evidencias a guardar

• Salida de curl -v y tiempos.
• dig con +stats.
• ip route get desde cliente y servidor.
• Si aplica, pcap con SYN/SYN-ACK o RST.

Caso guiado 2: “DNS intermitente”

Escenario: algunas consultas fallan con timeout, pero otras funcionan. Objetivo: distinguir entre problema de red hacia el resolver, saturación, MTU, o inconsistencias entre resolvers.

Test mínimo (repetible y cuantificable)

for i in $(seq 1 20); do dig @RESOLVER example.com A +tries=1 +time=1 +stats | grep -E 'status:|Query time|SERVER:'; done

Criterio de éxito: 0 timeouts en 20 intentos, tiempos estables (p.ej. < 100 ms en LAN, < 300 ms a Internet según contexto).

Árbol de decisión

• A) Falla solo con un resolver (p.ej. el corporativo), pero funciona con 1.1.1.1/8.8.8.8
  • Hipótesis: resolver saturado, filtrado, o problema de ruta hacia ese resolver.
  • Pruebas: ping -c 10 RESOLVER, traceroute -n RESOLVER
  • Logs del resolver (si administras): timeouts upstream, cola, errores.
• B) Falla aleatoriamente con varios resolvers
  • Hipótesis: pérdida/MTU/filtrado UDP.
  • Prueba con TCP DNS: dig @RESOLVER example.com A +tcp +tries=1 +time=2
  • Si UDP falla y TCP funciona: posible filtrado/fragmentación/MTU.
  • Captura: tcpdump -i eth0 -nn host RESOLVER and port 53 para ver consultas repetidas sin respuesta.
• C) Respuestas inconsistentes (IPs distintas o NXDOMAIN a veces)
  • Hipótesis: split-horizon, cachés diferentes, propagación, o balanceo DNS.
  • Pruebas: dig @resolver1 nombre vs dig @resolver2 nombre y comparar ANSWER SECTION y TTL.
  • Evidencia: guardar ambas salidas con timestamp.

Validación

• Repetir el bucle de 20 consultas tras el cambio.
• Confirmar que el porcentaje de timeouts cae a 0 y que el Query time se estabiliza.

Caso guiado 3: “Latencia alta”

Escenario: usuarios reportan lentitud al acceder a un servicio. Objetivo: separar latencia de red vs latencia de aplicación, y ubicar el tramo problemático.

Test mínimo (definir qué es “alto”)

Elige un umbral: por ejemplo, “p95 > 300 ms” o “RTT > 150 ms en LAN”.

ping -c 20 servidor_ip curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://servicio/

Criterio de éxito: RTT y tiempos de curl dentro del umbral acordado y estables.

Árbol de decisión

• A) ping muestra RTT alto y/o pérdida
  • Pruebas: traceroute -n servidor_ip para ubicar salto con incremento.
  • Si el incremento aparece a partir de un salto: sospecha congestión/cola en ese tramo.
  • Captura orientada a retransmisiones TCP durante una prueba real: tcpdump -i eth0 -nn host servidor_ip and tcp port 443 -w latencia.pcap
  • En Wireshark: revisar tcp.analysis.retransmission y RTT estimado.
• B) ping normal, pero curl total alto
  • Interpretación: red básica bien; el problema puede estar en DNS, TLS o aplicación.
  • Si dns alto: volver al caso DNS (medir con dig).
  • Si connect alto: problema de establecimiento TCP (posible saturación, SYN drops, firewall).
  • Si ttfb alto: backend lento; revisar logs del servicio y dependencias.
• C) Latencia solo desde una red/origen
  • Pruebas desde dos orígenes: cliente afectado vs cliente sano.
  • Comparar: ip route get, traceroute, y capturas en ambos lados si es posible.
  • Hipótesis: ruta asimétrica, política de enrutamiento, NAT/ACL por segmento.

Validación

• Comparar antes/después: RTT promedio y pérdida, y tiempos de curl (especialmente p95 si tienes medición repetida).
• Confirmar que no hay retransmisiones anómalas en una captura breve post-cambio.

Guía práctica: cómo capturar “lo justo” sin perder la evidencia

Paso a paso (tcpdump)

• 1. Identifica interfaz: ip link
• 2. Define filtro por host y puerto: reduce ruido.
• 3. Captura con tamaño completo: -s 0
• 4. Guarda a archivo: -w para analizar luego.
• 5. Reproduce el fallo mientras capturas (ejecuta curl o dig).

tcpdump -i eth0 -nn -s 0 -w evidencia.pcap host 203.0.113.10 and (tcp port 80 or tcp port 443 or udp port 53)

Interpretación rápida (patrones)

Criterios de éxito (definición operativa)

• Reproducibilidad: existe un test mínimo que falla antes y pasa después.
• Evidencia: salidas/pcap/logs muestran claramente el punto de fallo (DNS, ruta, puerto, app).
• Validación: métricas comparables mejoran (pérdida, RTT, tiempos de curl, timeouts de dig).
• Alcance: confirmado desde los orígenes afectados (no solo desde tu máquina).