Línea base en reposo

En resumen: en reposo, los cuatro núcleos del RB5009 de referencia están ocupados un 6–8 %, time_squeeze nunca es cero (unos 200 cada 20 s) y el log del kernel calla. Lee todos los demás casos contra esa forma: un flujo constante de sucesos del kernel en reposo es la anomalía, y un squeeze distinto de cero, por sí solo, no.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · agente a 10 Hz en un contenedor privilegiado efímero

Grabación

Tres tramos de 20 segundos:

   t  busy%  per-core busy%           ctxt    sirq  squeeze  temp   MHz  events
   0    7.1  10.5   7.9   4.3   5.8  41793     325      296  36.2  1400       0
   1    8.4   8.0   7.8   9.9   7.8  60518     251      223  36.2  1400       0
   2    6.5   7.1   5.2   6.7   6.8  58259     199      179  36.3  1400       0

Los porcentajes se calcularon después a partir de los deltas de ticks en bruto que envía el agente; el agente nunca los convierte en porcentajes. Esta lectura no tiene gráfico: es anterior al historial del almacén InfluxDB de referencia, que empieza el 2026-09-19. El gráfico grabado de abajo es un record posterior del mismo router en reposo.

Qué mirar

• Un 6–8 % de ocupación en los cuatro núcleos es el suelo de este router, no un problema. Son DNS, DHCP, WireGuard, el bridge y su propio mantenimiento.
• time_squeeze nunca es cero (~200 cada 20 s). Un squeeze distinto de cero es normal; lo que importa es el cambio bajo carga, que muestra la inundación de paquetes. Una alerta con “squeeze > 0” te despertaría para siempre.
• arch_timer y switch0 son siempre las dos fuentes de interrupciones con más actividad.
• Cero sucesos del kernel es el estado sano. Cualquier flujo constante de events en reposo merece el tratamiento del caso del bucle: así empezó.

Squeezes de fondo

El suelo del squeeze se volvió a medir en las 24 h hasta el 2026-09-16 a las 07:00 UTC, en el mismo equipo, sobre 3 738 704 muestras por CPU:

• alrededor del 11,2 % de las muestras llevan un squeeze de fondo;
• el 1,2 % lleva exactamente dos;
• el 0,21 % lleva exactamente tres.

En este router, el 2026-09-15, una regla que marcaba cualquier squeeze saltó 92 veces en veinte minutos, y no significaba nada.

Así que la marca burst del colector es una desviación respecto a la norma del propio equipo. Marca una muestra cuyo número de paquetes estuvo en su mediana móvil o por debajo y que tiene:

• un paquete descartado, o
• más squeezes de los que esa CPU suele tener: por encima de su percentil 90 móvil y al menos 3.

Las líneas base móviles abarcan diez segundos de reloj de pared a cualquier cadencia. Tres muestras marcadas en una CPU en 60 s disparan la detección microburst; una sola muestra marcada se queda en un dato.

Cierto en este equipo, no en el tuyo

Este suelo es un RB5009 con el reloj fijado a 1400 MHz, que ejecuta el DNS, el DHCP, el WireGuard y el bridge de su propietario. Un router con otros servicios, un reloj que escala o una placa distinta tiene otra forma en reposo. Toma los mismos sesenta segundos en el tuyo antes de leer cualquier otro caso contra ella.

Gráfico grabado

Abre el gráfico a tamaño completo (SVG, 1200 × 754) para leer sus etiquetas en un móvil. Los rótulos de los paneles van en inglés porque plot los escribe así: el título lo pones tú con --title, el resto es el vocabulario del kernel.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · un record de 70 s a 10 Hz, 700 muestras en 69,9 s, el router por lo demás en reposo, tres notas escritas en el terminal de record

Es una grabación real de un router en reposo, la forma contra la que se lee todo lo demás. Las tres líneas discontinuas son las notas escritas en el terminal de record durante ella; las etiquetas las llevan enteras porque caben, y una más larga se acorta en vez de montarse sobre la siguiente.

• t = 12 s, baseline, router idle. No pasa nada, y los paneles lo dicen: cada núcleo promedia menos del 10 % en toda la grabación, y en el tramo tranquilo que sigue a esta nota los cuatro juntos promedian un 3,9 %.
• t = 30 a 50 s, entre dashboards check started y check finished. Un navegador cargando los dos paneles de Grafana contra el colector de este mismo router. Los cuatro núcleos juntos promedian un 5,0 % en ese tramo, y el trabajo llega en dos ráfagas cortas justo después de la nota: el núcleo 0 al 50 % o por encima durante 0,6 s desde los 32,3 s, y otros 0,3 s a los 33,2 s.
• El trabajo está en excursiones cortas. 76 de las 700 muestras tienen un núcleo al 50 % o por encima, en 46 tramos separados; 38 de ellos duran una sola muestra, y el más largo dura 1,4 s, al principio de la grabación y antes de la primera nota. El planificador del kernel pone cada excursión en el núcleo que esté libre. Una muestra aislada —un núcleo al 100 % durante 100 ms— mueve una media de un segundo sobre cuatro núcleos en un 2,5 %.
• softnet: dropped plano en cero, time_squeeze entre 0 y unos 20 por segundo. No se perdió nada en 70 s. Los squeezes son el fondo de este equipo, no un suceso; lo que el colector llama microburst es un racimo de ellos —tres muestras marcadas en un mismo núcleo dentro de 60 s—, y nunca uno solo.
• Memoria disponible, de 662 a 671 MiB. Unos 9 MiB de vaivén normal en toda la grabación, sin ningún escalón en ninguno de los dos extremos de la comprobación de los paneles.

El propio cpu-load de RouterOS, a 1 s, da este minuto por un puñado plano de puntos porcentuales. La grabación muestra de qué está hecho ese puñado: qué núcleo se llevó cada excursión, cuánto duró y dónde caen las notas frente a ella.

Cierto en este equipo, no en el tuyo

Una grabación, en un router, a 10 Hz, con el router por lo demás en reposo. Las cifras por panel de arriba están leídas de este gráfico, no vueltas a medir.

Véase también

• Inundación de paquetes: lo que hace el squeeze cuando sí cambia.
• Bucle de capa 2: lo que resultó ser un flujo constante de sucesos en reposo.
• Reglas de detección: la regla microburst y las demás, con lo que cada una no puede afirmar.