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.
Antes de probar
Sección titulada «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:
-
Averigua por qué puerto estás conectado:
/interface/bridge/host/print where mac-address="<la MAC de tu máquina>" -
Deja en paz ese puerto, el puerto WAN y cualquiera que lleve un servicio.
Firmas de fallos
Sección titulada «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 | 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 |
Desliza en horizontal para ver todas las columnas
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.
Revisa antes los datos
Sección titulada «Revisa antes los datos»- Al muestreador no le faltó CPU.
mikroscope_slipped_totaldeberí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_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 dekmsg_ dropped_ total mikroscope_son una cota inferior, y también lo es una tasa de sucesos sacada de ellos.kmsg_ records_ total
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.