# Límites de la evidencia

Las preguntas que las medidas de este sitio no pueden responder, y a qué métrica acudir en vez de adivinar.

Source: https://docs.jmrp.io/mikroscope/es/cost/limits/

Todas las medidas hechas en un router que recoge este sitio se tomaron en un único equipo, un
RB5009UG+S+, con el tráfico propio de ese router y los pocos sucesos
[provocados a propósito](https://docs.jmrp.io/mikroscope/es/playbooks/). No se tomaron en un día: la más antigua, el
coste de una conexión SSH, es del 2026-08-26 con RouterOS 7.24.1, y las demás son del 2026-09-11 en
adelante, con 7.24.2 y después 7.24.4; [Probado en](https://docs.jmrp.io/mikroscope/es/about/status/) fecha cada una. El
CHR del laboratorio virtual aporta corrección, no coste: no es una placa, y ninguna de sus duraciones
ni de sus cifras de CPU mide un router. Lo que sigue es lo que estas medidas no te dicen, guardado
aquí en vez de dejarlo para que un lector lo descubra equivocándose.

## Límites del histograma

El histograma `mikroscope_cpu_busy_ticks` (ticks ocupados enteros por muestra y núcleo, lo que
mantiene la fluctuación de temporización fuera de la elección de bucket) recupera el **tiempo por encima de un umbral** con resolución de una muestra. Lo que no puede recuperar es la
**continuidad**: una meseta de 2 s al 30 % y veinte picos sueltos de 100 ms al
30 % se ven idénticos en él.

Para eso está `mikroscope_cpu_busy_run_seconds{threshold="0.5"|"0.9"}` — la
duración de cada racha de muestras consecutivas en el umbral o por encima,
observada cuando la racha termina, con la racha aún en curso en
`…_run_open_seconds`.

Los medidores de ventana móvil (`window="1s"|"10s"|"60s"`,
`stat="max"|"min"|"p95"`) muestran el pico sea cual sea tu intervalo de scrape,
porque el colector los calcula sobre las marcas de tiempo de las propias muestras
del agente y no sobre los instantes de tu scrape. Para ver
la _forma_ de un transitorio en vez de su envolvente, grábalo con `record`, o
deja que un disparador lo capture.

## Tiempos del muestreador

Cuánto tardó el muestreador en despertar tras su temporizador y cuánto tardó la
lectura son `mikroscope_tick_wake_latency_seconds` y
`mikroscope_tick_read_seconds`, con el intervalo realmente conseguido en
`mikroscope_tick_interval_seconds`. Si sospechas del muestreador y no del
router, esos tres son el primer sitio donde mirar.

## Huecos

El agente guarda 60 s por defecto. Un corte del colector más corto que eso se
rellena al reconectar mediante `since=<seq>`; uno más largo se informa como un
hueco de longitud conocida — un marcador en una grabación, un contador en el
colector. Un gráfico con un agujero es un gráfico diciendo la verdad.

> **No medido, luego no afirmado**
>
> Cualquier placa que no sea el RB5009 de [Techo de muestreo](https://docs.jmrp.io/mikroscope/es/cost/rate-ceiling/).
> Tráfico por encima de unos 19 Mbit/s. Una compilación de RouterOS de 32 bits,
> que llegará con un hEX S pero todavía no ha llegado. Funcionamiento sostenido más allá de las
> ventanas indicadas. Ninguna de estas es una afirmación de este proyecto, y ninguna debería
> deducirse de las que sí lo son.

## Véase también

- [Techo de muestreo](https://docs.jmrp.io/mikroscope/es/cost/rate-ceiling/): las seis ejecuciones y las condiciones en
  que se tomaron.
- [Coste del agente](https://docs.jmrp.io/mikroscope/es/cost/): el presupuesto, y cómo medir el coste en un equipo que
  no sea este.
- [Probado en](https://docs.jmrp.io/mikroscope/es/about/status/#not-tested): todo lo demás que no se ha probado.
