Eu tenho um servidor Rocky Linux 9.2. Nós o monitoramos via check_mk e recebemos regularmente um aviso de que a última vez desde que a sincronização pode exceder 1 hora. Observe como nas fontes abaixo a fonte mansfield.id.au está em 64 minutos.
Pelo meu entendimento limitado do NTP, o maxpoll de 10 especificado abaixo é 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
Rastreamento - depois que o chrony finalmente foi sincronizado, esse intervalo de atualização mudou para 4.135,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
Fontes
[]# 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
Alguém sabe por que parece ignorar o valor maxpoll ou há alguma configuração ausente/errada?
obrigado
jc
Responder1
Essa é uma saída saudável do chrony. Quatro fontes, todas acessíveis recentemente, precisão abaixo de 1 ms e atraso em dezenas de milissegundos, e você está a 3 saltos (estrato) do relógio de referência. Típico para servidores NTP da Internet.
Sua saída aí eu não consideraria acionável e, portanto, não é algo para alertar. É possível que algum problema temporário não exista mais após o disparo do alerta ou a verificação esteja alertando incorretamente sobre as coisas.
A configuração poll/minpoll/maxpoll do chrony é log base 2, então valores típicos de 10 são 1024 segundos. Sim, é normal que instâncias chrony saudáveis diminuam os pacotes e acabem enviando apenas alguns por hora. O maxpoll é possível por muito mais tempo, mas aproximadamente ninguém altera o padrão.
Não estou familiarizado com checkmk. Felizmente, parece ter um núcleo de código aberto com o plugin crony. Eu estou saindochrony.py marcado como v2.2.0. Estas são as chaves que ele extrai da chronyc trackingsaída
Reference ID
System time
Stratum
Ref time (UTC)
A verificação usa o tempo atual menos o tempo de referência analisado para estabelecer um limite para "Tempo desde a última sincronização" com limites aparentemente padrão de 1.800 e 3.600 segundos. Parece propenso a erros ter que analisar uma hora formatada, mas pelo menos eles usam funções da biblioteca Python.
Acho que esta parte do alerta é inútil e inacionável. A falha na sincronização retornará o número de estrato de erro 16, e a verificação já alertará no estrato > 10. A verificação também alertará se não for possível analisar um endereço IP do ID de referência. E mesmo que o chrony perca todas as entradas, ele continuará disciplinando o relógio com base no desvio conhecido.
Desative a parte de atraso desta verificação. Ou pelo menos defina um limite muito mais alto, talvez 1 ou 2 dias. Não me importa que o último pacote NTP tenha ocorrido há 30 minutos, mas 30 horas em um servidor sempre ativo sem uma medição de relógio de referência pode ser interessante.
Diversifique também suas fontes para incluir fontes que não sejam da Internet. Se você lida com hardware, poderá obter dispositivos NTP, provavelmente a partir de um sinal de satélite. Ou pode já existir um servidor NTP na rede local; em algumas nuvens, existe um como parte de um serviço de metadados.