# Cómo leer lo que muestra

Siete lecturas de datos del kernel de un RB5009 — un fallo de producción encontrado por casualidad, tres sucesos provocados a propósito, dos que no hubo que provocar y la forma en reposo contra la que se leen.

Source: https://jmrplens.github.io/mikroscope/es/playbooks/

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,

```text
/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](/mikroscope/es/playbooks/idle/)                | 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](/mikroscope/es/playbooks/loop/)               | 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](/mikroscope/es/reference/port-names/) | un puerto muerto apagado y vuelto a encender               | `events`                                              | el kernel escribe `eth5` donde RouterOS dice `ether6`                                                                         |
| [Una carga limitada por CPU](/mikroscope/es/playbooks/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](/mikroscope/es/playbooks/packet-flood/)             | `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](/mikroscope/es/playbooks/flash-wear/)                     | 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](/mikroscope/es/playbooks/conntrack/)                      | 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.

> **Las órdenes de estas páginas no llevan token**
>
> Los ejemplos con `curl` hablan con el agente en `http://172.30.10.2:9123` sin credenciales, que es
> como responde una instalación por defecto. Un agente arrancado con token — obligatorio con
> `--expose` — devuelve 401 en todas las rutas salvo `/healthz` hasta que cada petición lleve la
> cabecera `Authorization: Bearer <token>`.

## 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:

```sh
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](/mikroscope/es/cost/): el presupuesto, el coste medido y el procedimiento
  de arriba completo.
- [El suelo de resolución es del kernel](/mikroscope/es/limits/): 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](/mikroscope/es/sinks/detections/): las reglas que el colector ejecuta sobre estas
  mismas señales.
- [Cinco minutos con un router](/mikroscope/es/start/walkthrough/): una grabación con marcadores, la
  otra forma de leer un transitorio.