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: qué guarda, cuándo se envía y dónde lo pone cada destino.

Contenido

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: cada techo del registro es la lectura del propio equipo.

Motivos de 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í están en Cadencias de las fuentes.

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 mostrarían «No data» en toda ventana posterior. Cinco minutos pone los datos dentro de cualquier ventana en la que valga la pena leerlos y cuesta, por envío, una fila de identidad, una por zona térmica, una por núcleo con datos de cpufreq y una por fuente de nivel, frente a las 864 000 filas de muestra al día que produce --rate 10.

La repetición va marcada como tal, y los destinos se reparten según eso: los almacenes la escriben como cualquier otra fila, así que toda ventana tiene los datos, 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) y no observado (Probado en).

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.

Almacenamiento por 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 (`--sql`, `--postgres`)	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 familias de datos del equipo, representadas por la exposición del colector

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

El agente lee el cluster de cpufreq de cada núcleo de su related_cpus, en cada equipo. En una placa cuyos núcleos cambian de frecuencia por parejas, por ejemplo con los clusters {0,1} y {2,3}, un panel de frecuencia por núcleo son en realidad dos series. 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.

Escrito y mantenido por José Manuel Requena Plens (jmrplens)jmrp.ioGitHub