Cadencias de las fuentes

No todas las fuentes cambian tan rápido como hace tick el muestreador, y guardar un valor más a menudo de lo que el hardware lo refresca es almacenamiento sin información. El agente lee cada contador en cada tick salvo los contadores ECC de MTD (cada 10 s), ralentiza una fuente de nivel solo por un motivo que nombra y publica cada cadencia para que ningún consumidor tenga que deducirla. FLOOR_HZ desactiva todos los suelos a la vez.

Contadores

Los ticks de CPU, las interrupciones, las softirqs, los contadores de vmstat, la PMU y los niveles de memoria (que cambian muchas veces por segundo, medido) se leen y se envían en cada tick. En un contador, un delta de cero es información real, el núcleo estaba ocioso, así que no hay nada que saltarse.

Otras tres fuentes se leen en cada tick con su propia regla:

El desgaste de la NAND (/proc/yaffs) y la E/S de bloque (/proc/diskstats) son contadores y baratos de leer. La fila de un dispositivo solo se guarda cuando su delta no es cero: un router puede listar muchos dispositivos ociosos, nbd entre ellos, y una fila por tick para cada uno sería carga útil y nada más.
El log del kernel (/dev/kmsg) se vacía en cada tick y nunca se ralentiza. El valor de un evento es su marca de tiempo, y un marcador retrasado un segundo ya no cuadra con el pico que explica.

Fuentes de nivel

Una fuente de nivel (una temperatura, una frecuencia de reloj, la población de una caché) puede leerse o guardarse con menos frecuencia que en cada tick, pero solo por un motivo que el agente nombra. Nunca se ralentiza porque se la haya visto cambiar despacio, ya que eso mediría una noche en un equipo. Cada fuente de nivel publica su cadencia y su motivo en /capabilities bajo cadences, en /metrics como mikroscope_source_cadence_hz{source,reason}, y a cada destino en el flujo de datos del equipo, de modo que un consumidor lee la cadencia verdadera de un campo en vez de deducirla de los datos.

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

rate describe solo la cadencia de lectura, así que /proc/buddyinfo publica rate aunque se guarda al cambiar. Los contadores MTD publican budget aunque no se midió ningún coste de análisis para ellos. Así los etiqueta el código, y ninguno de los dos encaja del todo con la tabla de arriba.

Cadencia por fuente

Fuente	Lectura	Almacenamiento	`reason`
zonas térmicas	al `polling_delay` declarado por la zona, si no en cada tick	cada lectura	`declared`, o `rate` donde la placa no declara ninguno o la cadencia del muestreador no es más rápida que la declarada
`scaling_cur_freq`	en cada tick	al cambiar, o por latido	`change`, o `policy` con un gobernador `userspace`
`/proc/slabinfo`	a unos 6 Hz	al cambiar, o por latido	`budget`
`/proc/buddyinfo`	en cada tick	al cambiar, o por latido	`rate`
contadores ECC MTD	cada 10 s	al cambiar, o por latido	`budget`

Una cadencia más lenta es un número entero de ticks: la cadencia del muestreador dividida entre el suelo, redondeada al entero más cercano y nunca menor que uno. Así que la cadencia publicada es lo que ocurre de verdad, no el suelo nominal.

Temperatura. Una zona térmica declara su propio polling_delay. Con 1 000 ms el propio kernel vuelve a leer el sensor a 1 Hz, y a 10 Hz el agente lee uno de cada 10 ticks. El sensor cuantiza en escalones de unos 0,42 °C, y la lectura en bruto tiembla a ambos lados de un escalón decenas de veces por segundo. Guardar al cambiar guardaría ese temblor como señal; muestrear y mantener a la cadencia declarada captura la curva real y descarta el temblor. En una placa que no declara cadencia, las zonas se leen en cada tick.

Frecuencia de CPU. Un salto de frecuencia es una transición DVFS real, no ruido, así que la frecuencia se lee en cada tick y se guarda cuando se mueve cualquier núcleo. En un equipo con el reloj fijado eso no guarda nada tras la primera lectura salvo el latido; en un equipo que escala recoge cada movimiento. Con un gobernador de cpufreq userspace el reloj no puede moverse sin una escritura, así que el motivo es policy.

/proc/slabinfo es la cara, el mayor análisis por tick, un orden de magnitud por encima de cualquier otro, y ese coste es la razón de que se ralentice. Los 6 Hz a los que se ralentiza son la frecuencia a la que se midió que cambiaba su caché más rápida, nf_conntrack. Se guarda al cambiar. A 10 Hz eso es uno de cada 2 ticks (5 Hz); a 100 Hz, uno de cada 17 (unos 5,9 Hz). Cómo se nota ese reparto en el coste por muestra está en Techo de muestreo.

/proc/buddyinfo ocupa unos 100 bytes, uno de los ficheros más baratos que lee el agente, y no tiene suelo porque no se ha medido ninguno. Las listas libres se agitan con cada asignación, así que en un router ocupado se guardará en la mayoría de los ticks, y eso es la medida, no ruido.

Los contadores ECC de MTD se leen cada 10 segundos. Eso no es un suelo medido: los contadores se mueven a la escala de la vida de un equipo, y cada lectura son seis pequeños ficheros de sysfs por partición, así que diez segundos es una elección arbitraria pero holgada. El código sigue etiquetando esa cadencia como budget, aunque no se midió ningún coste de análisis para ella. Necesitan privileged=yes.

Los 6 Hz de /proc/slabinfo son el único suelo medido, y salen de un solo equipo durante una sola noche en reposo (dónde se midió). Un router con un reloj que escala, una carga con muchas páginas sucias o una placa distinta tienen suelos distintos, así que vuelve a medir con FLOOR_HZ igual a la cadencia del muestreador antes de fiarte de ellos en el tuyo. Los suelos son constantes con nombre en internal/agent/source.go.

Latido

Toda fuente que se guarda al cambiar se vuelve a emitir además aproximadamente una vez cada 60 segundos (en la primera lectura que toque pasados 60 s), de modo que un valor que se queda quieto una hora sigue teniendo una fila reciente en cualquier almacén. El propio memory.max del contenedor, una constante, se vuelve a emitir en las muestras una vez por latido (en cada tick con FLOOR_HZ); los limits de /capabilities y el flujo de datos del equipo lo llevan desde el arranque.

En /metrics, un medidor con suelo mantiene entre emisiones la última lectura, porque el valor de un nivel entre lecturas es el último leído, no nada. mikroscope_source_age_seconds{source} dice lo antigua que es esa lectura mantenida.

El filtro de cambios se rearma tras la lectura de referencia del muestreador, así que la primera muestra lleva todas las fuentes que se guardan al cambiar, y las familias de medidores con suelo llegan a /metrics con ella y no un latido después.

Anulación con `FLOOR_HZ`

Todos los suelos se pueden anular a la vez, sin recompilar:

mikroscope install --rate 10 --floor-hz 10   # escribe FLOOR_HZ=10 en la envlist del agente

FLOOR_HZ es la variable de entorno del agente; --floor-hz es la opción de despliegue (install, upgrade, y plan para el listado) que la escribe en la envlist del contenedor, solo cuando es mayor que cero. Es un único ajuste global en hercios, de 0 a 1000.

0, el valor por defecto, mantiene los suelos por fuente descritos arriba.
Cualquier N > 0 pone las zonas térmicas, /proc/slabinfo y los contadores MTD en una única cadencia de N Hz, y desactiva el filtro de guardar al cambiar para todas las fuentes de nivel, de modo que no se retiene nada y una captura ve cada lectura. Todas las fuentes de nivel publican entonces el motivo override.
Un N igual o superior a --rate lee y emite todo en cada tick. Es la configuración desde la que se midieron los suelos, y la que hay que volver a ejecutar antes de fiarse en tu equipo de cualquier número de esta página.

Hay dos cosas que FLOOR_HZ no cambia. El filtro de filas por dispositivo de /proc/yaffs y /proc/diskstats se mantiene: un dispositivo cuyos contadores no se movieron sigue sin fila, lo que no pierde nada porque el delta era cero. Y scaling_cur_freq y /proc/buddyinfo se leen en cada tick con o sin él; con N por debajo de --rate se emiten en cada tick, pero su cadencia publicada es la del override, no la del muestreador.

Lo que cuesta leerlo todo en cada tick, a 50 y a 100 Hz, está en Techo de muestreo.

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