Nagios Core : Sortie de la version 4.0

Le 20 septembre 2013 devient une date historique dans l’histoire de Nagios Core. C’est en effet plus de 5 ans après la version 3 (sortie le 13 mars 2008) que sort cette nouvelle version, qui au moins sur le papier (car je n’ai pas eu le temps de la tester), mérite vraiment une nouvelle version majeure.

Un bilan de la situation avant Nagios Core 4

Avant de rentrer dans les détails de ce qui est nouveau, je tiens à rappeler que cette nouvelle version 4 de Nagios Core est la première dont le développement a été porté par la communauté, notamment Andreas Ericsson chez OP5. Le travail a porté essentiellement sur les performances du Core.

Il faut dire que Nagios Core 3 se retrouvait désormais largement à la traîne par rapport à ses « descendants » comme Shinken (le premier à avoir jeter le pavé dans la mare des performances de Nagios 3), Centreon Core ou même un setup basé sur Mod Gearman + Icinga. Avec l’arrivé prochaine de Icinga 2, il y avait le feu dans la maison Nagios et de plus en plus d’architectes de solutions libres de supervision se tournaient vers une des alternatives possibles dès qu’il s’agissait de construire quelque chose de « scalable ». Ceci appartient désormais du passé et d’après ce graphe fourni par l’équipe de développement de Nagios Core 4, celui-ci repasse théoriquement en tête sur le niveau des performances.

Les nouveautés de Nagios Core 4 dans le détail

Mais en dehors de l’aspect performance, c’st bien une nouvelle version majeure avec son lot de nouveautés qui vient de sortir. Voyons ça dans le détail.

Amélioration des performances

Les améliorations de performance portent sur les principaux sujets suivants :

Core workers

Les core workers sont des processus dont le seul travail est d’exécuter des contrôles. On pense bien sûr au « poller » dans Shinken ou aux workers de Gearman. Ils communiquent avec le Core Nagios directement en mémoire, éliminant au passage les problèmes d’I/O rencontrés sur les grosses installations.

Vérification de la configuration

Chaque objet de configuration est désormais vérifié une seule fois.

Queue d’événements

L’insertion des événements est désormais beaucoup plus rapide et consomme bien moins de CPU.

Résolution des macros

Les macros sont triées au démarrage de façon à pouvoir utiliser une recherche binaire lors des recherches de macros. Les macros les plus utilisées comme $USERx$, $ARGx$ et $HOSTADDRESS$ sont traitées à part pour être disponible le plus tôt possible.

Définitions des objets de configuration

Des changements notables sont intervenus au niveau objets de configuration.

• L’attribut address est désormais optionnel. Quand cet attribut est absent, il lui est alors affecté la valeur de hostname. Vu que beaucoup de personnes utilisent une résolution DNS pour déterminer l’adresse, cet attribut devenait dans de nombreux cas redondant.
• hosts et services supportent désormais un attribut hourly. Cet attribut permet de représenter la valeur d’un hôte ou service au sein de l’organisation. Utilisé par le nouvel objet minimum contact.
• Les services supportent la notion de services parents. Ceux-ci fonctionne comme les parents pour les hôtes et évitent dans de nombreux cas de passer par les dépendances de services.
• Le drapeau de configuration failure_prediction_enabled a été retiré des définitions d’hôtes et services.
• Les contacts supportent une valeur minimum. Celle-ci est utilisée avec le nouvel attribut d’hôte ou service hourly pour déterminer l’envoi ou non de notifications.
• Les attibuts obess_over_host et obsess_over_service sont désormais regroupés en un seul attribut obsess.

Comportement des objets de configuration

• Les héritages de contact fonctionnent désormais comme indiqué dans la documentation; à savoir qu’ils doivent hériter du contact de l’hôte uniquement dans le cas ou il n’y a pas de contact spécifié pour le service.
• Tous les problèmes concernant les périodes de temps sont censés appartenir au passé.

Configuration

Pas mal de changements également à noter concernant le fichier principal de configuration de Nagios Core.

• Il ya une nouvelle variable de configuration, log_current_states, qui détermine si les états actuels seront enregistrés dans les fichiers journaux au moment de leurs rotations. Dans Nagios Core 3, cela a toujours été le comportement par défaut et il le reste dans Nagios Core 4. La désactivation de la journalisation des états actuels peut économiser de l’espace disque dans les grandes installations.
• Il y a une nouvelle variable de configuration, check_workers, qui indique le nombre de processus à créer lorsque Nagios démarre. S’il n’est pas spécifié, le nombre de processus est basé le nombre de processeurs dans le système.
• Une nouvelle variable de configuration, query_socket permet de spécifier l’emplacement du gestionnaire de requêtes. L’emplacement par défaut est /usr/local/nagios/var/rw/nagios.qh.
• Les variables de configuration, check_result_reaper_frequency et max_check_result_reaper_time ont été abandonnées. En raison de la nouvelle architecture basée sur les workers, les contrôles ne sont plus récoltés mais envoyés au Nagios Core. En conséquence, ces variables n’ont plus de sens.
• Toutes les variables de configuration ayant trait aux fichiers et répertoires dans nagios.cfg peuvent maintenant utiliser des chemins qui sont relatifs à nagios.cfg.
• Bien que rarement utilisé dans le passé, il était possible de créer des objets de configuration directement dans le fichier de configuration principal de Nagios. Ceci est maintenant interdit.

Macros

• Une nouvelle macro, $CHECKSOURCE$, a été ajouté et permet de savoir quel processus exécute quel contrôle.
• Si use_large_installation_tweaks est activé, les macros $HOSTGROUPMEMBERS$ et $SERVICEGROUPMEMBERS$ ne sont plus exportées, car elles peuvent consommer l’espace disponible pour les variables d’environnement.
• Les macros sont normalement disponibles comme variables d’environnement pour les contrôles, le gestionnaire d’événements, les notification et autres commandes exécutées. Ceci pouvant être consommateur en temps CPU sur les gros périmètres Nagios, vous pouvez désactiver l’exportation des variables d’environnement complètement avec l’option enable_environment_macros.

Le gestionnaire de requête (Query handler)

Le gestionnaire de requêtes est un mécanisme de communication d’usage général qui permet aux applications tierces de communiquer avec Nagios d’une manière bien définie. A ce jour, toutes les communications avec le gestionnaire de requêtes s’effectue à travers un socket de domaine Unix dont l’emplacement est défini par la variable de configuration query_socket.

Il y a 5 gestionnaires de requêtes fournis.

• core: permet la gestion et fournit les informations du Core Nagios.
• wproc: permet la gestion des workers (enregistrement, information).
• nerd: fournit un service d’abonnement au Nagios Event Radio Dispatcher (NERD).
• help: fournit de l’aide sur le gestionnaire de requêtes.
• echo: implémente un gestionnaire de requête de base qui renvoie en echo les requêtes qui lui sont envoyées.

Vous trouverez plus d’informations sur l’interface du gestionnaire de requête, y compris une introduction à la création d’un gestionnaire de requêtes personnalisée, dans la documentation.

Core workers

Auparavant, tous les contrôles d’hôtes et services étaient effectuées par le core Nagios. Cela engendrait donc un fork (voir deux) du core pour chaque contrôle. De plus, des fichiers disque étaient utilisés pour le mécanisme de communication inter-processus (IPC) entre le processus Nagios exécutant la vérification et le processus principal de Nagios. Bref, pas top.

Dans Nagios Core 4, l’exécution des contrôles est confiés aux workers. Ils peuvent être lancés à tout moment après le démarrage de Nagios. Si la commande de contrôle est « simple », le processus de travail peut exécuter la commande directement.

Toujours dans Nagios Core 4, les workers rapportent les résultats du contrôle au Core Nagios directement en mémoire, éliminant les problèmes d’i/o dans les grandes installations.

Nagios Event radio Dispatcher (NERD)

Le Nagios Event Radio Dispatcher (NERD) est un service basé sur le nouveau gestionnaire de requête. Il permet de faire suivre les événements du Core Nagios vers des souscripteurs. Actuellement, il existe trois canaux pouvant être souscrits: hostchecks, servicechecks et opathchecks.

libnagios

libnagios est une bibliothèque de fonctions pouvant être utilisés par les développeurs de gestionnaires de requêtes et workers.

Tests

De nombreux tests ont été ajoutés avec la distribution des sources.

RPM

Le fichier de spec RPm a été complètemet refait pour être plus conforme aux standards actuels en la matière.

Fonctionnalités retirées

• Les objets de configuration hostextinfo and serviceextinfo sont désormais retirés et ne doivent plus être utilisés. Ces informations peuvent être directement insérées au niveau des objets hosts et services.
• Parce que la vérification de la configuration est beaucoup plus rapide, l’option -x de la lgine de commande est dépréciée.
• Toutes ces variables sont désormais dépréciées; check_result_reaper_frequency, max_check_result_reaper_time, sleep_time, external_command_buffer_slots, command_check_interval.

Fonctionnalités obsolètes

• Failure prediction est obsolète car jamais vraiment implémenté.
• l’option -o de la ligne de commande, qui n’était pas vraiment connue, disparaît.
• Le module Perl embarqué est obsolète vu la nouvel architecture à base de workers.

En attendant de tester

Un grand bravo à toutes les personnes qui ont particpé au développement de Nagios Core 4. C’est à n’en pas douter une version importante dans l’histoire du logiciel qui gomme pour bonne partie les défauts reprochés à sa prestigieuse lignée d’aînés. Reste à voir maintenant comment l’écosystème qui entoure Nagios Core va réagir. Les forks basés sur Nagios 3 ont-ils encore un avenir du coup ? Les personnes parties vers Icinga, Centreon Core et autres vont-elles vouloir réintégrer le navire Nagios au vue des nouvelles fonctionnalités proposées ? Pas mal de question vont se poser car Nagios Core 4 semble bien redistribuer les cartes de la supervision Open Source, au moins au niveau technique.