Quoi de neuf dans la version 2.0 ?

Important : assurez-vous d’avoir lu toute la documentation (et plus particulièrement les F.A.Q.) avant d’envoyer votre question aux listes de diffusion.

Journal des évolutions

Le journal des évolutions de Nagios est consultable en ligne sur http://www.nagios.org/changelog.php [Anglais] ou dans le fichier Changelog à la racine de la distribution du code source.

Problèmes connus

Il y a un problème connu qui affecte Nagios 2.0 sur les systèmes FreeBSD. Ce problème sera résolu, espérons-le, dans une version 2.x…

1. FreeBSD et les threads [NdT : fils d’exécution]. FreeBSD propose une implémentation native au niveau utilisateur des threads appelée ’pthread’, et en option un portage ’linuxthreads’ qui utilise les accroches du noyau [NdT : kernel hooks]. Des gars de Yahoo! ont signalé que l’utilisation de la bibliothèque pthread provoque l’arrêt de Nagios lorsque la demande d’entrées-sorties est importante, ce qui cause la perte de certains résultats de contrôles de services. Passer à la bibliothèque linuxthreads semble améliorer les choses, mais ne résoud pas le problème. Le blocage se produit dans la fonction __pthread_acquire() de liblthread - le verrou ne peut jamais être acquis. Cela se produit quand le thread principal est embranché [NdT : fork] pour exécuter un contrôle actif. Au second embranchement pour créer le processus petit-fils, le petit-fils est créé par fork, mais ne retourne jamais à l’adaptateur [NdT : wrapper] de fork dans liblthread, parce qu’il est coincé dans __pthread_acquire(). Peut-être des utilisateurs de FreeBSD peuvent-ils contribuer à la résolution de ce problème.

Changements et nouveautés

1. Changements dans les macros - Les macros ont subi une refonte majeure. Vous devrez mettre à jour la plupart de vos définitions de commandes pour vous adapter aux nouvelles macros. La plupart des macros sont maintenant disponibles en tant que variables d’environnement. De plus, des macros d’hôte et de service "à la demande" ont été ajoutées. Lisez la documentation sur les macros pour de plus amples informations.
2. Changements dans les groupes d’hôtes
   • Suppression des escalades de groupes d’hôtes - Cette fonction peut être remplacée par le paramètre hostgroup_name de la définition du groupe d’hôtes.
   • Changement du paramètre "members" - La définition d’un groupe d’hôtes peut maintenant contenir plusieurs paramètres members, ce qui devrait rendre plus facile la saisie des fichiers de configuration lorsque vous avez un grand nombre d’hôtes membres. Vous pouvez aussi utiliser le paramètre hostgroups de la définition d’hôte pour définir à quel(s) groupe(s) d’hôtes appartient un hôte en particulier.
   • Changement dans les groupes de contacts - Le paramètre contact_groups a été déplacé de la définition des groupes d’hôtes à celle des hôtes. Ceci afin d’être cohérent avec la définition des contacts de services. Mettez à jour vos fichiers de configuration !
   • Changement dans les permissions - Les permissions d’accès aux groupes d’hôtes dans les CGI ont été changées. Vous devez maintenant avoir accès à tous les hôtes membres du groupe d’hôtes pour avoir accès au groupe d’hôtes.
3. Changements dans les hôtes
   • Contrôle de fraîcheur de l’hôte - le contrôle de fraîcheur a été ajouté aux contrôles d’hôtes. C’est le paramètre check_host_freshness qui définit ce comportement, associé au paramètre check_freshness de la défintion d’hôte.
   • Commande OCHP - Les contrôles d’hôtes peuvent maintenant être remontés, comme l’étaient les contrôles de services. La commande OCHP est lancée pour tous les hôtes dont le paramètre obsess_over_host est activé dans la définition d’hôte.
4. Changements dans le contrôle des hôtes
   • Contrôles ordonnancés régulièrement - Vous pouvez maintenant ordonnancer le contrôle régulier d’hôtes en utilisant le paramètre check_interval de la définition d’hôte. NOTE : Attention ! Vous devez utiliser parcimonieusement les contrôles réguliers d’hôtes. Ils ne sont pas nécessaires au fonctionnement normal (les contrôles à la demande sont déjà réalisés quand c’est nécessaire) et peuvent dégrader les performances s’ils sont utilisés de manière inappropriée. Vous êtes prévenus.
   • Contrôles d’hôtes passifs - Les contrôles d’hôtes passifs sont maintenant possibles s’ils sont activés par le paramètre accept_passive_host_checks du fichier de configuration principal et le paramètre accept_passive_host_checks de la définition d’hôte. Les contrôles passifs d’hôtes peuvent simplifier la mise en oeuvre d’une supervision redondante ou répartie. NOTE : Certains problèmes sont liés aux contrôles d’hôtes passifs - pour en savoir plus lisez ceci.
5. Changements dans la mémorisation
   • Mémorisation des informations d’ordonnancement - Les information d’ordonnancement des contrôles d’hôtes et de services (prochains moments de contrôle) peuvent maintenant être mémorisées entre les redémarrages du programme grâce au paramètre use_retained_scheduling_info.
   • Mémorisation plus subtile - Les valeurs de divers paramètres d’hôtes et de services qui peuvent être mémorisées entre les redémarrages du programme ne le sont désormais que si elles ont été changées en cours d’exécution par une commande externe. Cela rendra les choses plus claires pour ceux qui tentent de modifier les valeurs de paramètres d’hôtes et de services puis redémarrent Nagios, s’attendant à constater des changements.
   • Plus de choses mémorisées - Il y a plus d’informations mémorisées entre les redémarrages du programme, y compris l’historique de la détection d’oscillation. Youpi !
6. Changements dans les informations étendues
   • Nouvel emplacement - Les définitions d’informations étendues d’hôtes et de services sont maintenant stockées dans les fichiers de configuration des objets, avec les définitions d’hôtes, etc. Il en résulte que les définitions d’information étendues sont maintenant analysées et validées par le démon Nagios avant le démarrage.
   • Nouveaux paramètres - Les définitions d’informations étendues d’hôtes et de services comportent maintenant deux nouveaux paramètres : notes et action_url.
7. Changements dans l’interpréteur Perl intégré
   • Emplacement de p1.pl - Vous pouvez maintenant définir l’emplacement du fichier d’aide de l’interpréteur Perl intégré (p1.pl) grâce au paramètre p1_file.
8. Changements dans les notifications
   • Notifications d’oscillation - Les notifications sont maintenant envoyées au commencement et à la fin de l’oscillation d’hôtes et de services. Cette fonction est définie par la valeur f dans le paramètre notification_options des définitions de contacts, d’hôtes et de services.
   • Meilleur algorithme - L’algorithme de notification a été légèrement amélioré. Cela devrait éviter d’envoyer des notifications de rétablissement alors qu’aucune notification de problème n’avait été préalablement envoyée.
   • Notifications de services - Avant que les notifications de services ne soient envoyées, les dépendances de notification pour l’hôte sont désormais vérifiées. Si les notifications d’hôte ne sont pas jugées valables, les notifications pour le service ne seront pas envoyées non plus.
   • Options d’escalade - Les paramètres de période et d’état ont été ajoutés aux escalades d’hôtes et de services. Cela vous permet de contrôler plus finement l’utilisation des escalades. Vous trouverez ici plus d’informations sur les escalades.
9. Ajout des groupes de services - Les groupes de services ont été ajoutés. Ils vous permettent de grouper des services pour l’affichage dans les CGI et peuvent être utilisés dans les définitions de dépendances de services et d’escalade de services pour faciliter la configuration.
10. Ajout de l’arrêt planifié déclenché - La gestion de l’arrêt planifié dit "déclenché" a été ajouté pour les hôtes et les services. L’arrêt planifié déclenché vous permet de définir un arrêt planifié qui commence en même temps qu’un autre arrêt planifié (très utile pour définir l’arrêt planifié des hôtes enfants d’un hôte dont le moment d’arrêt planifié est variable). Vous trouverez ici plus d’informations sur l’arrêt planifié.
11. Nouvel outil de statistiques - Un nouvel outil appelé ’nagiostats’ fait maintenant partie de la distribution de Nagios. C’est un outil en ligne de commande qui vous donne les statistiques pour un processus Nagios en cours d’exécution. Il peut également produire des données compatibles avec MRTG, vous permettant de représenter graphiquement les statistiques. Vous trouverez ici plus d’information sur l’utilisation de cet outil.
12. Supervision adaptative - Vous pouvez maintenant changer certains paramètres propres aux contrôles d’hôtes et de services (commandes de contrôles, intervalle de contrôle, nombre maximal d’essais de contrôle, etc.) en cours d’exécution en envoyant les commandes externes appropriées. Ce type de supervision adaptative ne sera probablement pas d’un grand usage pour la majorité des utilisateurs, mais il permet des trucs élégants. Vous trouverez ici plus d’informations sur la supervision adaptative.
13. Changements dans les données de performance - La méthode de traitement des données de performance a légèrement changé. Vous pouvez maintenant traiter les données de performance en exécutant des commandes externes et/ou en écrivant dans les fichiers sans recompiler Nagios. Lisez la documentation sur les données de performance pour de plus amples informations.
14. Abandon de la gestion native des bases de données - La gestion native du stockage de divers types de données (états, mémorisation, commentaires, arrêt planifié, etc.) dans MySQL et PostgreSQL a été abandonnée. Arrêtez de vous plaindre. J’espère que quelqu’un développera bientôt une solution alternative grâce au nouveau gestionnaire d’événements. De plus, la gestion des bases de données n’était pas très bien implémentée et son abandon va rendre la tâche plus facile pour les nouveaux utilisateurs (une question de moins à se poser).
15. API de distribution des événements [NdT : event broker] - Une API [NdT : interface de programmation] a été créée pour permettre aux développeurs indépendants d’écrire des greffons qui s’intégrent avec le coeur du démon Nagios. La documentation de l’API de distribution d’événements sera créée quand le code de la version 2.x sera mûr, et elle sera disponible sur le site web de Nagios.
16. Changements divers
    • Toutes les commandes peuvent avoir des paramètres - Tous les types de commandes (contrôles d’hôtes, notifications, traitement des données de performance, gestionnaires d’événements, etc.) peuvent recevoir des paramètres (séparés du nom de la commande par le caractère !). Les paramètres sont remplacés dans la ligne de commande via les macros $ARGx.
    • Récursivité dans le répertoire de configuration - Nagios traite maintenant de manière récursive tous les fichiers de configuration qu’il trouve dans les sous-répertoires des répertoires définis par le paramètre cfg_dir.
    • Abandon de l’ancien style de fichiers de configuration - La gestion de l’ancien style (sans templates) de fichiers de configuration des objets et des informations étendues a été abandonnée.
    • Recherches plus rapides - Les objets sont maintenant stockés dans une table de hachage chaînée pour accélérer les recherches. Cela devrait grandement améliorer la performance des CGI.
    • Threads de travail - Quelques threads de travail ont été ajoutés pour artificiellement mettre en mémoire tampon les données pour le fichier de commandes externes et le tube [NdT : pipe] interne utilisé pour traiter les résultats de contrôles de services. Cela devrait significativement améliorer les performances pour les grandes installations.
    • Changements dans la journalisation - L’état initial des hôtes et des services est maintenant journalisé légèrement différemment. De plus, les états initiaux de tous les hôtes et services sont immédiatement journalisés après toute rotation de journaux. Cela devrait résoudre les problèmes de "undetermined time" dans les CGI de disponibilité et de tendance.
    • Mise en cache du fichier de configuration des objets - Un fichier de cache des objets est maintenant créé par Nagios au démarrage. Il permet d’accélérer un peu les CGI et vous permet de modifier vos fichiers de configuration des objets alors que Nagios s’exécute, sans affecter l’affichage des CGI.
    • Limites initiales de contrôle - Vous pouvez définir des limites de temps dans lesquelles le contrôle initial de tous les hôtes et services doit être effectué après le démarrage de Nagios. Ces limites de temps sont définie par les paramètres max_host_check_spread et max_service_check_spread.
    • Acquittements "collants" - Vous pouvez maintenant déterminer si des acquittements d’hôtes ou de services sont "collants" [NdT : sticky] ou pas. Les acquittements collants suppriments les notifications jusqu’à ce qu’un hôte ou un service se rétablisse complétement dans l’état UP ou OK. Les acquittements non collants suppriment simplement les notifications jusqu’à ce qu’un hôte ou un service change d’état.
    • Changements dans le contrôle des grappes [NdT : clusters] - La façon de superviser des grappes de services et d’hôtes a changé et est plus fiable qu’elle n’était. Cela est dû à l’incorporation des macros à la demande et d’un nouveau plugin (check_cluster2). Vous trouverez ici plus d’informations sur le contrôle des clusters.
    • Expressions régulières - L’utilisation d’expressions régulières dans de nombreux paramètres des objets peut être activée grâce aux paramètres use_regexp_matching et use_true_regexp_matching. Vous trouverez des informations sur quand et comment utiliser les expressions régulières dans la documentation sur les trucs et astuces des modèles.
    • Pseudo-états des services - La gestion de pseudo-états de services qui étaient redondants a été supprimée du CGI d’état. Cela affectera les URL codées en dur qui utilisent le paramètre du CGI servicestatustypes=X. Voyez include/statusdata.h pour la nouvelle liste des états de service que vous pouvez utiliser.
    • Changements dans le contrôle de la fraîcheur - L’algorithme de contrôle de la fraîcheur a légèrement changé. Le contrôle de fraîcheur ne se fera pas si l’instant présent n’est pas définit dans le paramètre check_timeperiod de l’hôte ou du service. De plus, les contrôles de fraîcheur n’auront plus lieu si les deux paramètres check_interval et freshness_threshold pour l’hôte ou le service valent zéro (0).