# Diagnosticar fallos La firma de cada fallo que mikroscope ha leído en un router MikroTik, dónde se ve en los datos y las dos comprobaciones que hay que hacer antes de fiarse de una lectura. Source: https://docs.jmrp.io/mikroscope/es/playbooks/ Compara lo que muestran los datos con las firmas de abajo y abre después el caso real para ver la lectura completa y las órdenes que la reproducen en tu propio equipo. Cada firma es un cambio frente a la forma en reposo: un log del kernel que normalmente calla y trae un flujo constante, un núcleo al máximo mientras el total del equipo sigue moderado, una línea de interrupción que se multiplica. ## Antes de probar Nada de lo que hacen los casos provocados puede romper el enlace de subida del router ni cortar el camino de un administrador hasta él. Conserva esa propiedad en tu equipo: 1. Averigua por qué puerto estás conectado: ```routeros /interface/bridge/host/print where mac-address="" ``` 2. Deja en paz ese puerto, el puerto WAN y cualquiera que lleve un servicio. ## Firmas de fallos Lee primero la forma en reposo. Sin ella, cualquier otra firma parece una anomalía. | Fallo | Dónde se ve | Firma | | --------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Línea base en reposo](https://docs.jmrp.io/mikroscope/es/playbooks/idle/) | ocupación por núcleo, `time_squeeze`, `events` | un suelo de ocupación bajo y estable en cada núcleo, un squeeze que nunca llega a cero, ningún suceso del kernel | | [Bucle de capa 2](https://docs.jmrp.io/mikroscope/es/playbooks/loop/) | `events` (la fuente `kmsg`) | un flujo constante de `events` en reposo, espaciado al intervalo de hello de STP, mientras el log de RouterOS y su monitor de puertos siguen limpios | | [Nombres de puertos](https://docs.jmrp.io/mikroscope/es/reference/port-names/) | `events` | el kernel nombra un puerto por su propio nombre de netdev, que puede no coincidir con el de RouterOS | | [Núcleo saturado](https://docs.jmrp.io/mikroscope/es/playbooks/cpu/) | ocupación por núcleo, temperatura, frecuencia | un núcleo cerca del 100 % mientras el total del equipo ronda el 100 % dividido entre el número de núcleos; la carga salta entre núcleos antes de asentarse | | [Tormenta de despertares](https://docs.jmrp.io/mikroscope/es/playbooks/cpu/#cuando-los-núcleos-no-están-ocupados-pero-el-kernel-sí) | cambios de contexto, interrupciones del temporizador | una tasa de cambios de contexto varias veces su media del día anterior, interrupciones del temporizador en ráfagas en un núcleo cada vez, las columnas de ocupación planas | | [Inundación de paquetes](https://docs.jmrp.io/mikroscope/es/playbooks/packet-flood/) | interrupciones, softirqs, `time_squeeze` | una línea de interrupción que se multiplica con un arranque y un final bruscos, y su coste en el único núcleo al que está fijada | | [Desgaste de la flash](https://docs.jmrp.io/mikroscope/es/playbooks/flash-wear/) | la fuente `yaffs`, contadores ECC de MTD | deltas de `pw` y `er` en reposo que no has provocado tú (mira primero las acciones de logging puestas en `disk`); `corrected_bits` subiendo o cualquier `ecc_failures` | | [Conntrack sin la API](https://docs.jmrp.io/mikroscope/es/playbooks/conntrack/) | la caché slab `nf_conntrack` | el número real de conexiones del router, donde el propio namespace del contenedor informa 0 | | [Puerto que pierde tramas](https://docs.jmrp.io/mikroscope/es/playbooks/port-errors/) | los contadores MAC por puerto de la capa de la API | `rx overflow` en un puerto, en intervalos que llevan una fracción pequeña de la capacidad del enlace: una ráfaga, no una carga | La tormenta de despertares no tiene caso propio: su lectura forma parte del caso del núcleo saturado, y la regla que la vigila es `mikroscope-wakeup-storm`, en [Reglas de alerta](https://docs.jmrp.io/mikroscope/es/dashboards/alerts/). ## Revisa antes los datos - **Al muestreador no le faltó CPU.** `mikroscope_slipped_total` debería ser 0 en la ventana que estés leyendo. Un tick perdido es uno cuya lectura terminó después de que tocara el siguiente tick, y entonces la propia contabilidad del muestreador es lo primero de lo que hay que desconfiar. - **El log del kernel se conservó entero.** `mikroscope_kmsg_dropped_total` cuenta episodios de pérdida, no registros: uno por cada tick que llegó al tope de 64 registros del agente, y uno por cada desbordamiento del búfer circular del kernel, que puede suponer muchos registros. Mientras no sea cero, los recuentos por nivel de `mikroscope_kmsg_records_total` son una cota inferior, y también lo es una tasa de sucesos sacada de ellos. > **Las órdenes de estas páginas no llevan token** > > Los ejemplos con `curl` hablan con el agente en `http://172.30.10.2:9123` sin credenciales, que es > como responde una instalación por defecto. Un agente arrancado con token — obligatorio con > `--expose` — devuelve 401 en todas las rutas salvo `/healthz` hasta que cada petición lleve la > cabecera `Authorization: Bearer `. Para medir lo que cuesta el agente mientras ejecutas un escenario, lee el `/metrics` del colector, no una instantánea: el procedimiento está en [Coste del agente](https://docs.jmrp.io/mikroscope/es/cost/#medirlo-en-tu-propio-equipo). ## Véase también - [Coste del agente](https://docs.jmrp.io/mikroscope/es/cost/): el presupuesto, el coste medido y cómo medirlo en tu router. - [Límites de resolución](https://docs.jmrp.io/mikroscope/es/limits/): por qué el porcentaje de ocupación de un núcleo en una muestra de 100 ms se mueve en escalones del 10 %, y qué se lee por debajo de eso. - [Reglas de detección](https://docs.jmrp.io/mikroscope/es/sinks/detections/): las reglas que el colector ejecuta sobre estas mismas señales. - [Primera grabación](https://docs.jmrp.io/mikroscope/es/start/walkthrough/): una grabación con marcadores, la otra forma de leer un transitorio.