Ir al contenido

Diagnosticar fallos

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.

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:

    /interface/bridge/host/print where mac-address="<la MAC de tu máquina>"
  2. Deja en paz ese puerto, el puerto WAN y cualquiera que lleve un servicio.

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 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 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 events el kernel nombra un puerto por su propio nombre de netdev, que puede no coincidir con el de RouterOS
Núcleo saturado 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 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 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 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 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 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.

  • 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.

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.