Tráfico (E/S de red)

Descripción general — qué hace

Infraestructura ▸ Conectividad y tráfico ▸ Tráfico (/infra/traffic/net) es una consola de solo lectura que representa el rendimiento de E/S de red de cada servidor (bytes y paquetes de entrada y de salida) como un gráfico de líneas de ECharts por cada tarjeta de servidor.

El origen es la tabla heredada server_traffic (≈1,6 M de filas, conexión legacy_glory), alimentada por el recolector heredado check_tx.js. Esa tabla acumula, por ventana, los bytes y paquetes delta de cada servidor × dirección (entrada/salida), pero la antigua interfaz de stats-design solo llegó a mostrar el traffic-out de server_status (un único delta de paquetes de salida). Esta pantalla es la primera en exponer el conjunto de datos completo de entrada/salida × bytes/paquetes.

Las tres pantallas hermanas (Conexiones de puerto, Conexiones IP, Tráfico) comparten el mismo TrafficController y SessionQueryService, pero solo la pestaña Tráfico lee la serie temporal de rendimiento de server_traffic en lugar de la instantánea de sesiones (traffic_session_ct). Por eso utiliza una ventana de rango (1h/6h/24h) en vez del temporizador (1/5/60 min) que usan las otras dos.

Cuándo usarla

• Para rastrear a lo largo del tiempo los picos o subidas de ancho de banda en un servidor concreto (transferencias nocturnas de copias de seguridad, descargas grandes, entrada de DDoS).
• Para deducir el carácter de un servidor a partir de su relación entrada:salida (los servidores web se inclinan hacia la salida; los receptores de copias de seguridad, hacia la entrada).
• Como pantalla de primer paso para nodos cuyos paquetes/bytes de salida se disparan de repente, antes de profundizar en Seguridad ▸ Amenazas o en la ventana emergente de investigación de IP.
• Para detectar de un vistazo los servidores obsoletos (con recolección retrasada) mediante el KPI de frescura.

Disposición

Cabecera (barra superior)

Franja de KPI (flujo: entrada · salida · paquetes · relación → punto caliente → frescura)

Leyenda de color de escala + escala del eje Y

El color de la línea y del área codifica la magnitud del valor (visualMap por tramos de ECharts). Cuando un valor cruza un umbral cambia el color, de modo que la escala se percibe a través del color.

• La dirección se codifica mediante la forma de la línea: salida = línea continua + área más marcada; entrada = línea discontinua + área tenue. También se distinguen por las flechas de la cabecera (↓ entrada / ↑ salida) y por la información emergente.
• Conmutador de escala del eje Y: linear (predeterminado, mínimo fijado en 0 → área honesta) | log (comprime de KB a MB en un solo eje para que entrada y salida sean visibles a la vez). La selección se conserva en localStorage.

Tarjetas de tráfico por servidor

Cada tarjeta = un servidor. La cabecera muestra el nombre de host más los bytes de entrada/salida actuales; el cuerpo es un gráfico de líneas <metric-chart> de 200 px (ECharts, importación dinámica).

• Reordenar arrastrando: use el asa (⋮) para reordenar las tarjetas; el orden se conserva bajo infr:order:traffic-net.
• Disposición tipo mampostería + 12 tarjetas por página.
• Eje temporal fijo: cada tarjeta fija su eje X a win.since ~ win.until (una ventana compartida). Los servidores con recolección retrasada se dibujan con honestidad como un muñón a la izquierda, evitando una curva falsa estirada a todo lo ancho a partir de un puñado de puntos.

Cómo usarla

1. Elija un rango: 1h para perseguir picos, 24h para patrones diarios.
2. Cambie de métrica: bytes para la carga de ancho de banda, packets para el carácter de las conexiones/PPS.
3. Eje logarítmico: en servidores con gran disparidad entre entrada y salida (nodos web donde la salida ≫ la entrada), log mantiene visibles ambas curvas.
4. Reordene las tarjetas: arrastre arriba los servidores que le interesen (se guarda en el navegador).
5. Persiga un punto caliente: cuando detecte el servidor Top del KPI o una curva crit (roja), salte a Conexiones de puerto / Conexiones IP para investigar qué IP o puerto lo provocó.

La información emergente muestra una cabecera HH:MM más el valor de cada serie (entrada/salida). Incluso en tarjetas estrechas, las etiquetas del eje temporal se ocultan automáticamente para evitar solapamientos (hideOverlap).

Orígenes de datos

server_traffic (legacy_glory · solo lectura)

La consulta de origen (TrafficRepository::serverTraffic) usa vinculación de parámetros para explorar solo una ventana estrecha (sin valores fijos en el código ni interpolación de cadenas):

SELECT server_name, server_index, time_window_start, direction,
       delta_packet_count, delta_bytes_count
FROM   server_traffic
WHERE  time_window_start >= :since   -- (última ventana) − rango
ORDER  BY time_window_start
LIMIT  6000;

Ancla = MAX(time_window_start) (MAX indexado → económico). since = anchor − range minutes.

Normalización por cubos de un minuto (corrección del diente de sierra)

El recolector check_tx.js marca la entrada y la salida con llamadas new Date() independientes dentro de su bucle, de modo que, dentro del mismo ciclo de 5 minutos, los valores de time_window_start difieren en 1–2 segundos (por ejemplo, :02 la entrada y :03 la salida). Agrupar por la marca de tiempo exacta captura solo una de las dos direcciones en cada instante y deja la otra a 0, lo que produce un gráfico en diente de sierra.

Corrección: SessionQueryService::reshapeNet redondea las marcas de tiempo a un cubo de un minuto (round(ts/60)*60), de forma que entrada y salida se fusionan en un único punto. El intervalo de la ventana (300 s) es mucho mayor que el cubo (60 s), por lo que ventanas contiguas nunca colisionan.

Desplazamiento de la zona horaria de visualización

Como la hora de almacenamiento de la base de datos heredada puede diferir de la hora de visualización (se ha observado un desfase de ~9 h), los valores se desplazan mediante OpsPolicy::trafficTzOffsetSec() solo para la visualización (marca de tiempo, eje temporal, marcas de tiempo de las series). Los límites SQL (min/max) NO se desplazan: la consulta usa la hora heredada en bruto.

Caché · sondeo

• En el servidor, Cache::remember('infr:traffic:net:v1:<range>', 30, …): caché de 30 segundos.
• El frontend sondea automáticamente cada 30 segundos (/infra/traffic/net/live?range=<minutes>).

Acceso

• Pantalla de solo lectura. Sin escrituras, bloqueos ni otras acciones destructivas.
• Al pertenecer al área de rol de Infraestructura, se abre con un user_level mínimo de 1 (demo=1); staff (5) y admin (10) también tienen acceso, por supuesto.
• La ruta está protegida por el middleware infr.auth (requiere autenticación de sesión).
• Las credenciales del origen proceden únicamente de config('database.connections.legacy_glory') (es decir, de .env): no hay credenciales fijadas en el código del controlador ni del servicio.

Resolución de problemas y preguntas frecuentes

P. Solo veo «No hay muestras de tráfico». Significa que server_traffic no tiene ninguna ventana reciente. Compruebe que el recolector check_tx.js esté en ejecución y que la conexión legacy_glory sea válida. Cuando latestTrafficWindow() (MAX) es nulo, las tarjetas quedan vacías y los KPI marcan 0.

P. Un servidor solo dibuja un muñón corto a la izquierda. Es intencionado. El eje temporal está fijado a una ventana compartida, de modo que un servidor con recolección retrasada se dibuja con honestidad hasta su última observación como un muñón a la izquierda. También se cuenta como inactivo en el KPI Active servers (su último punto queda fuera de los 15 min previos al fin de la ventana).

P. La curva de una dirección parece un diente de sierra. La normalización por cubos de un minuto corrige la mayoría de los casos, pero si las propias ventanas de recolección son irregulares puede quedar algo de diente de sierra residual. Cambiar al eje log lo suaviza.

P. ¿Los valores son acumulados? No. delta_* = incremento por ventana (~5 min). Por eso el KPI Total packets está etiquetado como /window. No son contadores acumulados.

P. Las horas están desfasadas varias horas. La zona horaria de visualización se corrige mediante el ajuste traffic_tz_offset de OpsPolicy (véase Política de operaciones).

Relacionado

• Conexiones de puerto: distribución de estados TCP por puerto y servidor + IP de origen principales
• Conexiones IP: IP remotas por servidor × intensidad por puerto + ventana emergente de análisis de IP
• Servidores (serie temporal de carga): series temporales de carga/CPU/memoria, con el mismo patrón <metric-chart> de ECharts
• Estado (salud de los nodos): anillos de CPU por nodo + puntos de servicio
• Política de operaciones: ajustes globales como traffic_tz_offset y los puertos monitorizados