Nagios - Check_nTP_Time - Décalage inconnu
J'ai un serveur local NTP exécutant sur le sous-réseau pour conserver d'autres nœuds de sous-réseau en synchronisation, sans que chaque nœud synchronisation avec des serveurs en amont. Mais, tout en mettant en œuvre le plugin check_ntp_time pour Nagios, je remarque un problème frustrant, où Nagios continue de signaler une erreur critique pour la synchronisation des nœuds locaux avec le serveur NTP local.
Voici la configuration NTP sur le serveur NTP local, remarquez les entrées en amont serveur et la saisie restreindre Entrée, selon mes recherches, cela qualifie le nœud en tant que serveur NTP que les nœuds locaux peut synchroniser contre.
driftfile /var/lib/ntp/drift
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod limited nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
restrict -6 ::1
# Makes me able to answer requests from local nodes
restrict 10.0.0.0 mask 255.255.192.0 nomodify notrap
# My source
server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
logfile /var/log/ntp/server.log
statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable
Et sur les nœuds de serveur non-NTP locaux, tout est identique à l'exception de la saisie restreindre est supprimé et les entrées serveur Référence uniquement le serveur NTP local: server ntp.example.com iburst.
Chaque nœud local peut résoudre ntp.example.com.
Le problème que j'ai eu est lorsque j'exécute la commande suivante du serveur Nagios:
/usr/lib64/nagios/plugins/check_ntp_time -H node-a-1 -v
Et la sortie:
sending request to peer 0
response from peer 0: offset -0.002921819687
sending request to peer 0
response from peer 0: offset -0.0001939535141
sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
re-sending request to peer 0
discarding peer 0: stratum=0
overall average offset: 0
NTP CRITICAL: Offset unknown|
Cela se produit pour tous les nœuds, à l'exception du serveur NTP local, qui fait référence à des serveurs en amont. Au début, je pensais que c'était une question d'IPTABLES, mais j'ai le pendage des ports sur chaque nœud NTP local (pour permettre à Nagios Access pour vérifier la diffusion temporelle):
ACCEPT udp -- eth0 * 10.0.0.0/18 0.0.0.0/0 multiport dports 123 /* 777 allow ntp access */ state NEW
Versions:
nagios-plugins-ntp: 1.4.16
ntp: 4.2.6p5-1.el6.centos
Toute aide est grandement appréciée, je ne peux vraiment pas soumettre le travail Nagios jusqu'à ce que je reçois cela résolu, comme vous le savez garder les heures de serveur en synchronisation est la priorité 1.
- Edit -
Pour les commentaires, voici les résultats de ntpq -p, sur divers nœuds:
# Actual NTP Server (10.0.0.2)
==============================================================================
+propjet.latt.ne 241.199.164.101 2 u 105 128 337 14.578 12.954 7.138
+x2la01.hostigat 63.145.169.2 3 u 21 128 377 16.037 13.546 4.090
*pacific.latt.ne 241.199.164.101 2 u 72 128 377 15.148 24.434 7.403
# Local node 1
==============================================================================
*service-a-1.sn1 204.2.134.163 3 u 9 128 377 0.228 5.217 1.296
# Local node 2
==============================================================================
*service-a-1.sn1 204.2.134.163 3 u 91 128 377 0.200 3.608 1.167
La ligne clé ici est celle-ci:
jeter les pairs 0: Stratum = 0
An NTP Server s'identifiant comme Stratum 0 est une violation de la spécification (elle est réservée aux horloges atomiques ou quelque chose comme ça). J'avais ce problème il y a des années avec certains hôtes BSD et Mac OS X. J'ai fini par pirater la strate Vérifiez la source et maintenez une construction séparée du plugin pour les hôtes "problématiques".
Les lignes incriminées sont 254-257 (actuellement, de toute façon), si vous voulez le déchirer. C'est un hack, mais ça marche pour moi ;-)
J'ai trouvé ce fil dans les archives de la liste de diffusion à ce sujet. Je pense qu'il y en avait un autre où j'ai suggéré d'ajouter une option de ligne de commande pour ignorer la vérification de la strate, mais je ne pense pas que cela ait eu une traction.
Il y a aussi un bogue rapport à ce sujet, mais cela n'a rien cédé d'utile autant que je puisse dire.
J'ai supprimé le problème de désactiver la fonctionnalité KOD (Kiss-of-Death) sur le NTP Server.
cHECK_NTP envoie (au moins) 4 demandes de succession rapide pour calculer un décalage moyen statistiquement sonore. La troisième et toutes les demandes suivantes sont considérées comme une nivelle d'attaque de service par le serveur et reçoive un message KOD (Stratum invalide, à savoir 0). En fait, ce comportement devrait être considéré comme un bogue de check_ntt car KOD doit être traité correctement par le client.