Cómo leer lo que muestra

Esta sección responde a la pregunta que viene después de instalar el agente: los números están llegando — ¿qué aspecto tiene un fallo en ellos? Cada página es una forma, leída en datos que el agente recogió en el router de referencia, con las órdenes que la produjeron para que puedas reproducirla en tu propio equipo.

Todos los números de estas páginas salen de una sola campaña en el router de referencia, un kernel aarch64 en una placa con 1 GB de RAM:

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

Cuando una página añade una cifra de otra fecha, lo dice junto a la cifra. Cuando un fallo se provocó a propósito, la página dice exactamente cómo.

Antes de provocar nada

Los escenarios se eligieron de forma que nada de lo que hacen pueda romper el enlace de subida del router ni cortar el propio camino de un administrador hasta él. Conserva esa propiedad en tu equipo: averigua primero por qué puerto estás conectado,

/interface/bridge/host/print where mac-address="<la MAC de tu máquina>"

y deja en paz ese puerto, el puerto WAN y cualquiera que lleve un servicio.

Las siete lecturas

Lee primero la forma en reposo. Sin ella, cualquier otra página parece una anomalía.

Página	Cómo surgió	Dónde se ve	Firma
La forma de un router en reposo	60 s en reposo	ocupación por núcleo, `time_squeeze`, `events`	6–8 % de ocupación en los cuatro núcleos, el squeeze nunca a cero, cero sucesos del kernel
Un bucle que solo veía el kernel	real, encontrado por casualidad en el router de producción	`events` (la fuente `kmsg`)	`events` a 1,49 /s, separados 2,00–2,01 s; la API informaba de un equipo sano
Puertos de RouterOS y nombres del kernel	un puerto muerto apagado y vuelto a encender	`events`	el kernel escribe `eth5` donde RouterOS dice `ether6`
Una carga limitada por CPU	un bucle de consola que termina solo	ocupación por núcleo, temperatura, frecuencia	~29 % en total, un núcleo al 99,8 %, ~20 s de migración antes de asentarse
Una inundación de paquetes	`ping -f` a la propia dirección LAN del router, 10 s	interrupciones de `switch0`, softirqs, `time_squeeze`	`switch0` de 5,5 k a 34 k por tramo de 5 s, todo en el único núcleo al que está fijada la IRQ
Desgaste de la flash	nada provocado; el router escribe por su cuenta	la fuente `yaffs`, contadores ECC de MTD	2 escrituras de página cada 30 s en reposo, rastreadas hasta el tema `dns` que registra en disco
Conntrack sin la API	una comprobación cruzada contra la API, sin tormenta	la caché slab `nf_conntrack`	el número real de conexiones del router donde el propio namespace del contenedor informa 0

Dos comprobaciones antes de fiarte de una lectura

Al muestreador no le faltó CPU. mikroscope_slipped_total debería ser 0 en la ventana que estés leyendo. Un tick perdido es uno cuya lectura terminó después de que tocara el siguiente tick, y entonces la propia contabilidad del muestreador es lo primero de lo que hay que desconfiar.

El log del kernel se conservó entero. mikroscope_kmsg_dropped_total cuenta episodios de pérdida, no registros: uno por cada tick que llegó al tope de 64 registros del agente, y uno por cada desbordamiento del búfer circular del kernel, que puede suponer muchos registros. Mientras no sea cero, los recuentos por nivel de mikroscope_kmsg_records_total son una cota inferior, y también lo es una tasa de sucesos sacada de ellos.

Lo que cuesta el agente mientras haces esto

Mide al observador, y mídelo con honradez — incluida la parte en la que medir cambia la respuesta.

Descargar un /snapshot de 60 segundos no sale gratis: el agente tiene que entregar ~600 líneas ya codificadas, unos 1,5 MB, y el self.cpu_us de esas muestras incluye el coste de servirlas. Leer el coste del agente en una instantánea grande lo exagera, por tanto, y hacerlo repetidamente lo exagera más.

Usa /metrics en su lugar. Es pequeño, sus contadores son acumulados y no depende de quién lo lea ni de cuándo — léelo dos veces y divide:

U=http://172.30.10.2:9123/metrics
get() { curl -s "$U" | awk -v k="$1" '$1==k{print $2}'; }
c0=$(get mikroscope_self_cpu_usec_total); t0=$(date +%s)
sleep 180
c1=$(get mikroscope_self_cpu_usec_total); t1=$(date +%s)
echo "$c0 $c1 $t0 $t1" | awk '{printf "%.2f %% of one core\n", 100*($2-$1)/1e6/($4-$3)}'

Dos cosas que cabe esperar:

El coste y la memoria suben hasta que el anillo se llena. Con el anillo por defecto de 300 s a 10 Hz, el agente guarda 3 000 muestras ya codificadas; una cifra tomada en el primer minuto tras la instalación se mide sobre un heap casi vacío y saldrá optimista. Espera a que pase BUFFER_S antes de citar un número de régimen estacionario.
mikroscope_slipped_total es el número que de verdad importa. Un muestreador que cuesta algo más pero nunca pierde ticks te está diciendo la verdad; uno que los pierde, no.

Como referencia: con los valores por defecto de la instalación, el agente cuesta un 2,85 % de un núcleo y un 31,3 MiB de RSS. Esa cifra se midió el 2026-09-15 con el conjunto completo de fuentes y tres destinos a la vez, no durante la campaña de la que vienen estas lecturas:

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-15 · ventanas de 60 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, colector reenviando a la vez a fichero, a una exposición Prometheus y a InfluxDB 3

Véase también

El coste del observador: el presupuesto, el coste medido y el procedimiento de arriba completo.
El suelo de resolución es del kernel: por qué el porcentaje de ocupación de un núcleo en una muestra de 100 ms se mueve en escalones del 10 %, y qué se lee por debajo de eso.
Detecciones: las reglas que el colector ejecuta sobre estas mismas señales.
Cinco minutos con un router: una grabación con marcadores, la otra forma de leer un transitorio.