Nagios Core : Sortie de la version 4.0

Posted by on 23 Sep 2013 in Nagios, Planet | 13 comments

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.

Nagios Core 4 performance

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.

13 Comments

  1. 23-9-2013

    Centreon Core
    « Centreon Core » est l’interface web de Centreon. Je pense que tu faisais plutôt référence à « Centreon Engine » en lieu et place de « Centreon Core » car tu peux aujourd’hui utiliser « Centreon Core » et « Nagios Core » en même temps.

    Sinon, où as tu trouvé le graphique de comparaison des outils? Je ne comprends vraiment pas les chiffres et j’aimerai avoir du détail. Merci.

    • 23-9-2013

      Je te fais confiance concernant les différentes appellations Centreon 😉 Je m’y perds un peu des fois. Le graphique provient de la présentation qu’a fait Andreas Ericsson à la Nagios Konferenz 2012 (http://fr.slideshare.net/nagiosinc/andreas-ericsson-nscorenwcna2012).

      • 23-9-2013

        Hou… ça date! Houlalala que ça date! 😀

        Faudrait refaire des tests car il y a eu de très nombreuses améliorations sur Centreon Engine depuis.

        • 23-9-2013

          Dans un graphe sans unité il n’y a tout de façon pas grande chose à comprendre, à part qu’il n’y a rien à comprendre 🙂

  2. 24-9-2013

    Tout le monde sait qu’Op5 est partenaire de Nagios et donc ne peut avoir un avis totalement neutre sur la question.
    Centreon, Icinga, Shinken, gearman ont tous beaucoup évolué depuis cette présentation. Ils n’ont pas attendu 5 ans pour améliorer leurs performances.
    Quand proposerez-vous (l’équipe Monitoring_Fr) un vrai benchmark (neutre et objectif) sur toutes ces différentes solutions Open Source ?

    J’ai hâte de lire ton compte rendu du test de Nagios 4.0
    😉

  3. 24-9-2013

    Il est évident que tous ces chiffres sont à prendre avec des pincettes, notamment pour les raisons évoquées dans les commentaires. Il serait certainement intéressant de mener un test neutre sur ces outils si tant est qu’on ne puisse les jauger, juger uniquement sur leur aspect performance. Après tout, qui est-ce que ça concerne les périmètres à plus de 100 000 checks toutes les 5 minutes ? Certainement pas la majorité des admins sys. Je ne dis pas qu’il ne faut pas s’intéresser à l’aspect performance des choses 🙂
    Donc pur faire ce test, il faudrait s’entendre sur les modalités de celui-ci . le but est-il d’enquiller le maximum de contrôles dans le minimum de temps ? Est-ce le seul critère qui détermine les performances d’une solution…
    Je regrette déjà d’avoir mis ce graphique 😉

    • 25-9-2013

      Tu as tout à fait raison. Cependant, tous les outils sortent leur dernière version en disant « je suis plus rapide, je suis plus rapide, nanananère rheu ».

      Tout le monde n’a pas besoin de disposer de la solution la plus performante. J’en suis un exemple : mon périmètre de supervision ne nécessite pas de faire 100 000 checks toutes les 5 minutes. Ni 10 000 d’ailleurs. Le nombre de tests à la minute n’est pas le plus important pour moi mais les fonctionnalités de l’interface de « la solution ».

      « solution » == pile d’applications, quelles qu’elles soient.

  4. 25-9-2013

    Donc concernant le graph il date c’est un fait. Si je me souviens bien il indique la capacité d’ordonnancement des checks (donc uniquement le scheduling, le plugin étant un bête echo ou un truc dans le genre). Ce qui est loin d’être une référence en soit car dès qu’interviennent les plugins cela ne correspond plus du tout à la réalité. Depuis longtemps j’utilise la lib perl de sven nierlen (http://search.cpan.org/~nierlein/Monitoring-Generator-TestConfig-0.44/lib/Monitoring/Generator/TestConfig.pm) pour lancer des tests de charge assez proches de la réalité. Peut être un bon moyen de « bencher » les outils « nagios like ».

  5. 26-9-2013

    Salut,
    Dans l’article, sur la partie des workers, il est fait un parallèle entre cette « nouvelle » features de Nagios4, Gearman et Shinken (et les pollers de Centreon d’ailleurs, ainsi que les proxys Zabbix).

    Je viens de regarder la doc que j’ai pu trouvé, l’archive des sources, et je ne trouve pas de mention sur le fait qu’un worker peut-être sur un hôte distant. Me trompe-je ?
    Sur ce point précis, Nagios a-t-il réellement rattrapé son retard sur Gearman, Shinken, Centreon et Zabbix ? (Bref, tout le monde)

    Qu’on soit bien d’accord, il ne s’agit pas de troller, mais de s’avoir si la fonction est au rendez-vous, ou pas.

    Mais si l’innovation ici, c’est de pouvoir déléguer sur le même serveur les checks à une batterie de process pré-lancés, c’est une innovation maigre et qui ne devrait, à mon avis, intéresser que les gros gros hébergeurs.

    • 26-9-2013

      Salut,
      Excellente remarque à laquelle je souscris mais à laquelle je ne peux apporter de réponse, n’ayant pas encore eu le temps de tester la chose. Le point est en tous les cas important à vérifier.

    • 27-9-2013

      >Je viens de regarder la doc que j’ai pu trouvé, l’archive des sources, et je ne >trouve pas de mention sur le fait qu’un worker peut-être sur un hôte distant. Me >trompe-je ?

      c’est lié à l’utilisation de « socket de domaine Unix », les workers se connectent localement à la « query_socket ».
      Les « remote workers » ont été discutés ici http://comments.gmane.org/gmane.network.nagios.devel/8644 « Core 4 Remote Workers ».

      En gros, c’est prévu (le code est écrit dans ce sens), mais pas avant « 4.1 au plus tôt ».

      > […] intéresser que les gros gros hébergeurs.

      C’est peut-être aussi intéressant pour des configurations « moyennes » qui sont à l’étroit dans un seul nagios, mais qui ne peuvent pas changer d’architecture matérielle et/ou logicielle (par exemple des machines à base de processeurs relativement peu puissants, comme les ARM, mais multi-coeurs).
      Ou simplement pour augmenter la fréquence des vérifications.

  6. 30-9-2013

    Ils ont améliorés les performances c’est un fait (bon c’est pas comme si on leur avait gentiment soufflé ce qu’il fallait faire en 2009 et que ça n’arrive qu’en 2013 mais bon passons, faut pas s’attendre à une latence géniale avc Nagios).

    Par contre s’ils ont bien rajouté les pool de process (nommés ici workers), je ne suis pas sûr qu’ils aient réglés le soucis des checks d’hôtes car je n’ai rien vu dans le code qui corrige le défaut conceptuel présent depuis les toutes premières version de Nagios.

    Je m’explique: quand un service revient en CRITICAL/WARNING on doit lancer un check d’hôte pour vérifier la « vraie » source du problème. Dans Nagios1/2/3 soit on lance un check d’hôte en asynchrone (donc bonne perf) mais tu as alors l’alerte de service lancé directement, soit on locks tout les checks en attendant le résultat de ce check d’hôte. Bref: on a le choix entre des performances acceptables et mais une armée de notifications fausses sur les services, soit les alertes sont bonnes, mais les performances sont atomisées.

    Dans Nagios 4 on n’a même plus le choix en fait (cf fonction handle_async_service_check_result de base/checks.c), on a les bonnes performances mais forcément les informations fausses!

    Avoir de bonnes performances c’est très bien, et ils ont réussis, mais si c’est pour sacrifier la qualité des informations sur un élément aussi basique que la dépendance service->hôte non merci. Avoir plus rapidement des informations fausses ne va pas arranger les administrateurs a mon sens.

    Il est quand même bon de voir qu’Andreas a repris les choses en main et qu’Ethan ne pose plus de verrous. Mais je ne peux m’empêcher de penser qu’ils ont travaillés à refaire ce qu’avait déjà fait Sven Nierlein et Matthias Kettner: entre un nagios 3+ mod_gearman + livestatus et un nagios 4, je ne vois pas d’améliorations conceptuelles.

    On a un core qui utilise (enfin) tous les cœurs des serveurs, et une api de communication. Très bien, mais on les avait déjà avec les modules. Mais rien n’est amélioré dans la logique même de la supervision, la facilité de maintenance (genre maintenir les règles de dépendances reste un calvaire avec nagios, or elles ne sont plus optionnelles dans nos grands environnements). Or là c’est au cœur de faire ce travail.

    Je ne vois donc pas en quoi cette version va arrêter l’hémorragie du projet vers ses concurrents, mis à part l’effet d’annonce que ça produit. L’équipe d’Icinga a par exemple pris le taureau par les cornes et on repris l’architecture du cœur à zéro. C’est courageux et c’est ce que l’on pouvait attendre d’un Nagios 4. Mais si peu en 5ans, c’est pas génial, même pour un code en C.

    Ps: pour le graphique d’après les valeurs l’échelle est « nombre de checks lancés en 5min avant d’avoir une latence qui explose ».
    Ps2: pour ceux qui vont se dire « si peu? tu n’as qu’à aider! » -> j’ai déjà donné, ça a juste un autre nom que Nagios désormais 😉

  7. 11-10-2013

    Bonjour, c’est pas forcément la suite des divers commentaires, néanmoins j’ai mis en ligne une documentation sur Nagios 4…qui hélas n’est toujours pas encore référencée…snif
    Bon si cela vous intéresse : http://www.archil.fr/docs/Install-Nagios4.html

    A+ merci