# Cinco dashboards, una sola lista

Qué contienen los dashboards de InfluxDB 3, Prometheus, PostgreSQL, Graphite y Elasticsearch, sección a sección y en el orden en que se leen, y por qué los cinco almacenes no llevan los mismos paneles.

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

`dashboards/` contiene un dashboard de Grafana por almacén, los dos generados por
`mikroscope dashboards gen` a partir de una única lista de paneles en `internal/dashboards`. Esta
página responde a qué hay en ellos: qué secciones, qué paneles en cada una, qué muestra el Overview
antes de desplegar nada y qué paneles existen solo en uno de los dos almacenes. Importarlos y
comprobarlos contra un Grafana en marcha está en
[Importar y comprobar](/mikroscope/es/dashboards/import-and-check/); las reglas de alerta que se
generan a su lado, en [Reglas de alerta](/mikroscope/es/dashboards/alerts/).

Los dashboards están en inglés. Los títulos de filas y paneles se citan aquí tal como los muestra
Grafana, sin traducir, para que puedas encontrarlos.

## Lo que escribe `gen`

- dashboards/
  - mikroscope-influxdb.json 171 paneles, InfluxDB 3 (SQL)
  - mikroscope-prometheus.json 133 paneles, Prometheus
  - mikroscope-postgres.json 156 paneles, PostgreSQL / TimescaleDB
  - mikroscope-graphite.json 41 paneles, Graphite
  - mikroscope-elasticsearch.json 30 paneles, Elasticsearch
  - mikroscope-alerts-influxdb.yaml 10 reglas
  - mikroscope-alerts-prometheus.yaml 11 reglas
  - mikroscope-alerts-postgres.yaml 8 reglas

```sh
mikroscope dashboards gen                    # escribe los cuatro ficheros en ./dashboards
mikroscope dashboards gen --out /tmp/dash    # o en otro directorio
```

Los cinco dashboards están en el formato de exportación compartible de Grafana: la fuente de datos es
un marcador `${DS_MIKROSCOPE}` declarado en `__inputs`, no hay `id` y el `uid` es fijo —
`mikroscope-influxdb` y `mikroscope-prometheus` —, así que una reimportación actualiza el mismo
dashboard en su sitio en vez de crear un segundo. Un test comprueba que dos generaciones del
dashboard de InfluxDB son idénticas, y regenerar el 2026-09-15 reprodujo byte a byte los cuatro
ficheros del repositorio.

El dashboard de InfluxDB consulta InfluxDB 3 en SQL, y toda consulta está acotada por
`$__timeFilter`, porque InfluxDB 3 Core rechaza los recorridos sin límite; donde una columna se llama
`cluster` el SQL la entrecomilla, porque `cluster` es una palabra reservada en DataFusion. El
dashboard de Prometheus consulta un Prometheus que hace scrape del `/metrics` del colector — que
lleva todo lo que lleva el del agente, recalculado a partir de las muestras, más las familias
derivadas y de detección propias del colector — y del propio agente para las pocas familias que solo
produce el muestreador. Prometheus 3 representa el borde del bucket cero de un histograma como
`le="0.0"`, así que una consulta que lee ese bucket casa con `le=~"0|0.0"`. Los dos trabajos de
scrape están en
[Importar y comprobar](/mikroscope/es/dashboards/import-and-check/#prometheus-dos-trabajos-de-scrape).

## Qué aspecto tiene

Una captura por sección del dashboard de InfluxDB, en el orden en que las pone
el dashboard. Cada una enlaza al fichero a tamaño completo.

> **Esto es una base de demostración, no un router**
>
> Todas las capturas de abajo son el dashboard de InfluxDB sobre una ejecución del mismo agente
> simulado enlatado que usan las baterías de extremo a extremo, escrita en un almacén en contenedor
> por el paso de llenado de `test/e2e/docker` y fotografiada por
> `site/scripts/gen-dashboard-captures.mjs`. Nada en ellas viene de un equipo real, el host se llama
> `rb5009` porque el agente simulado imita el `/proc` capturado de esa placa, y las cifras son las
> que publique el simulador: léelas como «esta es la forma de la página», nunca como una medición.
> Un panel vacío en una captura es uno para el que el agente simulado no produce nada; en un router
> real con la capa de la API en marcha, varios se llenan, y vuelven dos secciones enteras que el
> sondeo del almacén movió a «no disponible».

Una captura por sección del dashboard de InfluxDB, sobre una base de demostración llenada por el agente simulado, en [la página](/mikroscope/es/dashboards/):

- Overview (12)
- CPU and scheduler (11)
- Memory and load (9)
- Connections (9)
- Interface traffic (13)
- Detections and captures (5)
- Network receive path (9)
- Forwarding cost (derived) (4)
- Interrupts and softirqs (12)
- Temperature and clock (10)
- Kernel log (7)
- CPU: how long a core stayed busy (3)
- Memory: fragmentation (3)
- Memory: reclaim and page faults (8)
- Memory: detail and cross-checks (5)
- Hardware counters (PMU) (11)
- Flash wear (7)
- NAND health (ECC) (2)
- RouterOS API cross-checks — CPU and memory (9)
- The observer (11)
- The observer: sampler timing and self events (3)
- This device (3)
- Not available on this device (5)

## Una lista, dos almacenes

Cada panel se declara una sola vez, con su SQL y su PromQL uno al lado del otro, de modo que un
panel añadido a un almacén queda añadido al otro. Cuando un panel no tiene consulta para un almacén,
el generador **lo quita del dashboard de ese almacén** en vez de publicarlo para que muestre "No
data" para siempre. Una sección a la que se le quitan todos los paneles no emite ninguna fila.

Por eso difieren los recuentos, y difieren en los dos sentidos. Casi toda la familia térmica y de
reloj, la sección de desgaste de la flash, el censo de slab y varios paneles de memoria tienen SQL y
no PromQL, así que solo existen en InfluxDB. Los histogramas de temporización del muestreador, las
supresiones de disparadores y el presupuesto de capturas viven solo en el `/metrics` del agente. La
racha de ocupación aún en curso y la antigüedad de cada lectura retenida son familias de la
exposición de Prometheus, también en el `/metrics` del colector, sin campo en InfluxDB. Ninguno de
los dos grupos se escribe en InfluxDB, así que los paneles que los leen solo existen en Prometheus. Cada panel de abajo que está en un solo
almacén dice en cuál.

Paneles por sección y por almacén:

| Sección (fila en Grafana) | InfluxDB 3 | Prometheus | PostgreSQL | Graphite | Elasticsearch |
| --- | --- | --- | --- | --- | --- |
| Overview | 12 | 12 | 12 | 10 | 6 |
| CPU and scheduler | 11 | 9 | 11 | 1 | sin fila |
| Memory and load | 9 | 9 | 9 | 7 | 5 |
| Connections | 9 | 3 | 9 | 1 | 1 |
| Interface traffic | 13 | 11 | 9 | 2 | sin fila |
| Detections and captures | 5 | 4 | 5 | sin fila | sin fila |
| Network receive path | 9 | 7 | 9 | 3 | 3 |
| Forwarding cost (derived) | 4 | 4 | 4 | sin fila | sin fila |
| Interrupts and softirqs | 12 | 10 | 12 | 2 | 2 |
| Temperature and clock | 10 | 2 | 10 | 2 | 2 |
| Kernel log | 7 | 6 | sin fila | sin fila | sin fila |
| CPU: how long a core stayed busy | 3 | 4 | 3 | sin fila | sin fila |
| Memory: fragmentation | 3 | 1 | sin fila | sin fila | sin fila |
| Memory: reclaim and page faults | 8 | 6 | 8 | 2 | 1 |
| Memory: detail and cross-checks | 5 | 3 | 5 | 1 | 1 |
| Hardware counters (PMU) | 11 | 7 | 11 | sin fila | sin fila |
| Flash wear | 7 | sin fila | 7 | 1 | 1 |
| NAND health (ECC) | 2 | 2 | 2 | sin fila | sin fila |
| RouterOS API cross-checks — CPU and memory | 9 | 9 | 9 | 1 | sin fila |
| The observer | 11 | 9 | 10 | 3 | 3 |
| The observer: sampler timing and self events | 3 | 7 | 3 | sin fila | sin fila |
| This device | 3 | 3 | 3 | sin fila | sin fila |
| Not available on this device | 5 | 5 | 5 | 5 | 5 |
| **Total** | **171** | **133** | **156** | **41** | **30** |

Los recuentos son los de los ficheros del repositorio, que llevan los valores compilados por defecto.
`import` y `check` preguntan primero a la fuente de datos qué contiene y pueden meter paneles en la
última fila o sacarlos de ella; consulta [No disponible en este equipo](#no-disponible-en-este-equipo)
más abajo.

## Orden de lectura

Las secciones están ordenadas por la frecuencia con que se abren, no por taxonomía (propietario,
2026-09-13: "normalmente lo primero que se quiere ver es cpu, RAM, conexiones y cosas así"). Primero
las cuatro preguntas con las que llega un operador — cuánto trabaja, cuánta memoria le queda, cuántas
conexiones mantiene, cuánto tráfico mueve —, después lo que marcaron el colector y el agente, después
las familias que explican las cuatro primeras cuando una tiene mala pinta, después los niveles
profundos a los que un lector va a propósito, y al final lo que mikroscope le cuesta al router que
está midiendo.

Todas las secciones salvo el Overview se publican **plegadas**. Grafana guarda los paneles de una fila
plegada dentro del objeto de la fila y no ejecuta ninguna de sus consultas hasta que alguien la
despliega, así que el primer renderizado pide al almacén los doce paneles del Overview y no los 171.

Los valores por defecto son un rango de 3 horas (`now-3h`) y un refresco de 5 minutos. El refresco de
5 minutos se mantiene para cuando alguien despliega una sección: el censo de slab y los mapas de calor
de la PMU y del coste por muestra devuelven una fila por muestra, y `maxDataPoints` no se aplica al
SQL en bruto. El rango de 3 horas se mantiene porque `now-15m` abría 108 paneles vacíos con el agente
parado, y con el agente en marcha una ventana de 15 minutos de muestras de 100 ms dibujaba muros de
ruido ilegibles. Una investigación en vivo fija su propio rango y su propio refresco.

## El Overview

La única sección abierta. Responde a "¿está sano este router ahora mismo?" y, antes de eso, a "¿puedo
creerme estos números?". Ningún panel de ella es un mapa de calor ni una combinación de varias
medidas, y todos devuelven un agregado; tres paneles ("Reboots in the window", "Sample continuity" y
"Ticks never delivered, this window") lo calculan con una función de ventana sobre las muestras en
bruto de la ventana. La mayoría son copias de paneles que también viven en una sección posterior,
porque un panel de Grafana pertenece exactamente a una fila. "Connections tracked right now", "Load
average (1 min) against the core count", "Reboots in the window" y "Detections in the window" viven
solo aquí, igual que "OOM kills in the window" en Prometheus, donde la copia de la sección de
recuperación de memoria no tiene PromQL y se quita. Las copias comparten su SQL; en Prometheus, el
"OOM kills in the window" del Overview y el "Ticks never delivered, this window" del observador
difieren de sus homólogos (el del observador lleva una tercera consulta, los ticks perdidos por
retraso del muestreador).

1. **CPU busy per core**, **Memory in use, against the kernel's own total** (un indicador de
   `(MemTotal − MemAvailable) / MemTotal`, naranja al 75 %, rojo al 90 %) y **Connections tracked
   right now** (los objetos activos del slab `nf_conntrack`; en blanco en un contenedor sin
   privilegios, y el panel lo dice).
2. **Interface throughput — rx above, tx below** (capa de la API; en blanco con `--api-mode off`, y
   el panel nombra la opción), **Die temperature by zone** y **Load average (1 min) against the core
   count**, donde el número de núcleos se mide en el almacén en vez de suponerse.
3. **Sample continuity**, a todo lo ancho: cada intervalo, nunca más estrecho que un minuto,
   clasificado como continuo, con ticks perdidos o con el agente reiniciado, a partir de la primera
   diferencia del número de secuencia de las muestras. En Prometheus, que no tiene número de
   secuencia, la franja lo aproxima a partir del contador de huecos del colector y de los reinicios
   del contador de muestras del agente, y su descripción lo dice. Todos los demás paneles del
   dashboard deben leerse contra esta franja.
4. **Packets dropped in the kernel RX path (window total)**, **OOM kills in the window**, **Reboots
   in the window** y **Detections in the window** — cada uno a cero en un equipo sano y coloreado
   según sus propios umbrales.
5. **Ticks never delivered, this window**, junto al recuento de reinicios del agente.

> **Una pantalla, medida una vez**
>
> El 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 sin nada cortado. El Overview tiene doce paneles y la
> cuadrícula pasa "Ticks never delivered" a su propia línea a todo lo ancho; esa altura no se ha
> medido en un navegador, aunque el JSON de los dos paneles del repositorio le da 31 unidades de
> cuadrícula, cabecera de fila incluida. En un móvil no es una pantalla: Grafana apila una fila de
> 24 columnas en una sola columna por debajo de unos 768 px, y un Overview de ocho paneles se
> renderizó con 2 188 px de alto en una ventana de 844 px el 2026-09-12.

## Las cuatro preguntas de todos los días

### CPU y planificador

Ticks de `/proc/stat` y la cadencia del propio muestreador. Cada serie por núcleo sale de los datos
(`GROUP BY cpu`, `by (cpu)`), así que una placa de 2 núcleos y una de 8 dibujan cada una sus propias
líneas.

- CPU busy per core
- Busy per core, p95 of one-second means
- Worst sample interval, relative to the window's median
- Per-core busy as states — which core paid, and when
- Where the ticks went — device share by mode
- softirq share of busy time, per core
- Busy-tick distribution per sample
- Share of samples the tick counter called completely idle
- Cycles retired in samples /proc/stat called idle — solo InfluxDB
- nice, irq and iowait ticks in the window
- Tick accounting closes — solo InfluxDB

### Memoria y carga

Los niveles de `/proc/meminfo` y `/proc/loadavg`, promediados o con el máximo sobre un intervalo y
nunca sumados. Todo "porcentaje de RAM" divide por el total que emite el propio kernel.

- Memory in use, against the kernel's own total
- Load average, all three windows
- Runnable threads out of total
- Memory by category, as a share of total
- Free memory — three definitions, against the ceiling
- Commit headroom — Committed_AS as a share of CommitLimit
- Load average (1 min) per core
- Threads on the whole router
- Slab — the conntrack and route tables the netns hides

### Conexiones

La tabla de conexiones del router, sacada del asignador de slab global (`/proc/slabinfo`, solo con
privilegios), junto al recuento de la capa de la API cuando se consulta. Una sección vacía aquí
significa un agente sin privilegios, no un router en reposo; el panel "Slab caches reporting" existe
para decir cuál de los dos es.

- Connection table, two ways — slab objects against the RouterOS API count
- Connection churn floor — peak-to-trough swing inside each bin — solo InfluxDB
- Packet-buffer and large-allocation caches — solo InfluxDB
- Every slab cache, normalized to its own window minimum — solo InfluxDB
- Connection count distribution over time (nf_conntrack) — solo InfluxDB
- Slab census — latest, min, max and spread per cache — solo InfluxDB
- Connection table occupancy
- Connections as RouterOS counts them (API poll)
- Slab caches reporting (is this a privileged deployment?) — solo InfluxDB

### Tráfico por interfaz

`/interface/monitor-traffic`, los contadores por puerto del MAC y `/system/health` desde la API de
RouterOS — los únicos contadores por interfaz que tiene mikroscope, porque el `/proc/net/dev` del
contenedor describe su propio veth — junto a la configuración que la capa de la API lee al arrancar
y cada `--labels-every`: qué es cada interfaz. Las tasas llegan ya por segundo y nunca se suman, y
los contadores por puerto tampoco, porque RouterOS cuenta una cosa distinta en cada tipo. Un puerto
del switch cuenta su cable, tramas reenviadas por hardware incluidas; el bridge cuenta su lado de
CPU; una VLAN o un PPPoE cuentan lo que la CPU envió y recibió. En el RB5009 de referencia
(RouterOS 7.24.2, 2026-09-16) ether1 había recibido 255,8 GB por el cable y 29,7 GB de ellos habían
llegado a la CPU: ether1 y bridge son planos distintos, y ninguno es un subconjunto del otro. El
conjunto de interfaces de los paneles de tasas es el que seleccionó `--interfaces`, así que una
interfaz que falta en uno puede estar en reposo, sin configurar o sin seleccionar, y las tres cosas
se ven igual.

- Interface throughput — rx above, tx below
- Interface packet rate — rx above, tx below
- Mean packet size per interface
- CPU cost of forwarding: cpu-load against the busiest interface's packet rate — solo InfluxDB
- Port errors per bin — typed, from the MAC counters
- Where a port's receive bytes went — switched in hardware, CPU fast path, CPU slow path — solo InfluxDB
- Link flaps — link-downs per interface, per bin
- Frame size mix over the window, per Ethernet port
- Interface drops — rx, tx and tx-queue
- What each interface is: type, role, bridge and label
- Interface inventory and window summary
- /system/health sensors, as RouterOS reads them
- API tier coverage — which sources delivered, and when

"What each interface is: type, role, bridge and label" es la tabla que hay que leer antes de comparar
dos series de interfaz: una fila por interfaz que tiene el router — el tipo de RouterOS, sus listas
de interfaces, el bridge del que es puerto, su comentario, su nombre de fábrica y su MTU — a partir
de tres lecturas de configuración, nunca por consulta. "Frame size mix over the window, per Ethernet
port" es una fila por puerto y no lleva total: cada contador `tx-rx-*` guarda los dos sentidos de su
propio puerto, así que una trama conmutada de ether1 a ether8 se cuenta en los dos, y una suma por
puertos cuenta dos veces cada trama conmutada. "Interface inventory and window summary" no lleva
columnas de errores, porque `monitor-traffic` en RouterOS 7.24.2 no devuelve ninguna tasa de error;
los contadores de error tipificados del MAC tienen su propio panel.

## Lo que se marcó

### Detecciones y capturas

Sucesos, no niveles: lo que la [etapa de derivación](/mikroscope/es/sinks/derive/) del colector y la
[captura por disparo](/mikroscope/es/record/triggers/) del agente dijeron de la ventana. Vacío es el
estado sano, y los paneles de sucesos están marcados como vacíos conocidos para que `check` no falle
por ello.

- Detections per bin, by rule
- Memory pressure state
- Detections in this window — solo InfluxDB
- Trigger fires and suppressions per bin
- Captures held on the agent, and the budget they pin — solo Prometheus
- Trigger markers in this window — solo InfluxDB

En "Trigger fires and suppressions per bin", las supresiones solo están en Prometheus: viven en el
`/metrics` del agente.

### Las rayas rojas discontinuas de todos los paneles

Un dashboard con detecciones en su ventana dibuja una raya vertical roja discontinua, con un pequeño
triángulo al pie del eje, cruzando **todos** los paneles en el instante de cada una. Son anotaciones,
no datos: no son un hueco en el registro, ni un tick perdido, ni un corte de la serie. Están para que
el panel que estés mirando, sea cual sea, se pueda leer al lado de lo que el colector señaló en ese
momento — un régimen de atasco en memoria en un núcleo, una microrráfaga en una cola, un enlace que
parpadeó — sin tener que bajar a la sección de detecciones para enterarte de que pasó algo.

Cada dashboard trae dos capas:

| Capa           | Color   | Por defecto | Qué es cada marca                                                                                                  |
| -------------- | ------- | ----------- | ------------------------------------------------------------------------------------------------------------------ |
| **detections** | rojo    | activada    | una fila de `mikroscope_detection`: la regla, su clave y su mensaje, de la etapa de derivación del colector        |
| **triggers**   | naranja | desactivada | un marcador de captura del agente: la condición que se disparó, el campo y el valor                                 |

Al pasar el ratón por una marca sale el mensaje que lleva la fila, así que la raya responde al *qué*
además de al *cuándo*. La capa de disparos viene apagada para que un dashboard tranquilo siga
tranquilo; actívala cuando estés trabajando con [capturas disparadas](/mikroscope/es/record/triggers/).

**Cómo apagarlas.** Las dos capas son casillas en la fila de submenú de debajo del título del
dashboard — la misma fila en la que van las variables de un dashboard, que en los de InfluxDB,
Prometheus y PostgreSQL no lleva nada más. Pulsa el nombre de la capa para ocultar sus marcas. Es un
ajuste de vista: dura la sesión, y guardar el dashboard lo conserva. No cambia nada de las filas
subyacentes, y la sección de detecciones las sigue contando.

En InfluxDB cada anotación es una fila de suceso con su mensaje; en Prometheus es
`increase(…[1m]) > 0` con un paso de 1 minuto, así que allí una anotación marca el minuto, no el
instante.

Las capturas por sección de más arriba están tomadas con las dos capas apagadas, porque el agente
simulado que llena la base de demostración dispara una detección cada pocos segundos y veinte minutos
de eso salen fotografiados como una mancha roja. Esta es la misma vista general con la capa de
detecciones activada, sobre una base de demostración que lleva tres — la densidad que produce un
despliegue real, y el recuadro de abajo a la derecha cuenta esas mismas tres:

*La capa de detecciones, activada: una raya roja discontinua por detección, en todos los paneles a la vez.*

## Por qué una de las cuatro tiene el aspecto que tiene

### Ruta de recepción de red

`/proc/net/softnet_stat`, que es global incluso dentro del espacio de nombres de red del contenedor.
Aquí no sobrevive ninguna banda absoluta de tasa de paquetes: el régimen de squeeze se clasifica como
un múltiplo de la mediana de la propia ventana.

- RX path: packets processed per second, per core
- Squeeze rate: softirq budget exhaustions per second, per core
- Squeeze pressure: budget exhaustions per 1 000 packets
- Receive-path balance across cores
- Packets dropped in the kernel RX path (window total)
- Squeeze regime per core, as a multiple of this window's median
- Burst distribution: packets per sample (all cores) — solo InfluxDB
- Squeeze against throughput (1 s points, whole window) — solo InfluxDB
- Packets per NET_RX poll, per core

### Coste de reenvío (derivado)

Los cocientes por paquete y la proporción de ruta rápida que el colector deriva cruzando subsistemas
— la PMU contra softnet, softnet contra las interrupciones, los contadores de puerto de RouterOS
entre sí.

La proporción de ruta rápida es la proporción del tráfico que una interfaz le entrega a la CPU, no
una proporción del cable: `fp-rx-byte` sobre `driver-rx-byte` en un puerto del switch, sobre
`rx-byte` en una interfaz software, con las tramas conmutadas por hardware fuera de los dos números.
Ese reparto lo enseña el panel "Where a port's receive bytes went", a partir de los contadores en
bruto. En el RB5009 de referencia (RouterOS 7.24.2, 2026-09-16) los puertos del switch leen en torno
al 100 % — allí `fp-rx-byte` iguala a `driver-rx-byte` con unos pocos kB de diferencia —, mientras
que bridge había llevado por la ruta rápida 211,9 GB de 663,0 GB desde el arranque (32 %) y
PPPoE_DIGI el 99,97 %. La línea de tx suele estar ausente: `fp-tx-byte` se quedó en 0 en todas las
interfaces de ese router después de cientos de GB transmitidos, así que el colector retiene la
proporción de tx mientras el contador acumulado sea 0 en vez de dibujar un 0 % que no ha medido. Por
intervalo, la proporción está ponderada por bytes — los bytes de ruta rápida del intervalo sobre los
bytes del intervalo — porque una interfaz que mueve unos pocos paquetes por consulta oscila entre 0 y
100 % de una consulta a otra, como mostró ese mismo router el 2026-09-15. La forma de Prometheus es
el medidor por consulta del colector y conserva ese ruido.

- Cycles, instructions and cache misses per packet
- Packets per device interrupt (NAPI coalescing depth)
- Fast-path share of the traffic each interface hands the CPU
- Sub-sample bursts: squeezed samples whose packet count looked ordinary

### Interrupciones y softirqs

Deltas de `/proc/interrupts` y `/proc/softirqs`. El nombre del dispositivo se recupera en la consulta
a partir del texto en bruto de `/proc/interrupts`, no comparándolo con un nombre de driver.

- Interrupts per second by source (top-K)
- Per-line interrupt load on the device with the most lines
- Receive-path IRQ imbalance (max / mean across a device's lines)
- Which core takes each interrupt
- Top-K interrupt coverage
- Interrupt mix right now
- Top-K membership — which interrupt sources the agent was watching — solo InfluxDB
- NET_RX softirq invocations per core
- Softirq invocations by kind (all CPUs)
- NET_RX burst size distribution per sample — solo InfluxDB
- µs of softirq CPU per invocation
- NET_TX and TASKLET softirq invocations per second

### Temperatura y reloj

`/sys/class/thermal` y cpufreq. Todo umbral térmico se mide desde el punto de disparo crítico de la
propia zona, leído de la placa: los umbrales del panel de margen están a 10 °C y 5 °C de margen por
debajo de él. Ningún panel lleva una temperatura que la placa no haya publicado.

- Die temperature by zone
- Temperature by source — kernel zones, and the RouterOS sensor when it is polled — solo InfluxDB
- Thermal slope, °C per minute by zone
- Sensor step dwell — where each zone actually sat — solo InfluxDB
- Latest temperature by zone — solo InfluxDB
- Thermal headroom — how far each zone is from its own critical trip — solo InfluxDB
- Gap between the hottest and coolest thermal zone — solo InfluxDB
- Core clock per core — governor state — solo InfluxDB
- Is the clock pinned? — solo InfluxDB
- Clock-weighted work: effective Hz per core — solo InfluxDB

### Log del kernel

`/dev/kmsg`, solo con privilegios. Cuando el log está vacío no está ausente, está en silencio, y el
silencio es el estado sano.

- Worst kernel-log severity in each bin
- Kernel-log records per second by severity
- Warning-or-worse kernel-log rate now
- Kernel records in the window, by severity
- Kernel records per sample — burst distribution against the per-tick cap — solo InfluxDB
- Port events from the kernel log, per port and kind
- Port events in the window, per port

Dos de ellos leen los registros que nombran un puerto de red. Cada registro así lleva una clase —
link-up, link-down, `stp-<estado>`, own-address (el bridge recibiendo una trama con su propia MAC
como origen, la firma de un bucle de capa 2) u otra —, clasificada por el agente mientras lee
`/dev/kmsg`, y por el colector para los registros de un agente que no la clasifica. El colector
sustituye después el nombre de fábrica del puerto por el nombre actual de la interfaz en RouterOS y
le añade su comentario y sus listas de interfaces desde el inventario de la capa de la API; sin la
capa de la API el registro conserva el nombre de fábrica y no lleva etiqueta. "Port events from the
kernel log, per port and kind" los cuenta por intervalo, una serie por puerto y clase, y "Port events
in the window, per port" es el censo que va a su lado: una fila por puerto, con la etiqueta, el rol y
una columna por clase. Esta es la vista por puerto que el contenedor tiene gratis — el log del kernel
no le cuesta nada al router y fecha cada transición al microsegundo, mientras que los contadores por
puerto de RouterOS necesitan una lectura de la API en cada consulta — y es ciega a todo lo que el
kernel nunca llega a oír, las tramas conmutadas por hardware incluidas. A un link-up le siguen
stp-blocking, stp-learning y stp-forwarding en su puerto del bridge: cuatro registros, no cuatro
fallos. Los dos paneles están marcados como vacíos conocidos, porque un conjunto de puertos tranquilo
es el estado sano. La forma de Prometheus lee el `/metrics` del colector, donde todo registro de
puerto lleva un `kind` porque el colector clasifica lo que le llega sin clasificar; la exposición del
propio agente lleva la etiqueta solo cuando es el agente quien clasifica, cosa que el del router de
referencia no hace a fecha del 2026-09-16.

En InfluxDB la tabla `mikroscope_kmsg` se crea con el primer registro del kernel que se escribe, y su
columna `kind` con el primer registro de puerto que se escribe ya clasificado. En un router cuyo
kernel no ha dicho nada desde que arrancó el colector, la tabla no existe e InfluxDB 3 rechaza la
consulta al planificarla; la sección plegada impide que esa consulta se ejecute hasta que alguien la
abre. El código lo llama una mitigación, no un arreglo. `import` con el sondeo lleva esos paneles a
la fila de no disponibles.

## Los niveles profundos

### CPU: cuánto tiempo siguió ocupado un núcleo

La contigüidad, que ningún histograma por muestra puede recuperar: una meseta de 2 s y veinte picos
sueltos caen en los mismos intervalos. En InfluxDB las longitudes de racha son una consulta sobre las
muestras en bruto; en Prometheus son el borde superior del bucket poblado más alto de
`mikroscope_cpu_busy_run_seconds`, recortado a 60 s, así que 60 se lee como "más de un minuto", no
como una medida.

- Longest run at or above 90 % busy, per cpu
- Longest run at or above 50 % busy, per cpu
- Busy run in progress right now — solo Prometheus
- Blocked tasks and forks

### Memoria: fragmentación

`/proc/buddyinfo`, el único número de memoria que `/proc/meminfo` no puede dar.

- Free memory by block order (pages) — solo InfluxDB
- Free blocks per order (count)
- Largest block order with any free block — solo InfluxDB

### Memoria: recuperación y fallos de página

Los deltas de `/proc/vmstat`, sumados o convertidos en tasa sobre un intervalo y nunca promediados —
en una sección separada de los niveles para que los dos tipos de reductor no puedan mezclarse.

- Reclaim efficiency — pgsteal ÷ pgscan
- Did the kernel have to reclaim at all?
- Allocation distress — stalls and swap
- OOM kills in the window — solo InfluxDB
- Page churn — allocate, free, and the net
- Page faults — minor and major per second
- Minor-fault bursts — distribution per sample — solo InfluxDB
- Context switches and all interrupts per second

### Memoria: detalle y comprobaciones cruzadas

La escritura diferida, la LRU, los niveles pequeños y dos paneles que validan el propio instrumento.
Se leen una vez por equipo nuevo, no durante un incidente.

- Writeback backlog — dirty pages and pages in flight
- LRU balance — active vs inactive
- Mapped, kernel stacks and page tables
- vmstat pages vs meminfo kB — unit cross-check — solo InfluxDB
- Kernel stack per thread — solo InfluxDB

### Contadores hardware (PMU)

`perf_event_open` desde el contenedor privilegiado. Cada panel divide dos recuentos en bruto; los
normalizados por reloj dividen por la frecuencia que el kernel informó para ese núcleo en esa
muestra.

- IPC per core (instructions retired / cycles)
- Beneath the tick floor: PMU cycles against /proc/stat busy ticks — solo InfluxDB
- Instructions retired while /proc/stat reported the core idle — solo InfluxDB
- Work the jiffie threw away (selected range) — solo InfluxDB
- Core cycles per bus cycle
- Unhalted-cycle fraction of the clock, per core
- Distribution of cycles per sample, as a share of the clock (all cores pooled) — solo InfluxDB
- Cache-miss rate per core (misses / references)
- Cache misses per 1 000 instructions (MPKI), per core
- Branch mispredictions per 1 000 instructions per core
- PMU counters this CPU actually opened

### Desgaste de la flash

`/proc/yaffs`, la única señal de desgaste de la NAND en una RouterBOARD. Solo InfluxDB: la sección no
tiene fila en el dashboard de Prometheus. Ningún panel puede mostrar una proporción de la partición,
porque el agente no analiza el rango de bloques de la partición, así que no hay denominador para ello.

- Flash page traffic per YAFFS partition (pages/s)
- Write amplification — GC copies per page write
- Flash housekeeping — erasures, garbage collections and GC copies per bin
- YAFFS free-chunk drift within the window (chunks, relative to the first sample)
- YAFFS partition state over the window
- Bad blocks retired during the window, per YAFFS partition
- Page writes and erasures per day, at the window's rate

### Salud de la NAND (ECC)

Los contadores ECC de MTD bajo `/sys/class/mtd`, solo con privilegios — el indicador adelantado de la
flash, mientras que el recuento de bloques defectuosos de YAFFS es la autopsia.

- ECC corrections since boot, per partition, against the bitflip threshold
- Uncorrectable ECC failures and bad blocks, per partition

### Comprobaciones cruzadas con la API de RouterOS — CPU y memoria

`/system/resource` y `/system/resource/cpu`: la capa independiente contra la que se comprueban las
cifras del kernel. RouterOS las recalcula una vez por segundo, así que cada campo es de 1 Hz como
mucho y está cuantizado en enteros; ningún panel de aquí pretende una lectura por debajo del segundo.

- RouterOS cpu-load vs kernel busy — do the two tiers agree?
- Cross-tier residual: cpu-load − kernel busy, distribution
- Per-core load, RouterOS's own accounting
- Per-core mean over the window: RouterOS load next to kernel busy
- Per-core IRQ time as RouterOS accounts it, against kernel softirq+system
- Per-core disk time (RouterOS) — max over the window
- RAM used, as RouterOS accounts it
- Free memory: RouterOS free-memory vs the kernel's two answers
- RouterOS uptime

## Lo que cuesta observar, y si llegó a funcionar

### El observador

Lo que mikroscope le cuesta al router que está midiendo, y si estaba funcionando. En InfluxDB, la
continuidad se deriva del número de secuencia de cada muestra (Prometheus la aproxima, como en el
Overview), lo que 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.

- Agent CPU cost against its 2 % budget
- Observer effect: agent share of all busy CPU on the router
- CPU per sample: mean and worst tick
- Where the agent's cost actually lives (per-sample distribution over time) — solo InfluxDB
- Agent memory against the container cap
- Headroom under the container memory cap
- CPU budget used (window mean)
- Ticks the agent took vs ticks the store received
- Sample continuity
- Ticks never delivered, this window
- Gaps and restarts in this window — solo InfluxDB

### El observador: temporización del muestreador y sucesos propios

El emborronamiento del propio muestreador — con cuánto retraso despertó y cuánto tardó la lectura — y
los sucesos de cgroup que el agente registra sobre sí mismo. Los tres mapas de calor leen los
histogramas del agente, que nunca se envían como muestras, así que solo existen en Prometheus.

- Tick interval distribution, relative to the nominal period — solo Prometheus
- Wake latency: how late the sampler ran after its ticker — solo Prometheus
- Read duration: how long every source took to read — solo Prometheus
- Counter resets the agent saw
- The container's own throttling and OOM kills
- How each level source is read
- Age of each held reading — solo Prometheus

### Este equipo

El [flujo de datos del equipo](/mikroscope/es/sinks/device-info/): lo que el agente estableció sobre
la placa al arrancar sin la API de RouterOS — identidad, techos, la escalera de frecuencias.

- This device, as the agent established it
- Thermal zones: the board's own trip points and polling cadence
- CPU clock: range, ladder, governor and clusters

## No disponible en este equipo

La última fila se titula "Not available on this device — measurements this kernel or board does not
produce (open to read why)" y está plegada. Un panel cuya medida no está en el almacén se saca de su
sección y se lleva a esta fila, donde su descripción dice qué está esperando.

En los ficheros del repositorio — los valores compilados por defecto, que son lo que escribe `gen` a
secas y lo que recibe una subida manual a Grafana — la fila contiene los cinco paneles que el RB5009
de referencia (RouterOS 7.24.2, kernel 5.6.3 arm64) no puede producir:

- Pressure stall (PSI), where the kernel exposes it
- Block-device queue depth (requests in flight)
- Block-device requests per second (reads and writes completed)
- Block-device busy percent (io_s / wall time)
- Block-device throughput (sectors → bytes per second)

El panel de PSI está vacío allí porque ese kernel no tiene `/proc/pressure`. Los paneles de dispositivos de bloques están vacíos allí porque el agente descarta un dispositivo de
bloques cuyas lecturas, escrituras y peticiones en curso son todas cero en un tick, y en ese router
todos los dispositivos listados se quedan a cero, así que ningún destino llega a crear la tabla.

Para estos paneles hay declaradas dos secciones, **Pressure stall (PSI)** y **Block devices**, que no
emiten fila mientras todos sus paneles estén ausentes. En un kernel compilado con PSI, o en una placa
con almacenamiento USB o eMMC que se mueva, `import` encuentra la medida y la sección aparece en su
sitio sin tocar el generador. `import` también funciona en el otro sentido: en un almacén al que le
falta una medida que sí tenía el equipo de referencia — o un campo añadido después de que ese almacén
se escribiera por primera vez — el panel pasa a esta fila con su consulta eliminada, así que muestra
su explicación y no una insignia roja de error. Cómo decide el sondeo está en
[Importar y comprobar](/mikroscope/es/dashboards/import-and-check/#el-sondeo).

## Cómo tratan los dashboards los cocientes, los huecos y las cifras

- **Los cocientes nunca son del agente.** El agente solo envía contadores en bruto, nunca
  porcentajes. Un cociente de estos dashboards se calcula o bien en la consulta del propio
  panel o bien en la etapa de derivación del colector (la sección de coste de reenvío y las familias
  `mikroscope_derived*`). Las tasas de interfaz de la capa de la API son la excepción: llegan de
  RouterOS ya calculadas.
- **No dibujan los huecos cortos.** Una línea se corta donde dos puntos vecinos están separados más de
  5 minutos. El umbral tiene que superar el intervalo más ancho que seleccione un lector — con un
  rango de 2 días el intervalo de un panel de 12 columnas es de unos 4 minutos —, así que un hueco de
  menos de 5 minutos se sigue dibujando como una línea interpolada. Lee los huecos en Sample
  continuity, no en la forma de una línea.
- **Sus cifras son las de un router.** Las descripciones que citan una cifra la atribuyen al RB5009 de
  referencia con la fecha en que se midió y dicen que las tuyas serán distintas. Ningún título,
  consulta ni umbral nombra un equipo, su número de núcleos, sus interfaces o su tamaño de memoria;
  los únicos números fijos son los objetivos de presupuesto propios de mikroscope
  (2 % de un núcleo, 16 MiB).

> **Versiones de Grafana**
>
> Los dashboards se comprobaron en Grafana 12.3.2 (2026-09-12) y Grafana 13.2.1 (pasadas en el
> navegador el 2026-09-12 y el 2026-09-14, `check` y renderizado el 2026-09-15, y `check` otra vez el
> 2026-09-16). Las opciones de los
> paneles están escritas según el esquema que espera Grafana 13.2.1 — la marca del xychart, por
> ejemplo, cambió de sitio entre Grafana 11 y 13 — y `__requires` declara Grafana 11.0.0. No se ha
> probado ninguna versión aparte de esas dos.

## Véase también

- [Importar y comprobar](/mikroscope/es/dashboards/import-and-check/): la fuente de datos, los dos
  trabajos de scrape de Prometheus y lo que `check` verifica y lo que no.
- [Reglas de alerta](/mikroscope/es/dashboards/alerts/): las reglas que se generan junto a los
  dashboards, y de dónde sale cada umbral.
- [Detecciones](/mikroscope/es/sinks/detections/): los sucesos detrás de la sección de detecciones y
  de las anotaciones.
- [Familias de métricas de Prometheus](/mikroscope/es/reference/metrics/): lo que lee cada panel de
  Prometheus.