El flujo de datos del equipo

Al arrancar, el agente averigua lo que puede sobre la placa en la que corre, sin la API de RouterOS y sin ninguna credencial, y lo sirve en /capabilities. El colector lo entrega a cada destino como registro propio. Esta página responde a qué guarda el registro, cuándo se envía y dónde lo pone cada destino.

Lo que lleva

Identidad: la cadena de modelo del device tree (la placa), el kernel, el número de núcleos, si el contenedor es privilegiado y si tiene cgroup2, las fuentes activas, la procedencia de la tabla de puertos, y un hash del kernel, el número de núcleos y las fuentes activas.
Los techos propios del equipo, leídos una vez al arrancar el agente: el punto de disparo crítico y el retardo de sondeo de cada zona térmica; el rango cpufreq, la escalera de frecuencias, el governor y el cluster de cada núcleo; el techo de conntrack del kernel; el memory.max del propio contenedor.
Cadencias: la cadencia a la que se lee y guarda cada fuente de nivel, y el motivo con nombre por el que no es la cadencia del muestreador.

Un techo que la placa no publica se omite, nunca se rellena con un número sacado de otro sitio — el techo de conntrack de 966 656 y el límite de 64 MiB del contenedor son los de la propia placa.

Los motivos que da una cadencia

Los motivos de cadencia que puede publicar una fuente
`reason`	Qué significa
`rate`	se lee a la cadencia completa del muestreador; nada de lo que declara el equipo justifica menos
`declared`	el equipo publica su propia cadencia de refresco, y leer más rápido devuelve el mismo valor con un temblor nuevo
`policy`	un ajuste dice que el valor no puede moverse por sí solo: un gobernador cpufreq `userspace`
`budget`	un coste de análisis medido
`change`	se lee en cada tick y se guarda solo cuando se mueve
`override`	`FLOOR_HZ` está fijado, y todas las fuentes de nivel van a su única cadencia

Los contadores nunca tienen suelo; solo las fuentes de nivel llevan cadencia. Los suelos en sí y cómo se midieron están en cada fuente a su propio suelo.

Cuándo se envía

Cuando arranca forward, cada vez que cambia el hash de capacidades del agente — un agente reiniciado con otro conjunto de fuentes, por ejemplo — y, si no, cada cinco minutos. El colector comprueba el hash en la lectura de estado que hace cada minuto para volver a medir el desfase de reloj, así que un cambio llega a los destinos en más o menos un minuto. Tanto el transporte directo como el relay pueden obtener /capabilities; cuando la obtención falla, el colector lo registra, no envía nada y lo vuelve a intentar en la siguiente lectura de estado. Que no se envíe nada es ausencia, no una placa sin datos.

Por qué se repite. Estos datos son filas con la marca de tiempo del colector, así que un almacén solo los tiene en los instantes en que se enviaron, y una ventana de panel que no contiene ningún envío no contiene ningún dato. Enviados una sola vez al arrancar, los cuatro paneles del equipo muestran «No data» en toda ventana posterior: medido en el despliegue de referencia el 2026-09-17, donde la última fila de equipo tenía 26 horas y esos paneles llevaban vacíos otro tanto. Cinco minutos pone los datos dentro de cualquier ventana en la que valga la pena leerlos y cuesta doce filas por envío — una de identidad, una por zona térmica, una por núcleo con datos de cpufreq, una por fuente de nivel — frente a las 864 000 filas de muestra al día que produce --hz 10.

La repetición va marcada como tal, y los destinos se reparten según eso: los almacenes la escriben como cualquier otra fila, que es justo para lo que está, y los flujos pensados para que alguien los lea — Loki, stdout, una grabación — la saltan, porque un registro es para lo que cambia. Así Loki sigue llevando exactamente una línea device por conjunto de datos.

El hash solo cubre la cadena del kernel, el número de núcleos y los nombres de las fuentes activas; quedan fuera la placa, privileged, cgroup, la procedencia de la tabla de puertos, cada techo y cada cadencia. Un agente reiniciado cuyo único cambio es un techo o una cadencia — un --memory-max nuevo, o un FLOOR_HZ con el mismo conjunto de fuentes — conserva su hash, así que el cambio no es lo que dispara el envío; llega a los destinos en la siguiente repetición de cinco minutos, y la fila que lo lleva queda marcada entonces y no cuando ocurrió. Esto está leído en el código (capsHash en internal/agent/source.go), no observado.

Son hechos, no muestras. No tienen reloj propio, así que los destinos que ponen marca de tiempo a sus registros los marcan con el reloj del colector en el momento en que se enviaron; las líneas del fichero y de stdout json no llevan marca de tiempo, y Prometheus los genera al hacer el scrape. Nunca se mezclan en una fila de muestra.

Dónde lo pone cada destino

Destino	Forma
InfluxDB, Telegraf, stdout `lp`	`mikroscope_device{board,kernel}`, `mikroscope_device_thermal{zone}`, `mikroscope_device_cpufreq{cpu}`, `mikroscope_device_cadence{source,reason}`
SQL	las tablas `mikroscope_device`, `mikroscope_device_thermal`, `mikroscope_device_cpufreq`, `mikroscope_device_cadence`
file, stdout `json`	una línea `{"device":…}` con las capacidades tal como se obtuvieron
Elasticsearch	un documento con `kind: device`
Graphite	los datos numéricos bajo `device.*`; placa, kernel y governor no tienen forma en Graphite
OTLP	gauges: `mikroscope.device.cores` con placa, kernel y hash como atributos, los techos térmicos y de cpufreq, `mikroscope.device.source_cadence`
Loki	una línea `source="device"`, `level="info"`: board, kernel, cores, privileged, cgroup, sources, hash
Prometheus	las mismas familias de datos del equipo que lleva el propio `/metrics` del agente

InfluxDB y SQL

Medida o tabla	Identificada por	Guarda
`mikroscope_device`	`board`, `kernel`	`cores`, `privileged`, `cgroup`, `sources` (unidas por comas, ordenadas), `hash`, `conntrack_max`, `cgroup_mem_max`, `ports_from`
`mikroscope_device_thermal`	`zone`	`critical_celsius`, `polling_ms`
`mikroscope_device_cpufreq`	`cpu`	`cluster` (el núcleo de número más bajo que cambia de frecuencia con este), `min_khz`, `max_khz`, `governor`, `steps`
`mikroscope_device_cadence`	`source`, `reason`	`hz`

En InfluxDB board y kernel son tags, unknown cuando están vacíos; en SQL son columnas, NULL cuando están vacías, y un techo que no se publicó es NULL. steps es la escalera de frecuencias como lista de kHz separada por espacios.

Prometheus

Familia	Lleva
`mikroscope_device_info{board,kernel,cores,privileged,cgroup,ports_from,hash}`	siempre 1
`mikroscope_thermal_critical_celsius{zone}`	el disparo crítico más bajo de la zona
`mikroscope_thermal_polling_seconds{zone}`	el retardo de sondeo de la zona
`mikroscope_cpu_frequency_limit_hertz{cpu,bound}`	el rango del reloj hardware, `min` y `max`
`mikroscope_cpu_frequency_step_hertz{cpu,step}`	cada frecuencia que usará el driver
`mikroscope_cpu_frequency_governor_info{cpu,governor}`	siempre 1
`mikroscope_cpu_frequency_cluster{cpu}`	el cluster, nombrado por su núcleo de número más bajo
`mikroscope_self_cgroup_memory_max_bytes`	el `memory.max` del propio contenedor
`mikroscope_source_cadence_hz{source,reason}`	la cadencia de cada fuente de nivel

En el RB5009 de referencia, leídos de related_cpus y affected_cpus dentro del contenedor el 2026-09-14 (RouterOS 7.24.2), los clusters de cpufreq son {0,1} y {2,3}, así que un panel de frecuencia por núcleo son en realidad dos series. Esa es la topología de esta placa y de ninguna otra: el agente lee los clusters por equipo, y no se ha medido ninguna otra placa. El techo de conntrack llega a Prometheus como mikroscope_slab_limit_objects de la caché nf_conntrack y no como una familia de datos del equipo.