Cómo crear alertas en Prometheus para picos de latencia TCP
Descubre cómo construir métricas compuestas en Prometheus para identificar retransmisiones de paquetes y degradación de conexiones en la red.
Resumen
- La alta latencia TCP y las retransmisiones silenciosas degradan el rendimiento de sistemas distribuidos antes de causar caídas totales.
- El uso de Node Exporter permite exponer métricas cruciales del kernel de Linux directamente para la recolección continua de Prometheus.
- Las expresiones PromQL compuestas combinan el volumen de paquetes enviados con retransmisiones activas para generar alertas precisas.
- El monitoreo preventivo de ventanas de congestión evita falsas alarmas causadas por picos puntuales de tráfico en la infraestructura.
- La correlación entre pérdida de paquetes y métricas de aplicación aísla rápidamente cuellos de botella de red en producción.
Por qué monitorear la latencia TCP y las retransmisiones
Cuando una aplicación distribuida comienza a responder lentamente, la culpa suele recaer sobre la base de datos o el código de la API. Sin embargo, muchas veces el verdadero cuello de botella está escondido en la capa de transporte de la red, específicamente en las conexiones TCP que sufren microcortes, pérdida de paquetes y retransmisiones silenciosas. En la práctica, esto significa que los paquetes de datos se pierden a mitad de camino debido a congestiones en enrutadores o cables dañados, obligando al sistema operativo a reenviarlos y generando un retraso acumulado que arruina la experiencia del usuario.
Para quienes buscan estabilidad operacional, confiar únicamente en pings básicos o verificar si el puerto HTTP está abierto es insuficiente. Necesitamos mirar dentro del kernel del sistema operativo y extraer métricas de bajo nivel que revelan la salud real del tráfico. Como vimos al medir pérdida de paquetes y jitter en Linux con iperf3, comprender el comportamiento físico y lógico del tráfico evita sorpresas desagradables en horas pico. Prometheus surge exactamente como la herramienta ideal para recopilar estas variables y disparar avisos automáticos.
Extrayendo métricas del kernel con Node Exporter
Prometheus por sí solo no adivina lo que ocurre en la pila de red de Linux; necesita un agente recolector instalado en las máquinas monitoreadas. Node Exporter es el estándar de la industria para esta tarea, exponiendo cientos de estadísticas del sistema operativo en un formato que Prometheus puede leer fácilmente mediante peticiones HTTP periódicas.
Dentro del ecosistema de Node Exporter, las estadísticas relacionadas con el protocolo TCP provienen directamente del archivo virtual /proc/net/snmp de Linux. Este archivo agrupa contadores acumulativos desde el momento en que se encendió la máquina. Para monitorear la degradación, debemos concentrarnos en métricas como TcpOutSegs, que indica el total de segmentos enviados, and TcpRetransSegs, que muestra cuántos de esos segmentos necesitaron ser reenviados porque el destinatario nunca confirmó su recepción.
Construyendo la métrica compuesta en Prometheus
Monitorear únicamente el número absoluto de retransmisiones no funciona bien, porque un servidor con mucho tráfico natural tendrá más retransmisiones que un servidor ocioso, sin que eso represente un problema grave. La ingeniería de confiabilidad exige crear métricas compuestas, calculando la tasa proporcional de retransmisiones en relación con el total de paquetes enviados utilizando la función rate() de PromQL.
La expresión matemática divide la tasa de retransmisiones entre la tasa de segmentos enviados en una ventana de tiempo deslizante, como cinco minutos. Si la proporción supera un umbral seguro, digamos del 3%, sabemos que la red está degradada. Este enfoque matemático filtra ruidos pasajeros y garantiza que la alerta solo se active cuando haya un impacto real en la calidad de la comunicación entre los microservicios.
Escribiendo la regla de alerta en Prometheus
Con la expresión PromQL validada, el siguiente paso es estructurar el archivo de configuración de alertas de Prometheus, conocido como Alerting Rules. Este archivo define el umbral crítico, el tiempo de persistencia necesario para evitar falsos positivos y los metadados descriptivos que ayudan al operador a comprender el problema rápidamente durante una llamada de emergencia.
A continuación presentamos un ejemplo funcional de una regla de alerta configurada en formato YAML para detectar picos anómalos de retransmisión TCP:
groups:- name: tcp_alertsrules:
- alert: AltaTaxaRetransmissaoTCPSeveraexpr: (rate(node_netstat_Tcp_RetransSegs[5m]) / rate(node_netstat_Tcp_OutSegs[5m])) > 0.05for: 2minlabels:severity: criticalannotations:summary: