TL;DR:
- Configurez votre serveur NTP selon les meilleures pratiques actuelles.
- (Avertissement de promotion honteuse.) Utilisez mon vérificateur ntpmon si votre solution de surveillance utilise collectd, Nagios ou telegraf.
Version longue:
Configuration
La base la plus importante pour une bonne surveillance de NTP est une bonne configuration NTP. Pour mieux comprendre cela, lisez les meilleures pratiques actuelles de NTP (BCP 223/RFC 8633). Voici un résumé condensé de ses recommandations de configuration :
- Gardez votre logiciel NTP à jour
- Utilisez entre 4 et 10 sources
- Assurez-vous d'avoir une diversité d'horloges de référence représentées dans ces sources
- Ne permettez pas le contrôle à distance non authentifié (devrait être la valeur par défaut sur la plupart des distributions)
- Utilisez le pool de manière responsable (devrait également être la valeur par défaut sur la plupart des distributions)
- Ne mélangez pas les sources avec et sans étalement de décalage
- Ne pas utiliser le mode broadcast non authentifié
- Ne pas utiliser d'anycast ou d'équilibrage de charge lorsque vous servez l'heure
Où mesurer
Une fois que vous avez une bonne configuration locale, le principal à retenir est que votre vérification doit interroger le serveur NTP local pour ses métriques, plutôt que d'essayer de mesurer manuellement le décalage par rapport aux serveurs distants. Les principaux serveurs NTP (ntpd et chronyd) collectent déjà toutes les métriques dont vous avez besoin, donc les vérifications qui comparent l'horloge avec des serveurs distants ignorent beaucoup de la richesse intégrée de NTP.
Sélection des métriques
Donc, pour répondre à votre question, les métriques qui devraient vous intéresser le plus sont :
- décalage du système : la meilleure estimation calculée du décalage de l'horloge locale par rapport au temps réel
- dispersion de la racine : l'écart maximal calculé de l'horloge locale par rapport aux sources de strate 0
Surveillance
Il existe quelques solutions de surveillance pour NTP - en fonction de la surveillance que vous avez déjà mise en place, certaines pourraient mieux vous convenir que d'autres. J'ai écrit un aperçu de ceux-ci sur mon blog, voici un résumé :
- Nagios :
- check_ntp_peer : vérification de base décente ; ne vérifie pas une assez grande variété de métriques ; un peu trop libéral dans les décalages autorisés
- check_ntp_time : non recommandé ; ne vérifie que le décalage par rapport à un serveur NTP distant donné
- check_ntpd : couverture de vérification raisonnable ; utilisez-le si vous préférez perl à python.
- ntpmon's vérification Nagios
- collectd :
- Plugin NTP : certaines des métriques qu'il collecte ne sont pas claires
- ntpmon en mode collectd
- prometheus/influxdb
- node exporter de prometheus : non recommandé ; ne vérifie que le décalage par rapport à un serveur NTP distant donné
- plugin d'entrée ntpq de telegraf ntpq : une traduction directe de la sortie de ntpq en métriques telegraf ; cela est probablement trop détaillé si vous voulez simplement savoir, "Mon serveur NTP fonctionne-t-il correctement ?"
- ntpmon en mode telegraf
Mises en garde
- Ce qui précède est un résumé de l'état en octobre 2016 lorsque j'ai réalisé ma revue d'alerte et de télémesure. Les choses ont peut-être évolué depuis.
- ntpmon est mon projet qui, je pense, surmonte les lacunes des vérifications qui étaient disponibles à l'époque. Il prend en charge à la fois ntpd et chronyd, ainsi que les systèmes d'alerte et de télémesure répertoriés ci-dessus.
