# Documentación de mikroscope: lo esencial

> mikroscope es código abierto con licencia MIT y está escrito en Go: un agente que corre en un contenedor en MikroTik RouterOS 7.24 o posterior (arm64, arm, x86_64) y una CLI que lo instala, graba, dibuja y reenvía a once destinos. Versión actual: 1.6.1, 2026-10-06.

11 páginas, en el orden de la barra lateral del sitio, separadas por `---`. Cada una empieza por su título, su descripción y la URL de la página que dobla. El índice de todos los ficheros: https://jmrplens.github.io/mikroscope/es/llms.txt

---

# mikroscope

Telemetría de kernel por debajo del segundo desde dentro de un router MikroTik, con el coste del observador medido y no prometido.

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

La API de RouterOS informa de la carga de CPU una vez por segundo. mikroscope corre en el router, en un contenedor, y lee los contadores del propio kernel a entre 1 y 100 Hz: para quien tiene que contar qué hizo un equipo MikroTik dentro de ese segundo. Dos binarios con licencia MIT y lo que el observador le cuesta al router medido, no prometido, justo aquí abajo.

## Medido, no presupuestado

- [**2,69 %** — de un núcleo a 10 Hz, la cadencia por defecto](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18)
- [**13,2 MiB** — de memoria residente a 10 Hz](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18)
- [**16,83 %** — de un núcleo a 100 Hz, el máximo de la CLI](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18)
- [**0 / 0** — huecos y descartes, en seis ejecuciones](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18)

Las tres primeras salen del propio cgroup del agente, en cada muestra; la cuarta, de InfluxDB 3, el único destino al que reenviaba el colector. Cada una de las tres primeras es una sola ventana de 300 s en régimen estacionario, sin repetir, así que ninguna tiene dispersión. A 10 Hz la memoria está dentro de los ≤ 16 MiB que pide el presupuesto y la CPU por encima del ≤ 2 %. El router, la versión de RouterOS y la fecha están en [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18).

## Una media de un segundo es un informe sobre un segundo

La API de RouterOS publica `cpu-load` una vez por segundo. Un núcleo saturado 100 ms y ocioso los otros 900 mueve la media de un segundo de cuatro núcleos en 2,5 %. Es aritmética, no una medida, y la cifra es cierta: solo que no puede decir cuándo.

El agente lee `/proc/stat`, `/proc/interrupts`, `/proc/softirqs` y `/proc/net/softnet_stat` desde dentro del router, a 10 Hz por defecto, y envía los deltas crudos de ticks con el intervalo que cubre cada uno. Nunca calcula un porcentaje; la ventana la eliges tú.

El suelo es del kernel, no de la herramienta. `/proc/stat` cuenta en ticks de 10 ms, así que una muestra de 100 ms resuelve un núcleo en escalones de 10 %. No hay nada más fino que leer donde el kernel no tiene PSI ni schedstat, y el router probado no tiene ninguno de los dos ([Probado en](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-kernel-2026-09-11)).

[Cuántos segundos promedia `cpu-load` →](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/#cuántos-segundos-promedia-el-cpu-load-de-routeros)

## Lo que cuesta, a tres cadencias

Condiciones: ventanas de 300 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, la configuración que se envía —anillo de 60 s, límite de memoria derivado de él y el tope de contenedor de serie de 64M— con el colector reenviando a InfluxDB 3. Cada fila es una sola ventana, sin repetir, así que ninguna fila tiene dispersión; la memoria cambia por fila porque cambian el anillo y el límite de memoria.

Las ejecuciones medidas:

| cadencia | suelos | CPU de un núcleo | µs/muestra | RSS | ticks retrasados | huecos / descartes |
| --- | --- | --- | --- | --- | --- | --- |
| 10 Hz (por defecto) | por defecto | **2,69 %** | 2 685 | 13,2 MiB | **0** | 0 / 0 |
| 50 Hz | por defecto | **9,63 %** | 1 926 | 23,3 MiB | **0** | 0 / 0 |
| 100 Hz | por defecto | **16,83 %** | 1 684 | 45,7 MiB | 5 (0,02 %) | 0 / 0 |

No se perdió nada a ninguna de estas cadencias: todos los destinos informaron de 0 huecos y 0 descartes, y la cadencia entregada coincidió con la configurada a tres cifras. Con los suelos por defecto y a 100 Hz, todas las fuentes de un tick se leyeron en menos de 2 ms en el 97,7 % de las muestras, dentro de un periodo de 10 ms.

[Las seis ejecuciones, incluida la de todas las fuentes en cada tick →](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/)

## La CPU del router desde el kernel, sus interfaces desde la API

### Capa del kernel · el agente · de 10 a 100 Hz

Globales dentro del contenedor, así que son los del propio router: ticks de CPU por núcleo, interrupciones, softirqs, descartes y time squeezes de softnet, `/proc/meminfo`, `/proc/vmstat`, carga y E/S de disco. Un contenedor privilegiado añade el log del kernel como eventos con marca de tiempo y las cachés slab globales.

### Capa de la API · el colector · 1 Hz

El contenedor tiene su propio espacio de nombres de red, así que `/proc/net/dev` describe al contenedor, no al router. Los bytes y paquetes por interfaz vienen de la API de RouterOS y los fusiona el colector, sin interpolar. `privileged=yes` no cambia eso.

## Cada escritura, listada antes de hacerla

Versión actual: [1.6.1](https://github.com/jmrplens/mikroscope/releases/tag/v1.6.1), 2026-10-06 · [Registro de cambios](https://github.com/jmrplens/mikroscope/blob/main/CHANGELOG.md)

Descarga el archivo para tu plataforma de la versión publicada, o compila la CLI desde una copia del repositorio con `make build`. El router necesita RouterOS 7.24 o posterior —el paso del contenedor escribe `privileged=`, un atributo que las versiones 7.x anteriores rechazan— con el paquete `container` y `device-mode container=yes`, que MikroTik condiciona a pulsar el botón de reset o a un corte de alimentación. arm64, arm y x86_64; ni MIPS ni TILE.

1. `mikroscope doctor`

   Comprobación de solo lectura que nombra el arreglo de lo que falte, y luego lo que muestra el anillo del agente en marcha: un bucle de capa 2, churn de STP, un link flap o descartes de softnet.

2. `mikroscope plan`

   Cada orden de RouterOS, sin escribir nada.

3. `mikroscope install`

   Doctor, confirmación, las escrituras y luego una sonda al agente. La imagen sale de tu propia toolchain de Go, del tar del agente publicado o del registro del que el router se la descarga.

4. `mikroscope status`

   Recuento de propiedad y salud del agente.

5. `mikroscope uninstall`

   Elimina y verifica.

**Lo que `install` escribe en tu router**

- el manifiesto de la instalación, un fichero `mikroscope/<name>.manifest.txt` en el disco de la instalación que lista las opciones y cada objeto de abajo
- una veth
- una dirección
- una pertenencia a lista de interfaces, salvo con `--iface-list none`
- una entrada de address-list, salvo con `--addr-list none`
- una envlist
- el tar de la imagen, que se borra en cuanto el contenedor está extraído, salvo que `--remote-image` haga que el router se la baje
- el contenedor, y su raíz `mikroscope/<name>` en el mismo disco

Cada objeto lleva el comentario `mikroscope:<name> (managed by mikroscope)`

`mikroscope plan` imprime cada orden antes de escribir nada.

`uninstall` elimina por etiqueta exacta más identidad, nunca por patrón, y falla nombrando el paso si queda algo.

[Instalación rápida, paso a paso →](https://jmrplens.github.io/mikroscope/es/start/)

## Probado en

Las cifras de esta página salen de un solo router. [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/) dice cuál, con las versiones de RouterOS, las fechas y las condiciones de cada ejecución.

También dice lo que no se ha probado: otras placas, un tráfico mayor que la carga corriente de ese router, y los destinos y las compilaciones que no han corrido en hardware. No se afirma ninguna cadencia en otra placa.

El coste depende de la velocidad del núcleo, del conjunto de fuentes y del tamaño del anillo. [Mídelo en tu propio router](https://jmrplens.github.io/mikroscope/es/cost/#medirlo-en-tu-propio-equipo) antes de presupuestarlo.

## Por dónde seguir

- [Instalación rápida](https://jmrplens.github.io/mikroscope/es/start/): Instala la CLI, comprueba el router y pon en marcha el agente en un contenedor de RouterOS
- [Cómo funciona](https://jmrplens.github.io/mikroscope/es/how-it-works/): El agente, el colector y el camino de los datos entre ellos, qué lee y qué añade cada uno, y lo que la herramienta no hace
- [Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/): Las otras formas de vigilar un equipo RouterOS, qué lee cada una y cuándo usar otra herramienta
- [Primera grabación](https://jmrplens.github.io/mikroscope/es/start/walkthrough/): Graba mientras cambias algo, márcalo y dibuja el gráfico
- [Métodos de instalación](https://jmrplens.github.io/mikroscope/es/install/routes/): Todas las maneras de llevar el agente a un router, y lo que necesita cada una
- [Ejecutar el colector](https://jmrplens.github.io/mikroscope/es/sinks/): Extraer, fusionar, derivar, repartir a once destinos, y por qué uno lento nunca para el bucle
- [Diagnosticar fallos](https://jmrplens.github.io/mikroscope/es/playbooks/): Qué aspecto tiene cada fallo en los datos del kernel y de los puertos, y qué comprobar antes de fiarte de una lectura
- [Límites de la evidencia](https://jmrplens.github.io/mikroscope/es/cost/limits/): Cada límite de las cifras de arriba

---

# Instalación rápida

Instala la CLI, comprueba el router y pon en marcha el agente en un contenedor de RouterOS, en cuatro órdenes.

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

mikroscope ejecuta un agente en un contenedor de RouterOS que muestrea el kernel del router a 10 Hz
y responde por HTTP en el lado del router de una /30. La CLI de tu ordenador lo instala, e
`install` escribe estos objetos, que `uninstall` retira:

**Lo que `install` escribe en tu router**

- el manifiesto de la instalación, un fichero `mikroscope/<name>.manifest.txt` en el disco de la instalación que lista las opciones y cada objeto de abajo
- una veth
- una dirección
- una pertenencia a lista de interfaces, salvo con `--iface-list none`
- una entrada de address-list, salvo con `--addr-list none`
- una envlist
- el tar de la imagen, que se borra en cuanto el contenedor está extraído, salvo que `--remote-image` haga que el router se la baje
- el contenedor, y su raíz `mikroscope/<name>` en el mismo disco

Cada objeto lleva el comentario `mikroscope:<name> (managed by mikroscope)`

`mikroscope plan` imprime cada orden antes de escribir nada.

`uninstall` elimina por etiqueta exacta más identidad, nunca por patrón, y falla nombrando el paso si queda algo.

`install` no escribe nada fuera del router: el colector y los dashboards de Grafana son un paso
aparte y opcional ([Verlo en Grafana](https://jmrplens.github.io/mikroscope/es/start/#verlo-en-grafana)).

## Requisitos

| Requisito           | Valor                                                                    |
| ------------------- | ------------------------------------------------------------------------ |
| RouterOS            | 7.24 o posterior                                                         |
| Arquitectura        | `arm64`, `arm` o `x86_64`; ni MIPS, ni TILE, ni PPC                      |
| Paquete `container` | instalado y habilitado                                                   |
| Device mode         | `container=yes`, confirmado pulsando un botón o cortando la alimentación |

También necesitas un ordenador con acceso ssh al router como usuario administrador, con una clave o
un agente ssh: la CLI ejecuta ssh en modo batch y no puede responder a una petición de contraseña.
[Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/) tiene el detalle y lo que comprueba `doctor`.

## Instalar la CLI

```sh
curl -fsSL https://raw.githubusercontent.com/jmrplens/mikroscope/main/install.sh | bash
```

En PowerShell, en Windows:

```powershell
irm https://raw.githubusercontent.com/jmrplens/mikroscope/main/install.ps1 | iex
```

El script instala la versión más reciente y rechaza un archivo cuyo SHA-256 no sea el que publicó
la versión. [Instalar la CLI](https://jmrplens.github.io/mikroscope/es/install/cli/) tiene los mismos pasos a mano.

## Comprobar el router

```sh
mikroscope doctor --router admin@192.168.88.1 --remote-image jmrplens/mikroscope-agent:1.6.1
```

`doctor` lee el router y no escribe nada. Imprime una línea por comprobación, marcada `ok`,
`MISSING` o `WARN`, y termina con `doctor: every prerequisite is met`. Tras una línea `MISSING`
viene su arreglo:

```text
  MISSING interface list LAN exists (found=0)
          fix: --iface-list none: no firewall rule here needs the veth in an interface list. Or create it: `/interface/list/add name=LAN`
```

Aplica el arreglo, o añade la opción que nombra a esta orden y a `install` más abajo, y vuelve a
ejecutar `doctor` hasta que no quede nada `MISSING`. Una línea `WARN` no detiene la instalación.

> **Device mode te necesita junto al router**
>
> Tras `/system/device-mode/update container=yes`, pulsa el botón reset o mode, o corta la
> alimentación, en menos de 5 minutos. En CHR, apaga y enciende la máquina virtual. Ninguna sesión
> ssh ni llamada a la API puede dar este paso.

> **Un router que ssh no ha visto nunca**
>
> La CLI ejecuta ssh en modo batch, así que una clave de host que aún no está en `known_hosts` la
> detiene. Añade `--ssh-option StrictHostKeyChecking=accept-new` a la primera orden, o conéctate
> una vez con `ssh` tú mismo.

## Instalar el agente

```sh
mikroscope install --router admin@192.168.88.1 --remote-image jmrplens/mikroscope-agent:1.6.1
```

`install` hace las mismas comprobaciones, lee la arquitectura del router e imprime cada orden de
RouterOS que va a ejecutar, terminando con `nothing above has been written yet`. Después pregunta
`write the objects above to the router? [y/N]`. Tras las escrituras sondea el agente desde tu
ordenador:

```text
install done: 6 step(s) created
probing http://172.30.10.2:9123/healthz from this host …
  direct transport ok: agent 1.6.1 (<commit>) built <time>, 10 Hz, seq 7, 0 slipped, 2ms round trip
```

El router descarga la imagen de Docker Hub por su cuenta: no se sube nada y no se toca
`/container/config`. Si el sondeo no alcanza al agente, dice si el contenedor está en marcha;
[Acceso por red](https://jmrplens.github.io/mikroscope/es/install/reaching-the-agent/) tiene las tres formas de llegar a él.

## Verificar

```sh
mikroscope status --router admin@192.168.88.1
```

`status` lee el manifiesto de la instalación en el router, imprime cuántos objetos tiene cada paso
y sondea el agente:

```text
agent: 1.6.1 (<commit>) built <time>, 10 Hz, seq 14 (oldest 1), up 1s, 0 slipped, 1ms round trip
```

Desde un equipo de la LAN del router, `curl http://172.30.10.2:9123/healthz` responde
`{"ok":true,…}`.

## Verlo en Grafana

Es opcional, y nada de esto escribe en el router. Los dashboards leen un almacén, y quien lo llena es el
colector, `mikroscope forward`: trae las muestras del agente y las escribe en los destinos que
indiques. Con un InfluxDB 3 y un Grafana ya en marcha, arráncalo y déjalo funcionando:

```sh
export MIKROSCOPE_INFLUX_TOKEN=…   # el token del almacén; omítelo si el almacén no pide autenticación
mikroscope forward --influx http://localhost:8181 --influx-db mikroscope
```

Cuando hayan llegado muestras, ejecuta `dashboards publish` desde otra terminal con el mismo
`MIKROSCOPE_INFLUX_TOKEN`, las opciones de destino del colector y tu Grafana. Crea la fuente de
datos del almacén, publica su dashboard y termina:

```sh
export GRAFANA_TOKEN=…   # un token de cuenta de servicio de Grafana con el rol Admin
mikroscope dashboards publish --influx http://localhost:8181 --influx-db mikroscope --grafana http://localhost:3000
```

```text
folder "mikroscope" (<uid>) created
influxdb: datasource mikroscope-influxdb (influxdb) created
influxdb: dashboard http://localhost:3000/d/mikroscope-influxdb/…
```

- **Demasiado pronto.** Si se ejecuta antes de que el almacén tenga una muestra, publica los
  valores compilados por defecto e imprime `could not ask the datasource which measurements it
  holds`. Vuelve a ejecutarlo cuando hayan llegado datos y sustituye el dashboard.
- **Desde el colector.** Añade `--grafana http://localhost:3000` a `forward`, con `GRAFANA_TOKEN` en
  su entorno, y publica de la misma forma en cada arranque, antes de recoger.
- **Otra dirección.** Cuando Grafana llega a InfluxDB por una dirección distinta de la del
  colector, pasa esa dirección en `--grafana-datasource-url`. Con Grafana en un contenedor,
  `localhost` es el propio contenedor: usa el nombre de InfluxDB en la red de Docker, como
  `http://influxdb:8181`, o la dirección del host en la LAN.
- Los paneles de interfaces necesitan además la
  [capa de la API de RouterOS](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/).

[Configurar en Grafana](https://jmrplens.github.io/mikroscope/es/dashboards/import-and-check/) cubre Prometheus y los demás
almacenes, la importación a mano y la comprobación de cada panel.

## Otras formas de instalar

- [Generador de scripts](https://jmrplens.github.io/mikroscope/es/install/generator/): rellena un formulario y pega el script
  en el terminal del router. Sin CLI.
- [Script de RouterOS](https://jmrplens.github.io/mikroscope/es/install/script/): `mikroscope plan --rsc` escribe la misma
  instalación como un único script.
- [Instalación manual: terminal](https://jmrplens.github.io/mikroscope/es/install/manual-cli/): cada orden, de una en una.
- [Instalación manual: WebFig y Winbox](https://jmrplens.github.io/mikroscope/es/install/manual-gui/): los mismos objetos,
  desde los menús.
- [Instalación sin conexión](https://jmrplens.github.io/mikroscope/es/install/offline/): el tar de la imagen, para un router
  que no llega a un registro.
- [Desde el código fuente](https://jmrplens.github.io/mikroscope/es/install/routes/#un-checkout-con-go): un agente compilado
  desde tu copia del repositorio.
- [Actualizar y desinstalar](https://jmrplens.github.io/mikroscope/es/install/upgrade/): una versión nueva, o quitarlo todo.

[Métodos de instalación](https://jmrplens.github.io/mikroscope/es/install/routes/) los compara.

## Siguientes pasos

- [Primera grabación](https://jmrplens.github.io/mikroscope/es/start/walkthrough/): graba una ventana, márcala y dibújala.
- [Ejecutar el colector](https://jmrplens.github.io/mikroscope/es/sinks/): envía las muestras a Prometheus, InfluxDB 3 o
  nueve destinos más.
- [Configurar en Grafana](https://jmrplens.github.io/mikroscope/es/dashboards/import-and-check/): los dashboards de
  Prometheus y los demás almacenes, desde el colector, la CLI o a mano.
- [Dashboards](https://jmrplens.github.io/mikroscope/es/dashboards/): lo que muestra cada sección y cada panel.

## Limitaciones

- Se suma a la API de RouterOS y no la sustituye: el tráfico por interfaz viene de la API, porque
  el contenedor solo ve su propia red.
- El kernel cuenta el tiempo de CPU en ticks de 10 ms, así que una muestra de 100 ms resuelve un
  núcleo en pasos de 10 %.
- Una fuente que una placa no tiene falta en la salida; nunca vale cero.

[Cómo funciona](https://jmrplens.github.io/mikroscope/es/how-it-works/#limitations) tiene la lista completa.

## Véase también

- [Cómo funciona](https://jmrplens.github.io/mikroscope/es/how-it-works/): el agente, la veth, el colector y los destinos.
- [Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/): lo que el agente le cuesta al router, y cómo medirlo en
  el tuyo.
- [Preguntas frecuentes](https://jmrplens.github.io/mikroscope/es/start/questions/): respuestas cortas, cada una enlazada a la
  página con el detalle.
- [Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/): SNMP, mktxp, The Dude y el resto.

---

# Primera grabación

Graba el kernel del router mientras cambias algo, marca los momentos, añade el log del propio router y dibújalo como un solo gráfico.

Source: https://jmrplens.github.io/mikroscope/es/start/walkthrough/

Graba el kernel del router mientras cambias algo en él, y lee en un solo gráfico qué hizo el
cambio. Para esto hace falta un agente ya instalado:
[Instalación rápida](https://jmrplens.github.io/mikroscope/es/start/) pone uno.

## Antes de empezar

- `mikroscope status --router admin@192.168.88.1` imprime una línea `agent:`. Las órdenes de abajo
  llegan al agente en su dirección por defecto, `172.30.10.2:9123`; pasa `--subnet` y `--port` si
  instalaste con otras.
- Para el paso 3, un usuario de la API de RouterOS con acceso de lectura.
  [Usuario de la API](https://jmrplens.github.io/mikroscope/es/security/api-user/) tiene las dos órdenes que lo crean.

El paso 3 lee tres variables de entorno:

| Variable                  | Opción       |
| ------------------------- | ------------ |
| `MIKROSCOPE_API_ADDR`     | `--api`      |
| `MIKROSCOPE_API_USER`     | `--api-user` |
| `MIKROSCOPE_API_PASSWORD` | ninguna      |

La contraseña no tiene opción, así que no aparece en `ps` ni en el historial de tu shell. La CLI no
lee `.env` por su cuenta: exporta las variables, o copia [`.env.example`](https://github.com/jmrplens/mikroscope/blob/main/.env.example) a `.env` y
cárgalo con `set -a; . ./.env; set +a`.
[Variables de entorno](https://jmrplens.github.io/mikroscope/es/reference/environment/) enumera todas.

## Pasos

1. **Graba mientras haces el cambio.**

   ```sh
   mikroscope record --for 60s --out burst
   ```

   En un terminal, escribe una línea y pulsa Intro en cualquier momento que quieras recordar: se
   convierte en una marca con el reloj del agente. La CLI lo dice al arrancar:
   `type a line and press Enter to add a marker; Ctrl-C stops`. Sin `--for` graba hasta Ctrl-C.
   Al terminar imprime lo que escribió:

   ```text
   recorded 600 samples (seq 11..610), 0 gap(s), 0 marker(s), via direct http://172.30.10.2:9123
     burst.jsonl
     burst.csv
     burst.markers.csv
     burst.meta.json
   ```

   El resumen cuenta las marcas escritas en el propio `record`, y nombra cualquier tramo de
   muestras que ya hubiera salido del anillo del agente.

2. **Marca desde otro terminal.**

   ```sh
   mikroscope mark --out burst "queue tree applied"
   ```

   Imprime `marker added to burst.markers.csv at <time>`. `mark` añade al mismo fichero mientras
   `record` sigue, y también funciona después de la grabación.

3. **Añade el log del propio router.**

   ```sh
   export MIKROSCOPE_API_ADDR=192.168.88.1:8728 MIKROSCOPE_API_USER=mikroscope MIKROSCOPE_API_PASSWORD=…
   mikroscope mark --out burst --log-markers --router-tz Europe/Madrid
   ```

   Cada línea del log dentro de la ventana de la grabación cuyo tema sea `system`, `interface` o
   `container` se convierte en una marca:

   ```text
   7 log marker(s) added to burst.markers.csv (window <start> → <end>, topics system,interface,container)
   ```

   Añade `firewall` o `script` con `--topics`. `--router-tz` es la zona IANA que muestra el reloj
   del router, porque las horas del log de RouterOS no llevan zona; por defecto es la de tu
   máquina. `record --log-markers` hace lo mismo al acabar la grabación.

4. **Dibújalo.**

   ```sh
   mikroscope plot --in burst
   ```

   Escribe `burst.svg` e imprime `burst.svg: 600 samples, 10 markers`. `--title` fija el título y
   `--svg` otra ruta. La misma grabación da siempre los mismos bytes.

5. **Sigue recogiendo (opcional).** Para guardar las muestras y no solo una ventana,
   [ejecuta el colector](https://jmrplens.github.io/mikroscope/es/sinks/) hacia Prometheus, InfluxDB 3 u otro destino; con
   `--grafana` también publica el dashboard
   ([Configurar en Grafana](https://jmrplens.github.io/mikroscope/es/dashboards/import-and-check/)).

## Leer el gráfico

El gráfico tiene tres paneles sobre un mismo eje de tiempo:

- **Ocupación por núcleo.** La parte de cada tick de 100 ms que un núcleo pasó trabajando. Una
  muestra de un núcleo al 100 % son 100 ms de trabajo, y mueve una media de cuatro núcleos y un
  segundo solo 2,5 %: las excursiones cortas que una media esconde
  son el motivo de muestrear a 10 Hz.
- **softnet, por segundo.** `dropped` cuenta los paquetes que el kernel perdió de su cola, que
  ningún contador de interfaz muestra; `time_squeeze` cuenta las veces que el kernel se contuvo. Un
  squeeze por sí solo no es una avería.
- **Memoria disponible.** Lo que el kernel podría entregar sin recurrir al swap.

Cada marca es una línea vertical discontinua, dibujada en todos los paneles, con su etiqueta al
lado. Las marcas del log que caen en el mismo segundo se funden en una línea etiquetada `N×` con el
primer mensaje. Un hueco en las muestras es una línea roja. Una etiqueta de más de 40 caracteres se
corta a 37 y unos puntos suspensivos.

[Línea base en reposo](https://jmrplens.github.io/mikroscope/es/playbooks/idle/#gráfico-grabado) lee línea a línea una grabación real de un
router en reposo, la forma con la que se comparan las demás, y
[Diagnosticar fallos](https://jmrplens.github.io/mikroscope/es/playbooks/) tiene las firmas que deja una avería en estos
paneles.

## Quitar el agente

```sh
mikroscope uninstall --router admin@192.168.88.1 --yes
```

Retira cada objeto que creó la instalación, leyendo la lista del manifiesto de la instalación en el
router, y termina con `verified: nothing mikroscope created remains on the router`. Sin `--yes`
solo los enumera. [Actualizar y desinstalar](https://jmrplens.github.io/mikroscope/es/install/upgrade/) tiene lo que nunca
toca, y cómo quitar dashboards y datos guardados.

> **ssh no es una ruta de datos**
>
> `record`, `mark` y `plot` nunca usan ssh: las muestras viajan por HTTP a la dirección de la veth,
> o por el relé de la API de RouterOS. Solo las órdenes de instalación se conectan por ssh, una
> conexión por cada lote de lecturas.

## Véase también

- [Grabar, marcar y dibujar](https://jmrplens.github.io/mikroscope/es/record/): los ficheros, los transportes y las marcas al
  completo.
- [Captura por disparo](https://jmrplens.github.io/mikroscope/es/record/triggers/): deja que el agente guarde por ti los
  segundos alrededor de una avería.
- [Ejecutar el colector](https://jmrplens.github.io/mikroscope/es/sinks/): lo que fusiona `forward` y adónde lo envía.
- [Diagnosticar fallos](https://jmrplens.github.io/mikroscope/es/playbooks/): las firmas que deja una avería en estos
  paneles.

---

# Preguntas frecuentes

Respuestas cortas sobre mikroscope en MikroTik RouterOS, de MIPS y el mínimo de 7.24 al coste, el uso en producción, cpu-load y los dashboards de Grafana, cada una enlazada a la página con el detalle.

Source: https://jmrplens.github.io/mikroscope/es/start/questions/

Cada respuesta es la versión corta de una página que tiene el detalle, y enlaza a ella.

## MIPS y TILE

mikroscope no funciona en routers MIPS ni TILE. El agente se ejecuta en un contenedor de RouterOS,
y MikroTik publica el paquete `container` solo para arm, arm64, x86 y CHR ([la lista de paquetes de
MikroTik](https://help.mikrotik.com/docs/spaces/ROS/pages/40992872/Packages)). mikroscope compila su
agente para arm64, arm y x86_64. En una placa MIPS o TILE, la herramienta es SNMP o un exportador de
la API: [Cuándo usar otra herramienta](https://jmrplens.github.io/mikroscope/es/start/compared/#cuándo-no-usar-mikroscope).

## Routers probados

[Probado en](https://jmrplens.github.io/mikroscope/es/about/status/) enumera cada equipo y versión de RouterOS en los que ha
funcionado mikroscope, físicos y virtuales, con lo que se ejecutó en cada uno y lo que no se ha
probado. Un [informe de placa](https://github.com/jmrplens/mikroscope/issues/new?template=2-board-report.yml)
desde otro router lo añade allí.

## Por qué RouterOS 7.24

El paso del contenedor escribe `privileged=`, un atributo que RouterOS añadió en la 7.24, diga lo
que diga `--privileged`. `doctor` y el script de instalación comprueban primero la versión y se
detienen en una anterior sin escribir nada:
[Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/#un-equipo-capaz-de-ejecutar-contenedores).

## Botón de device-mode

MikroTik lo diseñó así. Device-mode limita lo que permite un router, para protegerlo de un atacante
que haya conseguido acceso, así que cambiarlo exige acceso físico: tras
`/system/device-mode/update container=yes`, alguien pulsa el botón reset o mode, o corta la
alimentación del router, en menos de cinco minutos ([la página de device-mode de
MikroTik](https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode)). Ninguna
herramienta puede hacerlo en remoto:
[Device mode](https://jmrplens.github.io/mikroscope/es/install/prerequisites/#device-mode-containeryes).

## Coste para el router

Con los 10 Hz por defecto de la instalación, el agente cuesta 2,69 % de un
núcleo y 13,2 MiB de memoria, leídos de su propio cgroup, y
cuesta 16,83 % a 100 Hz. Eso supera el presupuesto de CPU del propio proyecto,
de 2 %, y cabe en su presupuesto de memoria, de 16 MiB:
[Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/), con cómo medirlo en tu router.

## Uso en producción

El agente nunca se conecta hacia fuera y no presenta ninguna credencial. Cada escritura se enumera
antes de hacerse y va etiquetada, y `uninstall` retira todo lo que creó la instalación y verifica
que no queda nada: un ciclo con guion dejó el `/export` del router idéntico byte a byte
([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-export-identical)). El contenedor se ejecuta con
`privileged=yes`, una concesión real: [Modelo de seguridad](https://jmrplens.github.io/mikroscope/es/security/).

## Tráfico de interfaces

No desde dentro del contenedor. `/proc/net/dev` y los demás ficheros de red van por espacio de
nombres de red, así que allí cuentan la propia veth del contenedor, y `privileged=yes` no lo
cambia. Los bytes y paquetes por interfaz vienen de la API de RouterOS, que el colector fusiona con
el reloj del agente:
[Visibilidad del contenedor](https://jmrplens.github.io/mikroscope/es/limits/namespaces/#la-red-es-la-del-contenedor).

## Ventana de cpu-load

Alrededor de un segundo. El `cpu-load` de RouterOS sigue una media móvil de aproximadamente un
segundo del tiempo ocupado del kernel, llega a la API una fracción de segundo tarde y no es una media
de sesenta segundos ([medido](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-cpu-load-window-2026-09-15)). Una ráfaga más
corta que ese segundo queda promediada dentro: [Capa de la API de
RouterOS](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/#cuántos-segundos-promedia-el-cpu-load-de-routeros).

## SNMP y mktxp

mikroscope no sustituye a SNMP ni a mktxp. Tampoco sustituye a la API de RouterOS, de la que toma
el tráfico por interfaz. Lo que añade es la vista del propio kernel, que ninguno de los otros
documenta leer: ticks por núcleo hasta a 100 Hz, softirqs, descartes y squeezes de softnet, y el log
del kernel. Donde no se ejecuta ningún contenedor, la herramienta es SNMP o mktxp:
[Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/).

## Dashboards de Grafana

`install` no configura Grafana: solo escribe en el router. Lo hace el colector, cuando se ejecuta
con `--grafana <url>` y un token de cuenta de servicio de Grafana en `GRAFANA_TOKEN`: en cada
arranque crea o corrige la fuente de datos y publica el dashboard de cada almacén que sabe
describir: InfluxDB, Elasticsearch y PostgreSQL (con `--postgres`) sin más, y Prometheus y Graphite
cuando se les da la dirección en `--grafana-datasource-url`.
`mikroscope dashboards publish`, con las opciones de destino del colector y `--grafana`, hace lo
mismo una sola vez sin recoger, y `dashboards import` o la importación del propio Grafana asocian un
dashboard a una fuente de datos que ya tienes:
[Configurar en Grafana](https://jmrplens.github.io/mikroscope/es/dashboards/import-and-check/).

## Conexiones salientes

El agente no envía nada fuera del router. Sirve HTTP en la dirección de su veth, no abre ninguna
conexión saliente y no busca actualizaciones. Tu colector tira de él, y cada token de destino y
credencial de la API se queda en tu equipo, porque todo lo que está en la envlist del contenedor se
trata como legible por cualquier usuario de RouterOS con `read`:
[Modelo de seguridad](https://jmrplens.github.io/mikroscope/es/security/).

## Véase también

- [Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/): SNMP, The Dude, Graphing, el
  Profiler, mktxp y mikrotik-exporter, celda a celda.
- [Glosario](https://jmrplens.github.io/mikroscope/es/reference/glossary/): envlist, veth, PMU, PSI, softnet y los demás
  términos que usan estas respuestas.
- [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/): los equipos, versiones y resultados detrás de cada
  respuesta.

---

# Comparado con alternativas

Qué leen de un router MikroTik SNMP, The Dude, Graphing, el Profiler, mktxp y mikrotik-exporter, junto a mikroscope, y cuándo conviene usarlos en su lugar.

Source: https://jmrplens.github.io/mikroscope/es/start/compared/

mikroscope lee el kernel Linux de un router MikroTik desde dentro de un contenedor de RouterOS, a
entre 1 y 100 Hz. SNMP, The Dude, Graphing y el Profiler del propio RouterOS, mktxp y
mikrotik-exporter leen lo que informa el propio RouterOS. La tabla pone los siete uno junto a otro;
las secciones que la siguen dicen de dónde sale cada celda y cuándo uno de los otros seis es mejor
opción.

## Tabla comparativa

| Herramienta | Dónde corre | Qué lee | Vista de CPU más fina | softirq y softnet por núcleo | Log del kernel | Contadores de interfaz | Lo que necesita en el router |
| ----------- | ----------- | ------- | --------------------- | ---------------------------- | -------------- | ---------------------- | ---------------------------- |
| mikroscope | un agente en un contenedor de RouterOS; la CLI y el colector en tu máquina | el kernel del router: `/proc`, `/sys`, `/dev/kmsg`, `perf_event_open` | por núcleo, los ticks crudos de `/proc/stat` a 1–100 Hz; una muestra de 100 ms resuelve un núcleo en pasos de 10 % | sí, por CPU, en cada tick | sí, `/dev/kmsg`, con `privileged=yes` | de la API de RouterOS, fusionados: el espacio de nombres de red del contenedor oculta los del router | RouterOS 7.24 o posterior, el paquete `container`, `device-mode container=yes`; arm64, arm o x86_64 |
| [SNMP](https://help.mikrotik.com/docs/spaces/ROS/pages/8978519/SNMP) | un agente integrado en RouterOS; el sondeador en otra máquina | MIB: MIB-2, HOST-RESOURCES-MIB, IF-MIB, MIKROTIK-MIB y otras | `hrProcessorLoad` por procesador, definido como una media de un minuto ([RFC 2790](https://datatracker.ietf.org/doc/html/rfc2790)) | ningún objeto para ninguno de los dos en la [MIKROTIK-MIB](https://download.mikrotik.com/routeros/7.24.4/mikrotik.mib) | no; los traps avisan de cambios de interfaz, del arranque del servicio SNMP y de un umbral de temperatura (`temp-exception`) | sí, IF-MIB | `/snmp set enabled=yes` (desactivado por defecto) y una comunidad o un usuario SNMPv3 |
| [The Dude](https://help.mikrotik.com/docs/spaces/ROS/pages/377225250/Dude) | el paquete `dude` (arm, arm64, mmips, tile, x86, CHR); MikroTik lo da por descontinuado | no lo dicen las páginas actuales de MikroTik | no lo dicen las páginas actuales de MikroTik | no lo dicen las páginas actuales de MikroTik | no consta | no lo dicen las páginas actuales de MikroTik | el paquete `dude`; las páginas actuales de MikroTik no dicen nada más |
| [Graphing](https://help.mikrotik.com/docs/spaces/ROS/pages/22773810/Graphing) | dentro de RouterOS; las gráficas en WebFig y WinBox | las cifras de recursos y tráfico del propio RouterOS | no consta; `store-every`, 5 min por defecto, es cada cuánto escribe en disco | no: dibuja recursos, interfaces y colas simples | no | tráfico por interfaz | entradas en `/tool graphing`; desactivado por defecto |
| [Profiler](https://help.mikrotik.com/docs/spaces/ROS/pages/8323153/Profiler) | dentro de RouterOS, `/tool/profile`, a mano | la contabilidad de CPU por proceso de RouterOS | por núcleo y por clase de proceso; instantáneas de un segundo ([coste de la capa API](https://jmrplens.github.io/mikroscope/es/cost/#api-tier-cost)) | no: CPU por clase de proceso | no | no | nada: viene integrado |
| [mktxp](https://github.com/akpw/mktxp) | tu máquina: Python 3.9 o posterior en Linux, macOS o FreeBSD, o Docker | la API de RouterOS | `cpu-load` de `/system/resource`: una sola cifra para todo el router | ningún colector para ninguno de los dos (código en `1e4412a`) | no; el syslog de RouterOS va al [MKTXP Stack](https://github.com/akpw/mktxp-stack), un proyecto aparte | sí, por la API | un usuario de la API con `api,read` |
| [mikrotik-exporter](https://github.com/nshttpd/mikrotik-exporter) | tu máquina | la API de RouterOS | `cpu-load` de `/system/resource/print`: una sola cifra para todo el router | ningún colector para ninguno de los dos (código en `428dbfc`) | no | sí, `/interface/print` | un usuario de la API con `api,read,winbox` |

Las otras seis filas son lo que dice la documentación o el código de cada herramienta, con "no
consta" o "no lo dicen" donde no dicen nada. Ninguna de las seis se ejecutó para esta tabla, así que
ninguna celda de sus filas es una medición. Las fuentes son las páginas de MikroTik sobre
[paquetes](https://help.mikrotik.com/docs/spaces/ROS/pages/40992872/Packages) y
[`/system/resource`](https://help.mikrotik.com/docs/spaces/ROS/pages/40992875/Resource) además de
las cuatro enlazadas en la tabla; el [fichero MIKROTIK-MIB](https://download.mikrotik.com/routeros/7.24.4/mikrotik.mib),
ninguno de cuyos objetos se llama ni se describe como contador de softirq, de softnet, de
interrupciones o de log; la
[guía del exportador](https://github.com/akpw/mktxp/blob/1e4412a3349db95f59281c81d3b3bc65f2f7f963/docs/exporter.md) y el
[colector de recursos](https://github.com/akpw/mktxp/blob/1e4412a3349db95f59281c81d3b3bc65f2f7f963/mktxp/collector/resource_collector.py)
de mktxp en el commit `1e4412a`; y el
[colector de recursos](https://github.com/nshttpd/mikrotik-exporter/blob/428dbfcc37d05d52ee6a326fa45719a375a89d02/collector/resource_collector.go)
de mikrotik-exporter en el commit `428dbfc`. Las herramientas de terceros cambian: comprueba sus
páginas antes de fiarte de una celda.

La fila de mikroscope sale de este sitio: [Cómo funciona](https://jmrplens.github.io/mikroscope/es/how-it-works/),
[Límites de resolución](https://jmrplens.github.io/mikroscope/es/limits/), [Modo privilegiado](https://jmrplens.github.io/mikroscope/es/limits/privileged/),
[Visibilidad del contenedor](https://jmrplens.github.io/mikroscope/es/limits/namespaces/) y
[Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/). La resolución de su celda de CPU es aritmética
a partir del tick del kernel, no una lectura.

## cpu-load en los exportadores

mktxp y mikrotik-exporter leen los dos `cpu-load`, que MikroTik define como el porcentaje de los
recursos de CPU usados con todas las CPU juntas. Es [una media móvil de alrededor de un
segundo](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/#cuántos-segundos-promedia-el-cpu-load-de-routeros), así que
una ráfaga más corta que ese segundo queda promediada dentro. Hay cifras por núcleo en
`/system/resource/cpu` de RouterOS, que lee la capa de la API de mikroscope y que el código de
ninguno de los dos exportadores pide.

## Señales solo del kernel

Un bucle de capa 2 puede dejar el log y el monitor de puertos de RouterOS informando de un equipo
sano mientras el log del kernel recoge la propia dirección del router volviendo a entrar en el
bridge en cada hello de STP. mikroscope lee ese log a través de `/dev/kmsg`, y ninguno de los otros
seis documenta leerlo. [Bucle de capa 2](https://jmrplens.github.io/mikroscope/es/playbooks/loop/) es un caso real,
diagnosticado.

Tampoco sustituye a la API de RouterOS: los bytes y paquetes por interfaz vienen de esa API, y el
colector los fusiona con las muestras del kernel con el reloj del agente.

## Coste para el router

Con los 10 Hz por defecto de la instalación, el agente cuesta 2,69 % de un
núcleo y 13,2 MiB de RSS, de su propio cgroup
([Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/)). Su capa de la API, que pregunta a RouterOS una ronda por
segundo, tiene un coste propio: [Coste de la capa API](https://jmrplens.github.io/mikroscope/es/cost/#api-tier-cost).
Esa cifra es el cliente del propio mikroscope preguntando sus propias órdenes, no un exportador.

Lo que cuesta a un router el sondeo SNMP, The Dude, Graphing, el Profiler, mktxp o
mikrotik-exporter, con qué frecuencia puede sondear cada uno con utilidad, y qué pone RouterOS en
`hrProcessorLoad` no se ha medido ([No probado](https://jmrplens.github.io/mikroscope/es/about/status/#not-tested)).

## Cuándo usar otra herramienta

- **Un router MIPS, TILE o PPC.** El agente no es nada sin un contenedor, y MikroTik publica el
  paquete `container` solo para arm, arm64, x86 y CHR. `/system/resource/print` da el
  `architecture-name` de tu router. SNMP, o un exportador de la API como mktxp, lee lo que informa
  RouterOS en cualquiera de ellos.
- **RouterOS anterior a 7.24.** El paso del contenedor escribe `privileged=`, un atributo que
  RouterOS añadió en la 7.24, así que `doctor` y el script de instalación se detienen en una versión
  anterior antes de escribir nada. Actualiza RouterOS, o usa SNMP o mktxp, que no necesitan
  contenedor.
- **Sin paquete `container`, o sin nadie que pulse el botón.** `device-mode container=yes` exige
  pulsar el botón reset o mode, o un reinicio en frío, en los cinco minutos siguientes a la orden.
  [La página de device-mode de MikroTik](https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode)
  exige acceso físico a propósito, así que ninguna sesión remota puede concederlo. SNMP necesita
  activar un servicio, y un exportador, un usuario de la API.
- **Solo quieres el tráfico de las interfaces a un intervalo de scrape.** mikroscope toma los bytes
  y paquetes por interfaz de la misma API de RouterOS que lee un exportador, porque el contenedor no
  los ve. Un exportador los obtiene sin poner nada en el router.
- **Necesitas verlo probado antes en tu placa.** [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/)
  enumera las placas y versiones de RouterOS en las que ha funcionado. Un
  [informe de placa](https://github.com/jmrplens/mikroscope/issues/new?template=2-board-report.yml)
  añade la tuya.

## Véase también

- [Cómo funciona](https://jmrplens.github.io/mikroscope/es/how-it-works/): el agente, el colector y los límites que no se
  pueden eliminar con ingeniería.
- [Preguntas frecuentes](https://jmrplens.github.io/mikroscope/es/start/questions/): MIPS, la 7.24, el coste, un router de
  producción, en un párrafo cada una.
- [Capa de la API de RouterOS](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/): lo que el colector sigue
  preguntando a RouterOS.
- [Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/): la arquitectura, el paquete y el paso de
  device-mode.

---

# Métodos de instalación

Las formas de poner el agente de mikroscope en un router MikroTik — la CLI con una descarga del registro, el tar de la imagen o una copia del código, un script de RouterOS, el generador o a mano — y lo que necesita cada una.

Source: https://jmrplens.github.io/mikroscope/es/install/routes/

Todos los métodos crean los mismos objetos en el router: la veth, la dirección del router, las
pertenencias a listas que conserves, la envlist, el contenedor y el manifiesto de la instalación,
todos con la misma etiqueta. Así que `mikroscope status` y `uninstall` reconocen una instalación la haya hecho el
método que sea. Se diferencian en dónde se ejecutan y en cómo llega la imagen del agente al router.
Todos necesitan antes los [Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/), device mode incluido.

## Comparar métodos

| Método                                                                         | Necesita                                                             | Úsalo cuando                                                   |
| ------------------------------------------------------------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------- |
| **[Descarga del registro](https://jmrplens.github.io/mikroscope/es/install/routes/#un-pull-del-registro)** con la CLI                  | ssh al router; que el router llegue a Docker Hub o a GHCR            | por defecto: una orden, sin subir nada                         |
| [Instalación sin conexión](https://jmrplens.github.io/mikroscope/es/install/offline/)                    | ssh y `scp`; el tar de la imagen para la arquitectura del router     | el router no llega a ningún registro                           |
| [Desde el código fuente](https://jmrplens.github.io/mikroscope/es/install/routes/#un-checkout-con-go)                                  | Go 1.27 y una copia del repositorio; ssh y `scp`                     | estás cambiando el agente y lo quieres desde tu árbol          |
| [Script de RouterOS](https://jmrplens.github.io/mikroscope/es/install/script/)                           | la CLI en cualquier ordenador; un terminal en el router              | llegas al router por Winbox o WebFig, no por ssh               |
| [Generador de scripts](https://jmrplens.github.io/mikroscope/es/install/generator/)                      | un navegador; un terminal en el router                               | no tienes la CLI                                               |
| [Instalación manual: terminal](https://jmrplens.github.io/mikroscope/es/install/manual-cli/)             | un terminal en el router                                             | quieres escribir o adaptar cada orden                          |
| [Instalación manual: WebFig y Winbox](https://jmrplens.github.io/mikroscope/es/install/manual-gui/)      | WebFig o Winbox                                                      | prefieres los menús a las órdenes                              |

**Usa la descarga del registro salvo que algo te lo impida.** Es una orden sin nada que elegir ni
nada que ajustar en el router: el índice de la imagen publicada lleva todas las plataformas que
puede ser un contenedor de MikroTik, así que el router elige la suya. No queda ningún tar en la
flash.

El tar de la imagen es la única ruta en la que **tú** eliges la arquitectura, y una elección
equivocada se instala, arranca y muere con `exec format error` en el registro del contenedor.
[Instalación sin conexión](https://jmrplens.github.io/mikroscope/es/install/offline/) tiene la tabla.

## Descarga del registro

```sh
mikroscope install --router admin@192.168.88.1 --remote-image jmrplens/mikroscope-agent:1.6.1
```

El paso del contenedor pasa a ser
`/container/add remote-image="registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1" …`,
y el plan imprime
`the router pulls registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1 (nothing is uploaded)`
donde iría una subida. Cada versión publica la imagen dos veces, como
`jmrplens/mikroscope-agent:1.6.1` en Docker Hub y como
`ghcr.io/jmrplens/mikroscope-agent:1.6.1` en GHCR. Las dos llevan `linux/amd64`,
`linux/arm64`, `linux/arm/v7` y `linux/arm/v5`, y RouterOS elige la que necesita su arquitectura.

Esta ruta necesita dos cosas que las demás no: que el router llegue al registro, y RAM libre para las
capas mientras las extrae. `doctor` avisa cuando la memoria libre no llega a `--memory-max` más
16 MiB.

`--remote-image` toma su valor por defecto de `MIKROSCOPE_REMOTE_IMAGE`. `upgrade` también la
acepta, y toma la imagen solo de sus propias opciones, así que vuelve a pasarla con la versión
nueva. `image` la rechaza, porque no hay tar que escribir.

### Ajustes del registro

mikroscope le pasa a RouterOS la referencia entera, con el equipo del registro incluido. Una
referencia sin equipo, o que empieza por `docker.io/`, `index.docker.io/` o
`registry.hub.docker.com/`, sale como
`registry-1.docker.io/jmrplens/mikroscope-agent:1.6.1`, el equipo en el que responde
el registro de Docker Hub; cualquier otro equipo se deja como está. RouterOS 7.18 y posteriores
aceptan ahí un equipo de registro ([registro de cambios de la 7.18](https://download.mikrotik.com/routeros/7.18/CHANGELOG):
«container - allow specifying registry using remote-image property»), y mikroscope necesita la
7.24.

Así que no ajustas nada en el router:

- `/container/config registry-url`, un único valor para todo el equipo, no decide esta descarga.
  `install`, `upgrade` y el script de RouterOS nunca lo escriben
  ([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-remote-image-host)).
- No hace falta iniciar sesión en ningún registro: la imagen publicada es pública en los dos
  ([probado](https://jmrplens.github.io/mikroscope/es/about/status/#install-routes-tested)).
- `doctor`, y `upgrade` antes de retirar nada, leen `registry-url` y si hay un usuario fijado, para
  un único aviso.

> **Un único usuario de registro para todo el equipo**
>
> `/container/config` guarda un único usuario y contraseña de registro para todos los contenedores
> del router, y un inicio de sesión pensado para un registro y enviado a otro puede terminar la
> descarga de una imagen pública en `auth error`. `doctor` avisa, como
> `WARN no registry credential meant for another registry`, cuando hay un usuario fijado y el equipo
> que nombra `registry-url` no es del que se descarga la imagen.
> [Solución de problemas](https://jmrplens.github.io/mikroscope/es/reference/troubleshooting/#una-credencial-para-todos-los-registros)
> tiene las tres salidas.

Para descargar a través de un espejo o de una caché de descargas, nombra su equipo en la
referencia: `--remote-image <mirror-host>/jmrplens/mikroscope-agent:1.6.1`.
mikroscope la envía tal cual, y `upgrade` imprime una `note` cuando `registry-url` nombra un equipo
distinto del de la descarga.

Docker Hub permite a un cliente anónimo 100 descargas cada 6 horas por dirección IPv4 o `/64` de IPv6
([límites de descarga de Docker Hub](https://docs.docker.com/docker-hub/usage/pulls/)). Docker cuenta
una imagen multiarquitectura como una descarga por arquitectura descargada, y un router solo
descarga la suya. El límite es por dirección pública, así que los routers detrás de un mismo NAT lo
comparten, algo que importa cuando una flota se instala a la vez.

Un script de RouterOS con la misma instalación, para un router al que llegas sin ssh, está en
[Script de RouterOS](https://jmrplens.github.io/mikroscope/es/install/script/).

## Desde el código fuente

```sh
git clone https://github.com/jmrplens/mikroscope
cd mikroscope
make build
bin/mikroscope install --router admin@192.168.88.1
```

`plan`, `install`, `upgrade` e `image` compilan el agente por su cuenta cuando no reciben ni
`--remote-image` ni `--agent-tar`: `go build ./cmd/mikroscope-agent` para `linux/<arch>` con
`CGO_ENABLED=0`, empaquetado en un tar de imagen sin Docker. `install` y `upgrade` compilan para la
arquitectura que leen del router; `plan` e `image` no se conectan a nada y compilan `arm64` salvo
que `--arch` diga otra cosa. La ruta de compilación es relativa, así que ejecuta la CLI desde la
copia del repositorio. Es la única ruta que instala un agente compilado desde tu propio árbol.

`make build` deja la CLI en `bin/mikroscope`. Sin Go en el `PATH`, el verbo se detiene antes de
escribir nada y nombra las otras dos rutas y la versión de Go que necesita.

El tar de imagen publicado, cuál usa cada placa y cómo verificar la descarga están en
[Instalación sin conexión](https://jmrplens.github.io/mikroscope/es/install/offline/).

## Véase también

- [Requisitos](https://jmrplens.github.io/mikroscope/es/install/prerequisites/): lo que necesita en el router cada método.
- [Instalar con la CLI](https://jmrplens.github.io/mikroscope/es/install/): lo que hace `install` una vez decidido de dónde
  sale la imagen.
- [Actualizar y desinstalar](https://jmrplens.github.io/mikroscope/es/install/upgrade/): actualizar y retirar una instalación,
  hecha con cualquier método.
- [Almacenamiento y ajustes del contenedor](https://jmrplens.github.io/mikroscope/es/install/layout/): el disco que usan el tar y la raíz.

---

# Requisitos

Lo que necesita el router antes de instalar — RouterOS 7.24 o posterior, una arquitectura con contenedores, el paquete container y device-mode —, lo que necesita tu ordenador y cómo comprueba doctor cada cosa.

Source: https://jmrplens.github.io/mikroscope/es/install/prerequisites/

Tres cosas del router tienen que estar listas antes de que `install` pueda escribir nada, y la
herramienta no puede hacerlas por ti. `mikroscope doctor` comprueba cada requisito en modo de solo
lectura, en una conexión ssh, e imprime la orden o el paso físico que arregla cada uno que falte.

| Requisito           | Valor                                                  | `doctor` imprime                          |
| ------------------- | ------------------------------------------------------ | ----------------------------------------- |
| RouterOS            | 7.24 o posterior                                       | `RouterOS 7.24 or later`                  |
| Arquitectura        | `arm64`, `arm` o `x86_64`                              | `architecture has a container package`    |
| Paquete `container` | instalado y habilitado                                 | `container package installed and enabled` |
| Device mode         | `container=yes`                                        | `device-mode container=yes`               |
| Memoria libre       | al menos `--memory-max`, 64 MiB por defecto            | `free memory ≥ <size>`                    |
| Almacenamiento      | la raíz extraída, y el tar en la ruta del tar          | `free flash ≥ <size> (…)`                 |
| Lista de interfaces | la que nombra `--iface-list`, `LAN` por defecto        | `interface list <list> exists`            |
| ssh                 | un usuario administrador, con una clave o un agente ssh | ninguna; la propia conexión               |

> **Un paso necesita tus manos en el router**
>
> [`device-mode container=yes`](https://help.mikrotik.com/docs/spaces/ROS/pages/93749258/Device-mode)
> no se puede fijar en remoto. Tras la orden, RouterOS espera cinco minutos a que alguien pulse el
> botón reset o mode, o corte la alimentación. Ninguna sesión ssh, llamada a la API ni opción de
> esta herramienta puede dar ese paso. Prevé estar junto al router.

## Router

El router tiene que ejecutar RouterOS 7.24 o posterior en arm64, arm (RouterOS de 32 bits) o
x86_64. Los routers MIPS, TILE y PPC no tienen paquete `container`.

7.24 es el mínimo porque el paso del contenedor escribe `privileged=`, un atributo que RouterOS
[añadió en esa versión](https://download.mikrotik.com/routeros/7.24/CHANGELOG) («container - added
ability to run containers in privileged mode»). `--privileged=false` cambia el valor escrito, no si
se escribe. `doctor` marca una versión anterior como `MISSING`, y el script de instalación se
detiene ahí sin escribir nada. [Modo privilegiado](https://jmrplens.github.io/mikroscope/es/limits/privileged/) tiene lo que
cambia el atributo.

`install` lee la arquitectura del router (`--arch auto`, el valor por defecto), y cada ruta toma la
compilación del agente que le corresponde:

| Tu equipo                                           | `architecture-name` | `--arch` | Compilación del agente |
| --------------------------------------------------- | ------------------- | -------- | ---------------------- |
| RB5009, CCR2004, hAP ax³ y otros ARM de 64 bits      | `arm64`             | `arm64`  | `linux/arm64`          |
| hEX Refresh / hEX S (2025), cualquier placa EN7562CT | `arm`               | `arm`    | `linux/arm/v5`         |
| Otros ARM de 32 bits (hAP ac², hAP ax², …)           | `arm`               | `arm`    | `linux/arm/v5` o `v7`  |
| CHR y RouterOS x86                                   | `x86_64`            | `amd64`  | `linux/amd64`          |

**El ARM de 32 bits no es una cosa, son dos.** La
[documentación de contenedores](https://help.mikrotik.com/docs/spaces/ROS/pages/84901929/Container)
de MikroTik dice que los equipos con CPU EN7562CT solo admiten imágenes de contenedor arm32v5,
mientras que sus demás placas ARM de 32 bits ejecutan un espacio de usuario ARMv7. Un binario ARMv5 funciona en las dos; uno ARMv7 no arranca en las primeras, y falla con un
`exec format error` en el registro del contenedor después de una instalación correcta. Por eso
`--goarm` vale **5** por defecto, el nivel que arranca en todas partes, y la imagen declara la
variante que le corresponde. `--goarm 7` compila la ARMv7 para una placa donde se quiera ese juego
de instrucciones.

Con `--remote-image` el router elige la compilación por su cuenta: el índice publicado lleva
`linux/amd64`, `linux/arm64`, `linux/arm/v7` y `linux/arm/v5`. En `arm` no se sabe cuál de las dos
de 32 bits descarga RouterOS, así que `doctor` avisa ahí; si el contenedor se detiene con
`Exec format error`, instala desde el tar ARMv5
([Instalación sin conexión](https://jmrplens.github.io/mikroscope/es/install/offline/)).

## Paquete container

Descarga el paquete `container` para tu arquitectura y tu versión de RouterOS desde mikrotik.com,
súbelo al router y reinicia. Si ya está y deshabilitado, ejecuta
`/system/package/enable container` y reinicia. `doctor` solo cuenta el paquete cuando está instalado
y no deshabilitado. Para leerlo en el router:

```routeros
/system/package/print where name="container"
```

## Device mode

1. Ejecuta, en el terminal del router:

   ```routeros
   /system/device-mode/update container=yes
   ```

2. RouterOS responde con el paso que espera. Un router dice:

   ```text
   update: please activate by turning power off or pressing reset or mode button in 5m00s
   ```

   CHR dice `update: turn off power in 5m to activate changes`.

3. En esos cinco minutos, pulsa el botón reset o mode, o corta la alimentación. En CHR, apaga y
   enciende la máquina virtual. Si nadie lo hace, el cambio se cancela.

Tras tres intentos fallidos el router dice `too many unsuccessful attempts … to reset
attempt-count` y necesita un ciclo de alimentación, o pulsar el botón reset o mode, antes de aceptar
otro. `/system/device-mode/print` muestra `container: yes` cuando está hecho.

## Comprobaciones previas

`doctor` imprime `device:` con la placa, la versión de RouterOS y la arquitectura, y después una
línea por comprobación marcada `ok`, `MISSING` o `WARN`, con lo que encontró entre paréntesis y, en
una que falta o en un aviso, una línea `fix:`. Termina con `doctor: every prerequisite is met`, o
falla con `N prerequisite(s) missing; nothing was written`. Un `WARN` es un consejo: nunca cambia
ese final, e `install` sigue adelante. `install` hace las mismas comprobaciones primero salvo que
pases `--no-doctor`.

Las comprobaciones que ejecuta doctor:

| Comprobación, tal como se imprime | Pasa cuando | La solución que nombra |
| --- | --- | --- |
| RouterOS 7.24 or later | `/system/resource` informa una `version` 7.24 o posterior, que se lee con número de parche o sin él y sea cual sea el canal, como en `7.24 (stable)` o `7.25rc1 (testing)` | actualiza RouterOS a 7.24 o posterior (`/system/package/update`), y el paquete `container` con él |
| architecture has a container package | el `architecture-name` del router es `arm`, `arm64` o `x86_64`, las arquitecturas para las que MikroTik publica un paquete `container` | ninguno: en este router no puede ejecutarse ningún agente |
| the router picks the image's architecture | con `--remote-image`: siempre, con la arquitectura del router, porque RouterOS la elige del índice multiarquitectura de la imagen. Un aviso en `arm`, donde el índice tiene `linux/arm/v5` y `linux/arm/v7` y no se sabe cuál descarga RouterOS | en `arm`, si el contenedor se detiene con `Exec format error`, instala desde `mikroscope-agent-armv5.tar` con `--agent-tar` |
| architecture matches the --agent-tar image | con `--agent-tar`: la arquitectura del propio tar es la del router (`amd64` para `x86_64`); `--arch` no hace falta | descarga el recurso de la versión que nombra, `mikroscope-agent-<arch>.tar` |
| architecture read from the router | sin ninguna de las dos opciones de imagen y con `--arch` sin fijar (o `auto`): siempre; `install` y `upgrade` construyen o cargan la imagen de la arquitectura que leyó doctor | ninguno |
| architecture matches --arch <arch> | con un `--arch` explícito y sin opciones de imagen: el `architecture-name` del router es el que corresponde a `--arch` (`arm64`, `arm`, `x86_64`) | vuelve a ejecutar con el `--arch` que nombra, o quita `--arch` para que `install` la lea del router |
| container package installed and enabled | existe un paquete `container` con `disabled=no` | descarga el paquete `container` de esta arquitectura y versión de RouterOS, súbelo y reinicia; si ya está y deshabilitado, `/system/package/enable container` y reinicia |
| device-mode container=yes | `/system/device-mode` informa `container=yes` | `/system/device-mode/update container=yes` y confírmalo como pide la consola: en un router que dice `update: please activate by turning power off or pressing reset or mode button`, pulsa el botón reset o mode o corta la alimentación; en CHR, que dice `update: turn off power in 5m to activate changes`, apaga y enciende la VM en menos de 5 minutos |
| free memory ≥ <--memory-max> | `free-memory` es al menos lo que pide `--memory-max`, 64 MiB por defecto | libera memoria en el router, o pide menos con `--memory-max` |
| free memory leaves room for the pull | un aviso, solo con `--remote-image`: `free-memory` es al menos `--memory-max` más 16 MiB, margen para que RouterOS descargue y extraiga la imagen antes de que arranque el agente. No se ha medido cuánto ocupa una descarga, así que el margen es una estimación | instala desde un tar con `--agent-tar` si la descarga falla |
| free flash ≥ <size> (image tar + extracted root) | sin `--disk` ni `--ephemeral`: `free-hdd-space` es al menos el doble de la imagen más 4 MiB. Con `--remote-image` no se sube nada y el nombre acaba en `(extracted root)`: la raíz en la que se extrae la imagen descargada, 7 MiB, más 4 MiB | libera flash, o instala con `--disk tmpfs` o `--ephemeral` donde exista un disco tmpfs |
| disk <disk> exists | con `--disk` o `--ephemeral`: existe un disco con ese slot | `/disk/add type=tmpfs tmpfs-max-size=64M slot=tmpfs` para un disco en RAM, o nombra un disco existente con `--disk` |
| disk <disk> has ≥ <size> free (image tar + extracted root) | con `--disk` o `--ephemeral`, cuando el disco existe: su espacio libre es al menos el doble de la imagen más 4 MiB; con `--remote-image`, la raíz de 7 MiB más 4 MiB, como en la comprobación de la flash | libera espacio en ese disco, o da a un disco tmpfs un `tmpfs-max-size` mayor |
| disk tmpfs is RAM | con `--ephemeral`: el disco del slot `tmpfs` es de tipo `tmpfs` | libera el slot para un disco tmpfs, o instala con `--disk <slot>` sin `--ephemeral` |
| start-on-boot suits a root in RAM | un aviso, cuando el disco es tmpfs: start-on-boot queda en `no`, porque un reinicio vacía el disco y un contenedor que arranca con el equipo no tiene raíz | pasa `--start-on-boot no`, o `--ephemeral` |
| veth name <veth> is free or ours | ninguna veth tiene ese nombre, o la que lo tiene lleva la etiqueta de esta instalación | elige otra `--veth` (y otra `--subnet`), o borra la veth a mano si es un resto tuyo |
| envlist <name>-env is free or ours | ninguna envlist tiene ese nombre, o la que lo tiene contiene la entrada `MIKROSCOPE_TAG` de esta instalación | elige otro `--name` |
| install manifest <disk/>mikroscope/<name>.manifest.txt is free or ours | no hay ningún fichero en la ruta del manifiesto de instalación, o el que hay contiene la línea `tag=` de esta instalación | mueve el fichero a otro sitio, o elige otro `--name` |
| container name <name> is free or ours | con `--container-name`: ningún contenedor tiene ese nombre, o el que lo tiene lleva la etiqueta de esta instalación | elige otro `--container-name` |
| subnet <subnet> does not overlap a route | ninguna ruta de la tabla main, activa o no, cae dentro de la /30, y ninguna red conectada de otra interfaz contiene su extremo del router. Las rutas que solo contienen la /30 (una ruta por defecto, un prefijo más amplio hacia una VPN), las rutas blackhole y la propia veth de la instalación no cuentan | elige otra /30 con `--subnet` |
| interface list <list> exists | existe la lista `--iface-list` (por defecto `LAN`). Con `--iface-list none` doctor imprime `interface list the veth joins` y lo da por bueno: no se escribe ninguna pertenencia | `--iface-list none` si ninguna regla del cortafuegos necesita la veth en una lista (doctor lo ofrece primero en ese caso); si no, `/interface/list/add name=…`, o pasa la lista que usa tu regla de descarte `in-interface-list=!…` |
| address list <list> | siempre: install añade la /30 a la lista `--addr-list` (por defecto `LANs`), lo que la crea si falta, y uninstall retira la entrada. Con `--addr-list none` doctor imprime `address list the /30 joins`. Si alguna regla necesita esa pertenencia lo responde la fila siguiente | ninguno |
| no firewall rule drops the agent's replies | doctor lee todas las reglas activas de las cadenas por las que pasan las respuestas del agente, `/ip/firewall/raw` prerouting y `/ip/firewall/filter` forward e input, y recorre cada una como RouterOS, gana la primera que coincide, con las respuestas en las listas a las que se une el plan: ninguna regla las descarta. Un aviso cuando una regla podría hacerlo, porque filtra por algo que doctor no evalúa (un destino, una marca, un límite de tasa), y cuando las respuestas a un equipo de la LAN pasan pero una regla podría descartar las que van al propio router (filter input), que necesita el transporte por relay | las `--iface-list` y `--addr-list` que dejan pasar las respuestas; cuando ninguna lista lo consigue (una regla `src-address=!<rango>`, por ejemplo), añade antes de esa regla una de aceptación para `in-interface=<veth>`, o elige una `--subnet` dentro del rango |
| no firewall rule doctor reads is invalid or names a deleted list | un aviso: ninguna regla de raw prerouting ni de filter forward e input está marcada como inválida, que RouterOS salta como si no existiera (nombra una interfaz que se quitó o no está lista, y `about` dice cuál), y ninguna nombra una lista de interfaces que se quitó, que RouterOS guarda como el id de la lista (`in-interface-list=!*2000010`) y aplica como una lista vacía. Una regla cambiada un momento antes se lee inválida, sin motivo, hasta que RouterOS la aplica | corrige o quita lo que nombra una regla inválida; vuelve a poner por nombre una lista borrada, porque crear una lista con el mismo nombre no repara la regla. Sin motivo, ejecuta `doctor` otra vez |
| --lan-address <address> is the router's | con `--expose`: una interfaz del router tiene esa dirección | pasa la dirección que el router tiene en su LAN, tal como la lista `/ip/address/print` |
| --lan-address is not on the uplink | un aviso, con `--expose`: la interfaz que tiene la dirección no lleva la ruta por defecto, no está en ninguna lista `WAN` y no comparte ninguna lista de interfaces con la interfaz que lleva la ruta por defecto | pasa la dirección LAN del router: en el enlace de subida el dst-nat publicaría el agente hacia Internet |
| no registry credential meant for another registry | un aviso, solo con `--remote-image`: no hay usuario en `/container/config`, o el host de `registry-url` es el host del que se descarga la imagen, contando todas las grafías de Docker Hub como una. Un `registry-url` vacío con usuario puesto avisa. Doctor lee si hay usuario, nunca el nombre, y no puede leer la contraseña | `/container/config` guarda un solo usuario para todo el equipo, y una credencial de otro registro puede hacer que la descarga de una imagen pública acabe en `auth error`. Instala desde un tar con `--agent-tar`, pasa un `--remote-image` del registro al que pertenece el usuario, o borra el usuario si nada más lo necesita |
| the installed agent published on the LAN asks for a token | un aviso, que solo aparece cuando una instalación con este `--name` tiene un dst-nat en la LAN: su entorno contiene un `TOKEN`. Doctor cuenta las entradas, nunca lee el valor | `upgrade` con el mismo `--name` y `--token <secreto>`; o retira el agente, las reglas de LAN y el contenedor juntos con `uninstall --name <nombre> --yes` |
| the router does not answer DNS from its uplink | un aviso: `allow-remote-requests` de `/ip/dns` está apagado, o una regla de raw prerouting o de filter input descarta una consulta UDP al puerto 53 que entra por la interfaz de la ruta por defecto activa, recorrida como en la comprobación de trampas, gana la primera que coincide. Un aviso de que las consultas podrían pasar cuando una regla filtra por algo que doctor no evalúa, una lista de direcciones de origen por ejemplo. IPv6 no se lee | una regla de descarte para el puerto 53 UDP y TCP en el enlace de subida antes de cualquier aceptación que lo coja, o `/ip/dns/set allow-remote-requests=no` si ningún equipo de la LAN usa el router como resolvedor |
| nothing tagged for <name> that these flags do not select | un aviso: en cada menú donde escribe una instalación, los objetos con su etiqueta no son más que los que selecciona el plan de estas opciones. Una instalación hecha con otras opciones (`--expose`, otras listas, otra `--subnet`) deja más | ejecuta `status` y `uninstall` sin opciones de forma, para que lean el manifiesto de la instalación, o con las opciones con que se hizo |

- **Almacenamiento.** Dentro de `install`, la comprobación usa el tamaño real del tar: el doble de
  la imagen, porque el tar y la raíz extraída de él comparten el disco hasta que se borra el tar,
  más 4 MiB. `doctor` por sí solo supone una imagen de 7 MiB. Con `--remote-image` no se sube nada,
  y la comprobación pide la raíz extraída más 4 MiB.
- **Registro.** `--remote-image` le pasa a RouterOS la referencia entera, con el equipo del registro
  incluido, así que el `/container/config registry-url` de todo el equipo no decide de dónde sale la
  descarga, y mikroscope ni lo necesita fijado ni lo escribe. `doctor` lo lee solo para el aviso de
  credenciales de arriba:
  [Solución de problemas](https://jmrplens.github.io/mikroscope/es/reference/troubleshooting/#una-credencial-para-todos-los-registros).
- **Firewall.** La comprobación de la lista de interfaces y la del firewall existen por las reglas
  raw que descartan cada paquete que envía un contenedor:
  [Listas del firewall](https://jmrplens.github.io/mikroscope/es/install/firewall/).

## Comprobaciones de salud

`doctor` por sí solo, no el que va dentro de `install`, pregunta después al agente que ya está en
marcha qué tiene su anillo, en una sección `health` tras las comprobaciones. Lee el anillo una vez,
directamente desde esta máquina, en la dirección que dan `--subnet` y `--port`, la que sondea
`status`; pasa `--token` (o `MIKROSCOPE_TOKEN`) si el agente tiene token. Nunca pasa por el relé ni
por la dirección de `--expose`, y nunca cambia el código de salida. Se salta la sección, diciendo por
qué, en dos casos:

```text
health (what the running agent's ring shows now):
  skipped: no agent answered at 172.30.10.2:9123 from this host (…)
```

cuando nada responde a `/healthz` en 3 s, y
`skipped: the agent answered /healthz but its ring could not be read (…)` cuando `/healthz` responde
pero el anillo no, como con un agente con token leído sin `--token`.

Cuando lee el anillo, imprime cuánto leyó y, o bien una línea limpia, o bien un `WARN` por hallazgo,
cada uno con su `fix:`, sangrados bajo `health`:

```text
health (what the running agent's ring shows now):
  read 600 samples covering 60 s
  ok    no loop signature, STP churn, link flap or softnet drop in the window
```

```text
  WARN  layer2-loop: 30 frames this router sent came back in on ether2 in the last 60 s, carrying the bridge's own address as their source
        fix: something downstream of ether2 reaches the router by a second path. …
```

El anillo es de 60 s por defecto, así que esto ve lo que pasa ahora; los dashboards y las reglas de
alerta leen el historial. Pide al agente como mucho 10 000 muestras, todas en los mismos 3 s: el
anillo entero cuando no tiene más, y si no las 10 000 más recientes (los últimos 1 000 s a 10 Hz, los
últimos 100 s a 100 Hz). Cada hallazgo es una cuenta de sucesos que un router sano no produce, no un
umbral:

| Hallazgo        | Salta con                                                                                                                  |
| --------------- | -------------------------------------------------------------------------------------------------------------------------- |
| `layer2-loop`   | tres o más tramas en la ventana que volvieron a entrar por un puerto con la propia dirección del bridge como origen         |
| `stp-churn`     | un puerto que STP pasó a learning al menos tres veces más de las que lo dejó reenviar, sin la firma del bucle              |
| `link-flap`     | dos o más caídas de enlace en un puerto en cualquier punto de las muestras leídas                                          |
| `softnet-drops` | cualquier paquete que el kernel descartó de su cola softnet                                                                |

- **`layer2-loop`.** Un bucle repite la firma al intervalo de hello de STP, 2 s por el
  [valor por defecto de RouterOS](https://help.mikrotik.com/docs/spaces/ROS/pages/21725254/Spanning+Tree+Protocol#SpanningTreeProtocol-Defaultvalues),
  treinta veces en un anillo de 60 s, mientras los contadores de RouterOS pueden mostrar el puerto
  sano y STP lo mantiene bloqueado ([Bucle de capa 2](https://jmrplens.github.io/mikroscope/es/playbooks/loop/)).
- **`stp-churn`.** No cuenta bloqueos: un enlace sano que sube registra tres pasos a learning de
  golpe y llega a forwarding unos segundos después, y deja learning menos forwarding en 0.
- **`link-flap`.** La detección `link-flap` del propio colector cuenta de otra forma: subidas y
  caídas de enlace juntas, dos o más en un puerto en 60 s. Un cable que se desenchufa y se vuelve a
  enchufar una vez es una oscilación allí y no aquí.
- **`softnet-drops`.** Un paquete perdido dentro del router, donde ningún contador de interfaz lo
  ve. Los squeezes no cuentan: un squeeze es el kernel conteniéndose.

Cada hallazgo nombra el puerto de RouterOS en una placa que conoce el mapa de puertos, y el nombre
del kernel en las demás. Los registros del log del kernel se clasifican otra vez a partir de su
texto, así que un agente más antiguo se lee igual. Lo que se ha ejecutado contra un agente en marcha
está en [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/#qué-funciona-de-extremo-a-extremo).

## Tu ordenador

| Necesidad              | Para                                                    | Detalle                                                                                 |
| ---------------------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| ssh al router          | `doctor`, `install`, `status`, `upgrade`, `uninstall`    | un usuario administrador, con una clave o un agente ssh                                 |
| `scp`                  | las rutas del tar y del código fuente                   | la subida de la imagen                                                                  |
| una imagen del agente  | `install`, `upgrade`                                    | una descarga del registro, el tar de la versión o una compilación desde el código con Go 1.27 |
| una ruta hasta el agente | `record`, `forward`, el sondeo                        | una ruta a la /30 a través del router, el relé de la API o `--expose`                   |
| un usuario de la API de RouterOS | el relé, `--log-markers`, la capa de la API del colector | de solo lectura; se queda en tu máquina                                  |

- **ssh.** La CLI ejecuta el `ssh` del sistema con `BatchMode=yes` y `ConnectTimeout=15`, así que no
  puede responder a una petición de contraseña ni de clave de host: usa una clave o un agente ssh, y
  para un router nuevo añade `--ssh-option StrictHostKeyChecking=accept-new`. `--router` acepta
  `usuario@equipo` o un alias de la configuración de ssh; `--ssh-port` y `--ssh-key` recurren a tu
  configuración de ssh si no se fijan.
- **Sin ssh.** El [Script de RouterOS](https://jmrplens.github.io/mikroscope/es/install/script/), el
  [Generador de scripts](https://jmrplens.github.io/mikroscope/es/install/generator/) y las instalaciones manuales se ejecutan
  en el propio router: [Métodos de instalación](https://jmrplens.github.io/mikroscope/es/install/routes/).
- **El agente.** [Acceso por red](https://jmrplens.github.io/mikroscope/es/install/reaching-the-agent/) tiene las tres formas
  de llegar a él, y [Usuario de la API](https://jmrplens.github.io/mikroscope/es/security/api-user/) la política del usuario.

Lo que no se ha probado, como una placa de otra arquitectura o un RouterOS anterior a 7.24, está
en [No probado](https://jmrplens.github.io/mikroscope/es/about/status/#not-tested).

## Véase también

- [Instalar con la CLI](https://jmrplens.github.io/mikroscope/es/install/): lo que hace `install` cuando esto está listo.
- [Métodos de instalación](https://jmrplens.github.io/mikroscope/es/install/routes/): las rutas por las que la imagen del
  agente llega al router.
- [Listas del firewall](https://jmrplens.github.io/mikroscope/es/install/firewall/): por qué existen las comprobaciones de
  lista y de firewall.
- [Almacenamiento y ajustes del contenedor](https://jmrplens.github.io/mikroscope/es/install/layout/): el disco del que habla la
  comprobación de almacenamiento, y `--ephemeral`.

---

# Cómo funciona

El agente en un contenedor de RouterOS, la veth en la que responde, el colector en tu máquina y los destinos en los que escribe, y lo que el diseño no puede hacer.

Source: https://jmrplens.github.io/mikroscope/es/how-it-works/

mikroscope son dos programas. Un agente se ejecuta en un contenedor del router y muestrea el kernel
que comparte con RouterOS; una CLI en tu máquina lo instala, graba de él y ejecuta el colector que
escribe en tus almacenes.

## Componentes

- **`mikroscope-agent`** es un binario estático de Go en un
  [contenedor scratch](https://jmrplens.github.io/mikroscope/es/reference/glossary/#contenedor-scratch). Muestrea con un
  temporizador fijo de 1 a 100 Hz, 10 Hz por defecto, guarda los últimos 60 s en un
  [anillo](https://jmrplens.github.io/mikroscope/es/reference/glossary/#anillo) y los sirve por HTTP en la dirección de su
  [veth](https://jmrplens.github.io/mikroscope/es/reference/glossary/#veth). No abre ninguna conexión saliente y guarda como
  mucho un secreto: el token que exige a quien lo lea, que vive en la
  [envlist](https://jmrplens.github.io/mikroscope/es/reference/glossary/#envlist) del contenedor.
- **`mikroscope`**, la CLI, se ejecuta en tu máquina. Instala, actualiza y retira el agente por
  ssh; graba una ventana con marcas y la dibuja como SVG; y ejecuta `forward`, el colector.
- **Los objetos del propio router**: una veth con una /30, la dirección del router en ella, dos
  pertenencias a listas, una envlist, el contenedor y un manifiesto de instalación que los enumera.
  Todos llevan la etiqueta `mikroscope:<name> (managed by mikroscope)`, y `uninstall` los retira
  todos.

Cada versión publica la CLI como un archivo por plataforma (Linux y FreeBSD en amd64, arm64 y arm;
macOS y Windows en amd64 y arm64), y el agente como un tar de imagen por arquitectura y como imagen
de registro, `jmrplens/mikroscope-agent` en Docker Hub y `ghcr.io/jmrplens/mikroscope-agent` en
GHCR. El colector también es una imagen, `jmrplens/mikroscope` y `ghcr.io/jmrplens/mikroscope`
(linux/amd64, linux/arm64), y [`deploy/`](https://github.com/jmrplens/mikroscope/tree/main/deploy) tiene dos pilas de compose que la combinan
con InfluxDB 3 o Prometheus y Grafana. La orden por defecto de esa imagen es `forward`, y
`dashboards` también funciona en ella; las órdenes de instalación necesitan ssh y scp, que deja
fuera. Los dos programas tienen licencia MIT, en el
fichero [`LICENSE`](https://github.com/jmrplens/mikroscope/blob/main/LICENSE).

## Ruta de los datos

_De dónde vienen los datos y a dónde van_ — El router ejecuta el agente en un contenedor que lee el kernel compartido y lo sirve por un veth. El colector de tu máquina tira de ahí, le une la capa de la API de RouterOS, deriva y escribe en cada destino que hayas nombrado.

1. El agente lee el kernel en cada tick y añade una muestra a su anillo.
2. `forward`, o `record`, trae las muestras nuevas del agente por HTTP: directamente a la dirección
   de la veth a través del router, por el relé de la API de RouterOS, o en la dirección LAN del
   router con `--expose` ([Acceso por red](https://jmrplens.github.io/mikroscope/es/install/reaching-the-agent/)).
3. El colector pregunta a la API de RouterOS, una vez por segundo, lo que el kernel no le enseña al
   contenedor, y marca las dos capas con el reloj del agente.
4. Deriva proporciones, tasas y detecciones de las muestras fusionadas y las escribe en cada
   destino que indiques ([Ejecutar el colector](https://jmrplens.github.io/mikroscope/es/sinks/)).

ssh nunca está en esta ruta. La CLI lo usa para instalar y comprobar, y agrupa cada lectura en una
sola conexión, porque cada conexión le cuesta CPU al router mientras dura
([Coste de SSH](https://jmrplens.github.io/mikroscope/es/cost/#ssh-cost)).

## Lo que lee el agente

Un contenedor de RouterOS comparte el kernel del router, así que su `/proc` es el del propio router:

- `/proc/stat` por núcleo, `/proc/interrupts`, `/proc/softirqs` y
  [`/proc/net/softnet_stat`](https://jmrplens.github.io/mikroscope/es/reference/glossary/#softnet);
- `/proc/meminfo`, `/proc/vmstat`, `/proc/diskstats` y `/proc/loadavg`;
- con el contenedor en modo privilegiado: `/dev/kmsg`, el log del kernel; `/proc/slabinfo`, que
  contiene el número real de conexiones del router; los contadores ECC de la flash; y los contadores
  [PMU](https://jmrplens.github.io/mikroscope/es/reference/glossary/#pmu) de la CPU, de todo el sistema, mediante
  `perf_event_open`.

El contenedor es privilegiado por defecto; [Modo privilegiado](https://jmrplens.github.io/mikroscope/es/limits/privileged/)
enumera lo que da cada opción. El agente envía deltas de contadores en bruto, el tiempo de CPU en
ticks, nunca un porcentaje, así que quien lee elige la ventana. Al arrancar informa de qué fuentes
tiene este kernel, y una fuente que el kernel no tiene falta en la salida en lugar de valer cero.
[Métricas de Prometheus](https://jmrplens.github.io/mikroscope/es/reference/metrics/) enumera cada serie.

## Lo que añade el colector

- **La capa de la API de RouterOS**: contadores de tráfico y de errores por interfaz, `cpu-load`
  por núcleo, `/system/health`, y qué es cada interfaz (su comentario, tipo, listas, bridge y MTU).
  El contenedor no puede leerlos: su espacio de nombres de red es propio.
  [Capa de la API de RouterOS](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/) tiene los modos.
- **Un solo reloj**: cada registro se marca con el reloj del agente, así que las muestras del
  kernel y de la API coinciden.
- **Valores derivados**: proporciones de ocupación, tasas y cuotas, calculadas de los deltas en
  bruto ([Valores derivados](https://jmrplens.github.io/mikroscope/es/sinks/derive/)).
- **Detecciones**: un bucle de capa 2, un enlace que oscila, una microrráfaga y las demás reglas,
  cada una escrita como un evento ([Reglas de detección](https://jmrplens.github.io/mikroscope/es/sinks/detections/)).
- **Destinos**: fichero, Prometheus, InfluxDB 3, Loki, OTLP, Graphite, Elasticsearch y OpenSearch,
  SQL, PostgreSQL, Telegraf y la salida estándar.

## Limitaciones

- **RouterOS 7.24 o posterior, con contenedor.** El agente necesita el paquete `container` y
  `device-mode container=yes`, que exige pulsar un botón o cortar la alimentación junto al router.
  Los routers MIPS, TILE y PPC no tienen paquete `container`.
- **La resolución es la del kernel, no la de la herramienta.** `/proc/stat` cuenta el tiempo de CPU
  en [ticks de `USER_HZ`](https://docs.kernel.org/filesystems/proc.html#miscellaneous-kernel-statistics-in-proc-stat),
  100 por segundo, así que una ventana de 100 ms resuelve un núcleo en pasos
  de 10 % ([Límites de resolución](https://jmrplens.github.io/mikroscope/es/limits/)).
- **PSI y schedstat solo donde el kernel los tiene.** El agente lee los dos cuando existen; un
  kernel de RouterOS puede estar compilado sin ellos.
- **La red del contenedor es la suya.** `/proc/net/dev`, `/proc/net/snmp` y `nf_conntrack_count`
  describen el contenedor, no el router; el número de conexiones del slab, en modo privilegiado, es
  la excepción. Los contadores de interfaz vienen de la API de RouterOS y se fusionan, nunca se
  estiman ([Visibilidad del contenedor](https://jmrplens.github.io/mikroscope/es/limits/namespaces/)).
- **Se suma a la API de RouterOS y no la sustituye.** Sin usuario de la API la capa del kernel
  sigue funcionando, y los paneles de interfaces se quedan vacíos.
- **El agente no da porcentajes.** Nunca calcula uno, así que nunca decide qué significa un
  porcentaje; los derivan el colector y los dashboards.
- **El observador tiene un coste.** A 10 Hz el agente consume 2,69 % de un
  núcleo; [Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/) tiene la tabla y cómo medirlo en tu router.

## Véase también

- [Instalación rápida](https://jmrplens.github.io/mikroscope/es/start/): las cuatro órdenes que ponen el agente en un router.
- [Modelo de seguridad](https://jmrplens.github.io/mikroscope/es/security/): qué se ejecuta dónde, y qué credenciales se
  quedan en tu máquina.
- [Límites de resolución](https://jmrplens.github.io/mikroscope/es/limits/): ticks, contadores PMU y cuánto recuerda el
  anillo.
- [Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/): lo que leen SNMP, mktxp y The Dude
  en su lugar.

---

# Límites de resolución

El tick de 10 ms del kernel como suelo de toda lectura de CPU en un router MikroTik, los contadores de la PMU que leen por debajo de él y hasta dónde llega el anillo del agente.

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

Cada número de CPU que produce mikroscope se cuenta en ticks del kernel, así que el cambio más
pequeño que puede mostrar lo pone el kernel, no el agente. Una fuente lee por debajo del tick, los
contadores de la propia CPU, y el anillo del agente fija hasta dónde llega cualquier lectura hacia
atrás.

## Resolución del tick

Un tick dura 10 ms. [`/proc/stat`](https://man7.org/linux/man-pages/man5/proc_stat.5.html) no cuenta tiempo, cuenta ticks de
`USER_HZ`, 100 por segundo. Una muestra de 100 ms puede contener por tanto 10 ticks por núcleo, así que la
fracción de ocupación de un núcleo se resuelve en escalones del 10 %,
y la media de cuatro núcleos en escalones del 2,5 %. Sobre 1 s, la resolución de un núcleo es del 1 %.

Eso es aritmética del tick, no una propiedad del agente, y ninguna cadencia ni ajuste lo cambia.
El agente envía los ticks en bruto y el intervalo real de cada muestra (`dt_ns`), nunca un
porcentaje, de modo que la ventana sobre la que divides la eliges tú.

La contabilidad de ticks también está cuantizada en los bordes: un intervalo de 100,3 ms puede
llevar 11 ticks, lo que daría una fracción de ocupación por encima de 1. La fracción de ocupación
derivada está limitada a 1; los ticks en sí siguen en bruto.

Muestrear más rápido no afina esto. A 100 Hz una muestra contiene 0 o 1 tick ocupado, así que la
fracción de ocupación por muestra tiene dos valores posibles; por encima de unos 20 Hz los
contadores de ticks son un indicador de ocupación más que un porcentaje. Lo que sí compra una
cadencia mayor está en [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/).

## Contadores de la PMU

Una fuente lee por debajo del tick: la unidad de monitorización del rendimiento de la CPU (PMU),
a través de [`perf_event_open`](https://man7.org/linux/man-pages/man2/perf_event_open.2.html), que el agente recoge como la fuente `perf` cuando el contenedor
es privilegiado. Es la única fuente de mikroscope que no viene de un fichero.

Una muestra en la que `/proc/stat` no marca ningún tick ocupado en ningún núcleo puede contener aun
así millones de ciclos e instrucciones ejecutadas ([medido](https://jmrplens.github.io/mikroscope/es/about/status/#reference-hardware)).
El tick redondea ese trabajo hasta hacerlo desaparecer; el contador no.

El número que merece la pena vigilar es el de instrucciones por ciclo (IPC), y el agente no lo
calcula: envía las cuentas en bruto y la división la haces tú. El IPC distingue un núcleo que
trabaja de un núcleo parado esperando a la memoria, algo que ningún contador de ticks puede
expresar. Compáralo núcleo a núcleo: el IPC en reposo de dos núcleos de una misma placa puede
diferir en más del doble ([medido](https://jmrplens.github.io/mikroscope/es/about/status/#reference-hardware)).

- El agente pide siete contadores: `cycles`, `instructions`, `cache-references`,
  `cache-misses`, `branch-instructions`, `branch-misses` y `bus-cycles`.
- Cuáles se abren depende de la CPU. Un contador que no se puede abrir está ausente, nunca a
  cero, así que lee la etiqueta `counter` de `mikroscope_perf_events_total{counter,cpu}` en vez
  de dar por hecho un conjunto ([CPU sin probar](https://jmrplens.github.io/mikroscope/es/about/status/#not-tested)).
- Los eventos genéricos `stalled-frontend` y `stalled-backend` no se piden. Devuelven `ENOENT`
  donde se probaron y harían falta códigos de evento en bruto, propios de cada CPU.
- Cada cuenta lleva `enabled_ns` y `running_ns`. En una CPU que multiplexa sus contadores, la
  cuenta en bruto cubre solo la parte del intervalo en que funcionó el contador, no el intervalo.
- Sin `privileged=yes` falta la familia entera: los contadores se abren a nivel de sistema, y
  eso un contenedor sin privilegios no puede hacerlo. Consulta
  [Modo privilegiado](https://jmrplens.github.io/mikroscope/es/limits/privileged/).

El colector usa esos mismos dos contadores para una de sus detecciones, `ipc-collapse`: por
núcleo, una vez que hay al menos 20 s de historia, que las instrucciones por ciclo de un segundo caigan por debajo de la mitad de su mediana de los 60 s
anteriores mientras la tasa de ciclos está por encima de su propia mediana. Se describe junto
con las demás reglas en [Reglas de detección](https://jmrplens.github.io/mikroscope/es/sinks/detections/).

## PSI, schedstat y trazado

No esperes un reloj más fino de [PSI](https://docs.kernel.org/accounting/psi.html), cuyos totales de espera van en microsegundos, ni
de [`schedstat`](https://docs.kernel.org/scheduler/sched-stats.html), cuyos tiempos de ejecución y espera van en nanosegundos. El kernel de
RouterOS medido hasta ahora no tiene ni `/proc/pressure` ni `/proc/schedstat` ([medido](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-kernel-2026-09-11)).
El agente lee ambos donde el kernel los tiene ([aún no en un router](https://jmrplens.github.io/mikroscope/es/about/status/#not-tested)).

En un kernel cuya columna `irq` de `/proc/stat` se queda en 0, como en el medido, el tiempo de IRQ
hardware se cuenta dentro de `system`.

Tampoco hay un camino de trazado. El kernel medido no tiene ni eBPF, ni kprobes, ni ftrace, y el
router no tiene directorio de módulos del kernel, ni cabeceras, ni compilador con que añadirlos ([comprobado](https://jmrplens.github.io/mikroscope/es/about/status/#reference-hardware)).
Una función del kernel que falta no se puede añadir desde un contenedor.

El agente detecta al arrancar lo que tiene el kernel y lo publica en `/capabilities`: el mapa
`sources` dice qué fuentes lee realmente este despliegue. Los campos de una fuente ausente faltan
en cada muestra y en cada destino, nunca valen cero.

## Profundidad del anillo

El otro límite duro es la profundidad, no la resolución. El agente guarda sus muestras en un
anillo de `--buffer` segundos, 60 s por defecto y entre 10 y 3600 s permitidos, que contiene
cadencia × búfer muestras. Nada más antiguo existe en ningún sitio del router.

Esa profundidad es también toda la ventana de la sección `health` de `doctor`, que lee el anillo
una vez (el anillo entero cuando no guarda más de 10 000 muestras, y si no las 10 000 más
recientes, así que lo más corto entre `--buffer` y 10 000 / cadencia segundos) e imprime cuántos segundos cubrió. Un `doctor` limpio dice que no hubo bucle, churn de
STP, flap de enlace ni descartes de softnet en el último minuto con los valores por defecto, no
en todo el día; un fallo que ocurre una vez al día es cosa de los paneles y de las reglas de alerta.

Un corte del colector o del grabador más corto que el anillo se rellena al reconectar: pide
`since=<seq>` y recibe todas las muestras que se perdió. Un corte más largo que el anillo se
informa como un hueco de longitud conocida, nunca se tapa. El agente responde con una línea
`{"gap":{"from":…,"to":…}}` que nombra los números de secuencia perdidos, antes de las muestras
que aún conserva; `record` lo escribe como un marcador que dice `samples N..M lost`, y `forward`
lo cuenta en `mikroscope_collector_gaps_total` y se lo pasa a cada destino.

Un anillo más largo cuesta memoria en el agente, y el agente rechaza uno que no quepa. Al arrancar
cobra cada línea a 3 456 B: la clase de tamaño del asignador de la
que se sirve una línea con todas las fuentes activas (3 230 B), porque es
lo que paga el heap. Una placa con más núcleos o líneas de interrupción cuesta más por línea, y
una sin PMU, menos. El agente suma el presupuesto de la captura por disparo y sale con un error si
el total supera el `memory.max` del contenedor. Si el total es más de la mitad del límite blando
de memoria de Go, arranca pero registra un aviso, porque un heap tan justo mantiene al recolector
de basura trabajando sin parar. Cómo dimensionar ambos límites está en
[Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/).

## Véase también

- [Cadencias de las fuentes](https://jmrplens.github.io/mikroscope/es/limits/source-floors/): las fuentes que no se
  leen en cada tick, y el motivo con nombre de cada una.
- [Modo privilegiado](https://jmrplens.github.io/mikroscope/es/limits/privileged/): la PMU, el log del kernel y las
  cachés slab, y lo que el contenedor sigue sin ver.
- [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/): lo que compra muestrear más rápido
  cuando el tick ya ha dejado de ser un porcentaje.
- [Límites de la evidencia](https://jmrplens.github.io/mikroscope/es/cost/limits/): lo que `/metrics` puede y no puede
  recuperar de estas muestras.

---

# Probado en

Los equipos, las versiones de RouterOS, las fechas y las condiciones que hay detrás de cada medida y cada comprobación de la documentación de mikroscope, lo que se encontró y lo que no se ha probado.

Source: https://jmrplens.github.io/mikroscope/es/about/status/

Dónde se ejecutó, se midió o se comprobó cada parte de mikroscope: el equipo, la versión de
RouterOS, la fecha y las condiciones, lo que encontró cada ejecución y lo que no se ha probado. Las
guías dicen lo que hace la herramienta y enlazan aquí la prueba. Los veredictos de las funciones se
contrastaron con el código de la 1.2.0 y de la 1.2.2 el 2026-09-24, los apartados que vinieron de
las guías con el código de la 1.3.1 el 2026-09-26, y lo que esta página dice del código posterior a
la 1.3.1, que es el que publica la 1.4.0, con ese código el 2026-09-27, y sus apartados sobre la
publicación en Grafana, `uninstall` y las baterías de pruebas con el código de la 1.5.0 el mismo día;
la versión actual es la [1.6.1](https://github.com/jmrplens/mikroscope/releases/tag/v1.6.1).

## Hardware de referencia

Todas las cifras medidas en hardware de router que aparecen en esta documentación salen de un único
MikroTik RB5009UG+S+: arm64, 4 × 1,4 GHz Cortex-A72 (r0p1), 1 GiB de RAM, Linux 5.6.3. Es el router de
producción del mantenedor del proyecto, José Manuel Requena Plens, así que nada que necesite un
reinicio se hace en él fuera de una ventana de mantenimiento, y no se le provoca ninguna tormenta de
conntrack, que puede dejar sin acceso el camino por el que se está trabajando. No hay un segundo
equipo físico. El único otro RouterOS que usa el proyecto es el
[laboratorio virtual](https://jmrplens.github.io/mikroscope/es/about/status/#virtual-lab). Qué RouterOS tenía en cada momento está en
[Equipos y versiones](https://jmrplens.github.io/mikroscope/es/about/status/#un-equipo-dos-versiones-de-routeros).

### Kernel y PMU

- **Ficheros de contabilidad** (campaña [`kernel-2026-09-11`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-kernel-2026-09-11)):
  no hay `/proc/pressure` ni `/proc/schedstat`, y la columna `irq` de `/proc/stat` vale siempre 0,
  así que el tiempo de IRQ hardware se cuenta dentro de `system`. `USER_HZ` es 100, un tick de 10 ms.
- **Trazado**: un contenedor de descubrimiento privilegiado no encontró el 2026-09-12 ni eBPF, ni
  kprobes, ni ftrace: ni BTF, ni debugfs, ni tracefs, y los puntos de montaje no existen. Una nueva
  comprobación el 2026-09-14 encontró `/sys/fs/bpf` presente y vacío y `/proc/modules` con 238 módulos
  cargados, pero ni `/lib/modules`, ni cabeceras del kernel, ni compilador en el equipo.
- **PMU**, desde dentro de un contenedor privilegiado el 2026-09-12 (RouterOS 7.24.2): la prueba abrió
  `cycles`, `instructions`, `cache-misses`, `branch-misses` y `bus-cycles` a nivel de sistema en 4 de
  4 CPU. En los datos del propio agente de las 24 h que terminaron el 2026-09-12, seis de los siete
  contadores que pide informaron en 4 de 4 núcleos, `cache-references` entre ellos, y
  `branch-instructions` no produjo ninguna fila. Los eventos genéricos `stalled-frontend` y
  `stalled-backend` devuelven `ENOENT` en el A72.
- **El trabajo que el tick no ve**: en una muestra de 100,4 ms en la que `/proc/stat` no marcó ningún
  tick ocupado en ninguno de los cuatro núcleos, la PMU contó entre 2,2 y 4,6 millones de ciclos y
  entre 0,8 y 2,1 millones de instrucciones ejecutadas, con una tasa de fallos de caché del 3,8–5,7 %
  (registrado el 2026-09-12). Durante 2 s ese mismo día, las instrucciones por ciclo fueron de 0,381
  en cpu0 a 0,992 en cpu1.
- **Privilegios**: `perf_event_paranoid` vale 2 y no bloquea a un contenedor privilegiado, que conserva
  `CAP_SYS_ADMIN` efectiva frente al host (medido el 2026-09-12). Un contenedor sin privilegios ya
  tiene las 38 capacidades, y su root corresponde al uid 32768 del host, así que `/proc/slabinfo` y
  `/dev/kmsg` devuelven `EACCES` (RouterOS 7.24.2; la fecha de estas dos lecturas no consta). Con
  `privileged=yes`, el log del kernel, `/proc/slabinfo`, los contadores ECC de la MTD y la PMU se
  encontraron legibles el 2026-09-12 (RouterOS 7.24.2, kernel 5.6.3).

### Sensores y relojes

- `/sys/class/hwmon` está vacío, incluso con privilegios. Las dos zonas térmicas, `cpu-thermal` y
  `soc-thermal`, son todo el conjunto de sensores del modelo base, y las dos se leen sin privileged.
  El `/system/health` de RouterOS en esta placa informa de exactamente un sensor, `cpu-temperature`,
  que es la zona `soc-thermal` truncada a grados enteros: un desfase medio de +0,55 °C durante los 8
  minutos en que existieron las dos series (2026-09-14).
- Las dos zonas declaran un `polling_delay` de 1 000 ms y un `polling-delay-passive` de 250 ms (leído
  el 2026-09-14), así que el kernel vuelve a leer el sensor a 1 Hz. El punto de disparo crítico
  declarado es 105 °C, leído de `/sys` (la fecha no consta). El sensor cuantiza en escalones de
  unos 0,42 °C ([`floors-overnight`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-floors-overnight)).
- El gobernador de cpufreq marcaba `userspace` el 2026-09-14, y los clusters de cpufreq, leídos de
  `related_cpus` y `affected_cpus` dentro del contenedor ese mismo día (RouterOS 7.24.2), son `{0,1}`
  y `{2,3}`.

### Vista desde el contenedor

- **Globales dentro del contenedor** (establecido el 2026-09-11, RouterOS 7.24.2, kernel 5.6.3): los
  ficheros de CPU, interrupciones, memoria y dispositivos de bloques, y `/proc/net/softnet_stat`. Un
  contenedor normal leyó además como del router, el 2026-09-12: las dos zonas térmicas,
  `scaling_cur_freq` por núcleo, `/proc/yaffs` y `/proc/buddyinfo`. `/proc/device-tree/model` dice
  `RB5009` incluso sin privilegios.
- **Los del propio contenedor** (campaña [`netns-2026-09-12`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-netns-2026-09-12)):
  `/proc/net/dev`, `/proc/net/snmp`, `/proc/net/netstat` y `nf_conntrack_count` describían la veth del
  contenedor, 4 paquetes mientras el router reenviaba millones, y `privileged=yes` no cambió eso. El
  resto de esa frontera:

| Qué                                                                               | Lo que ve el contenedor                                                                             | Leído      |
| --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ---------- |
| `/sys/class/net`                                                                  | solo `lo` y la veth; ningún dispositivo para ningún puerto frontal, privilegiado o no               | 2026-09-14 |
| `/sys/class/mdio_bus`, `/sys/class/phy`                                           | `mdio_bus` solo contiene `fixed-0`; `phy` está vacío                                                | 2026-09-14 |
| `netdev_budget`, `netdev_max_backlog` y las demás entradas globales de `net.core` | ausentes; las entradas por espacio de nombres, como `somaxconn`, están presentes                    | 2026-09-14 |
| ficheros de `/proc/net/*` creados por módulos                                     | los del propio contenedor: `fib_trie` muestra solo el `/30` de la veth, `snmp6` cuenta sus paquetes | 2026-09-15 |
| `nf_conntrack_max`                                                                | el techo real del router, 966 656, el mismo que RouterOS informa como `max-entries`                 | 2026-09-14 |
| tiempos de expiración de conntrack                                                | los valores por defecto de Linux (`tcp_timeout_established` 432 000 s frente al `1d` de RouterOS)   | 2026-09-14 |

- **Los montajes del host** no cruzan la frontera:
  ver [el hecho verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-host-mounts) del 2026-09-15.
- El registro de datos del equipo lleva los techos propios de la placa, nunca un número sacado de
  otro sitio: el techo de conntrack de 966 656 y el límite de memoria de 64 MiB del contenedor.

### Almacenamiento

- `nbd0`–`nbd15` están presentes e inactivos y `mtdblock0`–`2` dan todo ceros (2026-09-12, RouterOS
  7.24.2, kernel 5.6.3; [`internal/dashboards/panels.go`](https://github.com/jmrplens/mikroscope/blob/main/internal/dashboards/panels.go), el panel de E/S en curso de
  disco). La fila de `/proc/yaffs` o de `/proc/diskstats` de un dispositivo solo se guarda cuando su
  delta no es cero, lo que aquí ocurre unas pocas veces por minuto. El almacén InfluxDB de referencia
  seguía sin tabla de dispositivos de bloques, y sin tabla de PSI, el 2026-09-25, con RouterOS 7.24.4.
- Los contadores ECC de la MTD están todos a cero tras años de servicio (la fecha de la lectura no
  consta).
- `/proc/slabinfo` ocupa 13 833 bytes y 129 líneas por lectura (2026-09-14), el mayor análisis por
  tick, un orden de magnitud por encima de cualquier otro.
- El log del router tenía 66 217 filas cuando `record` lo leyó, porque su tema `dns` registra a disco
  (la fecha no consta).
- Tiene un disco tmpfs, que usa `--ephemeral`. Su cortafuegos raw lleva las dos reglas de descarte
  `defconf:` de MikroTik en su forma de listas, `in-interface-list=!LAN` y `src-address-list=!LANs`
  ([Listas del firewall](https://jmrplens.github.io/mikroscope/es/install/firewall/)).

### Puertos e interfaces

- **Nombres del kernel frente a nombres de RouterOS**
  ([Nombres de puertos](https://jmrplens.github.io/mikroscope/es/reference/port-names/)): `eth1` = `ether2` por el bucle de capa
  2 del caso real (2026-09-13). `eth5` = `ether6` y `eth6` = `ether7` el 2026-09-15: los dos puertos
  están comentados como `Unused` y ninguno estaba `RUNNING`, así que cada uno se apagó y se volvió a
  encender por la API mientras el agente leía `/dev/kmsg`. El kernel registró
  `br0: port 7(eth5) entered disabled state` dentro de la ventana de `ether6` y `port 7(eth6)` dentro
  de la de `ether7`, con nueve segundos entre ellas, lo que descarta leer dos veces el mismo apagado.
  No se interrumpió ningún tráfico y los dos puertos estaban de vuelta en menos de cuatro segundos.
  Los seis pares deducidos y el switch se apoyan en un `/interface/ethernet/print` de solo lectura del
  2026-09-13: direcciones MAC consecutivas, de `…:55` para `ether1` a `…:5D` para `sfp-sfpplus1`, en el
  orden de enumeración de RouterOS, y los nueve puertos declarando `switch=switch1` frente al único
  `switch0` del kernel. El device tree, analizado el 2026-09-14, muestra el `ethernet@0` del SoC con
  tres MAC, solo `eth0` habilitada (el enlace de subida de 10 G) y `eth1`/`eth2` deshabilitadas; los
  nueve puertos del frontal son netdevs que el driver del switch crea en tiempo de ejecución. La tabla
  es la de esta placa, observada con RouterOS 7.24.2.
- **Las formas de registro del log del kernel** para cada clase de suceso de puerto se vieron entre el
  2026-09-12 y el 2026-09-15 (kernel 5.6.3).
- **Inventario** (2026-09-16, RouterOS 7.24.2): las tres lecturas de configuración devuelven 17
  interfaces. `ether1` es un `ether` de la lista `LAN`, puerto de `bridge`, etiquetado «TrueNAS - High
  Performance Storage», MTU 9000; `ether5` es un `ether` de `WAN` que no está en ningún bridge,
  etiquetado «DIGI ONT»; `PPPoE_DIGI` es `pppoe-out`, `WAN`, MTU 1480; `VLAN_DIGI` es `vlan`, `WAN`;
  `wg_devices` y `wg_trastero` son `wg` en `LAN,VPN`; `ether6` y `ether7` llevan el comentario
  «Unused».
- **Contadores**: 9 puertos × 45 contadores, y 15 en cada interfaz bridge, VLAN, PPPoE, WireGuard,
  veth o loopback, contados en las propias filas `mikroscope_api_ifcounters` del colector el
  2026-09-24. La versión de RouterOS no se leyó con ellas; el router tenía 7.24.4 ese día.

## Laboratorio virtual

El Cloud Hosted Router de MikroTik bajo QEMU, en un contenedor Docker, en la máquina en la que se
construyó el laboratorio (x86_64, 12 núcleos, 27 GB de RAM, Docker 29.8, QEMU 10.0.13), aprovisionado
en una instantánea limpia con el paquete `container` y `device-mode container=yes`. Medido el
2026-09-26 con RouterOS 7.24.4 y la CLI y la imagen del agente 1.3.1 publicadas:

- **CHR x86_64** con KVM: 2 núcleos, kernel `5.6.3-64`.
- **CHR arm64** con la emulación TCG de QEMU, `cortex-a72`, 2 vCPU, 1 GiB: kernel `5.6.3`, la
  arquitectura, la versión del kernel y el modelo de CPU del RB5009, a la velocidad del host.

**Lo que muestra**: corrección. Las órdenes de RouterOS que envía mikroscope y lo que responde
RouterOS, la lectura que hace `doctor` del router, que RouterOS elija y descargue la imagen de su
arquitectura, el arranque y la parada del contenedor, la detección de capacidades del agente, su
formato de muestra y su anillo. Las rutas de instalación que se ejecutaron allí están en
[Rutas de instalación probadas](https://jmrplens.github.io/mikroscope/es/about/status/#install-routes-tested).

**Cómo llega el laboratorio a sus agentes**: por una ruta estática. El lado LAN del laboratorio,
`192.168.88.10/24` dentro del contenedor del laboratorio, tiene su ruta por defecto por el puente de
Docker, no por el router, y llega a cada agente por `172.30.0.0/16 via 192.168.88.1`, el valor por
defecto de `LAB_AGENT_ROUTES`: el prefijo más amplio de
[Ruta estática](https://jmrplens.github.io/mikroscope/es/install/reaching-the-agent/#ruta-estática). El 2026-09-27, la
`172.30.10.0/30` por defecto y una instalación en `172.30.11.0/30` respondieron ambas a `/healthz` por
ella.

**Lo que no puede mostrar**:

- Una placa. No hay chip de switch, flash, sensores ni modelo en el device tree, así que no hay mapa
  de puertos. Las `/capabilities` del agente dan `cpufreq`, `mtd`, `psi`, `schedstat` y `thermal`
  ausentes en los dos, `perf` y `kmsg` presentes en los dos, y `yaffs` ausente en x86_64 y presente
  en arm64, un `/proc/yaffs` sin flash detrás.
- Cadencias por encima de 10 Hz. La licencia gratuita de CHR limita lo que envía el router a
  1 Mbit/s por interfaz: copiar 2 MiB desde el router por ether2 llevó 15,6 s, unos 1,07 Mbit/s,
  frente a 0,2 s hacia él. `/stream` midió 2 526 B por línea en el laboratorio, 0,21 Mbit/s a 10 Hz,
  así que 50 Hz está en el tope y 100 Hz por encima. No se midió ninguna de las dos.
- Ningún coste en arm64. Con TCG el reloj del invitado sigue al del host, así que ninguna duración,
  ninguna cifra de CPU (`cpu-load`, `self.cpu_us`, `read_ns`, `wake_ns`, la dispersión de `dt_ns`,
  `slipped`), ninguna tasa de interrupciones, softirqs o cambios de contexto y ninguna cuenta de la
  PMU del laboratorio arm64 mide un Cortex-A72. El agente aguantó allí a 10 Hz, 3 003 ticks en 300,1 s
  con 1 retrasado y 1 202 en 120,1 s sin ninguno, y su tamaño residente de 14–16 MiB (32 MiB
  cargados a su cgroup) es solo orientativo.

Un bucle de rutas del propio laboratorio, ya corregido, hacía que el router emulado se arrastrara
cada vez que algo sondeaba una dirección de agente sin veth detrás: antes de la corrección, `install`
en arm64 tardó 38,4, 11,8 y 34,1 s, y el primero y el tercero salieron con 1 en una instalación
completa. Las cifras de arm64 de aquí son de después de la corrección; las de x86_64 se tomaron
antes. Lo que encontró allí la 1.3.1 está en
[Problemas conocidos](https://jmrplens.github.io/mikroscope/es/about/status/#encontrado-en-el-laboratorio-virtual).

### Tiempos del laboratorio

En la máquina de arriba, desde la instantánea limpia. Cómo se ejecuta cada batería está en
[Baterías de pruebas](https://jmrplens.github.io/mikroscope/es/reference/testing/#el-laboratorio-virtual-de-routeros).

- **Un arranque desde la instantánea hasta que responde ssh**, 2026-09-26: 7 s en x86_64 (6,9, 7,2,
  7,4 y 7,4 s) y de 26 a 28 s en arm64 (25,7, 26,6, 27,0 y 27,5 s).
- **`make roundtrip`**, 2026-09-26: `doctor`, `install`, `status`, `upgrade` y `uninstall`, cada
  orden con `--ephemeral`, y el `/export` del router resumido con un hash antes y después. De 28 a
  34 s en x86_64 en tres ejecuciones y de 40 a 45 s en arm64 en cuatro, con el export idéntico byte a
  byte todas las veces. Con el código de la 1.4.0, que hace un solo intento de `uninstall`, el
  2026-09-27: 20 s en x86_64 y 35 s en arm64, una ejecución de cada una con los pasos de compilación
  de make incluidos, con el export idéntico byte a byte. Con el código de la 1.5.0 el mismo día:
  21 s en x86_64 y 30 s en arm64, medidos igual, con el export idéntico byte a byte.
- **`make test-lab` con los escenarios de la 1.3.1**, 2026-09-26: de 7 min 21 s a 9 min 49 s en
  x86_64 en seis ejecuciones y de 12 min 12 s a 16 min 48 s en arm64 en tres, las más lentas de cada
  una con las dos baterías en paralelo en un anfitrión ocupado. Ninguna instalación falló.
- **`make test-lab` con los escenarios de las opciones de instalación**, con el código posterior a
  la 1.3.1, 2026-09-27: 28 min 32 s en x86_64 sola, y después 28 min 17 s en x86_64 y 57 min 29 s en
  arm64 en paralelo. Tras las correcciones que pidió la revisión, 29 min 2 s y 57 min 13 s en
  paralelo, con todas las pruebas superadas; las veinte desinstalaciones de S9 con un cliente en
  `/stream`, diez por arquitectura, quedaron limpias al primer intento, en 8,0 a 12,6 s. Ese mismo
  día S17 se ejecutó en un laboratorio CHR x86_64 con RouterOS 7.23.7: a `doctor` le faltó
  `RouterOS 7.24 or later` y leyó todas las demás comprobaciones.
- **RouterOS 7.24.4 cambia su propio `/export`**: añade y quita por su cuenta una línea
  `/system keymat-provider … name=default`, así que la comparación de la batería deja esa línea fuera
  (2026-09-26).

### Corte de corriente tras instalar

El 2026-09-26, un corte de corriente hecho en cuanto una instalación recién hecha respondió no
devolvió ningún agente en 90 s en tres de cuatro intentos en el laboratorio arm64. Los dos
contenedores que se miraron no podían arrancar (`Exec format error`, `Segmentation fault`), muy
probablemente porque RouterOS aún no había escrito la instalación en su disco; eso no se examinó. En
x86_64 volvieron tres de tres. El escenario del arranque con el router, S7, espera 45 s entre la
instalación y su corte, y solo pregunta si ese arranque funciona. S6 corta la corriente bajo una
instalación `--ephemeral` en el disco tmpfs del laboratorio: después el contenedor sigue configurado y
detenido, su raíz, su imagen y el manifiesto se han ido con el contenido del disco, el disco sigue ahí
y vacío, y nada responde; `uninstall --ephemeral` no deja después nada en absoluto. Pasó en las dos
arquitecturas en las ejecuciones del 2026-09-27.

### Detecciones de reinicio

El 2026-10-05, en el laboratorio x86_64 (CHR, RouterOS 7.24.4, KVM), el colector del código
posterior a la 1.5.0 ejecutó `forward --api-mode off --stdout json` a través de un reinicio hecho
con el propio `/system/reboot` de RouterOS, con el agente 1.5.0 instalado por la descarga de Docker
Hub y arranque con el sistema. El agente volvió a responder unos 20 s después del reinicio; el
colector registró `agent restarted: its newest sample is 439 and the cursor was 1057; resuming from
1`, y `agent-restart` saltó con su resumen de los 30 s anteriores: 300 muestras, CPU ocupada al 0 %,
MemAvailable 767,5 MiB de 863,0 MiB, nf_conntrack 24 de 843 776, ninguna caída en softnet y después
16,2 s sin muestras. `reboot` no saltó: ningún registro del log del kernel tras volver el agente
tenía un tiempo desde el arranque menor que el último de antes del reinicio. Una sola ejecución, en
un router en reposo.

Más tarde ese mismo día, en el mismo laboratorio, el agente y el colector del código posterior a la
1.5.0 que lee el identificador de arranque del kernel (el agente del tar de la rama, con arranque con
el sistema) ejecutaron siete minutos de `forward --api-mode off --stdout json` a través de una parada
y un arranque del contenedor del agente y después un `/system/reboot`. El agente dentro del
contenedor de RouterOS leyó el identificador y lo sirvió en `/healthz`. Tras `/container/stop` y
`/container/start` (20,6 s sin muestras) el identificador era el mismo, y `agent-restart` lo dijo:
`the kernel's boot id did not change, so the router did not reboot`; ningún `reboot`. Tras
`/system/reboot` (16,5 s sin muestras) el identificador era nuevo: el colector registró `router
rebooted: the kernel's boot id went from 30b9831d-… to 8d4e19f2-…`, y `agent-restart` y `reboot`
saltaron con la primera muestra del agente con el mismo resumen (300 muestras, CPU ocupada al 0 %,
nf_conntrack 24 de 843 776, ninguna caída en softnet). El log del kernel del arranque nuevo no hizo
saltar un segundo `reboot`. Una ejecución de cada caso, en un router en reposo; el laboratorio arm64
no se ejecutó.

Lo que RouterOS escribe sobre un arranque se leyó esa misma tarde por la API, de `/log/print`, tras
cada forma de tumbar el laboratorio x86_64. Tras `/system/reboot` desde una sesión SSH su buffer de
memoria tenía `router rebooted by ssh-cmd:admin@192.168.88.10/reboot` (topics `system,info`); desde
un script, `…/script:rb/reboot`; tras `/system/shutdown` y un arranque, `…/shutdown`; tras quitar la
corriente (`power-cycle`), `router was rebooted without proper shutdown` (`system,error,critical`), y
lo mismo tras el `system_reset` de QEMU (`reset-button`). Con una acción de logging que mandaba
también el topic `system` a disco, un `/log/print` sin más devolvió además las líneas del arranque
anterior, y `/log/print ?buffer=memory` solo las de este.

Después el colector del código que lo lee (`forward --api-mode slow --stdout json`, con la capa de
API recibiendo las credenciales del laboratorio mediante `LAB_CLI_API=lab`) funcionó ocho minutos a
través de un `/system/reboot` y un `reset-button`. Las dos veces la lectura salió bien en la lectura
de salud que notó el identificador de arranque nuevo, antes de que la ronda propia de la capa de API
reconectara (la lectura reabrió la conexión), así que `reboot` saltó con la primera muestra del
agente, con `RouterOS logged at boot: "router rebooted by ssh-cmd:admin@192.168.88.10/reboot"` la
primera vez y `"router was rebooted without proper shutdown"` la segunda, 19,4 s y 22,1 s sin
muestras. Una ejecución de cada caso; la espera de dos minutos a una API que no ha vuelto no se
ejercitó en un router, solo en las pruebas unitarias.

En el RB5009 (RouterOS 7.24.4), el agente 1.6.0 instalado el 2026-10-06 sirvió el identificador de
arranque del kernel en `/healthz` desde dentro de su contenedor. El `agent-restart` de esa
actualización dijo `the kernel's boot id did not change, so the router did not reboot`, que era
cierto pero no se sabía: el agente 1.5.0 anterior no daba ningún identificador. En el código
posterior a la 1.6.0 el primer agente que da un identificador después de uno que no lo daba no
afirma nada sobre el kernel.

Un `power-cycle` del laboratorio no sirve para probar el colector: reinicia el contenedor del
laboratorio, y un colector lanzado antes con `mikroscope-lab cli` conserva el espacio de red del
contenedor viejo y no alcanzó nada tras el corte (`no route to host` hasta que terminó, el mismo
día). El reinicio desde dentro conserva la red del laboratorio.

### Avisos de exposición de doctor

El 2026-10-05, en el laboratorio x86_64 (CHR, RouterOS 7.24.4, KVM), el `doctor` del código
posterior a la 1.5.0 que añade los dos avisos se ejecutó contra el router del laboratorio preparado
de tres maneras. Con `allow-remote-requests=yes` y ninguna regla de cortafuegos, avisó `the router
does not answer DNS from its uplink (…, uplink ether1: no rule drops a query that comes in on it)`.
Con las dos reglas de input de la configuración por defecto (aceptar
`established,related,untracked`, descartar `in-interface-list=!LAN`) añadidas diez segundos antes,
pasó, nombrando el descarte `!LAN`; con solo `in-interface=ether1 protocol=udp dst-port=53
action=drop` también pasó. Con una regla de filter cuya lista de interfaces se había quitado y una
regla de raw cuya veth se había quitado, nombró las dos bajo `no firewall rule doctor reads is
invalid or names a deleted list`.

Lo que hace RouterOS con una regla cuya referencia desaparece se leyó por SSH el mismo día. Una lista
de interfaces quitada bajo una regla dejó la regla válida, con `in-interface-list=!*2000010`; crear
una lista con el mismo nombre no la cambió, y la regla contó paquetes como una regla que lo coge
todo puesta al lado. Un descarte `!LAN` que se quedó así en la cadena input cortó el SSH del propio
laboratorio desde la LAN hasta que se reinició el laboratorio. Una veth quitada bajo una regla dejó
la regla inválida (`in-interface=*4`, `about=vprobe not ready`), y no contó ningún paquete. Una
regla leída justo después de añadirla era inválida sin `about`, y válida cinco segundos después.
RouterOS no deja añadir una regla que nombra una lista que no existe (`input does not match any
value of interface-list`).

Para la colocación de la solución: `place-before=0` falló desde una sesión SSH de una sola orden
(`no such item`), y un place-before de la primera regla de la cadena input falló con la cadena vacía
y funcionó con una regla en ella. Sin probar: IPv6, y una consulta DNS enviada desde fuera del
laboratorio, cuyo enlace de subida es la red de usuario de QEMU; `doctor` lee las reglas y no envía
ningún paquete.

En el RB5009 (RouterOS 7.24.4, 2026-10-06), el `doctor` de la 1.6.0 leyó 80 reglas activas en raw
prerouting y en filter forward e input, ninguna inválida ni que nombrara una lista borrada, y dijo
que la comprobación de DNS no tenía enlace de subida que evaluar: la ruta por defecto activa del
router va por PPPoE, y su `immediate-gw` es la interfaz sola (`PPPoE_DIGI`), que la lectura del
enlace de subida no contemplaba; el enlace DHCP del laboratorio se lee `10.0.2.2%ether1`. Con esa
lectura corregida, el código posterior a la 1.6.0 encontró `PPPoE_DIGI` en la lista `WAN` y evaluó
las consultas como un quizá, porque la regla `accept to local loopback (for CAPsMAN)` de la
configuración por defecto, `dst-address=127.0.0.1`, va antes de su `drop all not coming from LAN` y
se leía como una aceptación posible. Tomando un destino de loopback como no coincidente para un
paquete que llega de Internet, nombró `defconf: drop all not coming from LAN` como la regla que
descarta las consultas. Cada una de las tres ejecuciones fue una sola conexión de lectura.

### RouterOS x86 desde la ISO

El laboratorio opcional que instala RouterOS x86 desde la ISO de MikroTik se ejecutó el 2026-09-26
con RouterOS 7.24.4. El router informó de la placa `x86 QEMU Standard PC (Q35 + ICH9, 2009)` y de
una licencia de prueba sin nivel y con 24 horas por delante. La CLI 1.3.1 y el agente de la rama del
laboratorio se comportaron como en CHR x86_64: a `doctor` le faltaron las mismas dos listas, una
instalación desde el tar respondió al momento, `status` reconoció todos los objetos y `uninstall`
verificó el router limpio, dejando el mismo directorio `mikroscope` vacío. Las `/capabilities` del
agente fueron las de CHR x86_64.

### Ejecuciones en la CI

El flujo se ejecutó por primera vez en los runners de GitHub el 2026-09-26, como el trabajo del
laboratorio de la CI en el pull request #69: cuatro ejecuciones x86_64 entre las 21:06 UTC de ese día
y las 00:45 UTC del 2026-09-27, cada una con las diez pruebas que tenía entonces la batería superadas
(de 471,7 a 485,8 s) en un trabajo de 10 min 30 s a 13 min 30 s. De las tres ejecuciones de abajo,
las dos primeras tenían la caché vacía, así que `make lab-up` descargó RouterOS y lo aprovisionó; la
tercera tomó las descargas de la caché y aprovisionó una instantánea nueva.

| Ejecución                          | Commit                                   | Runner                                                         | `make lab-up`                                                    | Batería                                                                                   | Trabajo       |
| ---------------------------------- | ---------------------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------- |
| arm64, a petición sobre main       | `e7efbbe`, el laboratorio tal como se fusionó | `ubuntu-latest`: 4 CPU, 15 989 MB, `/dev/kvm` presente     | 4 min 29 s: aprovisionamiento 83 s, un arranque de la instantánea 24 s | 638,6 s, las diez pruebas de ese commit superadas                                    | 16 min 24 s   |
| x86_64, pull request #70           | `3c34d9a`, las opciones de instalación   | `ubuntu-latest`: 4 CPU, 15 989 MB, `/dev/kvm` usado por KVM    | 4 min 28 s: aprovisionamiento 46 s, un arranque de la instantánea 8 s | 1 591,4 s (26 min 31 s), todas las pruebas superadas; S17 omitida, porque necesita un RouterOS anterior a 7.24 | 32 min 42 s   |
| x86_64, pull request #70           | `1826aa5`, con la credencial de registro | `ubuntu-latest`, `/dev/kvm` usado por KVM                      | 1 min 25 s: las descargas desde la caché, aprovisionamiento 76 s | 1 633,1 s (27 min 13 s), todas las pruebas superadas; S17 omitida. El router descargó como la cuenta de Docker Hub del repositorio, S2 incluida; S1, S18 y los scripts de Docker Hub y de GHCR de S5 arrancaron sin ella | 29 min 52 s   |

En las dos primeras de esas ejecuciones se cortó una descarga desde MikroTik
(`connection reset by peer`) y se reanudó al primer reintento. La sonda de KVM en el runner arm64 de
GitHub encontró `ubuntu-24.04-arm` con 4 CPU y sin `/dev/kvm`, así que el laboratorio arm64 sigue
emulado en un runner x86_64.

Las dos ejecuciones en el pull request #70 lo retuvieron 30 y 33 min, y por eso `lab.yml` se ejecuta ahora
solo cada semana y a petición, nunca en un pull request ni antes de una publicación.

En el commit de la publicación 1.4.0 (`79b7c2f`, una ejecución a petición el 2026-09-27, run
36329638066) la batería entera pasó en las dos arquitecturas: 1 517,2 s en x86_64 en un trabajo de
31 min 38 s, y 3 042,6 s en arm64, emulado, en un trabajo de 54 min 52 s. La imagen del agente 1.4.0
aún no estaba publicada, así que los trece casos de referencia que descargan su imagen descargaron la
de la 1.3.1, como hace S5 antes de una etiqueta y dice en su registro.

En el commit de la publicación 1.5.0 (`e61ffb6`, una ejecución a petición el 2026-09-27, run
36344788569) la batería entera volvió a pasar en las dos arquitecturas: 1 573,2 s en x86_64 en un
trabajo de 31 min 38 s, y 3 065,8 s en arm64, emulado, en un trabajo de 54 min 55 s. Los trece casos
de referencia que descargan su imagen descargaron la de la 1.4.0, porque la de la 1.5.0 aún no
estaba publicada, como registró S5.

## Equipos y versiones

| Equipo                         | Tipo                            | RouterOS | Cuándo                                               | Qué se ejecutó allí                                                                                                                            |
| ------------------------------ | ------------------------------- | -------- | ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| RB5009UG+S+                    | hardware, arm64                 | 7.24.1   | hasta la actualización del 2026-09-10                | el coste de una conexión SSH, 2026-08-26                                                                                                       |
| RB5009UG+S+                    | hardware, arm64                 | 7.24.2   | del 2026-09-10 a más o menos el 2026-09-18 22:43 UTC | la mayoría de las campañas, del 2026-09-11 al 2026-09-18                                                                                       |
| RB5009UG+S+                    | hardware, arm64                 | 7.24.4   | desde más o menos el 2026-09-18 22:43 UTC           | la campaña de errores de puerto, los tiempos de `/stream`, las gráficas del almacén de referencia y las órdenes de despliegue desde el 2026-09-21; `upgrade` con la 1.5.0 y la 1.6.0, `doctor` con la 1.6.0 |
| CHR x86_64, laboratorio virtual | virtual (KVM), amd64            | 7.24.4   | 2026-09-26 y 2026-09-27                              | `doctor`, `plan`, tres rutas de instalación, `--expose`, `uninstall` con la 1.3.1; la batería entera del laboratorio con el código posterior y en el commit de la 1.4.0     |
| CHR arm64, laboratorio virtual  | emulado (TCG), arm64            | 7.24.4   | 2026-09-26 y 2026-09-27                              | `doctor`, `plan`, tres rutas de instalación, `uninstall` con la 1.3.1; la batería entera del laboratorio con el código posterior y en el commit de la 1.4.0                |
| CHR x86_64, laboratorio virtual | virtual (KVM), amd64            | 7.23.7   | 2026-09-27                                           | `doctor`, que rechaza un RouterOS anterior a 7.24 (S17)                                                                                         |
| RouterOS x86 desde la ISO, laboratorio virtual | virtual (KVM), amd64 | 7.24.4 | 2026-09-26                                    | `doctor`, una instalación desde el tar, `status` y `uninstall` con la 1.3.1                                                                    |

**Cuándo pasó el RB5009 a 7.24.4.** La actualización en sí no quedó anotada, pero está acotada: la
fecha de compilación de 7.24.4 es 2026-09-16 11:32:21; el 2026-09-24 el router informó de 7.24.4 con
un uptime de 5d15h49m12s, un arranque hacia el 2026-09-18 22:43 UTC; y una actualización de RouterOS
lo reinició a las 00:43:30 CEST del 2026-09-19, las 22:43:30 UTC del día anterior, tras lo cual la
capa del kernel se reanudó a las 00:45:03. El uptime de la capa de la API en el almacén de referencia
crece al ritmo del reloj desde el 2026-09-19 a las 11:13:35 UTC. Así que el router tiene 7.24.4 desde
ese arranque como tarde. Las campañas fechadas del 2026-09-16 al 2026-09-18 constan como 7.24.2; la
cota ni lo confirma ni lo desmiente. Ninguna de las medidas de 7.24.2 se ha repetido sobre 7.24.4.

**Lo que se ejecutó sobre 7.24.4.** `doctor`, `plan`, `install`, `status` y `uninstall` el
2026-09-21, con el agente instalado funcionando de forma continua desde el 2026-09-19. El 2026-09-23
se reprodujo en solo lectura la forma 1.2.x del aviso de registro de `doctor`, y su aviso de token
con una instalación desechable que se expuso, se actualizó sin token y se retiró, así que `upgrade`
también se ha ejecutado allí. Ese mismo día `doctor` leyó 600 muestras del anillo del agente en
marcha y no encontró nada. El 2026-09-24 se le dio a RouterOS la referencia del agente con su host de
registro dentro de `remote-image=`
(dos [hechos verificados](https://jmrplens.github.io/mikroscope/es/about/status/#verified-remote-image-host)). La capa de la API funciona sin
parar sobre 7.24.4 desde el 2026-09-19; sus lecturas de inventario y de claves de pérdidas y su
perfil de coste son de 7.24.2 (2026-09-15 y 16), y su prueba de reconexión y su A/B con 16
interfaces del 2026-09-19, tras la actualización de ese día, sin la versión anotada al lado.

**Los ajustes del contenedor** que escribe `install` se verificaron en el RB5009 con RouterOS 7.24.2
y se volvieron a ejercitar sobre 7.24.4; no se probó ninguna otra placa.

**El agente del RB5009** se actualizó a 1.0.9 el 2026-09-19, a 1.2.0 a las 08:08:54 UTC del
2026-09-24 y a 1.2.1 y 1.2.2 ese mismo día, a 1.5.0 el 2026-09-27 y a 1.6.0 a las 07:15 UTC del
2026-10-06, cada vez con `upgrade --remote-image`; la última tardó 11,8 s desde la orden hasta la
respuesta de la sonda. Los tiempos de `/stream` del 2026-09-21 son del agente 1.0.9.

### Plataformas

De las cuatro plataformas que publica una versión, `arm64` se ha ejecutado en hardware, el RB5009, y
emulada en el laboratorio. `amd64` solo se ha ejecutado en el laboratorio, en el CHR x86_64 y en
RouterOS x86 desde la ISO, ambos bajo KVM, nunca en hardware x86. `arm/v7` y `arm/v5` nunca se han
ejecutado en RouterOS: se compilan de forma cruzada, y la CI arranca cada imagen con `-version` bajo
la emulación de modo usuario de QEMU (`make agent-smoke`), que no es RouterOS. Qué publica cada
versión, y qué números de versión nunca llegaron a publicarse, está en
[Versiones](https://jmrplens.github.io/mikroscope/es/about/changelog/#lo-que-publica-cada-versión).

## Estado de las funciones

Todo lo siguiente se ejecutó contra el RB5009 salvo que diga la batería de contenedores o el
laboratorio: con RouterOS 7.24.2 si está fechado hasta el 2026-09-18, y con 7.24.4 si está fechado
desde el 2026-09-19 ([Equipos y versiones](https://jmrplens.github.io/mikroscope/es/about/status/#un-equipo-dos-versiones-de-routeros)). Cada parte
empieza por su veredicto y la fecha que lo respalda.

### Agente

**El agente funciona en el RB5009: el instalado estaba en marcha allí el 2026-09-23, cuando `doctor`
leyó 600 muestras de su anillo.** Lee `/proc`, `/sys`, `/dev/kmsg` y los contadores de
`perf_event_open` del kernel compartido con un temporizador fijo de 1 a 100 Hz (10 Hz por defecto;
10, 20, 50 y 100 Hz [medidos](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-18)), guarda las muestras en un
anillo y las sirve: `/healthz`, `/capabilities`, `/snapshot`, `/stream`, `/sampler`, y los endpoints
de captura por disparo `/captures` y `/capture`. No sirve ningún `/metrics`; la exposición es la del
colector.

### Órdenes de despliegue

**Las seis órdenes de despliegue se han ejecutado en el RB5009 con RouterOS 7.24.4, las seis a más
tardar el 2026-09-23, cada una con la CLI de su fecha. De la 1.4.0 en adelante solo se han
ejecutado allí `upgrade` (la 1.5.0 el 2026-09-27 y la 1.6.0 el 2026-10-06, la segunda leyendo el
manifiesto de instalación que escribió la primera) y `doctor` (1.6.0, 2026-10-06); el resto del
código posterior a la 1.3.1, que es el que publica la 1.4.0, solo se ha ejecutado en el laboratorio
virtual (2026-09-27). Según su código, la 1.5.0 no cambia ningún paso de las seis
órdenes en el router; su `uninstall` rechaza `--grafana-dry-run` y lista los objetivos de Grafana y
de los almacenes antes de tocar el router, ambas cosas comprobadas solo en pruebas unitarias
([`uninstall --targets`](https://jmrplens.github.io/mikroscope/es/about/status/#uninstall---targets)).** `doctor`, `plan`, `install`, `status`, `upgrade`
y `uninstall` instalan, actualizan y retiran el agente, listando cada escritura antes de hacerla y
verificando cada retirada por recuento de propiedad.

- **Ida y vuelta, 2026-09-12**: `doctor` → `install` → `status` → `upgrade` → `uninstall` dejó el
  `/export` del router idéntico byte a byte ([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-export-identical)).
  El agente respondió 3 s después de la instalación, con un tiempo de ida y vuelta de 5–7 ms: dos
  sondeos, 7 ms tras `install` y 5 ms tras `upgrade`, y el primero imprimió
  `direct transport ok: agent 4857d0a-dirty, 10 Hz, seq 29, 0 slipped, 7ms round trip`. Es una
  instalación en una red, no una cifra para otra. La ejecución pasó `--ephemeral` a `doctor`,
  `install` y `upgrade`, y es anterior a 1.1.0, desde la que `uninstall` solo retira con `--yes`.
  `scripts/roundtrip.sh` pasa ahora `--yes` a su desinstalación (hasta 1.2.0 no lo hacía, así que ahí
  solo listaba y su comprobación del export fallaba) y `--ephemeral` a todas las órdenes. En esa forma
  se ejecuta en el laboratorio como `make roundtrip` ([Tiempos del laboratorio](https://jmrplens.github.io/mikroscope/es/about/status/#lab-timings)), y no
  se ha ejecutado contra el RB5009, donde es `make roundtrip-device`.
- **Rutas de instalación**: cuatro rutas de principio a fin el 2026-09-17, y las del laboratorio el
  2026-09-26, en [Rutas de instalación probadas](https://jmrplens.github.io/mikroscope/es/about/status/#install-routes-tested).
- **`doctor` por sí solo** lee además una vez el anillo del agente en marcha y nombra cuatro fallos
  que las herramientas de RouterOS no muestran: un bucle de capa 2, cambios continuos de STP, un
  enlace que cae y vuelve y descartes de softnet. Si ningún agente responde en 3 s lo dice y lo
  omite, y lo que encuentra nunca cambia el código de salida. El 2026-09-23 leyó 600 muestras y no
  encontró nada; los cuatro fallos los cubren pruebas que reproducen el texto real de los registros y
  la cadencia de 2,0 s del bucle del RB5009, no un fallo en vivo. Su hallazgo de cambios de STP se
  apoya en cómo se ve un enlace sano al subir: en el ether7 del RB5009, cinco subidas de enlace el
  2026-09-21 registraron cada una tres pasos a learning a la vez y llegaron a forwarding entre 2,1 y
  2,8 s después, y en 30 días del almacén de ese router toda subida sana dejó learning menos
  forwarding en 0.
- **Sus comprobaciones `WARN`**, que no cambian ni el código de salida ni que `install` siga
  adelante. Dos son anteriores a la 1.4.0: con `--remote-image`, un usuario puesto en
  `/container/config` cuando `registry-url` está vacío o nombra un host distinto del que se descarga
  la imagen; y una instalación con el mismo `--name` publicada en la LAN sin `TOKEN` en su entorno.
  Lee si hay un usuario puesto y cuántas entradas `TOKEN` existen, nunca un valor. La forma 1.2.x del
  aviso de registro se reprodujo en solo lectura sobre 7.24.4 el 2026-09-23; la comparación de hosts
  que la sustituyó solo ha avisado contra respuestas de router falsas en los tests. La 1.4.0 añade un
  `WARN` para una descarga en un router ARM de 32 bits, para una descarga con menos de 16 MiB libres
  por encima del `memory-max` del contenedor, para el arranque con el router cuando la raíz está en un
  disco tmpfs, para una regla de cortafuegos que puede descartar las respuestas del agente, para un
  `--lan-address` en el enlace de subida, para objetos etiquetados para la instalación que las
  opciones no seleccionan, y para una tabla de rutas o un cortafuegos que no pudo leer. De ellos, los
  avisos del tmpfs y de los objetos etiquetados saltaron en el laboratorio en CHR x86_64, RouterOS
  7.24.4, el 2026-09-27; ninguno se ha ejecutado en el RB5009.
- **Extracción del tar**, 7.24.2, 2026-09-11: un tar de 1,8 MiB, una compilación de esa fecha
  anterior a 1.0.0, se extrajo en el mismo segundo que su `/container/add`. La CLI de entonces borraba
  el tar tras una espera fija; la 1.4.0 espera a que el contenedor marque `stopped`, con
  `--extract-timeout` como límite.
- **Una instalación expuesta actualizada sin su token**, 7.24.4, 2026-09-21: el upgrade pasó su
  comprobación, dejó las dos reglas en su sitio y escribió una envlist sin `TOKEN`, y `/snapshot` por
  la dirección LAN del router pasó de `401` a `200`. Desde 1.2.0 `doctor` señala ese estado, y el
  código posterior a la 1.3.1 rechaza un `upgrade` así (laboratorio, 2026-09-27).
- **Un `uninstall` sin más de una instalación expuesta**, 7.24.4, 2026-09-21: retiró todo lo demás,
  imprimió `verified: nothing mikroscope created remains on the router` y dejó el dst-nat apuntando a
  una dirección que ya no existía. El código posterior a la 1.3.1 lee del router la forma de la
  instalación, y un `uninstall` sin más retiró las dos reglas en el laboratorio (2026-09-27).

### `record`, `mark` y `plot`

**`record`, `mark` y `plot` funcionan de extremo a extremo, como muestra una grabación hecha en el
RB5009 el 2026-09-12:** 60 s a 10 Hz, exactamente 600 muestras, 0 huecos y −7 ms de desfase de
reloj. Lo que mostró está en [su campaña](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-record-2026-09-12).

En el laboratorio el 2026-09-27 (CHR x86_64, RouterOS 7.24.4, la imagen publicada del agente 1.3.1),
`record --for 60s` escribió 600 muestras, `seq` de 11 a 610, con 0 huecos. Tres notas de `mark`
desde una segunda shell llegaron al mismo `.markers.csv` mientras `record` corría, y el resumen de
`record` dijo `0 marker(s)`: solo cuenta las notas escritas en él. `mark --log-markers` por la API
del laboratorio añadió 7 marcadores del log del router en la ventana, y `plot` dibujó las 600
muestras y 10 marcadores.

### `forward`

**`forward` se ha ejecutado desde el RB5009 hacia tres de sus once destinos, fichero, Prometheus e
InfluxDB 3, los tres a la vez el 2026-09-15; los otros ocho solo se han vuelto a leer desde productos
reales en contenedores, desde el 2026-09-16.** `forward` une la capa del kernel con la capa de la API
de RouterOS y escribe en once destinos. Por Loki, OTLP, Graphite, Elasticsearch, SQL, PostgreSQL,
Telegraf y stdout no han pasado muestras del router; la batería de contenedores escribe en cada
producto real y lo vuelve a leer por su propia API ([Baterías de pruebas](https://jmrplens.github.io/mikroscope/es/about/status/#las-baterías-de-pruebas)).

- **2026-09-12, ocho minutos**: 4 800 muestras del kernel y 479 de la API reenviadas con 0 huecos y 0
  descartes, ejecutando
  `mikroscope forward --for 8m --prom :9124 --influx … --interfaces bridge,ether1,PPPoE_DIGI --conntrack-every 10s`.
- **2026-09-15, cinco ejecuciones de cadencia** a 10, 50 y 100 Hz hacia un fichero, una exposición
  Prometheus e InfluxDB 3 a la vez: todos los destinos informaron de 0 huecos y 0 descartes
  ([`rates-2026-09-15`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-rates-2026-09-15)).
- **Prometheus**: un Prometheus 3.14 hizo scrape de la exposición del colector cada 5 s con el RB5009
  alimentando el colector, el 2026-09-12 y de nuevo el 2026-09-15. No consta ningún otro intervalo de
  scrape ni ninguna otra versión de Prometheus.
- **InfluxDB 3**: el primer destino real, el 2026-09-12, respondió
  `422: would exceed limit of 5 databases`, el límite por nodo que InfluxData documenta para Core. Las
  ejecuciones medidas usaron una instancia de InfluxDB 3 Core propia. El 2026-09-19 el colector pasó
  a InfluxDB 3 Enterprise 3.11.4 y escribió 44 820 filas en 36 tablas en sus primeros 19 minutos, 0
  descartadas y 0 errores. Todo lo anterior a esa fecha se midió contra Core.
- **El colector frente a un agente más rápido**, 2026-09-21: con el agente a 100 Hz y otra vez a
  50 Hz, `/healthz` daba `rate_hz` 100 y 50 y el propio registro del colector repetía esa misma
  cadencia, mientras que `mikroscope_info{rate_hz}` valía `10` en los dos casos;
  `mikroscope_cpu_busy_ticks` llevaba los cubos `le="0"` a `le="11"` más `+Inf` en los dos; y
  `window="1s"`, `window="10s"` y `window="60s"` estaban los tres presentes en los dos.
- **Detecciones en el almacén de referencia**, del 2026-09-19 a las 11:13 UTC al 2026-09-24 a las
  08:26 UTC: saltaron cuatro de las once reglas, `microburst` 116 veces, `ipc-collapse` 41 (en los
  cuatro núcleos), `link-flap` 11 y `agent-restart` una. Solo de `microburst` se ha medido el
  comportamiento contra las muestras
  ([`microburst-replay-2026-09-16`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-microburst-replay-2026-09-16)); las otras
  tres se contaron, sin cotejarlas con lo que hacía el router. Las 11 filas de `link-flap` están en
  `ether1`, `ether2`, `ether4`, `ether6` y `ether7`, cada una con entre 2 y 6 registros de enlace en
  60 s, todas sin provocar; no se comprobó cuál se debió a un cable, a un equipo del otro lado o a
  otra cosa.
- **Reinicios**: el reinicio por la actualización de RouterOS del 2026-09-19 ejercitó de verdad la
  resincronización del colector (la capa del kernel se reanudó a las 00:45:03 CEST). No se comprobó
  si entonces se escribió una fila de `mikroscope_detection` para `agent-restart`, y el almacén que
  la habría guardado se sustituyó más tarde ese mismo día; el actual empieza a las 11:13 UTC. Guarda
  una fila de `agent-restart`, a las 08:08:54 UTC del 2026-09-24, con `value` 1 frente a `threshold`
  4 338 037, cuando se actualizó el agente a 1.2.0.
- **Datos del equipo**: enviados una sola vez al arrancar, los cuatro paneles del equipo muestran «No
  data» en toda ventana posterior: el 2026-09-17 la última fila de equipo del despliegue de
  referencia tenía 26 horas y esos paneles llevaban vacíos otro tanto. Repetidos cada cinco minutos,
  cuestan doce filas por envío en el RB5009.
- **La entrega durante 24 horas**, 2026-09-17, en el despliegue de referencia: la mayor interrupción
  fue de 114,5 s, y la provocamos nosotros, un cambio de contenedor más el minuto que tarda el colector
  en notar que el agente se ha reiniciado. En funcionamiento normal el colector nunca se quedó atrás.
  Por eso el anillo guarda 60 s por defecto: cubre un reinicio de cualquiera de los dos lados en una
  LAN.

### Capa de la API

**La capa de la API ha funcionado en una sola placa, el RB5009, sin parar sobre 7.24.4 desde el
2026-09-19.**

- **Reconexión**, 2026-09-19, tras la actualización de ese día, sin tocar el router: a un colector que
  ejecutaba `monitor-traffic` sobre 16 interfaces (todas salvo `lo`) a 1 Hz se le destruyó el socket
  de la API desde el host con `ss -K`, que es como se ve desde él el lado del router en un reinicio.
  La capa reabrió la conexión y reintentó dentro de la misma ronda: 0 comandos fallidos, 0 rondas
  perdidas, 16 interfaces en cada uno de los 108 segundos a ambos lados de la muerte del socket.
- **Lo que devuelve RouterOS**: [claves de pérdidas](https://jmrplens.github.io/mikroscope/es/about/status/#verified-monitor-traffic-keys),
  una [cuenta de `rx-overflow` que solo llevan los contadores de puerto](https://jmrplens.github.io/mikroscope/es/about/status/#verified-rx-overflow-port-counters),
  los [dos planos de cuenta](https://jmrplens.github.io/mikroscope/es/about/status/#verified-port-planes) de un puerto del switch y su bridge,
  y las [horas del log](https://jmrplens.github.io/mikroscope/es/about/status/#verified-log-time-full-date).
- **`cpu-load`** es una media móvil de más o menos un segundo, ajustada contra `/proc/stat`
  ([`cpu-load-window-2026-09-15`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-cpu-load-window-2026-09-15)).
- **Lo que le cuesta al router**: [Coste de la capa API](https://jmrplens.github.io/mikroscope/es/cost/#api-tier-cost).

### Dashboards

**Todos los paneles de los cinco dashboards respondieron sin error en un Grafana real sobre los
almacenes de la batería de contenedores (2026-09-17), y los dashboards de InfluxDB y Prometheus
superaron `dashboards check` sobre los datos del propio RB5009 (2026-09-16).** Hay uno por almacén,
InfluxDB 3, Prometheus, PostgreSQL, Graphite y Elasticsearch, generados a partir de una sola lista de
paneles. Graphite y Elasticsearch llevan menos paneles a propósito
(39
y 28
frente a 177): Graphite no tiene etiquetas y
Elasticsearch no tiene documentos anidados. Los paneles de PostgreSQL son los de InfluxDB reescritos,
y la batería de contenedores hace que un PostgreSQL real planifique todas sus consultas. Las versiones
de Grafana usadas son la 12.3.2 el 2026-09-12; la 13.2.1 en las pasadas en el navegador del
2026-09-12 y el 2026-09-14, `check` y renderizado el 2026-09-15, `check` el 2026-09-16 y la batería
de contenedores; la 12.3.0 el 2026-09-21 y en los renderizados del 2026-09-25; y la 13.2.2 el
2026-09-24 y el 2026-09-25. No se ha probado ninguna otra versión.

- **2026-09-12.** En Grafana 12.3.2, el dashboard de InfluxDB contra un InfluxDB 3 Core aislado
  alimentado por `forward` desde el RB5009: todos los paneles devolvieron filas, entre 158 y 316 por
  panel en 10 minutos. El dashboard de Prometheus contra un Prometheus 3.14 haciendo scrape del
  colector cada 5 s: todos los paneles devolvieron filas, entre 228 y 2 052 en 5 minutos. Sin el
  campo `token` de la fuente de datos, los paneles fallaban con `flightsql: Unauthenticated`. Ese
  mismo día `dashboards check --store influxdb --window 12h` pasó en los 125 paneles que recorrió
  mientras unos 90 eran ilegibles en un navegador: leyendas que decían "value core 0", dos xycharts
  atascados en "Loading plugin panel…", una franja de continuidad que seguía en verde sobre 2 170
  ticks perdidos. Un Overview de ocho paneles se renderizó con 2 188 px de alto en una ventana de
  móvil de 844 px, y 900 puntos de datos es el ancho que envió el navegador para las gráficas.
- **2026-09-14.** Un Overview de once paneles midió 1 052 px de alto en una ventana de navegador de
  1 080 px, una pantalla de escritorio; un
  recorrido de renderizado contra una captura de 10,5 h del RB5009 renderizó 140 paneles de InfluxDB
  con 0 insignias de error y 0 "No data"; la fuente de datos de InfluxDB escapó `$__interval_ms` en
  cinco paneles, en el navegador, convirtiéndolo en un SQL que InfluxDB 3 no podía analizar; y una
  consulta que nombraba un campo que el almacén nunca había recibido falló al planificarse,
  `No field named limit. Valid fields are …`, a través del proxy de la fuente de datos.
- **2026-09-15, Grafana 13.2.1**: `check`, y un recorrido fila a fila sin interfaz de los dos
  dashboards en Chromium a 1600x1000, 0 insignias de error y 0 "No data" en 168 paneles de InfluxDB y
  130 de Prometheus. No se ha repetido para los tres paneles que no cubrió: los dos de eventos de
  puerto y "What each interface is: type, role, bridge and label". El mismo recorrido vio la
  proporción de fast path oscilar entre 0 y 100 % de una lectura a otra en interfaces que movían
  pocos paquetes. Regenerar ese día reprodujo byte a byte los ficheros del repositorio.
- **2026-09-16, Grafana 13.2.1**, contra el agente del RB5009 (RouterOS 7.24.2, privilegiado, los
  disparadores por defecto), `forward --prom :9124 --influx … --interfaces bridge,ether1,PPPoE_DIGI
  --counters-every 10s` durante 30 minutos hacia un InfluxDB 3 Core aislado, y un Prometheus 3.14
  haciendo scrape del colector cada 5 s y del agente directamente para las familias que el colector
  no podía recalcular entonces:

| Almacén    | Ventana    | Paneles | Fallan | Vacíos conocidos tolerados                                                                                                                                  |
| ---------- | ---------- | ------: | -----: | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| InfluxDB 3 | 30 minutos |     171 |      0 | 10 (los dos paneles de eventos de puerto, la consulta opcional de conntrack, los dos paneles de disparos, PSI, los cuatro dispositivos de bloques en reposo) |
| Prometheus | 30 minutos |     133 |      0 | 9 (los dos paneles de eventos de puerto, los dos paneles de conntrack de la API, PSI, los cuatro dispositivos de bloques)                                    |

Los 10 y 9 son ese despliegue sobre esa ventana. El SQL de los dos paneles de eventos de puerto se
validó ese mismo día contra una tabla sintética en ese mismo InfluxDB 3, porque el almacén en vivo no
tenía columna `kind` hasta que se le escribiera el primer registro de puerto clasificado; la tiene
desde el 2026-09-19, con las ocho clases. La página de dashboards de esa fecha registró además que
la exposición del propio agente llevaba la etiqueta `kind` solo cuando el propio agente clasificaba,
cosa que el del RB5009 no hacía entonces; hoy los agentes no sirven exposición.

- **2026-09-17, batería de contenedores**: los cinco dashboards importados en un Grafana real sobre
  los almacenes que llenó la batería, preguntando a cada panel: devolvieron datos 57, 98, 136, 35 y
  28 paneles, y no falló ninguno.
- **2026-09-21, Grafana 12.3.0**: `import` contra el almacén InfluxDB 3 en vivo y después `check` sobre
  una ventana de 15 min: 167 paneles devolvieron filas, los 9 vacíos conocidos salieron vacíos, y el
  indicador de detecciones del Overview salió vacío porque el almacén no tenía ninguna detección en
  esa ventana, que es el único caso que `check` señala y que un navegador lee como el «none» sano.
- **2026-09-24, el Grafana de producción**, cuyo endpoint de salud informaba de la 13.2.2 más tarde
  ese mismo día: el dashboard de InfluxDB importado y capturado a 390x844 y a 1600x1000 para comprobar
  el texto de 32 px de los paneles stat y la serie temporal de memoria. Con el tamaño automático de
  Grafana, un simple "0" se dibujaba de unos 60 px de alto a 390x844 y cada panel stat ocupaba cerca
  de un tercio de la pantalla; con el tamaño fijo, los números se leían a un tamaño normal en los dos.
  No se hizo recuento de insignias fila a fila, no se midió la altura del Overview y los otros cuatro
  dashboards no se capturaron.
- **2026-09-25, Grafana 12.3.0, 13.2.1 y 13.2.2 sobre un InfluxDB 3.11.2 Core desechable**:
  - La fila no disponible tal como estaba en 1.3.0 envió cinco consultas y pintó cinco insignias
    `table … not found` en 12.3.0 y 13.2.1; con sus consultas publicadas ocultas no envió ninguna ni
    pintó ninguna, y 13.2.2 hizo lo mismo en un segundo renderizado.
  - Una consulta de detecciones contra una tabla `mikroscope_detection` que falta no puede escribirse
    de forma que evite el error de planificación de InfluxDB 3: `WHERE false`, un `UNION ALL` y una
    guarda `EXISTS` sobre `information_schema` fallaron todas al planificar. En 13.2.1 la capa que
    falla no mostró nada en el dashboard y escribió en el log de Grafana una línea de nivel error
    `Partial data response error` por carga. 12.3.0 nunca envió la consulta de esa capa, con la tabla
    o sin ella ([problema conocido](https://jmrplens.github.io/mikroscope/es/about/status/#encontrado-y-sin-corregir)).
  - Un `import` con sondeo desde 1.3.0 quitaba las consultas de un panel que faltaba, y Grafana
    12.3.0 le da a un panel sin consultas una por defecto: el plugin de InfluxDB le respondió
    `No SQL statements were provided in the query string`, como una insignia roja. 13.2.1 no envió
    nada por ese mismo panel.
  - Elasticsearch 9.5.3: la búsqueda de la variable Host, escrita hasta 1.3.0 como un objeto JSON,
    salía de 13.2.1 y 13.2.2 como una consulta vacía respondida con 400
    `invalid query, missing metrics and aggregations`, y 12.3.0 no la enviaba; abierto sin
    `?var-host=`, seis paneles del Overview fallaban con `Failed to parse query [host.keyword:]`.
    Escrita como la cadena JSON que analiza la fuente de datos, Host se llenó desde el índice y ningún
    panel mostró insignia en ninguna de las tres.
  - Un panel de InfluxDB que agrupa con `$__dateBin` con un paso por debajo del segundo dibujó un bin
    de 0 segundos y volvió vacío, en `check` y en un navegador con el zoom en unos pocos minutos, en
    13.2.1 y 13.2.2.
- **2026-09-25, el Grafana 13.2.2 de producción contra el almacén InfluxDB 3 de referencia**, con una
  compilación que oculta las consultas de la fila no disponible: `dashboards check --window 1h`, con
  el sondeo y con `--no-probe`, dio 164 paneles con filas, 12 vacíos conocidos tolerados y 1 fallo,
  "Detections in the window", porque el almacén no tenía ninguna detección en esa hora. Sin el
  sondeo, los cinco paneles no disponibles salen como `none … rows=0 frames=0` sin texto de error,
  donde 1.3.0 imprimía `400 … table … not found`; los dos paneles de disparos respondieron
  `mikroscope_trigger not found`, porque ese almacén no tiene tabla de disparos. El SQL de la anotación
  de detecciones devolvió 44 filas en 6 horas. Repetido más tarde ese día, después de que los ficheros
  sin sondeo de los otros cuatro almacenes recuperaran sus consultas de la fila no disponible, dio los
  mismos recuentos, y la capa de detecciones 32 filas en 6 horas; el fichero de InfluxDB comprobado
  era idéntico byte a byte al de la primera vez.
- **2026-09-25, batería de contenedores** (Grafana 13.2.1, Prometheus 3.14.0, PostgreSQL 18.6,
  graphite-statsd 1.1.10-5, Elasticsearch 9.5.3): las consultas no disponibles de los ficheros del
  repositorio, contra almacenes que no tenían nada para ellas, respondieron todas 200 sin error, y en
  Elasticsearch todos los puntos fueron 0, tanto si otro router del mismo índice había mapeado el
  campo como si no. En PostgreSQL la consulta de la capa de detecciones respondió 200 sin filas sobre
  una ventana anterior a cualquier detección, y 10 filas sobre la de la propia ejecución. Las dos
  fueron consultas por la API de Grafana, no renderizados.
- **La continuidad** se deriva del número de secuencia de cada muestra, y encontró 4 493 ticks
  perdidos y un reinicio en la captura del 2026-09-11/12 de los que el registro de huecos del colector
  no decía nada.
- **El rango por defecto** es de 3 horas porque `now-15m` abría 108 paneles vacíos con el agente
  parado, y con el agente en marcha dibujaba muros de ruido ilegibles de muestras de 100 ms (la fecha
  no consta).

### Reglas de alerta

**Solo la forma de InfluxDB 3 de las reglas se ha cargado en Grafana y se ha visto evaluarse, el
2026-09-21 contra el almacén del mantenedor; las formas de Prometheus y PostgreSQL nunca.** Las reglas
son 14 para InfluxDB
3, 15 para Prometheus
y 10 para PostgreSQL.

- **La carga del 2026-09-21**, en Grafana 13.2.1 contra el almacén InfluxDB 3 en vivo, tenía las doce
  reglas de InfluxDB de esa fecha y destapó dos defectos, los dos corregidos en 1.1.0. `coalesce()`
  sobre el agregado sin signo que escribe el destino de InfluxDB devolvía HTTP 200 sin marcos, que
  Grafana lee como NoData y estas reglas como OK: siete de las doce no podían saltar nunca,
  `mikroscope-l2-loop` entre ellas, mientras el mismo SQL contra `/api/v3/query_sql` devolvía 109 con
  la firma del bucle en vivo. Y la regla de conntrack nombraba `limit_objs`, la columna del destino
  SQL, donde el destino de InfluxDB escribe `limit`; la página de reglas de alerta había predicho ese
  defecto antes de confirmarse. Tras la corrección las doce devolvieron un valor, y
  `mikroscope-l2-loop` pasó a Alerting a las 16:58:50Z con la firma `own-address` en vivo; la lista de
  instancias de Grafana para esa regla seguía llevando `Normal (NoData)` de las 16:56:50Z, de la
  ejecución anterior a la corrección.
- **Consultas ejecutadas a mano contra el almacén en vivo el 2026-09-21**: `mikroscope-l2-loop` dio
  109 en su propia ventana de cinco minutos, con la firma `own-address` en `ether2` corriendo sin
  parar a unos 0,5 registros/s desde el 2026-09-19; `mikroscope-port-link-down` dio 3 en la ventana que
  contiene una caída de enlace real en `ether7` a las 16:33:49 y 4 en el grupo de cuatro de `ether4`
  de las 09:19 del 2026-09-20. Las dos tienen umbral 0 con `gt`, así que las dos condiciones se
  cumplieron.
- **Las dos reglas que añadió 1.2.0** no estaban en esa carga, y ningún Grafana las ha evaluado
  desde entonces. Su SQL de InfluxDB se contrastó con datos pasados del almacén de referencia:
  `mikroscope-bridge-port-dark` devolvió 1 en tres ventanas dentro del bucle y 0 después, y marcó
  `sfp-sfpplus1` en 204 intervalos de diez minutos y `ether2` en 376 entre el 2026-09-19 11:13 y el
  2026-09-23 22:44 UTC, las dos fases del bucle de capa 2 de esa semana, y ningún otro puerto.
  `mikroscope-wakeup-storm` devolvió 0,94–0,95 en dos ventanas sanas, nunca pasó de 1,81 en 551
  ventanas de diez minutos con un día completo detrás (del 2026-09-20 al 23), y se abrió en 35,7 con la
  tormenta de despertares del 2026-09-23; se apagó cuando la nueva tasa pasó a ser la base, al cabo de
  unas cuatro horas. Su PromQL solo se comprobó en su sintaxis. De la forma PostgreSQL de la regla de
  despertares no consta ninguna ejecución, y la regla del puerto oscuro no tiene forma PostgreSQL: la
  1.2.1 la quitó, porque la tabla de contadores de interfaz del destino SQL no tiene las columnas que
  lee.
- **La regla de detecciones** ya no salta con `microburst` ni con `ipc-collapse`, que describen cómo
  lleva el tráfico un router sano: del 2026-09-23 10:30 al 2026-09-24 10:30 UTC en el RB5009 fueron 64
  de 71 detecciones, y con ellas la regla saltó en 43 de 288 ventanas de cinco minutos; sin ellas, en
  6.
- **La regla de salida**: un puerto de 1 GbE hacia un servidor perdió 3 337 paquetes en seis ráfagas
  de un segundo a lo largo de 6,5 h, con picos de 436 paquetes/s (2026-09-19), visible en el panel de
  cola de salida y, con razón, sin ser una alerta.
- **La regla térmica** lee el punto de disparo crítico de la propia zona, 105 °C en el RB5009.

### `forward --grafana`

**`forward --grafana` se ha ejecutado contra el Grafana del mantenedor (2026-09-19, InfluxDB 3) y
contra el de la batería de contenedores para los cinco almacenes (2026-09-20, y con el código de la
1.5.0 el 2026-09-27). `dashboards publish` solo se ha ejecutado allí, el 2026-09-27, sobre lo que
`forward --grafana` acababa de crear.** El 2026-09-20 se apuntó el colector a un Grafana real y a
cada uno de los cinco almacenes por turno, se le dejó crear la fuente de datos, y después
`dashboards check` pasó la consulta de cada panel por la API de Grafana contra la fuente de datos
que había construido el colector. Los cinco respondieron sin error de fuente de datos tal como lo
leía la prueba de esa fecha: buscaba `flightsql: Unauthenticated`, el error de TLS que se cita más
abajo y `err` con un espacio a cada lado, que no es ninguna marca que imprima `check`, así que un
error redactado de cualquier otra forma la pasaba. La misma ejecución encontró un defecto que
ninguna prueba unitaria tenía: un colector que escribía en un PostgreSQL vivo por `--postgres` y en
nada más no publicaba nada y decía «there is nothing to publish», porque la lista de almacenes solo
conocía `--sql`. Contra un almacén InfluxDB en HTTP plano, una fuente de datos sin `insecureGrpc`
respondía a todos los paneles
`tls: first record does not look like a TLS handshake` mientras el almacén estaba perfectamente
(medido el 2026-09-19).

El 2026-09-27 la prueba se ejecutó con el código de la 1.5.0 (el commit `ffb934e`, cuyo código Go es
el de la publicación; la ejecución 36344009521 de `e2e.yml`) contra Grafana 13.2.1, InfluxDB 3.11.2
Core, Elasticsearch 9.5.3, PostgreSQL 18.6, Prometheus 3.14.0 y graphite-statsd 1.1.10-5, y para
entonces fallaba con cualquier línea `FAIL` de `check` que llevara un error. Para cada almacén por
turno, `forward --grafana` creó la fuente de datos y publicó el dashboard, `check` pasó cada panel
contra esa fuente de datos sobre una ventana de 15 minutos, y `dashboards publish`, con las mismas
opciones de almacén y de Grafana, salió con código 0, dio la fuente de datos como `unchanged` e
imprimió la dirección del dashboard. Ningún panel que `check` cuenta como fallido llevaba un error;
un panel que se espera vacío se marca `none` cuando no devuelve filas o devuelve un error, y la
prueba solo lee esas líneas en busca de los dos errores de InfluxDB de arriba. La fuente de datos de
Elasticsearch fue la del colector, con `@timestamp` como campo de tiempo (la de la 1.4.0 nombraba
`time`, un campo que no lleva ningún documento), y su `check` salió con código 0; en InfluxDB,
PostgreSQL, Prometheus y Graphite, 5, 20, 33 y 4 paneles no devolvieron filas en la ventana, sin
error. No se ha probado en la batería: la cabecera `Authorization` que envía la fuente de datos de
Elasticsearch, porque su Elasticsearch funciona sin autenticación; una fuente de datos que lleve un
token o una contraseña, que ningún almacén de allí tiene; ni una ejecución que publique más de un
almacén, porque cada ejecución publicó uno.

### `uninstall --targets`

**`uninstall --targets` retiró solo lo que escribió este proyecto en la batería de contenedores
(2026-09-20, y `--targets data` de nuevo con el código de la 1.5.0 el 2026-09-27), y no se ha
ejecutado contra el almacén de producción del mantenedor.** La batería comprueba que una tabla que
este proyecto no escribió, en la misma base de datos y el mismo esquema, ni se lista ni se borra.
Ejecuta la orden solo con `--targets data`, contra PostgreSQL e InfluxDB 3, sin router y sin
Grafana. Lo que la 1.5.0 cambió en la orden fuera de ese camino solo tiene pruebas unitarias:
rechaza `--grafana-dry-run`, lista los objetivos de Grafana y de los almacenes antes de tocar el
router, se detiene ante un Grafana que no pudo leer, que la 1.4.0 contaba como uno sin nada que
retirar, y lee la dirección de Grafana de `GRAFANA_URL` cuando
`MIKROSCOPE_GRAFANA_URL` no está definida.

### Baterías de pruebas

**Cuatro baterías no necesitan router: la unitaria y la de extremo a extremo se ejecutan en la CI en
Linux, macOS y Windows contra árboles capturados y simulaciones, otra contra nueve almacenes reales
en docker compose, completa por primera vez el 2026-09-16, y otra ejecuta la CLI y el agente contra
un RouterOS virtual, en verde por primera vez el 2026-09-26 y ejecutada por primera vez en los
runners de GitHub el mismo día.** Qué demuestra cada una y cómo ejecutarla está en
[Baterías de pruebas](https://jmrplens.github.io/mikroscope/es/reference/testing/).

- **De extremo a extremo**: los dos binarios contra un árbol `/proc` capturado del RB5009 y un agente
  simulado, con un receptor por cada protocolo de destino que comprueba los bytes. No necesita router,
  ni Grafana, ni red, y se ejecuta en la CI tanto en macOS y Windows como en Linux, que es donde se
  notaría una diferencia en el nombre del ejecutable, en los ficheros que escriben los destinos de
  fichero y SQL, o en cómo se detiene un proceso hijo. Cada destino se prueba contra un receptor local
  desde el 2026-09-12, en el equipo de desarrollo amd64. La batería antes hacía scrape del agente y del
  colector, y ahora comprueba solo el colector.
- **Almacenes** (`make test-e2e-docker`): el colector, contra el mismo agente enlatado y con la capa
  de la API apagada, hacia Loki 3, el OpenTelemetry Collector, graphite-statsd, Elasticsearch 9,
  Telegraf 1.39 por HTTP, PostgreSQL 18 (con `--sql`, y con `--postgres` desde que ese destino llegó el
  2026-09-21), InfluxDB 3 y Prometheus, con el destino de fichero como el oráculo contra el que se
  comparan los demás. Cada almacén se vuelve a leer por su propia API, después se importan los cinco
  dashboards en Grafana y la consulta de cada panel pasa por la API de Grafana; la batería hace que
  `forward --grafana` publique las cinco fuentes de datos y comprueba sus dashboards contra ellas,
  después, desde el 2026-09-27, ejecuta `dashboards publish` con las mismas opciones de almacén y de
  Grafana, que tiene que salir con código 0 y nombrar la fuente de datos y el dashboard de cada
  almacén, y vuelve a vaciar los almacenes con `uninstall --targets data`. Necesita Docker y ningún
  router: las muestras son enlatadas, así que la
  ejecución es reproducible en cualquier máquina. La primera ejecución completa, el 2026-09-16,
  encontró un panel que nombraba dos columnas que el almacén solo tiene cuando se ejecutó la capa de la
  API: la tabla de eventos de puerto nombra `label` y `role`, que el destino escribe en una fila del
  registro del kernel solo desde el inventario de la capa de la API, y en InfluxDB 3 una columna que
  no está en la tabla hizo fallar la consulta con `Schema error: No field named label`, así que el
  panel no podía dibujarse. Las páginas de destinos registran el colector escribiendo en estos
  almacenes desde el 2026-09-17. En la máquina de desarrollo, el 2026-09-16, la pila se levantó en 55
  a 81 s con las imágenes ya descargadas, y la batería entera tardó de 75 a 100 s desde cero. La
  batería entró en la ruta de los pull requests el 2026-09-18. Hasta entonces se ejecutaba cada
  semana, a petición y antes de una publicación, y así llegó la 1.0.5 a `main` con dos pruebas de la
  batería leyendo todavía el `/metrics` del agente, que esa versión había quitado: todos los checks
  del pull request estaban en verde, y lo encontró la puerta de publicación. En la ejecución de
  publicación que falló tardó 2 min 37 s desde el inicio del trabajo hasta el resultado, contenedores
  incluidos; en el pull request #70, el 2026-09-27, 4 min 9 s. El OpenTelemetry Collector, que acepta JSON, es el único receptor OTLP real contra el que
  se ha ejecutado el destino. El 2026-09-20 los destinos SQL y PostgreSQL, ejecutados en paralelo
  hacia dos bases de datos, tenían 34 tablas coincidiendo byte a byte, cada columna de cada fila con
  un hash por fila sumado, más un `information_schema.columns` idéntico para todo el esquema.
- **Laboratorio virtual de RouterOS** (`make test-lab`): los verbos de despliegue de la CLI y el
  agente contra el Cloud Hosted Router 7.24.4 de MikroTik en QEMU, x86_64 y arm64 emulado:
  instalación por las dos vías de imagen, actualización, desinstalación, `--ephemeral` y
  `start-on-boot` a través de un corte de corriente, y cada escenario termina comparando el `/export`
  del router con el de su inicio. Prueba que el instalador es correcto; no es una placa, y ninguna
  cifra de [Coste del agente](https://jmrplens.github.io/mikroscope/es/about/status/#lo-que-cuesta-hoy-el-agente) ni de [Campañas](https://jmrplens.github.io/mikroscope/es/about/status/#campaigns) sale de él.
  El laboratorio, sus tiempos y sus primeras ejecuciones en los runners de GitHub están en
  [Laboratorio virtual](https://jmrplens.github.io/mikroscope/es/about/status/#virtual-lab), y sus escenarios en
  [Baterías de pruebas](https://jmrplens.github.io/mikroscope/es/reference/testing/#el-laboratorio-virtual-de-routeros).
- **Fixtures de los destinos**, no un router: los tamaños de SQL, OTLP, Graphite, Elasticsearch y
  Telegraf de [Otros destinos](https://jmrplens.github.io/mikroscope/es/sinks/other/) salen de fixtures de pruebas de dos
  núcleos del 2026-09-12. La cabecera SQL de las cuarenta y tres tablas, generada por el propio
  `header()` del destino el 2026-09-19, ocupa 10 482 B, 13 966 B con las sentencias de hypertable de
  TimescaleDB. Doce renderizados de un mapa de 8 nombres dieron 7 órdenes (2026-09-12), registrado
  en [`internal/sinks/telegraf.go`](https://github.com/jmrplens/mikroscope/blob/main/internal/sinks/telegraf.go).
- **El equipo de desarrollo** (amd64, kernel 6.12.107): `TestParsePressureReadsTheRunningKernel` y
  `TestParseSchedstatReadsTheRunningKernel` analizan el `/proc/pressure/{cpu,memory,io}` y el
  `/proc/schedstat` del propio equipo y los comparan con una segunda lectura de esos mismos bytes, y se
  saltan la prueba donde los ficheros no están, que es el caso del RB5009. En ese equipo pasan. Su
  `/proc/pressure/cpu` lleva línea `full`, toda a cero al volver a leerla el 2026-09-24: la
  documentación de PSI del kernel dice que el `full` de CPU no está definido para el sistema entero y
  que se publica desde la 5.13 a cero, así que un kernel más antiguo no tiene esa línea y el analizador
  acepta las dos formas. Su PMU, registrada el 2026-09-21,
  tiene seis contadores, `cycles`, `instructions`, `cache-references`, `cache-misses`,
  `branch-instructions` y `branch-misses`, multiplexados, cada uno funcionando en torno al 84 % del
  tiempo que estuvo habilitado. Un intervalo de 100,3 ms llevó allí 11 ticks (2026-09-11/12);
  `sample_test.go` comprueba que la fracción de ocupación está limitada a 1.
- **El rearme del filtro de cambios**, contra el árbol de fixtures el 2026-09-15: las familias de
  medidores con suelo y `mikroscope_slab_limit_objects` estaban presentes en 6 de 6 scrapes desde 5 s
  después del arranque. El comentario de `ProcSource.ReArm`
  en [`internal/agent/source.go`](https://github.com/jmrplens/mikroscope/blob/main/internal/agent/source.go) registra la misma comprobación como cuatro scrapes desde
  t+5 s, 0 antes de la corrección y 4 de 4 después; no consta de qué ejecución es cada cuenta.
- **El generador de scripts**, 2026-09-27: `pnpm run rsc:check` renderiza en JavaScript los 20 casos
  de referencia de la especificación de pasos y compara byte a byte con la salida de Go cada script,
  las órdenes de cada paso, el orden de retirada, los valores y la línea de órdenes; un cambio de una
  línea en el renderizador le hizo informar de 72 fallos. `pnpm test:generator` hizo 168
  comprobaciones en Chromium sin interfaz (Playwright 1.63) contra el sitio compilado: los 20 casos
  puestos con los propios controles del formulario, los errores, el token, copiar, el uso solo con
  teclado, ninguna petición de red, y las descargas `.rsc`, que funcionan bajo la CSP meta del sitio.
  Una comparación puntual con el código de Go sobre 304 juegos de opciones coincidió en 301; los
  otros tres son entradas que la página rechaza y Go acepta (un prefijo `/030`, un umbral
  `busy>=.5` y una dirección IPv6 con IPv4 mapeada).
- **El sitio**, 2026-09-25: Chromium 153 sin interfaz pidió solo `favicon.svg`, y resolvió un `id` de
  manifiesto `./` a la raíz del origen; en Chromium y WebKit sin interfaz, con los dos esquemas, tras
  elegir en el selector, tras una elección guardada y una recarga, tras el botón del teléfono y sin
  JavaScript, la etiqueta `theme-color` tuvo el color de la cabecera todas las veces, donde el par
  separado por `prefers-color-scheme` al que sustituye tenía el color del otro tema tras cada elección.

## Rutas de instalación probadas

| Ruta                                   | RB5009UG+S+                                                                                                                                                                                                                                         | CHR x86_64, laboratorio                                                                      | CHR arm64, laboratorio                                                                              |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Descarga de Docker Hub, `--remote-image` | 2026-09-17, 7.24.2: `/healthz` a 2 ms; la imagen 1.0.1, enviada sin su host y descargada a través de `registry-url`. 2026-09-24, 7.24.4: la referencia con su host, con un `/container/add` escrito a mano, sin arrancar; ningún `install` completo | 2026-09-26: `install` en 9,6 s, descarga anónima con el `/container/config` de fábrica; 2026-09-27: S2, S4 y S5 | 2026-09-26: `install` en 10,3 y 10,2 s, descarga anónima; 2026-09-27: S2, S4 y S5 |
| Descarga de GHCR, `--remote-image`     | 2026-09-21, 7.24.4: **falló**, `auth error`                                                                                                                                                                                                         | 2026-09-26: descarga sin credencial de registro y con el host en `remote-image=`, `/healthz` 5 s después de empezar la instalación; 2026-09-27: S18 y S5 | 2026-09-27: S18 y S5 |
| `plan --rsc`, con `/import`            | 2026-09-17, 7.24.2: `/healthz` a 15 ms en sus primeras muestras, sin CLI en la instalación                                                                                                                                                          | 2026-09-26: `/healthz` 14 s después de empezar la subida; 2026-09-27: S4, y los quince guiones de referencia que el laboratorio puede ejecutar (S5); el script por defecto pegado en el indicador `] >`, y un script de tar sin su tar, que se detuvo antes de escribir nada | 2026-09-26: `/healthz` 9,1 y 9,5 s después de empezar la subida; el script era el de x86_64; 2026-09-27: S4 y S5 |
| Tar de la imagen, `--agent-tar`        | 2026-09-17, 7.24.2: el tar arm64 publicado, `/healthz` a 2 ms                                                                                                                                                                                       | 2026-09-26: el tar amd64 de la versión, 6 s; 2026-09-27: el tar de la rama, S3 y diez instalaciones seguidas; el tar amd64 de la versión comprobado con `sha256sum` y `cosign verify-blob`, y después instalado y actualizado | 2026-09-26: el tar arm64 de la versión, suma de comprobación como la publicada, 9,6 y 9,2 s; 2026-09-27: el tar de la rama, S3 y tres instalaciones seguidas |
| Generador de scripts                   | sin ejecutar | 2026-09-27: el script por defecto de la página, igual al de `plan --rsc`, y un script de tar con otros ajustes, cada uno descargado de la página compilada y pegado en el indicador `] >`; el agente respondió cada vez, y el `uninstall` de la CLI y el script de desinstalación de la página dejaron cada uno el `/export` como estaba | sin ejecutar |
| Instalación manual, terminal           | sin ejecutar | 2026-09-27: las órdenes de la página una a una, descarga del registro y tar; `/healthz` respondió, `status` reconoció la instalación por su manifiesto, y la retirada de la página no dejó nada; de nuevo con las dos reglas de `--expose`, y con las dos pertenencias omitidas | sin ejecutar |
| Instalación manual, WebFig             | sin ejecutar | 2026-09-27: las dos vías de imagen, cada formulario enviado; `/healthz` 200 cada vez; la descarga retirada por WebFig, el tar por `uninstall` leyendo el manifiesto que escribió WebFig; el `/export` como estaba tras cada una | sin ejecutar |
| Desde el repositorio                   | 2026-09-17, 7.24.2: `/healthz` a 2 ms; la ida y vuelta del 2026-09-12                                                                                                                                                                               | sin ejecutar                                                                                 | sin ejecutar                                                                                        |
| `--expose`                             | 2026-09-11: las dos reglas [verificadas](https://jmrplens.github.io/mikroscope/es/about/status/#verified-expose-rules); 2026-09-23, 7.24.4: una instalación desechable expuesta, actualizada sin token y retirada                                                                             | 2026-09-26: `/healthz` 200, `/capabilities` 401 sin el token y 200 con él; 2026-09-27: S8 y S14 | 2026-09-27: S8 y S14 |
| `uninstall`                            | 2026-09-17: verificado por recuento de propiedad tras cada ruta; el `/export` tras las cuatro, idéntico byte a byte al de antes                                                                                                                      | 2026-09-26, 1.3.1: fallaron 5 de 15 primeros intentos; un segundo lo limpió todo cada vez. 2026-09-27: cada primer intento limpio, tras cada ruta (F4) | 2026-09-26, 1.3.1: 8 de 8 primeros intentos limpiaron; con un cliente en `/stream` falló. 2026-09-27: cada primer intento limpio, tras cada ruta (F4) |

- **En el laboratorio, el 2026-09-27**, con el código posterior a la 1.3.1 (la sección 1.4.0
  del registro de cambios): la batería entera del laboratorio en las dos arquitecturas, con todas las
  pruebas superadas ([Tiempos del laboratorio](https://jmrplens.github.io/mikroscope/es/about/status/#lab-timings)). Tras cada ruta, las de descarga y tar
  de la CLI, una instalación desde el tar y después una actualización, un guion de `plan --rsc`
  importado, cada guion de referencia que el laboratorio puede ejecutar e instalaciones hechas por la
  CLI 1.3.1 publicada, `uninstall` dejó el `/export` igual al tomado antes de instalar y ninguna ruta
  de mikroscope en `/file`. La descarga de GHCR del 2026-09-26 registró `registry=ghcr.io`, una capa
  de 3 093 207 bytes y `download/extract done` 2 s después, con `/container/config` sin
  `registry-url` ni usuario.
- **Las ejecuciones de las páginas de instalación**, 2026-09-27, en el laboratorio x86_64, con el
  código posterior a la 1.3.1 y la imagen y el tar publicados del agente 1.3.1:
  - El script por defecto del generador respondió 8,8 s después de empezar a pegarlo. Su script de
    tar (nombre `gen2`, `172.30.11.0/30`, puerto 9200, las dos listas `none`, cadencia 20, disparos
    `busy>=0.9,oom`, un token generado en la página, `--expose` en 192.168.88.1,
    `--restart-max-count 3`, `--start-on-boot no`) era idéntico byte a byte al de `plan --rsc` para
    la línea de órdenes de la página, respondió en `172.30.11.2:9200` y borró su tar tras la
    extracción.
  - El script por defecto de `plan --rsc`, idéntico byte a byte a `pull-dockerhub.rsc`, instaló un
    agente en marcha tanto pegado como subido y después con `/import` (`Script file loaded and
    executed successfully`). El script de tar sin el tar se detuvo con
    `mikroscope: upload mikroscope.tar first` y no escribió nada.
  - Las órdenes de la página de instalación manual por terminal, cada una por separado: las dos vías
    respondieron, la espera de la vía del tar borró el tar tras la extracción, y una instalación
    manual con tar también la retiró `uninstall --yes` sin más. Un buscar y reemplazar de los
    marcadores que también reescribió las claves de la envlist hizo que la retirada dejara la envlist
    entera, sin avisar, y por eso la página dice que se reemplacen solo los valores.
  - La misma página otra vez, cuando ya escribía un manifiesto por vía de imagen y daba a `--expose`
    una sección: una descarga del registro expuesta en `192.168.88.1` con token, una instalación con
    tar y una descarga del registro con las dos pertenencias omitidas. Cada manifiesto que
    escribieron sus órdenes fue idéntico byte a byte al de la CLI con los mismos ajustes
    (`pull-dockerhub`, `expose-token`, `default-tar`, `lists-none`); `status` leyó cada uno de su
    manifiesto, el expuesto con sus dos reglas como de la instalación; `/capabilities` respondió 401
    sin el token y 200 con él; y la retirada de la página, primero las dos reglas, dejó la cuenta de
    sobrantes en 0 y `/export`, el residuo y `/file` iguales a la referencia.
  - Una instalación por WebFig dejó un `/export` igual al que dejó el `/import` del script de
    referencia, en las dos vías, salvo las dos direcciones MAC de la veth, que RouterOS elige al azar;
    `status` listó cada uno de sus objetos como de la instalación.
  - Las comprobaciones de la página sin conexión sobre los ficheros publicados de 1.3.1:
    `sha256sum --ignore-missing -c checksums.txt` OK y `cosign verify-blob` (cosign v3.1.3)
    `Verified OK`. Después `install` y `upgrade --agent-tar` con el tar amd64, 7 053 KiB subidos, y un
    `uninstall` limpio.
  - Instalaciones hechas por la CLI publicada 1.3.1: `status` leyó su forma de las etiquetas,
    `upgrade --remote-image` escribió un manifiesto, y `uninstall --yes` lo retiró todo, el directorio
    `mikroscope/` de 1.3.1 incluido.
  - `upgrade` sin `--remote-image` ni `--agent-tar` buscó Go para compilar el agente: no toma la
    imagen del manifiesto. Un segundo `install` en un router ya instalado no creó nada
    (`install done: 0 step(s) created`).
- **Las ejecuciones de las páginas de configuración**, 2026-09-27, laboratorio x86_64: `doctor` en
  un CHR de serie marcó MISSING solo la lista de interfaces `LAN`, con una solución que ofrece
  `--iface-list none`, y con las dos listas en `none` pasó cada comprobación. Las listas integradas se
  rechazaron antes de conectar. La comprobación de trampas contra los perfiles `advanced-firewall` y
  `advanced-firewall-range` nombró la regla que descarta las respuestas del agente, y su solución.
  Una lista de direcciones que no existía la creó la entrada de la instalación y ya no estaba tras
  `uninstall`. La primera ida y vuelta del sondeo marcó de 1,02 a 1,03 s en tres de seis
  instalaciones y 2 ms en las otras tres, y `status` un segundo después de 1 a 2 ms.
- **En el RB5009, el 2026-09-17**, las cuatro rutas se ejecutaron una tras otra, cada una con su
  propio nombre, su veth y su `/30` para no tocar nada de lo que ya había en el equipo, y cada una se
  retiró antes de la siguiente. `/healthz` se leyó desde el equipo del colector.
- **GHCR, el 2026-09-21**, una segunda instalación junto a la que estaba en marcha, con su propio
  `--name`, `--veth`, `--subnet` y `--port`. La CLI de esa fecha ponía en `remote-image=` solo el resto
  de la referencia, así que `registry-url` se apuntó a `https://ghcr.io` para la ejecución y se
  restauró después; `doctor` se negó primero con `MISSING registry-url is https://ghcr.io`. Con el
  registro apuntando a GHCR el router creó el contenedor y falló la descarga:
  `download/extract error: fetch manifest failed: getting https://ghcr.io/v2/jmrplens/mikroscope-agent/manifests/1.0.9 failed: auth error`.
  `/container/config` guarda un único usuario y contraseña para todos los registros, y el del RB5009
  es un login de Docker Hub. Desde el equipo del operador ese mismo día, contra el mismo paquete
  público, sin credencial devolvía 200 una vez obtenido el token anónimo, y con una credencial ajena
  403 en el endpoint del token. La ejecución encontró además que una instalación con `--remote-image`
  identificaba su contenedor por la referencia del registro, la misma cadena en cualquier
  instalación, así que una segunda instalación en un router se negaba como si la primera fuera de
  otro; ahora se identifica por su veth.
- **Los límites de Docker Hub**, leídos el 2026-09-24: 100 descargas anónimas cada 6 horas por
  dirección IPv4 o `/64` IPv6, y el token anónimo lleva las mismas 6 h (`pull_limit_interval` 21600),
  mientras que la cabecera `ratelimit-limit` del registro en un `HEAD` del manifiesto del agente decía
  `100;w=3600`. No se midió cuál de los dos aplica Docker. La cifra de una descarga por instalación
  sale de la regla de recuento de Docker y de una descarga hecha con `curl` desde el equipo del
  operador, no de una descarga de RouterOS.
- **Las fuentes de MikroTik sobre el registro por defecto**, leídas el 2026-09-24: el changelog de 7.18
  añade `registry-url=https://lscr.io`, el de 7.21.2 dice "changed default container registry to
  docker.io", ningún changelog de 7.21.3 a 7.24.4 menciona el registro, y la documentación de
  contenedores sigue dando `https://lscr.io/`. El CHR del laboratorio con 7.24.4 no tenía
  `registry-url` ni usuario e informaba `assumed-registry-url: docker.io`.

## Coste del agente

Con los valores por defecto de la instalación, 10 Hz, suelos por fuente por defecto y un anillo de
60 s, el agente cuesta **2,69 % de un núcleo y 13,2 MiB de
RSS**, leídos de su propio cgroup en régimen estacionario con el anillo lleno:

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-18 · ventanas de 300 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, la configuración que se envía —anillo de 60 s, límite de memoria derivado de él y el tope de contenedor de serie de 64M— con el colector reenviando a InfluxDB 3

Las ejecuciones medidas:

| cadencia | suelos | CPU de un núcleo | µs/muestra | RSS | ticks retrasados | huecos / descartes |
| --- | --- | --- | --- | --- | --- | --- |
| 10 Hz (por defecto) | por defecto | **2,69 %** | 2 685 | 13,2 MiB | **0** | 0 / 0 |

Eso está por encima del presupuesto de 2 % de un núcleo y dentro
del de 16 MiB de RSS. La campaña del 2026-09-15 estaba por encima en los dos, con
un anillo de 300 s y un límite de memoria fijo, antes de que 1.0.6 trajera el anillo de 60 s y el
límite derivado. El presupuesto de imagen es 8 MiB; la imagen publicada de
1.2.1 para arm64 mide 6,38 MiB ([`image`](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-image)). El
presupuesto es orientativo, no un contrato: el coste depende del equipo, del conjunto de fuentes y
del tamaño del anillo.

Dos reglas mantienen honesta una cifra de coste. Espera primero a que se llene el anillo
(`BUFFER_S`): en el RB5009, con un límite blando de memoria de 14 MiB, una lectura tomada en el primer
minuto tras la instalación dio un 1,47 % de un núcleo frente a un 9,38 % en
régimen estacionario. Y lee el coste del `/metrics` del colector, o de `cpu_us` y `rss` en
`mikroscope_self` en el almacén que uses, en vez de un `/snapshot` grande, cuya respuesta de ~1,9 MB
tiene que serializar el agente. El procedimiento está en
[Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/#medirlo-en-tu-propio-equipo).

### Coste por configuración

Todas las filas se midieron en el mismo RB5009 a 10 Hz, y cada una es una ventana sin dispersión
registrada.

| Configuración                                                            | CPU de un núcleo                                                       | RSS                            | Medido     | Nota                                                                                                          |
| ------------------------------------------------------------------------ | ---------------------------------------------------------------------- | ------------------------------ | ---------- | ------------------------------------------------------------------------------------------------------------- |
| Cada fuente leída en cada tick                                           | 2,43 %                                                                 | no registrado                  | 2026-09-12 | por encima del presupuesto                                                                                    |
| Anillo lleno, `MEM_LIMIT_MB` 14                                          | 9,38 % (9 374 µs/muestra) | no registrado                  | 2026-09-12 | un anillo de 300 s de líneas de unos 2,4 kB, la línea de esa fecha, ocupa ~7,3 MB; el GC de Go corre sin pausa |
| Anillo lleno, `--mem-limit-mb 40`, `--memory-max 64M`                    | 1,39 % (1 388 µs/muestra) | 25,13 MiB                      | 2026-09-12 | 0 ticks retrasados                                                                                            |
| Contadores PMU activados, un `forward` en marcha escribiendo en InfluxDB | 1,72 %                                                                 | no registrado                  | 2026-09-12 | 0 ticks retrasados; 2 400 muestras reenviadas, 0 huecos, 0 descartes                                          |
| Los valores por defecto de la instalación                                | 2,69 %                                         | 13,2 MiB | 2026-09-18 | la cifra de arriba                                                                                            |

## Campañas

Cada campaña en una entrada: el equipo, la versión de RouterOS, la fecha y las condiciones, las
cifras que citan de ella las guías y lo que encontró. Una cifra de una guía enlaza aquí su campaña.

### Coste y cadencia

#### Cadencias con la configuración de serie

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-18 · ventanas de 300 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, la configuración que se envía —anillo de 60 s, límite de memoria derivado de él y el tope de contenedor de serie de 64M— con el colector reenviando a InfluxDB 3

- `read.under2ms` 97,7 %
- `read.floorOver5ms` 1,45 %
- `read.100hz.meanMs` 1,2 ms
- `read.100hz.worstMs` 17,9 ms
- `load.ordinary` 19 Mbit/s
- `run.10hz.cpu` 2,69 %
- `run.10hz.rss` 13,2 MiB
- `run.10hz.usPerSample` 2 685 µs
- `run.10hz.slippedPct` 0,000 %
- `run.20hz.cpu` 4,61 %
- `run.20hz.rss` 15,4 MiB
- `run.20hz.usPerSample` 2 303 µs
- `run.20hz.slippedPct` 0,000 %
- `run.50hz.cpu` 9,63 %
- `run.50hz.rss` 23,3 MiB
- `run.50hz.usPerSample` 1 926 µs
- `run.50hz.slippedPct` 0,000 %
- `run.100hz.cpu` 16,83 %
- `run.100hz.rss` 45,7 MiB
- `run.100hz.usPerSample` 1 684 µs
- `run.100hz.slippedPct` 0,017 %
- `run.50hz-floor.cpu` 22,56 %
- `run.50hz-floor.rss` 25,1 MiB
- `run.50hz-floor.usPerSample` 4 511 µs
- `run.50hz-floor.slippedPct` 0,027 %
- `run.100hz-floor.cpu` 42,70 %
- `run.100hz-floor.rss` 49,5 MiB
- `run.100hz-floor.usPerSample` 4 270 µs
- `run.100hz-floor.slippedPct` 0,593 %

Seis ventanas de 300 s, a 10, 20, 50 y 100 Hz y a 50 y 100 Hz con `FLOOR_HZ`, ninguna de las cuales
perdió una muestra: [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/) tiene la tabla. La WAN
llevaba de media unos 19 Mbit/s durante los 44 minutos de la campaña, con picos
de 933 Mbit/s.

#### Cadencias hacia tres destinos

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

Cinco ejecuciones de cadencia a 10, 50 y 100 Hz con el colector escribiendo a la vez en un fichero,
en una exposición Prometheus y en InfluxDB 3; todos los destinos informaron de 0 huecos y 0
descartes. El valor por defecto de la instalación a 10 Hz de esa fecha costaba un 2,85 % de un núcleo
y 31,3 MiB de RSS, con un anillo de 300 s y un límite de memoria fijo de 40 MiB; 50 Hz necesitó
`--memory-max 96M` y 100 Hz `128M`. La WAN llevaba unos 30 Mbit/s, por la tarde. La cifra de la
instalación por defecto que citan las guías es de `rates-2026-09-18`, no de esta campaña.

#### Límite de memoria y recolector

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-12 · 10 Hz, anillo de 300 s lleno, las mismas fuentes en las dos ejecuciones; solo cambian los límites de memoria

- `gc.tight.cpu` 9,38 %
- `gc.tight.us` 9 374 µs
- `gc.roomy.cpu` 1,39 %
- `gc.roomy.us` 1 388 µs

El mismo agente, anillo y fuentes con un límite blando de 14 MiB y después con margen:
[Coste por configuración](https://jmrplens.github.io/mikroscope/es/about/status/#coste-a-10-hz-por-configuración) tiene las dos filas.

#### Línea del anillo con todas las fuentes

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-17 · una línea del anillo con todas las fuentes activas, privileged, 10 Hz, 4 núcleos, `IRQ_TOP_K=8` —incluidos el PMU y la propia temporización del muestreador, que la medición del 2026-09-12 no tenía

- `ring.lineKB` 3,5 kB
- `ring.lineBytes` 3 230 B
- `ring.lineChargedBytes` 3 456 B
- `relay.maxBatch` 13

3 230 B medidos, cobrados desde la clase de tamaño de 3 456 B de Go. Los 2 439 B del 2026-09-12
subestimaban el anillo un 35 %, y el agente funcionaba con 32,9 MiB de RSS donde bastaban 24,3. Una
línea sin PMU cuesta un 35 % menos. El tamaño de las líneas con los suelos por fuente actuales no se
ha medido.

#### Primera medición de la línea del anillo

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-12 · la línea media precodificada del anillo con todas las fuentes de esa fecha, las lentas refrescadas a 1 Hz, privileged, 10 Hz, 4 núcleos, `IRQ_TOP_K=8`

La línea media antes de que llevara la PMU y la temporización del propio muestreador, redondeada a
unos 2,4 kB en las guías de esa fecha.

#### Bucle de shell de busybox

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · un bucle de shell de busybox leyendo a 10 Hz el conjunto de ficheros que leía entonces el agente, siete ficheros, con un fork por iteración, en un contenedor del router; dos ejecuciones de 60 s

- `busybox.cpu` 2,40–2,48 %
- `procread.ms` 0,77 ms

Dos ejecuciones de 60 s, 2,40 y 2,48 % de un núcleo, del `cpu.stat` del cgroup frente a
`/proc/uptime`; las lecturas en sí tardaban unos 0,77 ms por muestra. No se ha vuelto a medir con el
conjunto de fuentes actual del agente:
[Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/#lo-que-cuesta-la-alternativa).

#### Coste de una conexión SSH

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.1 · 2026-08-26 · una conexión ssh, mientras dura

- `ssh.connectCpu` 20–27 %

Medido antes de que existiera el agente, con RouterOS 7.24.1. Con 7.24.2, el 2026-09-11, el mismo
coste apareció en `/tool profile` como un 17–33 % en una o dos instantáneas, no en una ventana medida:
[Coste de SSH](https://jmrplens.github.io/mikroscope/es/cost/#ssh-cost).

#### Perfil del router con la capa de la API

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · `/tool profile duration=60s cpu=total`, una vez con el colector parado y otra con él en marcha con `--interfaces bridge,ether1,PPPoE_DIGI --counters-every 10s --api-every 1s`; descartadas las cinco primeras instantáneas de un segundo de cada perfil, porque llevan la conexión SSH que lo pidió

Un perfil de 60 s por condición, sin dispersión:
[Coste de la capa API](https://jmrplens.github.io/mikroscope/es/cost/#api-tier-cost).

#### Tamaño de la imagen publicada

2026-09-24 · tar de la imagen arm64 de la versión v1.2.1 publicada, el fichero que carga el router

- `image.size` 6,38 MiB

Medido con `ls -l` sobre el artefacto de la versión v1.2.1, con su suma de comprobación verificada
contra el `checksums.txt` firmado: 6 690 304 B, de los que el binario del agente ocupa 6 684 832 B.
Los tar de armv5 y armv7 miden 7 214 592 B y el de amd64 7 222 784 B. El trabajo `agent-size` de la CI
mantiene el binario del agente, que es todo lo que lleva la imagen, por debajo de 8 MiB en arm64,
armv7 y amd64.

#### Tamaño de la imagen en 1.0.0

fecha no registrada · tamaño de la imagen del agente de la versión 1.0.0

- `image.size.v100` 6,1 MiB

La cifra que dan las notas de la versión 1.0.0; la v1.0.0 se etiquetó el 2026-09-16. Las imágenes
entre ella y la 1.2.1 no tienen medida propia.

### Kernel y fuentes

#### Ficheros de contabilidad del kernel

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · `/proc/pressure` y `/proc/schedstat` ausentes

La columna `irq` de `/proc/stat` vale siempre 0 en este kernel, así que el tiempo de IRQ hardware
está dentro de `system`. `USER_HZ` es 100, así que un tick son 10 ms y los escalones de ocupación de
las guías son aritmética a partir de él. Los ficheros que dentro del contenedor son del router se
establecieron ese mismo día ([Vista desde el contenedor](https://jmrplens.github.io/mikroscope/es/about/status/#vista-desde-el-contenedor)).

#### Contenedor de descubrimiento privilegiado

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · un contenedor de descubrimiento privilegiado leyendo una vez el `/proc` del host, antes de que el agente leyera slabinfo

- `conntrack.slabDiscovery` 6 582

La ronda que no encontró ningún camino de trazado ([Kernel y PMU](https://jmrplens.github.io/mikroscope/es/about/status/#kernel-y-pmu)), y cuyo `slabinfo`
es el de `testdata/proc/rb5009`: `nf_conntrack` 6 582 activos de 8 075.

#### Espacio de red con privileged

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-12 · `privileged=yes` no cambia el espacio de nombres de red

Dentro del contenedor `/proc/net/dev` contaba la veth, 4 paquetes mientras el router reenviaba
millones, con `privileged=yes` y sin él.

#### Cadencias de las fuentes en una noche

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-13 · una captura de 10,5 h a 50 Hz durante una noche en reposo, con el reloj fijo

- `thermal.quantumC` 0,42 °C

La captura que fijó el suelo de 6 Hz al que se ralentiza `/proc/slabinfo`, la frecuencia a la que
cambiaba su caché más rápida, `nf_conntrack`. Los niveles de memoria se movían unas 24 veces por
segundo. Es una placa, una noche en reposo, con el reloj fijado en el ajuste del mantenedor: «cpufreq
nunca cambió» significa que no cambió esa noche.

#### Ventana de promedio de `cpu-load`

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-15 · `/system/resource` consultado a 1 Hz frente a la proporción de ocupación por núcleo del agente a 10 Hz, en dos horas distintas

- `cpuLoad.window1` 1,0 s
- `cpuLoad.delay1` 0,6 s
- `cpuLoad.r1` 0,9825
- `cpuLoad.samples1` 3 499
- `cpuLoad.window2` 1,1 s
- `cpuLoad.delay2` 0,1 s
- `cpuLoad.r2` 0,9734
- `cpuLoad.samples2` 3 594

El mejor ajuste de cada hora: una media móvil de 1,0 s que llegó a la
API con 0,6 s de retardo (r = 0,9825
sobre 3 499 muestras de la API), y una media
de 1,1 s que llegó con 0,1 s de retardo
(r = 0,9734 sobre 3 594). `/system/resource` publica
`cpu-load` como un porcentaje entero, y la serie de la API se correlacionó con la proporción de
ocupación por núcleo del agente, los mismos jiffies de `/proc/stat`, para una serie de longitudes de
ventana y retardos. Ensanchar la ventana solo empeoró el ajuste: 1,5 s dio 0,955; 2 s, 0,919; 5 s,
0,822; y 8 s, 0,791. Una media de sesenta segundos queda descartada dos veces: su correlación es
0,238, y en el mayor salto de carga del día el kernel pasó de 5 % a 27 % en un segundo y `cpu-load` de
5 a 26 en ese mismo segundo, y de 22 % a 6 % al bajar con la misma rapidez. La
[documentación de `/system/resource`](https://help.mikrotik.com/docs/spaces/ROS/pages/40992875/Resource)
de MikroTik define `cpu-load` como el porcentaje de recursos de CPU usados, sumando todas las CPU, y
no nombra ninguna ventana (leída el 2026-09-24).

### Grabación y transporte

#### Grabación de un bucle de script

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-12 · un `record` de 60 s a 10 Hz, 600 muestras en 59,9 s, un bucle de script de RouterOS lanzado por ssh y el log del router añadido como marcadores

Exactamente 600 muestras, 0 huecos y un desfase de reloj de −7 ms. Un bucle de RouterOS por script
(`:for … 400 000`) se vio como la carga de un núcleo entero al 100 % de t = 21,0 a 25,8 s, con la
muestra de 25,8 s marcando alrededor del 60 %, y el inicio y el final resueltos a 100 ms. Los
marcadores del log del router explicaron una meseta de 2 s entre 15 y 17 s que nadie había provocado:
el planificador `ensure-ipv6-nd-prefix`. Las horas del log llegaron por la API como fechas completas
([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-log-time-full-date)).

#### Grabación en reposo

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`

La grabación de la que sale el gráfico de
[Línea base en reposo](https://jmrplens.github.io/mikroscope/es/playbooks/idle/#gráfico-grabado).

#### Duración de una conexión `/stream`

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.4 · 2026-09-21 · tres conexiones `GET /stream` contra el agente instalado a 10 Hz, abiertas desde el equipo del operador en la LAN y mantenidas hasta que el servidor las cerró

- `stream.lifetime` 30,01–30,06 s
- `stream.lines` 304–306

Agente 1.0.9 a 10 Hz. Cada conexión terminó en el tiempo de escritura de 30 s del servidor, le
quedara lo que le quedara por enviar, así que quien consuma `/stream` reconecta con el último `seq`
que vio.

#### Límite del fetch del relay

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · `/tool fetch output=user` llamado por la API binaria; cada llamada tardó o unos 3 ms o alrededor de 1 s, y más o menos la mitad tardó 1 s

- `relay.replyMaxBytes` 64 512 B

`/tool fetch output=user` truncó el cuerpo sin avisar en 64 512 B con cuerpos de 64 K, 256 K, 1 M y
4 M.

#### Tamaño de una muestra en protocolo de líneas

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · una muestra del kernel a 10 Hz renderizada en protocolo de líneas de InfluxDB, con el conjunto de fuentes que tenía el agente en esa fecha

Unos 1,2 KiB por muestra, la cifra a partir de la cual los destinos de InfluxDB y Telegraf
dimensionan su presupuesto de bytes. No medido por encima de 10 Hz, ni vuelto a medir con el conjunto
de fuentes actual.

### Red y fallos

#### Lecturas de los casos reales

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

- `loop.eventsBefore` 1,49 /s
- `loop.eventsAfter` 0,03 /s
- `loop.helloGap` 2,00–2,01 s
- `conntrack.slab` 6 287

Las lecturas sobre las que se construyen los [casos reales](https://jmrplens.github.io/mikroscope/es/playbooks/idle/), de un
kernel aarch64 en una placa con 1 GB de RAM; donde se provocó un fallo, el caso real dice cómo. Tres
casos llevan además un gráfico del almacén InfluxDB de referencia, cuyo historial empieza el
2026-09-19: la vuelta del bucle, la comprobación cruzada de conntrack y el puerto que pierde tramas.
El puerto que pierde tramas es una campaña aparte, una semana después, leída en los contadores de
puerto de la capa de la API y no en el agente. `time_squeeze` no era cero ni siquiera en reposo.
Mientras el reflejo de capa 2 estaba activo, el log del kernel iba
a 1,49 /s, y una pareja «blocking state» y luego «learning state» llegaba
dentro de un mismo tick de 100 ms con el mismo nivel, así que su orden dentro del tick es la señal. La
tabla de conntrack tenía 6 287 entradas, un 0,65 % del techo de 966 656
que el kernel informó el 2026-09-14.

#### Distribución de los squeezes de softnet

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · 3 738 704 muestras por CPU en 24 h a 10 Hz, `time_squeeze` de softnet por muestra, 0 descartes en toda la ventana

- `squeeze.backgroundOne` 11,2 %
- `squeeze.backgroundTwo` 1,2 %
- `squeeze.exactlyThree` 0,21 %

Las 24 h terminaron a las 07:00 UTC del 2026-09-16. `time_squeeze` era 0 en el 87,3 % de las muestras
por CPU, y una ventana móvil de esa distribución tiene un percentil 90 de 1, así que «por encima de
p90» lo cumple cualquier 2. El 2026-09-15 una condición de disparo que salta ante cualquier squeeze
saltó 92 veces en veinte minutos (RouterOS 7.24.2), y por eso `squeeze` no es un disparador por
defecto.

#### Reejecución de la regla de microrráfagas

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · la regla reejecutada sobre 6 h de muestras almacenadas, 863 944 filas, 4 CPU

- `microburst.firesPerHourAtTwo` 77,7 /h
- `microburst.firesPerHourAtThree` 0,5 /h

Con suelo 3 la regla siguió marcando 88 muestras para el contador de ráfagas y para `derived.burst`.

#### Cuenta de conntrack por la API

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · la tabla de conexiones contada por la API binaria de RouterOS, `/ip/firewall/connection/print count-only`, diez llamadas

- `conntrack.api` 6 212
- `api.conntrackMs` 1,3 ms

La cuenta fue 6 212, el día antes de que el slab del agente marcara 6 287:
el mismo orden de magnitud, que no dice nada de si las dos se siguen. Las diez llamadas tardaron una
mediana de 1,3 ms, la más rápida 1,1 ms y la primera 71 ms, en frío; la hora no consta.

#### Contadores de puerto y de fast path

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · contadores de puerto y de interfaz de RouterOS leídos por la API, acumulados desde el arranque o desde el último reinicio del contador de cada puerto

`ether1`, 2,5 GbE hacia un NAS, había recibido 255,8 GB por el cable (`rx-bytes`) y había entregado
29,7 GB de ellos a la CPU (`driver-rx-byte`) desde el último reinicio del contador del puerto; el
resto lo reenvió el chip de conmutación en hardware. Todos los puertos del switch daban una
proporción de fast path de alrededor del 100 %, con `fp-rx-byte` igual a `driver-rx-byte` con unos
pocos kB de diferencia. `bridge` había pasado por el fast path 211,9 GB de los 663,0 GB que llevó a la
CPU desde el arranque (32 %), y `PPPoE_DIGI` el 99,97 %. `fp-tx-byte` estaba a 0 en todas las
interfaces tras cientos de GB transmitidos ([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-fp-tx-zero)).

#### Desbordamiento del puerto antes y después

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.4 · 2026-09-19 · ether1, el puerto de 2,5 GbE del NAS, en intervalos de contador de 10 s; las cifras de antes son las tres horas previas al arreglo y las de después los 39 minutos siguientes, con la misma carga

- `overflow.shareBefore` 0,502 %
- `overflow.perHourBefore` 5 399
- `overflow.occupancy` 0,36 %
- `overflow.burstRate` 8,96 Mbit/s

El caso real es [Puerto que pierde tramas](https://jmrplens.github.io/mikroscope/es/playbooks/port-errors/).

Medido sin campaña propia: el 2026-09-15 una ráfaga tuvo un pico de 736 paquetes en una muestra de
20 ms, una muestra a 50 Hz, frente a una mediana de 28.

## Comportamiento de RouterOS verificado

Hechos de sí o no sobre RouterOS en los que se apoyan las guías, cada uno comprobado una vez, con
dónde y cuándo.

### Un usuario read ve las envlists

Por la API binaria, `/container/print` devolvió todas las propiedades de todos los contenedores, `cmd` y `envlist` incluidas, a un usuario con solo `read,api`, el usuario `mikroscope`; solo se imprimieron los nombres de las propiedades, y no se comprobó si ese usuario lee los valores de `/container/envs` (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### Política test para fetch y profile

`/tool fetch` y `/tool profile` exigen ambos la política `test` (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### Valores entre comillas en find

En un `find` de RouterOS, los atributos de dirección y de puerto solo coinciden cuando su valor va entre comillas, y una palabra suelta se lee como nombre de variable: sobre las mismas 15 reglas dstnat (RouterOS 7.24.4, 2026-09-21), `protocol=tcp` encontró 0 y `protocol="tcp"` encontró 10 (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### Las reglas de exposición llegan al agente

Una regla `dst-nat` más una regla `accept` en forward llegan al agente desde la LAN, y las dos se retiran por su etiqueta (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### La LAN llega a la veth

La LAN llega a la veth en cuanto la veth entra en la lista de interfaces `LAN` y el /30 en la lista de direcciones `LANs` (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### El borrado del contenedor vuelve antes

`/container/remove` vuelve antes de que el contenedor haya desaparecido, y un `/file/remove` lanzado mientras tanto no hace nada, sin avisar (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### Borrar el tar vuelve a extraer

Con `ignore-remote-image-change=no`, borrar el tar de la imagen hace que RouterOS detenga y elimine el contenedor y lo vuelva a extraer minutos después (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### La ida y vuelta deja /export intacto

`doctor`, `install`, `status`, `upgrade` y `uninstall`, en ese orden, dejaron el `/export` del router idéntico byte a byte, salvo sus líneas de cabecera `#`, comparado por hash en memoria y sin escribirlo nunca a disco (RB5009UG+S+, RouterOS 7.24.2, 2026-09-12).

### Instalar en tmpfs no escribe en la NAND

Un disco tmpfs aloja el tar de la imagen y la raíz del contenedor sin escribir en la NAND: `write-sect-since-reboot` se quedó en 58 279 durante la instalación, el funcionamiento y la retirada (RB5009UG+S+, RouterOS 7.24.2, 2026-09-11).

### Privileged conserva red y PID

`privileged=yes` quita el espacio de nombres de usuario del contenedor, pero no el de red ni el de PID (RB5009UG+S+, RouterOS 7.24.2, 2026-09-12).

### Host del registro en la referencia

Un host de registro dentro de `remote-image=` manda sobre `/container/config registry-url`, y `docker.io` se descarga como `registry-1.docker.io`: con `registry-url=https://registry-1.docker.io`, una referencia en `registry.invalid` quedó registrada como `registry=registry.invalid` y falló con `resolving error`, mientras que la imagen 1.2.2 del agente escrita como `docker.io/…` y como `registry-1.docker.io/…` quedó registrada como `registry=registry-1.docker.io` y terminó en `download/extract done`, con su capa arm64 de 2 799 648 bytes; `/container/config` quedó igual que antes. Los contenedores se crearon en una veth temporal, nunca se arrancaron y se retiraron después (RB5009UG+S+, RouterOS 7.24.4, 2026-09-24).

### Descarga de Docker Hub sin login

Con el usuario y la contraseña de `/container/config` borrados, RouterOS descargó de Docker Hub la imagen 1.2.2 del agente de forma anónima, tanto como `remote-image=registry-1.docker.io/…` como sin host a través de `registry-url=https://registry-1.docker.io`, y las dos terminaron en `download/extract done` 5 s después del alta; después se restauró la configuración y se comprobó que era idéntica (RB5009UG+S+, RouterOS 7.24.4, 2026-09-24).

### Horas del log por la API

Por la API, `/log/print` devuelve el `time` de una entrada como fecha y hora completas y sin zona, `2026-09-12 02:21:24`, y acepta ese formato en una consulta `?>time=` (RB5009UG+S+, RouterOS 7.24.2, 2026-09-12).

### Claves de pérdidas de monitor-traffic

`/interface/monitor-traffic` devuelve `rx-drops`, `tx-drops` y `tx-queue-drops` por segundo y ninguna clave de errores (RB5009UG+S+, RouterOS 7.24.2, 2026-09-15).

### rx-overflow solo en los contadores de puerto

`ether1` llevaba 652 364 sucesos `rx-overflow`, en aumento, en sus contadores de puerto mientras `monitor-traffic` no devolvía ninguna clave de errores para ese puerto: esa cuenta solo llega a un consumidor por los contadores de puerto (RB5009UG+S+, RouterOS 7.24.2, 2026-09-15).

### Planos del puerto y del bridge

Un puerto `ether` de un bridge cuenta su cable, incluidas las tramas que el chip de conmutación reenvió por hardware, y el `bridge` cuenta su lado de CPU, así que ninguno es un subconjunto del otro: desde el último reinicio del contador del puerto, `ether1` había recibido 255,8 GB por el cable (`rx-bytes`) y había entregado 29,7 GB de ellos a la CPU (`driver-rx-byte`) (RB5009UG+S+, RouterOS 7.24.2, 2026-09-16).

### fp-tx-byte se queda a cero

`fp-tx-byte` marcaba 0 en todas las interfaces tras cientos de GB transmitidos, mientras `fp-rx-byte` sí contaba; no está establecido por qué RouterOS lo deja a 0 (RB5009UG+S+, RouterOS 7.24.2, 2026-09-16).

### Rutas del host en un contenedor privilegiado

Un contenedor privilegiado con `/proc`, `/sys` y `/` del host montados leyó cero PID en el `/proc` del host y no encontró `class/net` en su `/sys`, así que los espacios de nombres aguantaron; el `/` del host sí se montó, y expuso el sistema de ficheros de la flash de RouterOS, configuración y ficheros, secretos incluidos. Se hizo con el consentimiento del mantenedor (RB5009UG+S+, RouterOS 7.24.2, 2026-09-15).

### La credencial va si el host coincide

RouterOS presenta el usuario y la contraseña de `/container/config` para una referencia cuyo host es `registry-url` tal como está escrito: con una credencial errónea a propósito, la imagen del agente 1.3.1 nombrada como `registry-1.docker.io/jmrplens/mikroscope-agent` falló con `auth error` con `registry-url=registry-1.docker.io`, y se descargó de forma anónima con `https://registry-1.docker.io`, el valor de los ejemplos de MikroTik, y con el mismo terminado en barra. Un router al que se dio una credencial no volvió a intentar la descarga de forma anónima (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

### WebFig no tiene campo para ignore-remote-image-change

Los formularios New Container y de edición del contenedor de WebFig no muestran campo para `ignore-remote-image-change`, con File o Remote Image puestos o no; lo pone el terminal (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

### Un set del contenedor reinicia restart-policy

Un `/container/set` que no nombra `restart-policy` (de `ignore-remote-image-change`, de `comment`, de `logging`) la devolvió de `on-failure` a `always` sin cambiar nada más de lo que muestra `/container/print detail`; un set que la nombra la conservó, igual que Apply u OK en el formulario de edición de WebFig. La CLI nunca ejecuta `/container/set` (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

### WebFig muestra los valores de env

WebFig muestra en claro el valor de una entrada de `/container/envs`, en la lista Envs y en su formulario, también con la clave `TOKEN` (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

### WebFig no tiene página Device Mode

El menú System de WebFig no tiene página Device Mode, así que el modo de dispositivo se pone desde el terminal (CHR x86_64, RouterOS 7.24.4, 2026-09-26).

### fetch as-value devuelve el cuerpo

`:put ([/tool/fetch url="http://172.30.10.2:9123/healthz" output=user as-value]->"data")`, ejecutado en el router, imprimió el JSON de `/healthz` del agente, en una sesión ssh, en el terminal de WebFig y al final de un script pegado (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

### La pregunta de la licencia se lleva las primeras líneas

El primer inicio de sesión interactivo tras un reinicio pregunta `Do you want to see the software license? [Y/n]:` antes del indicador `] >`. Un script pegado en esa pregunta perdió sus primeras líneas: una o dos líneas de comentario de la cabecera, y después un fragmento ejecutado como orden (`bad command name .` o `syntax error`); el bloque `{ … }` del script de instalación se ejecutó igualmente e instaló, y el script de desinstalación retiró igualmente todo (CHR x86_64, RouterOS 7.24.4, 2026-09-27).

## Sin probar

Lo que no cubre aquí ninguna ejecución, medida ni comprobación. Una guía que afirma una de estas cosas
como comportamiento esperado enlaza esta lista.

### Hardware y versiones

- Una segunda placa de cualquier tipo. El hEX S (2025), RouterOS de 32 bits sobre un chip ARM64, que
  es para lo que existe la compilación `linux/arm/v5` del agente, no ha llegado, así que ni la ruta
  del desbordamiento de contadores de 32 bits ni ninguna de las dos imágenes ARM de 32 bits se han
  ejecutado en RouterOS. Un
  [informe de placa](https://github.com/jmrplens/mikroscope/issues/new?template=2-board-report.yml)
  desde otra placa es lo que cambia esto.
- RouterOS x86 en hardware: la imagen amd64 solo se ha ejecutado en QEMU, en el CHR x86_64 del
  laboratorio y en RouterOS x86 instalado desde la ISO de MikroTik.
- Ningún RouterOS anterior a 7.24 más allá de la comprobación de versión de `doctor`, que S17 ejecutó
  en un CHR con 7.23.7, y ninguna de las cifras de 7.24.2 vuelta a medir sobre 7.24.4.
- Nada que necesite un reinicio del RB5009, que espera a una ventana de mantenimiento. Así que no está
  probado en hardware que una instalación persistente sobreviva a un reinicio con
  `start-on-boot=yes`. En el CHR del laboratorio volvió a responder en menos de 90 s tras un corte de
  corriente (S7, en las dos arquitecturas).
- Qué ficheros están en un espacio de nombres en otra versión de RouterOS u otra placa: cada fila de
  [Vista desde el contenedor](https://jmrplens.github.io/mikroscope/es/about/status/#vista-desde-el-contenedor) se leyó en un único RB5009 con 7.24.2.
- Una placa con sensores hwmon, o un RouterOS posterior que construya los contenedores de otra
  manera: el conjunto de sensores, las 38 capacidades y la correspondencia de uid se leyeron en un
  único RB5009 con 7.24.2.
- La correspondencia de puertos en otra placa: el desplazamiento de uno, la posición de la jaula
  SFP+ y la reutilización de `port 7` se observaron en un RB5009UG+S+ con 7.24.2, y el agente no los
  aplica a ninguna otra placa.
- Los caminos de PSI y `schedstat` en un router: el kernel del RB5009 no tiene ninguno de los dos. El
  conjunto de contadores de la PMU solo se conoce en el Cortex-A72 del RB5009 y en el equipo de
  desarrollo amd64.
- Cualquier cadencia de las fuentes en otro equipo o con otra carga: las cadencias son las del RB5009,
  con 7.24.2. Vuelve a medirlas con `FLOOR_HZ` igual a la cadencia del muestreador.
- Qué claves de pérdidas y qué contadores devuelve otra versión de RouterOS u otra placa.
- Lo que ahorra `--goarm 7` frente a la compilación ARMv5: ningún hardware ARM ha ejecutado ninguna.
- Las entradas de la envlist en un RouterOS anterior a 7.24: mikroscope escribe `key=`, porque
  `name=` falló en el RB5009 con 7.24.2, y no se probó cómo toma una u otra una 7.x anterior.
- Un tráfico mayor que la carga corriente del RB5009: unos 19 Mbit/s en la WAN
  durante la campaña del 2026-09-18. No se afirma ninguna cadencia en otra placa.

### Instalación y actualización

- En el RB5009, una descarga de GHCR sin credencial de registro, y cualquier descarga de GHCR con el
  host dentro de `remote-image=`: su única ejecución contra GHCR tomó el host de `registry-url`. El
  CHR del laboratorio hizo las dos con 7.24.4 ([Rutas de instalación probadas](https://jmrplens.github.io/mikroscope/es/about/status/#install-routes-tested)).
- Qué credencial presenta RouterOS a un host que solo se nombra en `remote-image=` cuando
  `registry-url` nombra otro. La única ejecución con un host distinto del de `registry-url`, el
  2026-09-24, nombraba `registry.invalid`, que nunca se resolvió. Con el mismo host, el laboratorio
  mostró que RouterOS solo la presenta cuando `registry-url` se escribe como el host a secas
  ([verificado](https://jmrplens.github.io/mikroscope/es/about/status/#verified-registry-url-host-match)).
- En el RB5009: un `install` o un `upgrade` completo que envíe la referencia completa, un
  `registry-url` con su valor de fábrica y la referencia completa en cualquier RouterOS que no sea
  7.24.4. El CHR del laboratorio ejecutó las dos cosas con la 1.3.1 sobre 7.24.4.
- Una descarga a través de un espejo o una caché intermedia nombrados en la referencia.
- `install`, `status` y `uninstall` de la 1.4.0 en adelante en cualquier hardware, y el script con
  sus guardas: solo se han ejecutado en los CHR del laboratorio. En el RB5009, el `upgrade` de la
  1.6.0 leyó del router el manifiesto de instalación y la arquitectura (`--arch auto`), y su
  `doctor` ejecutó todas las comprobaciones.
- `--ssh-option` y `MIKROSCOPE_SSH_OPTIONS` contra cualquier router: la CLI del laboratorio se conecta
  con el `ssh_config` propio del laboratorio, y solo las pruebas unitarias pasan la opción.
- Que `--extract-timeout` se agote, lo que conserva el tar, en cualquier router.
- La comparación de hosts de registro de `doctor` contra un router real: solo se ha ejecutado contra
  respuestas de router falsas en los tests.
- Si un usuario `read,api` puede leer los valores de la envlist en `/container/envs`.
- La ida y vuelta idéntica byte a byte en hardware: en cualquier placa que no sea el RB5009, en el
  RB5009 con cualquier RouterOS salvo 7.24.2, con `install` y `upgrade` sin `--ephemeral`, o con los
  ajustes actuales del contenedor (`privileged=yes`, `memory-max=64M`, las entradas de la envlist
  `MEM_LIMIT_MB`, `CAPTURE_MB`, `TRIGGERS` y `FLOOR_HZ`): en el RB5009 se hizo con `memory-max=32M`.
  Desde entonces `install`, `status` y `uninstall` se han ejecutado allí en 7.24.4. En el CHR 7.24.4
  del laboratorio, `make roundtrip` la ejecuta con `--ephemeral` (2026-09-26); S2 y S3 ejecutan
  `install`, `upgrade` y `uninstall` sin él, con `privileged=yes`, `memory-max=64M`, `MEM_LIMIT_MB` y
  `CAPTURE_MB`, y S5 importa un script que además escribe `TRIGGERS` y `FLOOR_HZ`; cada uno termina
  con el `/export` igual al de su inicio, salvo la línea `keymat-provider` de RouterOS (las dos
  arquitecturas, 2026-09-27).
- Cortafuegos distintos del del RB5009, donde el 2026-09-11 bastaron las dos pertenencias a listas, y
  de los perfiles del laboratorio. Un cortafuegos con otras reglas de descarte en `raw`, `input` o
  `forward` puede descartar el tráfico del contenedor en otro punto, e `install` no añade nada para
  eso más allá de las dos pertenencias. No se comprobó si la configuración de fábrica de un router
  lleva las dos reglas raw.
- `--expose` desde fuera de la LAN: solo se probó una máquina de la LAN llegando a la dirección LAN
  del router. Si algo de fuera de la LAN llega a esa dirección depende del resto del cortafuegos, y no
  se probó ningún camino así.
- Winbox: la página de instalación por WebFig dice que Winbox tiene los mismos menús y campos, y no se
  ejecutó ningún Winbox. Las reglas de `--expose` por los formularios NAT y Filter Rules de WebFig, un
  script entero pegado en el terminal de WebFig o de Winbox, y WebFig en cualquier RouterOS salvo
  7.24.4.
- Los scripts del generador, la instalación manual por terminal y la instalación por WebFig en el
  laboratorio arm64 o en el RB5009.

### Grabación y captura

- Una grabación por encima de 10 Hz: las ejecuciones sin pérdidas a 20, 50 y 100 Hz fueron del
  colector, que usa el mismo tamaño de lote. Una grabación a través del relay, a cualquier cadencia.
- El rendimiento del relay. Con idas y vueltas de `/tool fetch` de cerca de 1 s en la mitad de las
  llamadas y unos 3 ms en el resto ([medido](https://jmrplens.github.io/mikroscope/es/about/status/#campaign-relay-fetch) en el RB5009 con
  7.24.2), la aritmética da del orden de 26 muestras por segundo, menos cuando
  las llamadas lentas se agrupan. El límite del relay y el aviso de arranque están leídos del código
  (2026-09-15), no medidos en un equipo. El límite del relay y su fracción de 1 s en cualquier
  RouterOS salvo 7.24.2.
- El coste de un disparo en el equipo; 3 µs para una ventana de 10 s a 10 Hz es la estimación del
  diseño. Cómo se comporta el agente bajo una tormenta sostenida de disparos. Cualquier captura a 50 o
  100 Hz. Los tamaños de captura de [Captura por disparo](https://jmrplens.github.io/mikroscope/es/record/triggers/) son
  aritmética a partir del tamaño de línea, no tamaños de capturas tomadas en el RB5009.

### Colector y destinos

- Destinos alimentados desde el RB5009 hacia un backend en marcha: solo fichero, Prometheus e
  InfluxDB 3. Loki, un receptor OTLP, carbon, Elasticsearch, OpenSearch, Telegraf, PostgreSQL y
  TimescaleDB no han recibido muestras del router en ninguna ejecución registrada. OpenSearch, las
  hypertables de TimescaleDB y la salida estándar nunca se han probado contra un almacén real; solo
  los cubren las pruebas de contrato de bytes.
- Un Elasticsearch u OpenSearch que exija autenticación. El Elasticsearch de la batería de
  contenedores funciona con la seguridad desactivada, así que la cabecera `Authorization` que se
  construye a partir de `MIKROSCOPE_ELASTIC_AUTH`, autenticación básica para `user:password` y
  `ApiKey` en otro caso, no tiene ninguna ejecución registrada contra uno: ni desde el destino ni
  desde la fuente de datos de Elasticsearch que construyen `--grafana` y `dashboards publish`, que
  envía la misma cabecera desde la 1.5.0. Las pruebas unitarias fijan ambas formas, y la batería de
  extremo a extremo el `ApiKey` del destino contra un receptor simulado. Esa fuente de datos tampoco
  se ha ejecutado contra un OpenSearch, con autenticación o sin ella.
- Un TimescaleDB real: las llamadas a `create_hypertable` siguen la firma documentada de TimescaleDB
  2.x y no están verificadas.
- El tamaño del destino SQL en un router. Las cifras del fixture (1 375 B de SQL para un evento del
  kernel frente a 716 B de protocolo de líneas, 1 138 B para un evento de la API frente a 608 B, unos
  14 KiB/s a 10 Hz más la capa de la API a 1 Hz tras una cabecera de 5,6 KiB, 2 749 B con las fuentes
  privilegiadas) cubren dieciocho de las cuarenta y tres tablas que escribe el destino: once se
  añadieron después del fixture, y `load`, `stat`, `buddy`, `mtd`, `api_ifcounter`, `api_ifinfo`,
  `trigger`, `derived`, `derived_iface`, `detection` y las cuatro tablas `device` no se ejercitaron.
  Son anteriores a las columnas `port` y `kind` de `mikroscope_event`.
- `--sql - | psql` con un `psql` que se queda atrás frente a un agente a 10 Hz, que bloquea el bucle de
  peticiones.
- El presupuesto de la salida estándar para `json`, cuyas líneas son más grandes que las del
  protocolo de líneas.
- Un renderizado OTLP de una muestra de cuatro núcleos con un top-K real de interrupciones, una
  muestra de cuatro núcleos en el formato de Elasticsearch, y el presupuesto de Graphite por encima de
  10 Hz.
- Una escritura en el `/api/v2/write` de InfluxDB 2. El tamaño en protocolo de líneas por encima de
  10 Hz o con el conjunto de fuentes actual. Si desactivar el reenvío propio del cliente HTTP evita
  los duplicados del 2026-09-13.
- La entrega de Loki durante una tormenta del log del kernel.
- Cualquier intervalo de scrape de Prometheus que no sea 5 s, y cualquier Prometheus que no sea 3.14.
- Los 10 Hz constantes del colector frente a un agente más rápido: la referencia de ráfagas y la poda
  del top-K están leídas del código; el peso EWMA de 1/600 y el desalojo a las 36 000 muestras no se
  han visto ocurrir nunca, porque ninguna ejecución hizo que una línea de interrupción cayera del
  top-K y siguiera fuera.
- Los deltas a cero que se escriben junto a una proporción de fast path ausente (leído
  en [`internal/derive/derive.go`](https://github.com/jmrplens/mikroscope/blob/main/internal/derive/derive.go)), y un cambio de techo o de cadencia sin cambio de hash
  que llega a los destinos en la siguiente repetición de cinco minutos (leído en `capsHash`).
- El coste de PMU por paquete comparado entre dos configuraciones del router. Si los diez segundos de
  la referencia de ráfagas sirven en otra placa u otra mezcla de tráfico: se ajustó contra un RB5009
  en un solo día. Una proporción de fast path de tx a partir de contadores en vivo.
- Detecciones provocadas con las reglas en marcha: ningún OOM kill en el contenedor, reinicio, flap de
  enlace, vaciado o tormenta de conntrack, excursión térmica ni colapso de IPC. Si `reboot` saltó en el
  reinicio del 2026-09-19. Un flap provocado con `link-flap` en marcha; los flaps del 2026-09-15 no lo
  estaban.
- Si RouterOS calcula la ventana de un segundo de `cpu-load` sobre un reloj de pared o sobre jiffies.
  Si la cuenta de conntrack de la API y la del slab se siguen la una a la otra.

### Otras herramientas

- Ninguna de las seis herramientas de [Comparado con alternativas](https://jmrplens.github.io/mikroscope/es/start/compared/) se
  ejecutó para esa página. Cada celda de sus filas es lo que dice su propia documentación o su
  código, leído el 2026-09-24: mktxp en el commit `1e4412a` (fechado el 2026-09-21),
  mikrotik-exporter en `428dbfc` (fechado el 2026-07-03), y el fichero MIB que MikroTik publica para
  RouterOS 7.24.4. No se midió lo que le cuesta a un router el sondeo SNMP, The Dude, Graphing, el
  Profiler, mktxp o mikrotik-exporter, con qué frecuencia puede sondearlo cada uno con utilidad, ni
  qué pone RouterOS en `hrProcessorLoad`.

### Dashboards y alertas

- Cualquier Grafana que no sea 12.3.0, 12.3.2, 13.2.1 o 13.2.2. En 12.3.0 los únicos renderizados son
  los del 2026-09-25; el resto del dashboard se comprobó allí solo por consulta.
- `dashboards publish` contra cualquier Grafana que no sea 13.2.1, y sobre algo que no sea lo que
  `forward --grafana` acababa de crear allí: en la batería de contenedores, el 2026-09-27, se ejecutó
  una vez por almacén, después del colector, sin credenciales en ninguna fuente de datos, y encontró
  la carpeta y cada fuente de datos tal como las había dejado el colector, y las dio como
  `unchanged`. Con `dashboards publish`, una ejecución de más de un almacén, un almacén que falla
  mientras los demás siguen, una fuente de datos que lleva un token o una contraseña (se escribe de
  nuevo en cada ejecución y se da como `updated`) y `--grafana-dry-run` solo se han ejecutado en las
  pruebas unitarias, contra Grafanas simulados.
- La altura del Overview de trece paneles en un navegador; el JSON del repositorio le da 31 unidades
  de cuadrícula.
- La regeneración byte a byte de los ficheros de dashboard añadidos después del 2026-09-15.
- Las anotaciones y capas de detecciones de Elasticsearch y Graphite en Grafana: solo se comprueba su
  JSON generado, con pruebas unitarias.
- Una pasada de renderizado sobre los dos paneles de eventos de puerto y la tabla de inventario de
  interfaces.
- Que una regla se resuelva: el bucle del RB5009 terminó el 2026-09-23, pero no se ha comprobado en el
  historial de estados de Grafana la vuelta de `mikroscope-l2-loop` a Normal. No se ha visto a
  `mikroscope-l2-loop` ni a `mikroscope-port-link-down` pasar a pendiente, saltar y resolverse.
- Las dos reglas que añadió 1.2.0 dentro de cualquier Grafana, su PromQL más allá de la sintaxis y el
  SQL de PostgreSQL de la regla de despertares.
- Los ficheros de alertas de Prometheus y PostgreSQL en cualquier Grafana, y cualquier consulta de
  alerta de PostgreSQL contra un PostgreSQL real: una prueba unitaria lee el esquema, no una base de
  datos.
- La entrega de avisos: no se configuró ningún punto de contacto, así que lo que se observó es el
  estado de cada regla.
- Un almacén al que le falta una tabla o una columna que lee una regla: se espera que la consulta
  falle y que se aplique `execErrState: Error` en lugar de OK. Lo que hace entonces Grafana es su
  comportamiento de Error y No Data, no probado aquí.

## Problemas conocidos

Contrastado con el código el 2026-09-24, y el flujo del resumen final otra vez con la 1.3.1 el
2026-09-26:

- **El resumen final de `forward` va a stdout**, el mismo flujo en el que el destino `--stdout`
  escribe los registros, así que `forward --stdout=lp | telegraf` termina cada ejecución con líneas que
  el consumidor no puede analizar.
- **Un `--token` erróneo no hace fallar la ejecución.** Cada petición queda registrada como
  `401 Unauthorized`, y la ejecución termina en el plazo de `--for` con código de salida 0 y
  `forwarded 0 kernel samples`. La comprobación de salud que hace `forward` antes de empezar a pedir
  datos lee `/healthz`, que no necesita token, así que la supera. El mensaje es correcto; el código de
  salida no le dice nada a un fichero de unidad.
- **Números de secuencia duplicados en la ejecución nocturna del 2026-09-13.** La ejecución a 50 Hz
  escribió valores de `seq` repetidos en InfluxDB; los paneles llaman a esas filas "duplicate sample
  (seq repeated)". La explicación más probable, sin verificar, es que el cliente HTTP de Go reenviaba
  un POST por una conexión reutilizada ya muerta después de que el servidor lo hubiera confirmado. Los
  destinos InfluxDB, Loki, OTLP, Elasticsearch y Telegraf rechazan ese reenvío, así que una conexión
  muerta es un error que el destino reintenta y contabiliza. Ninguna ejecución posterior a esa noche
  muestra si los duplicados han desaparecido.
- **Un tag negado dentro de un OR no devuelve nada, en silencio, en InfluxDB 3.** El 2026-09-23, en el
  almacén de referencia (InfluxDB 3 Enterprise desde el 2026-09-19; la versión no se anotó con la
  consulta), `NOT (port='ether2' AND kind IN (…))` sobre `mikroscope_kmsg` devolvió 0 filas donde
  coincidían 14, y lo mismo su forma de De Morgan y el OR explícito. Devolvió 14 en cuanto se filtró
  también `port='ether2'` fuera del OR. Los paneles y las reglas que se distribuyen no usan ese patrón.
- **Grafana 12.3.0 nunca envía la consulta de la capa de detecciones de InfluxDB**, con la tabla o sin
  ella: su interruptor se quedó con un indicador de carga, apagarlo, encenderlo y refrescar no envió
  nada, y no se dibujó ninguna marca, ni en el dashboard completo ni en una copia de un solo panel
  (2026-09-25). Grafana 13.2.1 la envió en el acto sobre el mismo almacén. Por qué, y si 12.3.2 hace
  lo mismo, no se ha investigado.

### Encontrado en el laboratorio virtual

Lo que encontraron la CLI y la imagen del agente 1.3.1 publicadas en el CHR del laboratorio, RouterOS
7.24.4, el 2026-09-26. Cada punto termina con lo que hace el código posterior a la 1.3.1, comprobado
en el laboratorio el 2026-09-27; la 1.4.0 publica ese código, y la sección 1.4.0 del registro de
cambios recoge cada cambio.

- **`doctor` con sus valores por defecto falla tres comprobaciones en un CHR.** `--arch` vale arm64
  por defecto, lo que falla solo en x86_64; la lista de interfaces `LAN` no existe; y la comprobación
  «has entries» de la lista de direcciones `LANs` falla con una lista vacía o inexistente, aunque su
  propio arreglo dice que una lista vacía está bien si no existe esa regla. Un router sin esa regla solo
  pasa dándole una entrada a la lista, o con `--no-doctor`, que se salta todas las demás comprobaciones.
  **Tras la 1.3.1**: `--arch` vale `auto` por defecto y lee la arquitectura del router, una lista de
  direcciones vacía ya no es un fallo, y una lista de interfaces que falta, todavía MISSING con los
  valores por defecto, tiene un arreglo que ofrece `--iface-list none` (S1).
- **Una lista de interfaces integrada** como `static`, `all` o `dynamic` pasa la comprobación de
  existencia de doctor, y RouterOS se niega a añadirle un miembro. **Tras la 1.3.1**: `--iface-list`
  rechaza `all`, `dynamic` y `static`; RouterOS responde `cannot add to builtin list`.
- **`--ephemeral` necesita un disco tmpfs**, y un CHR no lista ningún disco. El arreglo de doctor,
  `/disk/add type=tmpfs tmpfs-max-size=64M slot=tmpfs`, funcionó, y la instalación fue a
  `tmpfs/mikroscope/mikroscope` con `start-on-boot=no`. **Tras la 1.3.1**: igual, y `doctor` avisa
  además cuando se fuerza el arranque con el router sobre una raíz en un disco tmpfs, que un reinicio
  vacía.
- **`uninstall` compite con la parada del contenedor.** Detiene el contenedor, espera 4 s fijos y lo
  elimina, y el agente tardó 0 s en pararse seis veces, 4 s cuatro veces y 5 s una (log de RouterOS,
  resolución de 1 s): 5 de 15 primeros intentos en x86_64 fallaron con
  `failure: cannot remove running`. Con un cliente en `/stream` falló siempre en las dos arquitecturas,
  porque el cierre HTTP del agente lo espera hasta 5 s. Los pasos siguientes se ejecutaron igualmente,
  y un segundo `uninstall` lo limpió todo cada vez. **Tras la 1.3.1**: la retirada espera hasta 30 s
  mientras el contenedor está `running` o `stopping`, y cada primer intento quedó limpio
  ([Tiempos del laboratorio](https://jmrplens.github.io/mikroscope/es/about/status/#lab-timings)).
- **Un directorio `mikroscope` vacío se queda en `/file` después de cada `uninstall`**: el padre del
  root-dir del contenedor, que el recuento de propiedad no incluye. **Tras la 1.3.1**: cada vía de
  instalación escribe un manifiesto de instalación, y `uninstall` quita lo que lista, y después el
  manifiesto y el directorio `mikroscope/` cuando no queda nada más en él; tras ninguna vía quedó una
  ruta de mikroscope en `/file` (F4).
- **El sondeo posterior a `install` lee mal un contenedor en marcha** sobre 7.24.4. Pregunta
  `/container/find … status="running"`, y `status` no es una propiedad de `/container` allí
  (`/container/find status=running` responde `bad parameter status`), mientras que la marca `running`
  vale 1. Así que cuando falló el sondeo, la CLI dijo "the container is not running on the router" con
  el agente en marcha y a punto de responder. Visto dos veces en arm64. **Tras la 1.3.1**: el sondeo
  lee la marca `running`.
- **El listado del plan nombraba un tar con `--remote-image`**: `image=mikroscope.tar`, un fichero
  que `install` nunca sube, e imprimía la subida o la descarga como un paso propio con el número del
  paso del contenedor, así que dos pasos compartían número. **Tras la 1.3.1**: `image=` nombra la
  referencia que descarga el router, y la descarga o la subida es una línea del paso del contenedor.
- **El token del agente viajaba en la línea de órdenes de ssh**, donde la tabla de procesos del
  anfitrión lo mostraba mientras la orden se ejecutaba: el código de la 1.3.1 lo mostró en dos líneas
  de órdenes. **Tras la 1.3.1** una orden que lo lleva va a ssh por la entrada estándar; leer la
  tabla de procesos cada 2 ms durante una instalación y una actualización con `--expose` no lo
  encontró en ninguna, en las dos arquitecturas.
- **Las palabras de RouterOS se perdían cuando su ssh salía con 1**: el error decía
  `ssh "<script>": exit status 1`, y el mensaje de RouterOS, en las líneas siguientes, lo descartaba
  la línea de omisión de uninstall. El ssh de RouterOS salió con 1 o con 0 ante el mismo fallo, más o
  menos a partes iguales. **Tras la 1.3.1** el error empieza con lo que imprimió RouterOS.

## Fuentes sin recoger

Dos ficheros legibles del RB5009, leídos allí el 2026-09-15, no se recogen: `/proc/cmdline`, que lleva
`board=5009 ver=7.24.1`, una segunda identidad del equipo sin la API, y el watchdog hardware en
`/sys/class/watchdog/watchdog0`.

## Véase también

- [Coste del agente](https://jmrplens.github.io/mikroscope/es/cost/): el presupuesto, los costes de SSH y de la capa de la API,
  y cómo medir el agente en tu propio router.
- [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/): las seis ejecuciones medidas a 10, 20, 50 y
  100 Hz.
- [Límites de la evidencia](https://jmrplens.github.io/mikroscope/es/cost/limits/): lo que estas medidas no pueden decirte
  sobre otro equipo u otra carga.
- [Casos reales](https://jmrplens.github.io/mikroscope/es/playbooks/idle/): los fallos leídos en el RB5009, con las órdenes que
  los reproducen.
- [Versiones](https://jmrplens.github.io/mikroscope/es/about/changelog/): la versión actual, su fecha y lo que publica cada
  versión.

---

# Coste del agente

Lo que le cuestan a un MikroTik RB5009 el agente, una conexión SSH y la capa de la API de RouterOS, medido desde el propio cgroup del agente y con el profiler de RouterOS, y cómo medir el agente en tu router.

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

Con los valores por defecto de la instalación — 10 Hz, los suelos por fuente por defecto, anillo
de 60 s — el agente le cuesta a un MikroTik RB5009 **un 2,69 % de un núcleo
y un 13,2 MiB de RSS**, leído desde su propio cgroup:

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-18 · ventanas de 300 s en régimen estacionario (con el anillo ya lleno), conjunto completo de fuentes, la configuración que se envía —anillo de 60 s, límite de memoria derivado de él y el tope de contenedor de serie de 64M— con el colector reenviando a InfluxDB 3

El agente publica su propio coste en cada muestra, y la CI comprueba el presupuesto de tamaño de la
imagen.

## Presupuesto

El presupuesto es **≤ 2 % de un núcleo, ≤ 16 MiB de
RSS, ≤ 8 MiB de imagen**. La imagen arm64 publicada de 1.2.1
mide 6,38 MiB (6 690 304 B, medido sobre el artefacto de la versión el 2026-09-24); la
de 1.0.0 medía 6,1 MiB, la cifra que dan las notas de esa versión. Los otros
dos dependen de la cadencia y de cuánto le pidas leer al agente, así que la respuesta es una tabla y
no un número: [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/) es esa tabla.

**La memoria está dentro del presupuesto y la CPU no.** 13,2 MiB frente a
los 16 MiB que pide el presupuesto, y un 2,69 % frente
al 2 %, con todas las fuentes leídas, entre ellas los tiempos de perf,
buddyinfo, los contadores ECC de MTD, slabinfo, el log del kernel y los eventos de cgroup. El
tráfico por interfaz no está en ese conjunto: el contenedor no lo ve, y viene de la capa de la API.

La campaña del 2026-09-15 estaba por encima en los dos. Su anillo guardaba 300 s en vez de 60 y su
límite de memoria era un 40 MiB fijo que nunca apretaba, lo que dejaba al mismo agente en 31,3 MiB;
ninguna de las dos cifras decía nada sobre la cadencia. Nada del muestreo cambió entre las dos
campañas: la CPU pasó del 2,85 % al 2,69 %, que es el ruido entre dos ventanas.

### Bucle de shell como base

El presupuesto dice lo que se le permite costar al agente. La comparación que suele querer quien lee
es contra la forma obvia: un bucle de shell de busybox. El 2026-09-11, en el mismo router, un bucle
que leía a 10 Hz el conjunto de ficheros que leía entonces el agente costó
**2,40–2,48 % de un núcleo**, mientras que las lecturas en sí rondaban
los 0,77 ms por muestra.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · un bucle de shell de busybox leyendo a 10 Hz el conjunto de ficheros que leía entonces el agente, siete ficheros, con un fork por iteración, en un contenedor del router; dos ejecuciones de 60 s

Así que la mayor parte del coste del bucle de shell no estaba en leer. Paga un fork por iteración y
el agente no paga ninguno: un proceso arranca, abre sus ficheros una vez y los deja abiertos, y por
eso el agente es un binario y no un script. Aun así, las dos cifras no se pueden poner una al lado de
la otra. Hoy el agente lee mucho más — perf, buddyinfo, los contadores ECC de la MTD, slabinfo, el
log del kernel — y el bucle no se ha vuelto a medir con ese conjunto, así que no se puede comparar
con 2,69 %.

> **De dónde sale el número**
>
> No de `top`, y no de una instantánea. El agente cuenta sus propios microsegundos de CPU y su RSS
> desde su cgroup y los lleva en cada muestra, en el bloque `self`, como `cpu_us` y `rss`; el
> colector los representa como `mikroscope_self_cpu_usec_total` y `mikroscope_self_rss_bytes`. Dos
> lecturas del `/metrics` del colector separadas 60 s, en régimen estacionario y con el anillo ya
> lleno, son la medida: el agente no sirve exposición propia. El `/tool profile` de RouterOS
> muestra el mismo proceso como `mikroscope-agent`.

Quien tira del agente se suma a eso. Además del colector y de `record`, un `doctor` independiente
lee el anillo una vez, en una sola petición: el anillo entero cuando no guarda más de 10 000
muestras, y si no las 10 000 más recientes. Con los valores por defecto es el anillo entero de 60 s,
unos 1,9 MB a 10 Hz, y esa petición se sirve en el núcleo del muestreador; el coste de esa lectura en
el RB5009 no se ha medido.

## Límite de memoria

El error más caro disponible aquí es dar al proceso menos memoria de la que su anillo necesita. El
recolector de basura de Go responde a un límite blando ajustado ejecutándose más a menudo, y el
coste de CPU se dispara por un motivo que no tiene nada que ver con la cadencia de muestreo. El
anillo guarda líneas ya codificadas en vez de structs por la misma razón. Si subes `--buffer` o la
cadencia, sube con ellos `--mem-limit-mb` y el `--memory-max` del contenedor; las opciones que usó
cada ejecución están junto a ella en [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/).

`install` deriva `MEM_LIMIT_MB` del anillo: cadencia × buffer × el tamaño de línea, por 2,5, con un
mínimo de 16 MiB y un máximo de tres cuartos de `memory-max`, así que la instalación por defecto
escribe 16 para un anillo de 60 s a 10 Hz. El factor está medido. En el RB5009 (RouterOS 7.24.2,
10 Hz, un anillo de 300 s, todas las fuentes activas) el 2026-09-17, cuatro límites en cuatro
ventanas de unas 12 000 muestras cada una:

| límite | múltiplo del anillo | RSS      | CPU por muestra | Lo que costó                  |
| ------ | ------------------- | -------- | --------------- | ----------------------------- |
| 40 MiB | 4,0×                | 32,9 MiB | 2 657 µs        | el límite nunca aprieta       |
| 24 MiB | 2,4×                | 26,3 MiB | 2 780 µs        | ningún coste medible          |
| 21 MiB | 2,1×                | 23,5 MiB | 3 250 µs        | +22 %, y subiendo             |
| 18 MiB | 1,8×                | 20,4 MiB | 14 800 µs       | +457 %, el peor tick de 52 ms |

Las filas son las que registra el comentario de `memLimitRingFactor`
en [`internal/router/options.go`](https://github.com/jmrplens/mikroscope/blob/main/internal/router/options.go). El factor de 2,5× serían 25 MiB a 300 s; la ventana medida
más cercana fue la de 24 MiB, y ninguna de las cuatro ventanas se anotó con su dispersión. El mismo
precipicio se midió desde el otro lado el 2026-09-12: un 9,38 % de un núcleo
con 14 MiB frente a un 1,39 % con margen, las dos con el anillo lleno.

El análisis no es donde se va el tiempo. Analizar los siete ficheros globales de `/proc` más un
delta costó 27 µs y 239 asignaciones por muestra en el equipo de desarrollo amd64 (Go 1.27.1, tres
ejecuciones, 26,7–27,5 µs, 2026-09-11). En el Cortex-A72 del RB5009 un tick entero — con
temporizadores, JSON y el recolector de basura incluidos —
cuesta 2 685 µs a 10 Hz con los suelos por defecto, y
[las seis ejecuciones](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/) lo dan a cada cadencia. El análisis por sí
solo no se midió en el A72.

## Coste de SSH

Cada conexión SSH le cuesta al RB5009 un 20–27 % de CPU mientras dura.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.1 · 2026-08-26 · una conexión ssh, mientras dura

Esa lectura es anterior al agente y se tomó con RouterOS 7.24.1. Con 7.24.2, el 2026-09-11, el mismo
coste apareció en `/tool profile` como un 17–33 % en una o dos instantáneas, no en una ventana
medida. Por eso la CLI agrupa todas las lecturas en una sola conexión — `doctor` es una, `status` es
una, las preguntas de estado de `install` son una — y cada escritura suma otra, más la subida por
`scp`. SSH nunca es un camino de datos: `record` y `forward` llegan al agente por HTTP o por la API
de RouterOS.

## Coste de la capa API

Medido con el propio [profiler](https://help.mikrotik.com/docs/spaces/ROS/pages/8323153/Profiler)
de RouterOS, una vez con el colector parado y otra con él haciendo una ronda cada segundo:

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · 2026-09-16 · `/tool profile duration=60s cpu=total`, una vez con el colector parado y otra con él en marcha con `--interfaces bridge,ether1,PPPoE_DIGI --counters-every 10s --api-every 1s`; descartadas las cinco primeras instantáneas de un segundo de cada perfil, porque llevan la conexión SSH que lo pidió

| Fila del perfil  | Colector parado | Colector en marcha |
| ---------------- | --------------- | ------------------ |
| total            | 5,93 %          | 6,04 %             |
| `interface-mgmt` | 0,40 %          | 0,87 %             |
| `config-db`      | unos 0 %        | 0,15 %             |

El total se mueve 0,11 puntos, dentro del ruido del tráfico de un minuto; las dos filas que responden
a las preguntas de la capa se mueven juntas medio punto. En ninguno de los dos perfiles aparece una
fila de proceso `api`: el proceso de la API hace de intermediario y el trabajo cae en el subsistema
que responde. Así que una capa que hace una ronda por segundo le cuesta al router en torno al 0,5 %
de su CPU total. Esa tabla es un único perfil de 60 s por condición, sin dispersión.

Una configuración mayor se midió como A/B en el mismo router el 2026-09-19, el día de la
actualización de RouterOS que lo dejó en 7.24.4; no quedó registrado sobre qué versión corrió el A/B
en sí. Todas las interfaces salvo `lo` en `--interfaces` (16) y `--conntrack-every 10s`, 8 min sin
ella frente a 14 min con ella: el `cpu-load` medio pasó de 7,12 % a 7,91 % y la ocupación media del
kernel de 7,70 % a 8,46 %, unos +0,8 puntos. Es una cota inferior, porque el tráfico del bridge bajó
de 48,0 a 38,9 Mbit/s entre las ventanas. El p50 de `cpu-load` se quedó en 6 y el p95 pasó de 16 a
18.

`--conntrack-every` pregunta `/ip/firewall/connection/print count-only`: una llamada
tardó 1,3 ms con 6 212 entradas, la mediana de diez
llamadas; la más rápida tardó 1,1 ms y la primera 71 ms, en frío.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-11 · la tabla de conexiones contada por la API binaria de RouterOS, `/ip/firewall/connection/print count-only`, diez llamadas

## Medir en tu router

Nada de esto se traslada a una placa que no sea un RB5009: otro número de núcleos, otro reloj, otro
kernel y otra flash lo mueven. El procedimiento son tres órdenes y lleva un minuto:

```sh
curl -s http://<collector host>:9124/metrics | grep -E 'self_cpu_usec_total|self_rss_bytes'
sleep 60
curl -s http://<collector host>:9124/metrics | grep -E 'self_cpu_usec_total|self_rss_bytes'
```

La diferencia de `self_cpu_usec_total` dividida entre 60 000 000 es la fracción de un núcleo. O deja
que la shell haga la división, en tres minutos:

```sh
U=http://<equipo del colector>:9124/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)}'
```

Tres cosas que cabe esperar:

- **El coste y la memoria suben hasta que el anillo se llena.** Con el anillo por defecto de 60 s a
  10 Hz el agente guarda 600 muestras ya codificadas; una cifra tomada en el primer minuto tras la
  instalación se mide sobre un heap casi vacío y sale baja. Espera a que pase `BUFFER_S` antes de
  citar una cifra de régimen estacionario.
- **Una instantánea lo exagera.** Un `/snapshot` de 60 s entrega unas 600 líneas, unos 1,9 MB, y el
  `self.cpu_us` de esas muestras incluye el coste de servirlas; leer el coste en instantáneas
  repetidas lo exagera más.
- **`mikroscope_slipped_total` es el número que importa.** Un muestreador que cuesta algo más pero
  nunca pierde ticks te está diciendo la verdad; uno que los pierde, no.

La dirección es la del colector, no la del agente: el agente no sirve ningún `/metrics`, y esos dos
contadores llegan al colector en cada muestra. Sin destino de Prometheus configurado, esos mismos dos
números son `cpu_us` y `rss` en `mikroscope_self` en InfluxDB, Telegraf, stdout y los almacenes SQL,
`self.cpu_us` y `self.rss` en los documentos de muestra de Elasticsearch, `self.cpu_us` y
`self.rss_bytes` en Graphite, y `mikroscope.self.cpu.time` / `mikroscope.self.memory{kind="rss"}` en
OTLP. Medida en una placa que no sea un RB5009, con la cadencia, la fecha y lo que hacía el router,
la cifra va en un
[informe de placa](https://github.com/jmrplens/mikroscope/issues/new?template=2-board-report.yml).

## Véase también

- [Techo de muestreo](https://jmrplens.github.io/mikroscope/es/cost/rate-ceiling/): las seis ejecuciones, los valores por
  defecto que usó cada una y lo que compra muestrear más rápido.
- [Límites de la evidencia](https://jmrplens.github.io/mikroscope/es/cost/limits/): lo que estas cifras no pueden decirte
  sobre otro equipo u otra carga.
- [Probado en](https://jmrplens.github.io/mikroscope/es/about/status/): el equipo, las versiones de RouterOS y cada campaña
  que hay detrás de estas cifras.