# El flujo de datos del equipo Lo que el agente establece sobre la placa sin la API de RouterOS — identidad, techos, cadencias — y cómo el colector lo entrega a cada destino como hechos y no como muestras. Source: https://jmrplens.github.io/mikroscope/es/sinks/device-info/ 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](/mikroscope/es/limits/source-floors/). ## 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. ## Véase también - [Los endpoints HTTP del agente](/mikroscope/es/reference/http/): `/capabilities`, de donde sale este registro. - [Cada fuente a su propio suelo](/mikroscope/es/limits/source-floors/): las cadencias y las medidas que hay detrás. - [InfluxDB 3](/mikroscope/es/sinks/influxdb/): las demás medidas junto a las que están los registros del equipo.