Baterías de pruebas

Cuatro baterías prueban mikroscope, y ninguna necesita un router. Ejecuta la que cubre tu cambio antes de abrir un pull request. La CI ejecuta las tres primeras en cada pull request. El laboratorio se ejecuta cada semana y a petición, así que ejecútalo tú antes de un pull request que toque lo que instala el agente.

Batería	Orden	Necesita	Qué demuestra
Unitaria	go test ./cmd/... ./internal/...	Go	cada paquete, contra árboles /proc capturados, simulaciones y ficheros de referencia
De extremo a extremo	make test-e2e	Go	los dos binarios como procesos separados, y los bytes exactos que envía cada destino
Almacenes	make test-e2e-docker	Linux, Docker	que un almacén real acepta esos bytes y los devuelve; que responde la consulta de cada panel de los dashboards
Laboratorio virtual de RouterOS	make lab-up y después make test-lab	Linux, Docker, /dev/kvm para x86_64	las órdenes de despliegue contra un RouterOS real, con el /export del router igual al inicial tras cada una

make test ejecuta juntas la batería unitaria y la de extremo a extremo. Las de almacenes y laboratorio van tras las etiquetas de compilación dockere2e y labe2e, así que make test no compila ninguna de las dos, y make lint comprueba los tipos de ambas para que no se pudran.

Cuándo se ejecutó cada batería por primera vez, cuánto tarda y qué encontró está en Probado en.

Elegir una batería

Has cambiado	Ejecuta
Cualquier código Go	make test
El muestreador, el anillo, el flujo o un destino	además, make test-race
Una prueba que podría haber empezado a depender de la red	make test-e2e-offline (Linux)
Un destino, su codificación o su esquema, o un dashboard	make test-e2e-docker
internal/router, una orden de despliegue, la imagen del agente o cómo arranca	make lab-up y después make test-lab
El conductor del laboratorio (cmd/mikroscope-lab, internal/lab)	go test ./internal/lab/... ./cmd/mikroscope-lab/ y después make test-lab

Las comprobaciones estáticas que también debe pasar un pull request (make analyze, el presupuesto de tamaño del agente, las puertas del sitio) están en CONTRIBUTING.md.

Batería unitaria

go test ./cmd/... ./internal/...   # solo la batería unitaria
make test                          # todos los paquetes sin etiqueta, incluida la batería de extremo a extremo
make test-race                     # todas las baterías bajo el detector de carreras
make cover-check                   # falla por debajo de COVERAGE_MIN sobre cmd/ e internal/

Cada paquete se prueba contra datos de prueba, nunca contra un router:

• Los analizadores de /proc y /sys leen un árbol capturado de un router real, testdata/proc/rb5009/.
• plan, el guion de instalación y los listados se comparan con ficheros de referencia en internal/router/testdata/, un juego por cada caso de cases.json. make check-generated falla cuando la copia de esos guiones que tiene el sitio está desfasada.
• El conductor del laboratorio se prueba contra un Docker falso y un router falso: el aprovisionamiento, el cerrojo, las descargas y sus sumas de comprobación, la cadena de instantáneas, las reglas del cortafuegos, la línea de órdenes de QEMU y los rechazos de la CLI.

Trabajo	Qué ejecuta	Cuándo
Multiplataforma, Linux, macOS, Windows	la batería unitaria; en macOS y Windows, también la de extremo a extremo	en cada pull request
Cobertura	make cover-check	en cada pull request
Detector de carreras	make test-race	cada semana, y antes de una publicación

Batería de extremo a extremo

make test-e2e compila los dos binarios y los maneja como procesos separados. El agente lee el árbol capturado. El colector lee ese agente, o uno simulado que sirve muestras enlatadas, y escribe cada destino en un receptor dentro del binario de prueba, que comprueba lo que llegó byte a byte.

Destino	Receptor
InfluxDB, Loki, OTLP, Elasticsearch, Telegraf	un servidor HTTP de captura
Graphite, los modos de socket de Telegraf	escuchas TCP y UDP
Fichero, SQL	ficheros reales
stdout	la salida estándar del propio proceso
Prometheus	un scrape del /metrics del colector

No necesita router, ni Grafana, ni base de datos, ni contenedor, ni red: toda dirección que enlaza o marca está en loopback. make test-e2e-offline lo demuestra en Linux ejecutando la batería en un espacio de nombres de red sin nada más que lo. Necesita unshare y setpriv, y ejecuta unshare con sudo salvo que ya tenga la capacidad.

La CI ejecuta la batería y su forma sin red en cada pull request, cada semana y antes de una publicación, y ejecuta la batería también en macOS y Windows, donde pueden cambiar el nombre del ejecutable, los ficheros que escriben los destinos de fichero y SQL y la forma de parar un proceso hijo.

Batería de almacenes

Un servidor de captura responde 204 a todo; un almacén no. make test-e2e-docker levanta ocho almacenes y un Grafana con docker compose, ejecuta el mismo colector contra el mismo agente simulado con todos los destinos apuntando a ellos, y le hace a cada almacén su propia pregunta por su propia API. El JSONL del destino de fichero es el oráculo: cada almacén se compara con él valor a valor, no solo por recuento.

Almacén	La pregunta que se le hace
InfluxDB 3 Core	SQL por HTTP: las tablas, un recuento de filas por tabla, cada valor ctxt
PostgreSQL 18	el guion del destino SQL por psql, y el destino PostgreSQL con conexión en una segunda base de datos: recuentos, el rango de ctxt y si las dos guardan las mismas filas
Elasticsearch 9	_search con una agregación por tipo, y un documento entero
Loki 3	query_range para las etiquetas de esta ejecución, y el texto de cada registro
Graphite	metrics/find para el árbol, render para los puntos y su orden
OpenTelemetry Collector	lo que decodificó, escrito de vuelta como OTLP/JSON
Telegraf 1.39	el protocolo de línea que analizó: medidas, etiquetas, tipos de campo, marcas de tiempo
Prometheus 3	un scrape del exportador, contra la exposición que sirvió

La batería además publica las cinco fuentes de datos con forward --grafana, y vuelve a vaciar todos los almacenes con uninstall --targets data.

Fallos que solo muestra un almacén

• InfluxDB 3 fija una columna como etiqueta o como campo la primera vez que ve la tabla, y rechaza una escritura posterior que no coincida.
• Carbon no responde nada en absoluto: un punto más viejo que su archivo más largo, o un nombre del que whisper no puede hacer una ruta, se descarta en silencio.
• Loki responde 204 a un envío que no es consultable hasta que el trozo se vuelca, y rechaza entradas desordenadas por flujo, en el cuerpo.
• Elasticsearch infiere un mapeo del primer documento que ve para un campo y luego rechaza otro posterior que no encaje, por documento, dentro de una petición bulk que aun así responde 200.
• Telegraf es un analizador real de protocolo de línea: un espacio sin escapar en el valor de una etiqueta, o un campo sin tipo, se descarta y el lote sigue siendo 204.
• PostgreSQL es lo único que puede decir si el guion del destino SQL es SQL válido, si los tipos que eligió aguantan los valores que emite y si sus claves primarias chocan en una ejecución real.

Paneles

La misma ejecución importa los cinco dashboards en Grafana, cada uno apuntado al almacén que acaba de llenar, y pasa la consulta de cada panel por la propia /api/ds/query de Grafana: el dashboards check que puedes ejecutar contra tu almacén. Ahí un panel falla por motivos a los que no llega ninguna prueba unitaria: un tipo que devuelve una agregación y el complemento de la fuente de datos no sabe decodificar, una macro que el complemento escapa, una columna que el almacén no tiene. En InfluxDB 3 una columna que falta no es una columna vacía: la consulta falla con Schema error: No field named <column> y el panel no puede dibujarse (encontrado así).

Ejecutar la batería de almacenes

make test-e2e-docker        # la batería entera; la pila se levanta y se apaga con ella
make e2e-docker-up          # deja la pila levantada entre ejecuciones
go test -v -tags dockere2e -run TestLoki ./test/e2e/docker/
make e2e-docker-down        # para la pila y borra sus volúmenes
make test-e2e-docker-race   # la misma batería bajo el detector de carreras

El arnés reutiliza una pila que no levantó él, y la deja levantada al terminar. Por qué cada almacén es uno real y no una simulación está en test/e2e/docker/README.md. La CI ejecuta la batería en cada pull request, cada semana, a petición y antes de una publicación.

Linux, para dos de los nueve

Prometheus y Grafana se ejecutan sobre la pila de red del anfitrión, porque Prometheus es el único destino que se consulta en vez de recibir envíos, y tiene que alcanzar el exportador del colector en el anfitrión. Un contenedor en una red puente llega al anfitrión por la pasarela del puente, y ese camino pasa por la cadena INPUT del anfitrión, que un cortafuegos que deniega por defecto descarta. Los otros siete servicios son contenedores normales de red puente.

Laboratorio virtual de RouterOS

doctor, plan, install, upgrade, status y uninstall necesitan un RouterOS para poder probarse. El laboratorio es el Cloud Hosted Router (CHR) de MikroTik, un RouterOS real, bajo QEMU en un contenedor Docker. Se aprovisiona una vez en una instantánea limpia, con el paquete container instalado y device-mode container=yes confirmado, y vuelve a esa instantánea en segundos. El relato completo, cómo está montado y qué le enseñó CHR al instalador, está en test/lab/README.md.

Laboratorio	Se ejecuta como	Úsalo para
x86_64	CHR bajo KVM	todos los escenarios, rápido; la CI lo ejecuta cada semana y a petición
arm64	CHR emulado por QEMU (TCG), modelo de CPU cortex-a72	el paquete container y la imagen del agente de arm64, y RouterOS eligiendo la imagen para arm64; lento

Un tercer laboratorio, RouterOS x86 instalado desde la ISO de MikroTik (make lab-up LAB_KIND=iso, solo x86_64), es una receta opcional que la CI nunca ejecuta. Añade la vía de instalación de un PC, un nombre de placa x86 y la licencia de x86 (una prueba de 24 horas, y después un registro de nivel 1 o una licencia de pago por equipo), y nada que el agente lea y CHR x86_64 no tenga.

La CLI se ejecuta dentro de la LAN del laboratorio. mikroscope-lab cli la arranca en el espacio de nombres de red del contenedor del laboratorio, donde 172.30.0.0/16 va al router del laboratorio, así que la dirección por defecto del agente, 172.30.10.2, llega al agente del laboratorio y a nada más. Desde tu propia shell, la misma dirección sale por tu ruta por defecto, hacia la red que sea. Por eso toda orden de despliegue, a mano (make lab-cli) o en la batería, pasa por mikroscope-lab cli, que rechaza --router y un --subnet fuera de las rutas del laboratorio. El espacio de nombres del laboratorio tiene su propio cortafuegos: no abre ninguna conexión nueva hacia una dirección privada fuera del laboratorio, ni acepta ninguna de otro contenedor.

Batería del laboratorio

make test-lab compila la CLI y los tar de la imagen del agente, y luego ejecuta la batería de test/e2e/lab/ contra el laboratorio en marcha, con el cerrojo del laboratorio tomado durante toda la ejecución. Cada escenario empieza con un reinicio a la instantánea y el perfil que nombra, toma ahí el /export del router como línea base, y termina comparando los dos.

Escenario	Qué hace	Qué comprueba
S1	doctor en un CHR de fábrica, con las listas none y con los valores por defecto	nada falta con none; con los valores por defecto solo la lista de interfaces LAN, cuyo arreglo ofrece --iface-list none
S2	instalar descargando la imagen de Docker Hub, status, upgrade, uninstall	el agente responde a /healthz y /capabilities; el export vuelve a su línea base
S3	instalar y actualizar desde el tar de la imagen de la propia rama	el agente informa de la versión, el commit y la fecha de la compilación de la rama
S4	plan --rsc para las dos vías de imagen, ejecutado con /import	status reconoce los objetos del guion; uninstall deja la línea base
S5	cada guion de referencia que el laboratorio puede ejecutar, importado tal como lo entrega el sitio	el agente responde en su propia /30; uninstall con las opciones del caso deja la línea base
S6	--ephemeral en un disco tmpfs, y luego un corte de corriente	el contenedor queda parado y sin su raíz; uninstall --ephemeral no deja nada en absoluto
S7	una instalación persistente, 45 s para que llegue al disco, y luego un corte de corriente	el agente vuelve a responder en menos de 90 s: el arranque con el router funciona
S8	--expose con un token	/capabilities responde 401 sin el token y 200 con él; las dos reglas de cortafuegos se van con la desinstalación
S9	uninstall mientras un cliente lee /stream, diez veces	cada primer intento verifica el router limpio
S10	las reglas raw del cortafuegos avanzado de MikroTik, en forma de lista y de rango	doctor nombra la regla que descarta las respuestas del agente, y las pertenencias a listas que pasan
S11	una veth ajena, una /30 enrutada, una envlist ajena	doctor nombra cada una; install no escribe nada; el guion de plan --rsc se detiene en su guarda para la veth y la envlist
S12	dos instalaciones una al lado de otra	quitar una deja la otra en marcha e intacta
S13, S14	instalaciones con otras listas, y con --expose, desinstaladas sin opciones	se quita todo lo que crearon; una opción que contradice se rechaza
S17	doctor en un laboratorio por debajo del RouterOS mínimo	falta RouterOS 7.24 or later, y todas las demás comprobaciones se siguen leyendo
S18	una descarga de GHCR sin credencial de registro	el agente responde
F4	cada vía de instalación, una instalación hecha por una CLI publicada, objetos que el usuario creó antes	/export igual al de antes de instalar y /file sin ninguna ruta de mikroscope; los objetos del usuario se quedan
repetición	instalaciones y desinstalaciones desde el tar seguidas, diez en x86_64 y tres en arm64	ninguna instalación falla

Los escenarios comprueban el comportamiento corregido: ninguno ejecuta una segunda desinstalación y ninguno admite una ruta de mikroscope que quede en /file. Otras cuatro pruebas sostienen lo que la CLI debe seguir haciendo: el token del agente en ninguna línea de órdenes del anfitrión, las palabras de RouterOS en cada error, la sonda leyendo la marca running y el aviso de doctor para el arranque con el router con la raíz en un disco tmpfs.

S7 espera 45 s entre la instalación y el corte de corriente. Un corte hecho en cuanto el agente responde puede devolver un contenedor que no arranca (visto en el laboratorio), que es otra pregunta; S7 solo pregunta si el arranque con el router funciona.

Solo los escenarios que prueban una descarga hacen que el router descargue. Docker Hub limita las descargas anónimas por dirección, y un runner de la CI comparte su dirección con todo lo demás que se ejecutó desde ella, así que todos los demás escenarios instalan el tar de la propia rama que genera make agent-tars, lo que además prueba el agente de la rama. Esas descargas son anónimas salvo que el laboratorio reciba una cuenta (Descargar con una cuenta), y los escenarios sobre un router sin credencial, S1, S18 y los scripts de Docker Hub y de GHCR de S5, arrancan sin ella en cualquier caso. La batería quita toda variable MIKROSCOPE_* antes de ejecutar nada, así que una shell preparada para un router real no puede dirigirla.

Usar el laboratorio

make lab-up                   # arranca el laboratorio; la primera vez descarga RouterOS y lo aprovisiona
make lab-status               # el contenedor, quién tiene el cerrojo, qué informa el router
make test-lab                 # la batería entera, x86_64
make test-lab LAB_RUN='S09'   # las pruebas que casan con un patrón de go test -run
make lab-cli ARGS='doctor --arch amd64'
make lab-reset                # de vuelta a la instantánea limpia
make roundtrip                # doctor, install, status, upgrade, uninstall; se compara /export
make lab-down                 # lo para; los discos conservan su estado
make lab-up LAB_ARCH=arm64    # el laboratorio emulado: todos los objetivos admiten LAB_ARCH=arm64

S17 necesita un laboratorio por debajo del RouterOS mínimo, que es un laboratorio aparte:

make lab-up LAB_ROS=7.23.7
make test-lab LAB_ROS=7.23.7 LAB_RUN=S17

El laboratorio necesita:

• Linux, y un Docker que pueda dar a un contenedor NET_ADMIN y /dev/net/tun.
• Go, para el conductor del laboratorio y para la CLI y el agente que se prueban.
• Unos 910 MB de disco para las dos arquitecturas, 810 MB para una.
• Los puertos de loopback 220N, 800N, 870N y 910N libres, con N = 1 para x86_64 y 2 para arm64, más el desplazamiento de una instancia.
• Acceso a la red: Docker Hub y las réplicas de Debian para la imagen del laboratorio la primera vez, download.mikrotik.com una vez por versión de RouterOS, y Docker Hub para lo que descarga el router.
• /dev/kvm para x86_64. Sin él, LAB_KVM=auto recurre a la emulación, muchas veces más lenta, y LAB_KVM=require se detiene. arm64 se emula en un anfitrión x86 pongas lo que pongas.

Sin un laboratorio en marcha, cada prueba de la batería se omite, y MIKROSCOPE_LAB_REQUIRED=1 convierte eso en un fallo. La contraseña de administración del laboratorio y el token del agente se generan en test/lab/.env la primera vez, están en .gitignore y nunca se imprimen.

Cada objetivo ejecuta el conductor del laboratorio, bin/mikroscope-lab, que make lab-tool compila desde cmd/mikroscope-lab/ e internal/lab/: una herramienta de compilación que nada distribuye. bin/mikroscope-lab help lista sus verbos, y test/lab/lab.sh solo lo compila y lo arranca, para una orden escrita para el script antiguo. El mismo binario estático es el primer proceso del contenedor del laboratorio, que prepara su red y ejecuta QEMU hasta que el router se apaga.

Un solo conductor maneja un laboratorio cada vez: cada verbo toma el cerrojo del laboratorio, y bin/mikroscope-lab lock <orden> lo mantiene durante toda una sesión, como hacen make test-lab y make roundtrip. Los dos laboratorios funcionan a la vez, y sus baterías también, pero no como dos make test-lab en una misma copia del repositorio, porque cada una recompila los tar del agente que la otra puede estar leyendo. Compila una vez, y arranca cada batería con el cerrojo de su laboratorio:

make build agent-tars lab-tool
LAB_ARCH=x86_64 bin/mikroscope-lab lock go test -tags labe2e -count=1 -timeout 150m ./test/e2e/lab/ &
LAB_ARCH=arm64 bin/mikroscope-lab lock go test -tags labe2e -count=1 -timeout 150m ./test/e2e/lab/

Descargar con una cuenta

El router del laboratorio descarga él mismo la imagen del agente, una docena de veces por ejecución de la batería, y Docker Hub limita las descargas anónimas por dirección. Con una cuenta de Docker Hub, el router descarga como esa cuenta:

# en un archivo propio, modo 0600, fuera del repositorio
LAB_REGISTRY_USER=<la cuenta de Docker Hub>
LAB_REGISTRY_TOKEN=<un token de acceso personal suyo, de solo lectura>

set -a; . ~/.config/mikroscope/lab-registry.env; set +a
make lab-reset                  # cada up y cada reset dan la credencial al router

El laboratorio solo descarga, así que en tu máquina basta un token de solo lectura. En cada up y cada reset el conductor del laboratorio escribe /container/config/set registry-url=… username=… password=… en un archivo, lo copia al router, lo ejecuta con /import y lo borra, así que la credencial no está en ninguna línea de órdenes y la instantánea en caché nunca la tiene. Exportada desde un archivo, como arriba, tampoco pasa por la línea de órdenes de make, que la tabla de procesos mostraría. Sin las dos variables el router descarga de forma anónima; una sin la otra se rechaza. La batería imprime el usuario y el token como <LAB_REGISTRY_USER> y <LAB_REGISTRY_TOKEN>, y una de sus pruebas lee la tabla de procesos del anfitrión cada 2 ms durante un reset para que el conductor cumpla todo eso.

registry-url es registry-1.docker.io, sin esquema (LAB_REGISTRY_URL nombra el host de otro registro). RouterOS presenta el usuario y la contraseña para una referencia cuyo host es registry-url tal como está escrito, y mikroscope escribe el host en cada referencia; con https:// delante, la misma descarga sale de forma anónima (verificado).

Ajustes del laboratorio

Cada ajuste va en la línea de make o en el entorno.

Ajuste	Por defecto	Qué hace
LAB_ARCH	x86_64	qué laboratorio: x86_64 o arm64
LAB_ROS	el del Makefile	la versión de RouterOS que se descarga y ejecuta; una versión nueva es un aprovisionamiento nuevo
LAB_KIND	chr	iso es RouterOS x86 desde la ISO de MikroTik, solo x86_64
LAB_KVM	auto	require se detiene sin /dev/kvm, off nunca lo usa, auto lo usa cuando está
LAB_RUN	todas las pruebas	un patrón de go test -run para make test-lab, como S09 o F4
LAB_INSTALL_REPEAT	10 en x86_64, 3 en arm64	cuántas instalaciones hace la prueba de repetición
LAB_S5_CASES	todos los casos que el laboratorio puede ejecutar	los casos de S5, por id, separados por comas
LAB_REMOTE_IMAGE	la última publicación en Docker Hub	la imagen que descargan los escenarios de descarga
LAB_GHCR_IMAGE	la misma imagen en GHCR	la imagen que descarga S18
LAB_STATE_DIR	el test/lab de esta copia	dónde viven .cache/ y .env del laboratorio: apunta una segunda copia a un laboratorio que maneja otra
LAB_INSTANCE	ninguna	un segundo laboratorio de una arquitectura, con su propio contenedor, puertos, cerrojo y discos
LAB_LOCK_WAIT	lo que haga falta	segundos de espera al cerrojo de otro conductor antes de fallar y nombrar a quien lo tiene
MIKROSCOPE_LAB_REQUIRED	sin definir	1 convierte en fallo una omisión por falta de laboratorio
LAB_REGISTRY_USER, LAB_REGISTRY_TOKEN	sin definir: el router descarga de forma anónima	una cuenta de registro con la que descarga el router del laboratorio, que recibe en cada up y cada reinicio, nunca en la instantánea
LAB_REGISTRY_URL	registry-1.docker.io	el registro al que pertenece esa cuenta, escrito como el host que nombran las referencias

El laboratorio en la CI

El flujo .github/workflows/lab.yml ejecuta los mismos make lab-up y make test-lab, con MIKROSCOPE_LAB_REQUIRED=1, para las dos arquitecturas, cada semana en main y a petición. Nunca se ejecuta en un pull request ni antes de una publicación: una ejecución tarda media hora o más. Ejecuta tú make test-lab antes de un pull request que toque lo que instala el agente: internal/router, internal/image, internal/agent, cmd/mikroscope, cmd/mikroscope-agent, Dockerfile.agent, el Makefile, los guiones del tar del agente y del viaje de ida y vuelta, los guiones de RouterOS que muestra el sitio, y el laboratorio, su conductor y su batería. Una ejecución a petición admite ref, arch (both, x86_64 o arm64) y ros.

arm64 se ejecuta bajo emulación, que es lenta, y depende de que el servidor de descargas de MikroTik y Docker Hub estén disponibles.

La caché de Actions guarda las descargas de MikroTik por arquitectura y versión de RouterOS, comprobadas contra las sumas SHA-256 que el repositorio fija en test/lab/SHA256SUMS, y el router aprovisionado, con una clave que depende del conductor, de la imagen del laboratorio y de esas sumas. La instantánea no lleva ninguna credencial: admin tiene la contraseña vacía de CHR y ninguna clave hasta que el make lab-up de la ejecución le da las suyas, así que el .env y la clave ssh nunca salen del runner. Una ejecución fallida o que agota su tiempo sube el registro de la consola, el registro del contenedor, el estado del laboratorio, lo que una instalación dejó en el router y el registro de las pruebas, con cada credencial del laboratorio sustituida por su nombre, y nunca el .env ni la clave ssh.

El router descarga como una cuenta cuando el repositorio tiene dos secretos, DOCKERHUB_USERNAME y DOCKERHUB_TOKEN, el token con el que la versión también publica las imágenes; el laboratorio solo descarga con él. Se convierten en LAB_REGISTRY_USER y LAB_REGISTRY_TOKEN para los pasos que levantan el laboratorio, ejecutan la batería y ocultan las credenciales del informe de fallo, y para ningún otro; ci.yml y release.yml pasan los dos por su nombre. Una pull request desde un fork no recibe secretos, y un repositorio sin DOCKERHUB_TOKEN no recibe ninguna de las dos variables: ambos descargan de forma anónima. También una ejecución a petición que extrae otra ref, que puede ser el commit de fusión de un fork: el laboratorio compila y ejecuta ese código, y el token queda fuera de su entorno.

Límites del laboratorio

• Virtual, no hardware. Sin RouterBOARD, sin flash, sin sensores, sin chip de switch y sin árbol de dispositivos. cpufreq, mtd, psi, schedstat y thermal faltan en /capabilities del agente, y status no puede traducir los nombres de puerto del kernel a los de RouterOS. Todo lo que dependa de una placa sigue necesitando una real.
• La licencia gratuita de CHR limita lo que envía el router a 1 Mbit/s por interfaz. Una prueba de tasa por encima de 10 Hz en el laboratorio mide la licencia y no el agente (la aritmética).
• Las cifras del arm64 emulado no son costes. Bajo emulación el reloj del invitado sigue al del anfitrión, así que toda duración, toda cifra de CPU (cpu-load, self.cpu_us, read_ns, wake_ns, la dispersión de dt_ns, slipped), toda tasa de interrupciones, softirqs y cambios de contexto y todo contador de la PMU del laboratorio arm64 mide la emulación del anfitrión, no el núcleo que emula.
• Sin ARM de 32 bits. MikroTik publica CHR solo para x86_64 y arm64, así que el agente armv5 y armv7 solo se encuentra con RouterOS en hardware. make agent-smoke arranca su imagen bajo QEMU en modo usuario, que no es RouterOS.

Comprobaciones manuales

Ninguna batería muestra:

• Un destino alimentado desde un router. Las muestras de todas las baterías vienen de un agente simulado, de un árbol capturado o del CHR del laboratorio, y los almacenes se ejecutan en el anfitrión de pruebas, no a través del veth de un router. Qué destinos han llevado muestras de un router está en Estado de las funciones.
• Nada sobre una placa: su flash, sus sensores, su chip de switch y la frecuencia de su CPU, ni lo que cuesta el agente en ella. Coste del agente explica cómo medirlo en el tuyo.

Véase también

• Probado en: cuándo se ejecutó cada batería por primera vez, cuánto tarda, qué encontró el laboratorio y qué no se ha probado.
• Ejecutar el colector: qué escribe cada destino.
• Configurar en Grafana: el mismo dashboards check que ejecuta la batería de almacenes, contra tu almacén.