Tengo un servidor Rocky Linux 9.2. Lo monitoreamos a través de check_mk y periódicamente recibimos una advertencia de que la última vez desde la sincronización puede exceder 1 hora. Tenga en cuenta que en las fuentes siguientes la fuente mansfield.id.au tiene 64 minutos.
Desde mi comprensión limitada de ntp, ¿el maxpoll de 10 especificado a continuación es igual a 1024 segundos?
server 0.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 1.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 2.au.pool.ntp.org iburst minpoll 6 maxpoll 10
server 3.au.pool.ntp.org iburst minpoll 6 maxpoll 10
Seguimiento: después de que chrony finalmente se sincronizara, el intervalo de actualización cambió a 4135,0 segundos.
[]#chronyc tracking
Reference ID : 6EE87216 (mansfield.id.au)
Stratum : 3
Ref time (UTC) : Wed Jan 24 00:27:13 2024
System time : 0.000012703 seconds slow of NTP time
Last offset : -0.000079763 seconds
RMS offset : 0.000147473 seconds
Frequency : 10.848 ppm fast
Residual freq : -0.001 ppm
Skew : 0.052 ppm
Root delay : 0.032765601 seconds
Root dispersion : 0.005266702 seconds
Update interval : 1036.2 seconds
Leap status : Normal
Fuentes
[]# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- 192.9.171.167 2 10 377 254 +511us[ +511us] +/- 63ms
^* mansfield.id.au 2 10 377 64m -2117us[-2197us] +/- 19ms
^- ntp2.ds.network 2 10 377 1007 +16ms[ +16ms] +/- 173ms
^- 220-158-215-20.broadband> 2 10 377 943 +73us[ +73us] +/- 81ms
¿Alguien sabe por qué parece ignorar el valor maxpoll, o falta alguna configuración o es incorrecta?
gracias
jc
Respuesta1
Esa es una salida saludable para los cronistas. Cuatro fuentes, todas accesibles recientemente, precisión en el rango inferior a 1 ms y retraso en decenas de milisegundos, y estás a 3 saltos (estrato) del reloj de referencia. Típico de servidores NTP de Internet.
Su resultado allí no lo consideraría procesable, por lo que no es algo sobre lo que alertar. Es posible que algún problema temporal ya no exista después de que se disparó la alerta, o que la verificación esté alertando incorrectamente sobre cosas.
La configuración poll/minpoll/maxpoll de chrony es log base 2, por lo que los valores típicos de 10 son 1024 segundos. Sí, es normal que las instancias crónicas saludables reduzcan los paquetes y terminen enviando solo unos pocos por hora. Es posible realizar un maxpoll mucho más largo, pero prácticamente nadie cambia el valor predeterminado.
No estoy familiarizado con checkmk. Afortunadamente, parece tener un núcleo de código abierto con el complemento crony. me voy dechrony.py etiquetado v2.2.0. Estas son las claves que extrae de chronyc trackingla salida.
Reference ID
System time
Stratum
Ref time (UTC)
Check utiliza la hora actual menos el tiempo de referencia analizado para crear un umbral para el "Tiempo desde la última sincronización" con umbrales aparentemente predeterminados de 1800 y 3600 segundos. Parece propenso a errores tener que analizar una hora formateada, pero al menos usan funciones de la biblioteca de Python.
Creo que esta parte de la alerta no tiene sentido y no es procesable. Si no se sincroniza, se devolverá el estrato de error número 16 y la verificación ya alerta sobre el estrato > 10. La verificación también alerta si no puede analizar una dirección IP a partir del ID de referencia. E incluso si chrony pierde todas las entradas, seguirá disciplinando el reloj en función de la deriva conocida.
Deshabilite la parte de retraso de esta verificación. O al menos configúrelo en un umbral mucho más alto, tal vez 1 o 2 días. No me importa que el último paquete NTP haya sido hace 30 minutos, pero 30 horas en un servidor siempre activo sin una medición de reloj de referencia podrían ser interesantes.
También diversifique sus fuentes para incluir aquellas que no sean de Internet. Si se ocupa del hardware, puede obtener dispositivos NTP, probablemente a partir de una señal satelital. O puede que ya haya un servidor NTP en la red local; en algunas nubes hay uno como parte de un servicio de metadatos.