Panel Ejecutivo de LibreQoS

Hemos estado trabajando en algo especial para LibreQoS. Los mapas de calor de Insight son populares, pero los comentarios de la comunidad han indicado que a veces estos mapas no son muy claros, y aún requieren un esfuerzo considerable para identificar problemas.

Un enorme agradecimiento a la Fundación NLnet por patrocinar este desarrollo.

Recolección de Datos

En general, LibreQoS toma muestras de datos en intervalos de 1 segundo. El panel principal normalmente acumulaba datos del lado del cliente y te mostraba los últimos 5 minutos de información después de comenzar a observar. Siempre hicimos esto para minimizar el uso de RAM, con la idea de permitir que LibreQoS funcione en servidores relativamente pequeños. (Insight proporciona los mismos datos en marcos de tiempo mucho más amplios, de hasta 28 días, lo que hace que este compromiso sea aceptable). Un resumen de red que solo muestra datos acumulados mientras lo observas no sería muy útil. Pero necesitábamos equilibrar:

• Mantener bajo el uso de RAM, idealmente recuperando memoria liberada por otras optimizaciones.
• Mostrar suficiente información para que sea útil.
• Mantener un uso razonable del CPU para resumir los datos.

Así que ideamos una ventana fija de mapa de calor deslizante (internamente, TemporalHeatmap). Los datos en vivo se acumulan durante 60 segundos (una muestra por segundo por métrica). Al final del período de 60 segundos, se resumen utilizando medianas (no promedios/media) y se agregan al historial por minuto. La interfaz del mapa de calor ejecutivo muestra una ventana de 15 bloques:

• 14 bloques completos de 1 minuto (más antiguo → más reciente)
• 1 minuto actual “en progreso” (calculado a partir de las muestras disponibles hasta el momento)

Esto sigue siendo una cantidad fija de memoria por entidad rastreada (circuito/sitio/ASN/global), pero no es tan pequeña como se estimó inicialmente. La implementación actual almacena utilización, RTT (incluyendo p50/p90 por dirección) y porcentaje de retransmisiones en el mapa de calor, y almacena los puntajes QoO/QoQ en un mapa de calor separado de 15 minutos. En la práctica, esto suele estar en el rango de “unos pocos KB por circuito” para mapas de calor, más la sobrecarga de hash maps (por lo que 20,000 circuitos están en el orden de cientos de MB cuando están completamente poblados).

¿Qué Datos Recopilar?

Queríamos enfocarnos en lo que LibreQoS recopila mejor:

• Rendimiento (por host y resumido a través de árboles de red en redes jerárquicas)
• Tiempo de ida y vuelta TCP (RTT) - un buen indicador de la experiencia del usuario.
• Retransmisiones TCP - que tienden a aumentar cuando hay problemas en la red.

Modelando el Rendimiento

Presentar el rendimiento en una escala de “bueno a malo” es sencillo. Puedes tomar rendimiento / capacidad y obtener una medida instantánea de qué tan utilizado está el circuito. Utilizar completamente la capacidad no es necesariamente un problema; hacerlo durante largos periodos sí puede serlo (una señal de que una actualización sería buena idea).

Por lo tanto, los colores del rendimiento se basan en la utilización mediana durante el intervalo. Una conexión que esté continuamente saturada tenderá hacia el rojo.

Modelando el Tiempo de Ida y Vuelta (RTT)

El RTT es más complicado. En la versión actual, utilizamos métricas similares a otros productos de QoE. 0-100 ms es generalmente bueno, 100-150 ms es amarillo, y peor que eso comienza a ser rojo. Esto se basa en estudios de capacidad de respuesta. Algunas partes de la interfaz también utilizan una transición suave de verde → naranja → rojo con un límite suave (actualmente 200 ms) para colorear el mapa de calor.

El RTT tampoco es una “talla única”. LibreQoS ahora soporta perfiles QoO (configurados en qoo_profiles.json) para definir qué es “bueno” y “malo” según tu región/red, y el puntaje QoO refleja esa selección.

En lugar de almacenar grandes cantidades de números flotantes, agrupamos el RTT en un histograma no lineal (más resolución en los valores bajos). A veces hay cientos o miles de lecturas por segundo, por lo que almacenarlas individualmente no es práctico.

Una vez más, podemos resumir el RTT en bloques por minuto para tener una buena idea del rendimiento. Sin embargo, un “promedio” no es una buena medida. Algunos picos grandes en una conexión saludable pueden hacer que el promedio se vea mal. En su lugar, usamos medianas. El mapa de calor ejecutivo incluye p50 y p90 (por dirección) para que puedas ver tanto el comportamiento típico como la “latencia de cola”.

Retransmisiones TCP

Las retransmisiones TCP son complicadas. Algunas son inevitables, y LibreQoS (mediante CAKE y fq_codel) incluso puede inducir algunas como parte del control de tráfico. Así que su presencia no significa “problema”, pero grandes cantidades sí indican fuertemente que algo anda mal. Por eso usamos una escala suave de verdes para pocos porcentajes y rojo para porcentajes altos.

Resumimos estos valores usando medianas. Los picos pueden ser saludables (CAKE actuando, red estabilizándose), pero retransmisiones sostenidas suelen indicar problemas. Los resúmenes por minuto basados en medianas ayudan a suavizar estos picos temporales.

Calidad del Resultado / Quality of Outcome (QoO)

Quality of Outcome es una propuesta en borrador del IETF. Lee el borrador aquí

Decidimos implementar una medición de la Calidad del Resultado (QoO). En un despliegue pasivo “en medio de la red” es difícil medir directamente la pérdida de paquetes de extremo a extremo, por lo que LibreQoS utiliza la fracción de retransmisiones TCP como un proxy de pérdida (con un valor explícito de confianza). La puntuación QoO se basa en el enfoque del borrador IETF IPPM QoO (latencia + pérdida), y lo que se considera “bueno” o “malo” depende del perfil QoO seleccionado.

Gracias al uso de histogramas de RTT, podemos calcular percentiles confiables (incluyendo p50 y p90) en cada nivel de la jerarquía, y el panel ejecutivo puede mostrar tanto los mapas de calor como los puntajes QoO derivados.

Visualización

Decidimos mostrar las estadísticas globales de la red como un mapa de calor simple. Fácil de leer: verde es bueno, otros colores no tanto.

Seguimos un formato similar para RTT y retransmisiones. Decidimos enfocarnos en los peores puntajes para que puedas identificar rápidamente qué necesita mejorar.

La utilización y la Calidad del Resultado (QoO) siguen un patrón similar.

En general, estamos entusiasmados porque este es el panel de LibreQoS más fácil de usar hasta ahora. ¡Cuéntanos qué opinas!