Nagios

Nagios : supervision de services réseau et de ressources système

Description
Fonctionnalités générales
  • Nagios est un système de surveillance de services réseau (SMTP, HTTP…) et de ressources système (CPU, espace disque…).
  • Plus précisément, dans la terminologie Nagios, il s'agit de monitorer des services et des hosts, chaque service étant affecté à un host ou à un groupe de hosts. A un instant "t", un host se trouve dans un état down, unreachable ou ok, et un service dans un état critical, warning, unknown ou ok.
  • Conceptuellement, Nagios est un moteur :
    • d’acquisition d’états de hosts et de services (checks),
    • de déclenchement conditionnel d’actions préventives et curatives (handlers), et
    • de déclenchement conditionnel de notifications.
  • Ces acquisitions, actions et notifications sont assurées par des plugins.
  • L'outil s'adresse aussi bien à de petites infrastructures (une dizaine de service) qu'à des architectures conséquentes (plusieurs milliers de serveurs repartis sur plusieurs sites) pour lesquelles il propose un modèle de supervision distribuée.
  • Nagios offre une interface web qui permet de visualiser l'état des services et des hosts que l'on veut surveiller (tableau de bord). Cette interface web permet également l'administration (très partielle) du monitoring.
Autres fonctionnalités
  • Le déclenchement d'une acquisition d'état est normalement à l'initiative de Nagios : cela s'appelle un active check. Mais Nagios est aussi à l'écoute pour recevoir des états de services/hosts de toute provenance (déclenchés par exemple par cron jobs) : ce sont les passive checks.
  • L'envoi d'alertes, hautement paramétrable, peut se faire par mail, par SMS, etc. Une personnalisation est possible par host, par service, par état, par destinataire (contact), suivant le jour de la semaine, suivant l'heure de la journée, etc. Les alertes peuvent être réémises périodiquement, et peuvent s'escalader : par exemple, on peut faire en sorte que le weekend, l'équipe d'astreinte reçoive les alarmes en premier, et qu'en cas de problèmes persistants, toute l'équipe d'exploitation soit automatiquement avertie.
  • Lorsqu'un problème est décelé, le host ou le service passe d'abord dans un état de type soft : il est en alarme dans le tableau de bord, mais les alertes ne sont pas encore envoyées et il est possible de tenter de le résoudre en exécutant un handler (par exemple en effaçant les fichiers temporaires sur une partition pleine). Après plusieurs checks et tentatives de résolution infructueux (dont le nombre est paramétrable par service/host), l'état passe dans le type hard, et les alertes sont envoyées.
  • Il est possible de programmer des périodes de maintenance (scheduled downtime) pour un host donné. Pendant ces périodes, l'envoi d'alarmes relatives à ce hosts est suspendu.
Interopérabilité
  • Les plugins sont des programmes autonomes, développés et distribués indépendamment du moteur Nagios. Une distribution de plusieurs dizaines de plugins, sous forme de petits programmes C, scripts shell et Perl, est téléchargeable sur le site officiel.
  • La description de l’infrastructure à monitorer (hosts, services, etc.) et du contexte (contacts, commandes, périodes, etc.) est exprimée dans un formalisme objet (avec notion d'héritage), sous forme de fichiers textes.
  • Il existe nombre d'outils permettant de générer cette base de données d'objets (notamment via une interface web).
  • Les états courants des hosts/services sont mémorisés dans des fichiers textes et exprimés dans un formalisme objet.
  • Les informations collectées sont archivées dans des logs au format texte. L’addon NDOutils, téléchargeable sur le site officiel, permet de stocker ces informations dans une base MySQL.
  • D'autres addons sont téléchargeables sur le site officiel, les deux plus connus étant NRPE et NSCA, qui permettent de faire du client/serveur entre Nagios et ses plugins.
Contexte d'utilisation dans mon laboratoire/service

Nagios monitore les ressources informatiques et réseau de la plateforme en ligne pour les mathématiques (PLM) http://plm.math.cnrs.fr/, du LAL http://www.lal.in2p3.fr , du LAPP http://www.lapp.in2p3.fr , etc. LCG utilise Nagios : http://www.gridpp.ac.uk/wiki/Nagios_Plugins

Limitations, difficultés, fonctionnalités importantes non couvertes

  • Nagios ne garde pas d’historique des changements d’état (mis à part dans ses logs). Son interfaçage, directe ou indirecte, avec un outil comme RRDtool peut, de ce point de vue, se révéler judicieux, pour créer des graphes représentant l'évolution des valeurs d'acquisition au cours du temps.

  • L'inverse est également possible : utiliser un outil grapheur capable d'envoyer des informations à Nagios. Cette fonctionnalité est présente par exemple dans l'outil Munin.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré

DragonFly BSD, NetBSD, OpenBSD et certaines distributions Linux (Debian, Fedora, Gentoo, Mandriva, PLD, Skolelinux, Suse, Ubuntu).

Plates-formes
  • Nagios, ses plugins et addons officiels tournent sur plate-forme UNIX. Ils sont téléchargeables sous forme de tarballs et RPM.
  • Il existe des contributions de plugins/addons pour surveiller des services sur Windows.
Logiciels connexes
  • Nagios XI : la version commerciale et powerful de Nagios Core
  • Nagios Checker, https://addons.mozilla.org/fr/firefox/search/?q=na..., est une extensions de Firefox/Thunderbird qui, en récupérant périodiquement par HTTP/HTTPS la page web des états d'un ou plusieurs serveurs Nagios, affiche les alertes en cours sur ces serveurs : résumé dans la barre d'état, popup reprenant l'état des hosts/services en alertes, alertes sonores.
  • Nagios Tray, http://sourceforge.net/projects/nagiostrayicon, est un outil similaire de surveillance d'alertes Nagios, tournant sur Windows, qui affiche un popup lorsqu'une nouvelle alerte apparait sur un serveur Nagios
  • RRDtool, http://www.rrdtool.org, une fiche PLUME existe
  • Munin, http://munin-monitoring.org, basé sur RRDtool, est un outil de monitoring complémentaire de Nagios, puisque son objectif est justement l'archivage et la représentation de l'évolution des données de monitoring au cours du temps.
  • Cacti
Autres logiciels aux fonctionnalités équivalentes
  • Shinken : http://www.shinken-monitoring.org/ : un fork from scratch écrit en python, compatible avec les fichiers de configuration/définition de Nagios
  • Icinga : http://www.icinga.org. C'est un fork de Nagios, créé en 2009. L'objectif initial était de libérer le développement jugé trop lent et trop fermé de l'outil. Aujourd'hui, Icinga apporte des innovations intéressantes (authentification LDAP, API), une interface web plus moderne et un développement ouvert et lisible (roadmap publique). Les versions 1.x de icinga sont 100% compatibles avec les fichiers de configuration/définition de Nagios. Ce ne sera plus le cas avec la version 2, annoncée pour fin 2013, une réécriture from scratch, qui s'appuiera sur un nouveau formalisme de description des objets à monitorer.
  • Ganglia : http://ganglia.sourceforge.net
  • Hobbit Monitor : http://hobbitmon.sourceforge.net
  • Zabbix : http://www.zabbix.org
Environnement de développement
Type de structure associée au développement

Le moteur est développé par Ethan Galstad.
Le développement des plugins est collaboratif.

Eléments de pérennité
  • Nagios est le successeur de NetSaint http://netsaint.sourceforge.net
  • Depuis, il est développé par une seule personne, et son évolution est lente.
  • Aujourd'hui, le nom Nagios identifie un ensemble d'outils : l'outil libre appelé communément Nagios s'appelle maintenant Nagios Core, et des produits commerciaux, développés par la même personne, apparaissent : Nagios XI, Nagios Fusion.
  • Sans forcément remettre en cause la pérennité du produit, on peut s'interroger sur la pertinence de continuer à utiliser un produit qui n'est plus, aux dires de l'auteur, l'outil powerful de la gamme, alors qu'Icinga s'enrichit rapidement de nouvelles fonctionnalités, http://www.icinga.org/wp-content/uploads/2010/08/I...

Par ailleurs on voit apparaitre à ce jour le logiciel "shinken", sorte de "fork from scratch" de Nagios, qui est peut-être en train de devenir la référence en supervision de parc et d'infrastructure orientée cloud et multi-site.

Références d'utilisateurs institutionnels

1436 sites se sont déclarés utilisateurs de Nagios au 2008/04/22, sur http://nagios.org/userprofiles. On peut y lire par exemple que Tulip It Services Corp monitore 100 000 hosts (1 000 000 de services) avec Nagios, et que Yahoo Inc monitore 200 000 services répartis sur 100 000 hosts.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur

Toute la documentation est disponible sur le site http://www.nagios.org/docs en particulier :

  • une documentation en anglais (format HTML et PDF). La version HTML est installée avec l'application et intégrée à l'interface web de l'application,
  • une documentation en français (de Christian Vanguers and Pierre-Antoine Angelini) pour la version 1,
  • une documentation en français pour les versions 2.x http://nagios.manubulon.com/traduction,
  • des documentations en allemand et japonais.

De l'information additionnelle, rédigée collaborativement, est également disponible sur http://www.nagioscommunity.org

Des formations à Nagios se font dans notre communauté enseignement supérieur/ Recherche. Voir par exemple :
* http://www.mathrice.fr/IMG/pdf_nagios_slides.pdf
* http://www.mathrice.fr/IMG/pdf_nagios_tp_sujet.pdf
référencés sur http://www.mathrice.fr/spip.php?article165

Divers (astuces, actualités, sécurité)
  • Il est extrêmement facile de développer ses propres plugins : l'interface entre Nagios et ses plugins est très simple, et ces derniers peuvent être développés en n'importe quel langage, et pour n'importe quelle plate-forme.
  • Nagios accorde une attention particulière à la pertinence de l'envoi d'alertes, ce qui est crucial pour éviter un flot d'alarme ingérable en situation de crise. Par exemple :
    • lorsqu'un host tombe, une seule alerte est envoyée (Nagios considère inutile d'alerter pour chacun des services d'un host qui ne répond plus)
    • lorsqu'un host/service oscille, c'est-à-dire change d'état trop rapidement, Nagios envoie une alerte indiquant que le host/service bagote (flaps), puis suspend l'envoi d'alarme pour ce host/service jusqu'à ce que la situation se calme.
    • on peut de surcroit limiter l'envoi d'alertes en définissant des dépendances entre les hosts/services : par exemple, on peut spécifier que le virtual host HTTP X dépend du service Apache. Dans ce cas, si Apache est en alarme, aucune alerte n'est envoyée pour X.
  • Pour peu qu'on ait pris le soin de renseigner pour chaque host son ou ses hosts parents (au sens de la topologie du réseau), Nagios est capable :
    • de générer une carte des hosts du réseau, avec états et liens entre eux,
    • de différencier un host down d'un host unreachable : un host est unreachable si typiquement il ne répond pas au ping et si sur chaque chemin entre lui et le serveur Nagios il existe un host down (autrement dit, il est inaccessible par Nagios, mais fonctionne peut-être normalement).
Contributions

Il existe une communauté de développeurs de plugins/addons et un repository centralisé des contributions : http://www.MonitoringExchange.org