Mise à jour de la documentation - J'avance doucement dans la réécriture de la plupart de la documentation. Cela va prendre du temps, car (1) il y a beaucoup de documentation et (2) écrire de la documentation n'est pas mon passe temps favori. Il faut s'attendre à ce que certaines portions de la documentation n'évoluent pas pendant un bon moment. J'espère que les modifications que je réalise vont clarifier et rendre plus abordables certaines choses pour les nouveaux utilisateurs et les utilisateurs occasionnels de Nagios.

Nouvelles macros - De nouvelles macros ont été ajoutées:

Deux macros de temps à la demande ont également été ajoutées:

Macros supprimées - L'ancienne macro $NOTIFICATIONNUMBER$ a été désapprouvée au bénéfice des nouvelles macros $HOSTNOTIFICATIONNUMBER$ et $SERVICENOTIFICATIONNUMBER$.

Modifications - Les macros $HOSTNOTES$ et $SERVICENOTES$ contiennent maintenant elles-mêmes des macros, celles-ci sont: $HOSTNOTESURL$, $HOSTACTIONURL$, $SERVICENOTESURL$ et $SERVICEACTIONURL$.

Les macros sont normalement disponibles comme variables d'environnement quand les contrôles, gestionnaires d'événements, notifications et autres commandes sont exécutées. Ceci est plutôt consommateur de ressources CPU. Dans les installations où Nagios gère un nombre important d'hôtes et de services, vous devrez alors désactiver cette fonctionnalité à l'aide de l'option enable_environment_macros .

Des informations sur les macros peuvent être trouvées ici.

Les informations concernant les arrêts programmés ne sont plus stockées dans leur propre fichier de configuration (précédemment définies par le paramètre downtime_file dans le fichier de configuration principal). Les informations concernant les arrêts programmés courants et retenus sont maintenant stockées respectivement dans les fichiers status file et retention file .

Les commentaires de services et d'hôtes ne sont plus stockés dans leur propre fichier (précédemment spécifié à l'aide d'un paramètre comment_file dans le fichier de configuration principal). Les commentaires courant et retenus sont maintenant stockés respectivement dans le fichier statut et le fichier de rétention.

Les commentaires d'acquittement qui sont marqués comme non persistents sont maintenant supprimés quand l'acquittement est fait. Ils étaient précédemment automatiquement supprimés au redémarrage de nagios, ce qui n'était pas idéal.

Les informations d'état des contacts individuels sont dorénavant conservées à chaque redémarrage.

Les ID de commentaires et de mise en maintenance sont maintenant conservés entre les redémarrages et doivent être uniques tant que les données de rétention ne sont pas supprimées ou ignorées

Ajout des variables retained_host_attribute_mask et retained_service_attribute_mask permettant de contrôler quels attributs d'hôte/service sont conservés entre chaque redémarrage.

Ajout des variables retained_process_host_attribute_mask et retained_process_service_attribute_mask afin de contrôler quels attributs de processus sont conservés entre chaque redémarrage.

Ajout des variables retained_contact_host_attribute_mask et retained_contact_service_attribute_mask afin de contrôler quels attributs de contact sont conservés entre chaque redémarrage.

Ajout de le paramètre flap_detection_options aux définitions d'hôte et de service vous permettant de spécifier quels états d'hôte/service doivent être utilisés par la logique de détection d'oscillation (par défaut tous les états sont utilisés).

L'historique des pourcentages de changement d'état est maintenant conservé même si la détection d'oscillation est désactivée.

Les oscillations sont immédiatement vérifiées sur les hôtes et les services quand la détection d'oscillation est activée globalement.

Les hôtes et services en train d'osciller quand la détection d'oscillation est globalement désactivée sont maintenants loggés.

De plus amples informations concernant la détection d'oscillation peut être trouvées au chapitre Détection et gestion de l'oscillation d'état

L'ajout d'une nouvelle commande externe, PROCESS_FILE, permet le traitement de commandes externes placées dans un fichier. Utile pour traiter de larges quantités de contrôles passifs retournant de grandes quantités de données, ou pour scripter des commandes. De plus amples informations peuvent être trouvées ici.

Les commandes personnalisées doivent maintenant être soumises par Nagios. Les noms des commandes personnalisées sont préfixées par un underscore (_) et ne sont pas traitées en interne par le démon Nagios. Elle devraient, malgré tout, être traitées par un module NEB chargé.

L'option check_external_commands est maintenant activée par défaut, ce qui signifie que Nagios est configuré d'origine pour vérifier les commandes externes. Toutes les versions de Nagios antérieures à la version 2.x avaient cette option désactivée par défaut.

Les informations d'état de contact (Horaire de dernières notification, notification activées/désactivées, etc.) sont maintenant sauvegardées dans les fichiers de statut et de rétention, bien que celles-ci ne soient pas traitées par les CGIs.

Ajout des variables enable_embedded_perl et use_embedded_perl_implicitly afin de contrôler l'utilisation de l'interpréteur Perl intégré.

Les scripts/plugins Perl peuvent maintenant explicitement signaler à Nagios s'ils doivent, ou non, être exécutés par l'interpréteur Perl intégré. Cela est utile si vous avez des scripts qui ne fonctionnent pas bien avec l'interpréteur Perl intégré.

De plus amples informations à propos de ces nouvelles options peuvent être trouvées ici.

La planification des vérifications pour les hôtes et les services peut maintenant être modifiée à la volée à l'aide d'une commande externe (CHANGE_HOST_CHECK_TIMEPERIOD ou CHANGE_SVC_CHECK_TIMEPERIOD). Vous pouvez consulter cette page pour les commandes adaptatives de supervision.

L'option first_notification_delay a été rajoutée à la définition des hôtes et des services afin d'introduire un délai entre le moment où un problème survient sur un hôte/service et le moment où la première notification est envoyée. Dans les versions précédentes, vous deviez utiliser des configurations complexes avec des escalades pour réaliser cela. Cette fonctionnalité est maintenant accessible au commun des mortels.

Les notifications sont maintenant envoyées pour les hôtes/services qui oscillent quand la détection d'oscillations est désactivée au niveau hôte, service ou globalement. Dans ce cas, la macro $NOTIFICATIONTYPE$ sera positionnée sur FLAPPINGDISABLED.

Les notifications peuvent maintenant être envoyées lors de l'entrée/sortie dans une période de maintenance planifiée et être annulées pour les hôtes et services. La macro $NOTIFICATIONTYPE$ sera positionnée respectivement sur DOWNTIMESTART, DOWNTIMEEND, ou DOWNTIMECANCELLED. Pour recevoir des notifications sur les événements de maintenance planifiée, précisez s ou downtime dans les options de notifications de contact, d'hôte et/ou de service.

Vous pouvez trouver plus d'informations sur les notifications au chapitre les concernant (Notifications )

Des dépendances de services peuvent maintenant être créées afin de facilement définir les même dépendances de services sur un ou plusieurs hôtes. (Plus d'information ici. )

Les définitions étendues d'hôte et de service (respectivement hostextinfo et serviceextinfo) ont été abondonnées. Toutes les valeurs des définitions étendues ont été intégrées dans les définitions d'hôte et de service. Nagios 3 continuera à lire et traiter les anciennes définitions étendues, mais journalisera un warning. Les versions futures de Nagios (4.x et postérieures) ne supporteront plus des définitions étendues séparées.

Les variables hostgroup_members, servicegroup_members, et contactgroup_members ont été ajoutées respectivement aux définitions de groupes d'hôtes, de groupes de services et de groupes de contacts. Cela permet d'inclure des hôtes, services ou contacts de sous-groupes dans vos définitions de groupes.

Les variables notes , notes_url, et action_url ont été ajoutées aux définitions de groupes d'hôtes et de groupes de services.

Les définitions de contact ont les nouvelles variables host_notifications_enabled, service_notifications_enabled et can_submit_commands pour mieux contrôler les notifications et déterminer s'il est possible ou pas de passer des commandes depuis l'interface web.

Les dépendances d'hôte et de service supportent désormais une variable optionnelle dependency_period. Elle permet de limiter les périodes de temps pendant lesquelles les dépendances sont valides.

La variable parallelize dans les définitions de services est abandonnée et n'est plus utilisée. Tous les services sont contrôlés en parallèle dans Nagios 3.

Il n'y a plus aucune limite de longueur de nom d'hôte ou de description de services.

Les expressions régulières étendues sont désormais utilisées si vous activez l'option de configuration use_regexp_matching Les expressions régulières de base sont seulement utilisées dans certaines variables de définitions d'objets qui contiennent *, ?, + ou \..

Une nouvelle variable initial_state a été ajoutée aux définitions d'hôtes et de services, de façon à préciser à Nagios l'état dans lequel un hôte ou un service doit démarrer plutôt que UP ou OK (qui reste le comportement par défaut).

Vous pouvez désormais hériter des variables/valeurs d'objet de plusieurs modèles en précisant plus d'un nom de modèle dans la variable use des définitions d'objets. Cela permet des réglages d'héritage particulièrement puissants (et complexes). (En savoir plus )

Les services héritent désormais des groupes de contacts, des intervalles de notifications et des périodes de notifications de l'hôte auxquels ils sont associés si non précisé au niveau du service. (En savoir plus )

Les escalades d'hôtes et de services héritent désormais des groupes de contacts, des intervalles de notifications et des périodes d'escalades de l'hôte ou du service auxquels ils sont associés si non précisé ailleurs. (En savoir plus )

Les variables de chaines dans les définitions d'hôtes, de services et de contacts peuvent désormais ne pas être héritées en précisant la valeur null (sans les guillemets) pour la valeur de la variable. (En savoir plus )

La plupart des variables de chaînes dans les définitions locales d'objets peuvent désormais être ajoutées aux valeurs de chaines dont elles héritent. C'est plutôt utile sur des grandes installations. (En savoir plus)

Ajout de la possibilité de mettre en cache à l'avance les fichiers d'objets de configuration et d'exclure la détection de chemin circulaire du processus de vérification de configuration. Cela peut grandement améliorer le temps de démarrage de Nagios comprenant de nombreux hôtes et services! En savoir plus ici.

Une nouvelle option use_large_installation_tweaks a été ajoutée qui devrait permettre d'améliorer les performances sur les Nagios comprenant de nombreux hôtes et services. En savoir plus ici.

Un nombre d'améliorations internes ont été faites sur la façon dont Nagios traite les relations d'objets (par exemple hôte et service) et les structures de données internes. Ces améliorations devraient donner un gain de vitesse sur les installations comprenant de nombreux hôtes et services.

Une nouvelle option external_command_buffer_slots a été ajoutée pour permettre de facilement dimensionner Nagios dans des installations comprenant de nombreux hôtes et services. Pour obtenir les meilleurs résultats, vous devriez utiliser MRTG pour grapher l'usage que fait Nagios des slots de buffer dans le temps.

Le message retour d'un plugin peut désormais être multi-ligne pour les contrôles d'hôtes et de services. Hourra! L'API a été mise à jour pour supporter plusieurs lignes tout en conservant une compatibilité antérieure avec les plugins plus anciens. Les lignes supplémentaires de message (après la première ligne) sont maintenant stockées dans les nouvelles macros $LONGHOSTOUTPUT$ et $LONGSERVICEOUTPUT$.

La longueur maximale d'un message retour de plugin a été augmentée à 4K (à la place d'environ 250 bits dans les versions précédentes). Cette limite de 4K a été choisie arbitrairement de façon à protéger Nagios de plugins partant en vrille et lui renvoyant trop de données.

Vous pouvez trouver plus d'informations sur les plugins, les sorties multi-lignes et la longueur maximale d'un message retour ici.

Nagios contrôle désormais par défaut les services orphelins.

Ajout d'une nouvelle option enable_predictive_service_dependency_checks pour contrôler si Nagios va initier ou non un contrôle prédictif de service dont celui-ci dépend (dans les définitions de dépendances). Les contrôles prédictifs aide à s'assurer que la logique de dépendance est aussi précise que possible.

Un nouvelle fonctionnalité de cache pour les contrôles de services a été mise en œuvre. Elle peut significativement améliorer les performances pour pas mal de monde. Plutôt que d'exécuter un plugin pour contrôler l'état d'un service, Nagios peut souvent utiliser un résultat de contrôle mis en cache à la place. Vous pouvez trouver plus d'informations sur cette fonctionnalité ici.

Les contrôles d'hôtes sont désormais parallélisés! Les contrôles d'hôtes étaient effectués en série, ce qui impliquait un holdup majeur en termes de performance. Plus maintenant! (En savoir plus )

Les réessais de contrôles d'hôtes sont maintenant gérés comme ceux des services. Tout ça pour dire que les définitions d'hôtes ont un nouveau paramètre retry_interval qui précise le temps à attendre avant de faire un nouvel essai de contrôle sur l'hôte. ;-)

Les contrôles d'hôtes réguliers ne grèvent plus les performances. Au contraire, ils peuvent aider à améliorer les performances grâce à la nouvelle logique de mise en cache des contrôles (voir ci-dessous).

Ajout d'une nouvelle option check_for_orphaned_hosts pour activer ou non les contrôles d'hôtes orphelins. C'est maintenant nécessaire puisque les contrôles d'hôtes fonctionnent en parallèle.

Ajout d'une nouvelle option enable_predictive_host_dependency_checks pour contrôler si Nagios va initier ou non un contrôle prédictif pour les hôtes dont celui-ci dépend (dans les définitions de dépendances). Les contrôles prédictifs aide à s'assurer que la logique de dépendance est aussi précise que possible. (En savoir plus )

Un nouvelle fonctionnalité de cache pour les contrôles d'hôte a été implémentée ce qui peut significativement améliorer les performances pour pas mal de monde. Plutôt que d'exécuter un plugin pour contrôler l'état d'un hôte, Nagios peut souvent utiliser un résultat de contrôle mis en cache à la place. Vous pouvez trouver plus d'informations sur cette fonctionnalité ici.

Les contrôles passifs d'hôtes qui ont un résultat DOWN ou UNREACHABLE peuvent désormais être automatiquement traduit dans l'état approprié du point de vue de l'instance Nagios qui les reçoit. C'est particulièrement utile dans les installations distribuées et redondantes. Vous pouvez trouver plus d'informations sur la traduction d'état pour les contrôles passifs d'hôtes ici.

Les contrôles passifs d'hôtes placent normalement celui-ci dans un état HARD. Ceci peut désormais être changé en activant l'option passive_host_checks_are_soft

Une nouvelle option additional_freshness_latency a été ajoutée pour permettre de préciser le nombre de secondes qui devraient être ajoutées à n'importe quel seuil de fraîcheur d'hôte ou de service automatiquement calculé par Nagios.

Le mécanisme IPC utilisé qui permet de transférer les résultats de contrôles d'hôtes/services en retour au démon Nagios depuis les processus (grand)enfant a changé! Cela devrait permettre de réduire la charge/latence induite par le traitement de nombreux contrôles passifs dans des installations comprenant de nombreux hôtes et services.

Les résultats de contrôles sont maintenant transférés en écrivant dans le dossier précisé par l'option check_result_path . Les fichiers plus vieux que l'option max_check_result_file_age seront détruits définitivement et sans aucun traitement supplémentaire.

Les périodes de temps ont finalement été étendues pour accepter les exceptions, les sauts de dates (tous les 3 jours), etc. Cela devrait aider lors de la définition de périodes de notifications pour les rotations de pager.

Vous pouvez trouver plus d'informations sur les nouvelles variables de périodes de temps ici et ici.

Mise à jour de la version de l'API NEB

Modification du callback pour le statut adaptatif des données du programme

Ajout d'un callback pour le statut adaptif des données de contact

Ajout de callbacks de pré-contrôle pour les hôtes et services pour permettre aux modules d'annuler/modifier les contrôles internes d'hôtes/services.

Les résumés de groupes d'hôtes et de services montrent maintenant les successions de problèmes importants/pas importants comme dans le CGI tac.

Quelques changements mineurs dans l'organisation des vues de détail d'hôte et service ont été opérées dans le CGI extinfo.

De nouvelles statistiques de contrôle ont été ajoutées à l'écran Performance Info.

Ajout des options d'intégration de Splunk dans plusieurs CGIs. L'intégration est contrôlée par les options enable_splunk_integration et splunk_url du fichier de configuration des CGIs.

Ajout des nouvelles options notes_url_target et action_url_target pour contrôler dans quel cadre (frame) s'ouvrent les liens de notes et d'action.

Ajout de la nouvelle option lock_author_names pour prévenir la modification du noms des auteurs soumettant des commentaires, des prises en compte et des périodes de maintenance planifiée.

Les options de compilation DEBUGx disponible dans le script de configuration ont été enlevées.

Les informations de débogage peuvent désormais être écrites dans un fichier journal séparé, qui est automatiquement renouvelé dès que sa taille atteint une limite définie par l'utilisateur. Cela devrait grandement faciliter le débogage puisqu'il n'y a plus besoin de recompiler Nagios. Le support complet de ce mode a été ajouté pendant le début de la phase de développement, aussi n'est-il peut-être pas complet quand vous l'essayerez.

Les variables qui modifient le comportement du journal de debug sont

Variable de chemin temporaire - Une nouvelle variable temp_path a été ajoutée pour préciser un répertoire temporaire que Nagios peut utiliser.

ID unique attribué par événement et notification -Un ID unique est maintenant assigné à chaque notification d'hôte et de service. Un autre ID unique est également assigné aux changements d'états d'hôtes et services. Les IDs uniques sont rendus accessibles par l'usage des macros suivantes :

Nouvelles macros - Quelques autres nouvelles macros ont été ajoutées. Ceci inclut

Fréquence de reaper - L'ancienne variable service_reaper_frequency a été renommée en check_result_reaper_frequency puisqu'elle est désormais également utilisée pour traiter les résultats de contrôles d'hôtes.

Temps maximal de reaper - Une nouvelle variable max_check_result_reaper_time a été ajoutée pour limiter le temps d'exécution d'un événement reaper.

Intervalles fractionnés - Les intervalles fractionnés de notifications et d'hôtes (par exemple 3.5 minutes) sont maintenant supportés dans les définitions d'hôtes, de services, d'escalades d'hôtes et de services.

Échappement des arguments de commande - Vous pouvez maintenant utiliser le point d'exclamation (!) dans vos arguments de commandes en le faisant précéder d'un backslash (\). Les backslashs doivent être également être précédés d'un backslash si vous avez besoin d'en utiliser dans vos arguments de commandes

Sortie de commandes système multi-lignes - Nagios va maintenant lire plusieurs lignes de sortie pour les commandes système qu'il exécute (scripts de notification, etc.); et ce jusqu'à 4KiB. C'est la même limite que le message retour de plugin mentionné plus tôt. Les sorties de commandes système ne sont pas directement traitées par Nagios, mais le support en est assuré.

Meilleure information de planification - Des informations plus précises sont données quand Nagios est exécuté avec le -s argument de ligne de commande. Cette information peut être utilisée pour réduire le temps de (re)démarrage de Nagios.

Mises à jour agrégées du fichier d'état - L'ancienne option aggregate_status_updates a été enlevée. Toutes les mises à jour du fichier de statut sont maintenant agrégées à un intervalle minimum de 1 seconde.

Nouveau mode de fichier de données de performance -Une nouvelle option p a été ajoutée aux options host_perfdata_file_mode et service_perfdata_file_mode . Ce nouveau mode ouvre un fichier en lecture/écriture non exclusive, ce qui est utile pour les fichiers tubes.

Décalage de fuseau horaire - Une nouvelle option, use_timezone , a été ajoutée afin de vous permettre de démarrer des instances de nagios situées dans des fuseaux horaires autres que le fuseau local.