Capture d'écran de l'interface web de Nagios

Aller à : Navigation, rechercher

Nagios
Capture d'écran de l'interface web de Nagios
Développeur	Ethan Galstad et d'autres
Dernière version	3.4.1 (15 mai 2012) [+/-]
Environnement	Linux, *NIX
Langue	Anglais
Type	Supervision
Licence	GNU GPL
Site web	www.nagios.org

Nagios (anciennement appelé Netsaint) est une application permettant la surveillance système et réseau. Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes ont des dysfonctionnements et quand ils repassent en fonctionnement normal. C'est un logiciel libre sous licence GPL.

C'est un programme modulaire qui se décompose en trois parties :

1. 
   Le moteur de l'application qui vient ordonnancer les tâches de supervision.
   
2. 
   L'interface web, qui permet d'avoir une vue d'ensemble du système d'information et des possibles anomalies.
   
3. 
   Les plugins, une centaine de mini programmes que l'on peut compléter en fonction des besoins de chacun pour superviser chaque service ou ressource disponible sur l'ensemble des ordinateurs ou éléments réseaux du SI.
   

Suite au manque de réactivité du développeur principal de Nagios et de sa volonté de ne plus diffuser tous les modules sous Logiciel Libre, certains développeurs actifs sur le projet ont "forké" Nagios pour créer Icinga.

Sommaire

• 
  1 Possibilités
  
• 
  2 Voir aussi
  
  • 
    2.1 Articles connexes
    
    • 
      2.1.1 Autres logiciels de supervision
      
    • 
      2.1.2 Divers
      
  • 
    2.2 Liens externes
    

Possibilités

• 
  Superviser des services réseaux : (SMTP, POP3, HTTP, NNTP, ICMP, SNMP, LDAP, etc.)
  
• 
  Superviser les ressources des serveurs (charge du processeur, occupation des disque durs, utilisation de la mémoire paginée) et ceci sur les systèmes d'exploitation les plus répandus.
  
• 
  Interface avec le protocole SNMP.
  
• 
  La supervision à distance peut utiliser SSH ou un tunnel SSL (notamment via un agent NRPE).
  
• 
  Les plugins sont écrits dans les langages de programmation les plus adaptés à leur tâche : scripts shell (Bash, ksh, etc.), C++, Perl, Python, Ruby, PHP, C#, etc.
  
• 
  La vérification des services se fait en parallèle.
  
• 
  Possibilité de définir une hiérarchie dans le réseau pour pouvoir faire la différence entre un serveur en panne et un serveur injoignable.
  
• 
  La remontée des alertes est entièrement paramétrable grâce à l'utilisation de plugins (alerte par courrier électronique, SMS, etc.).
  
• 
  Acquittement des alertes par les administrateurs.
  
• 
  Gestion des escalades pour les alertes (une alerte non acquittée est envoyée à un groupe différent).
  
• 
  Limitation de la visibilité, les utilisateurs peuvent avoir un accès limité à quelques éléments.
  
• 
  Capacité de gestion des oscillations (nombreux passages d'un état normal à un état d'erreur dans un temps court).
  
• 
  Créer ses propres plugins, dans le langage désiré. Il suffit de respecter la norme Nagios des Codes retour
  
  • 
    0 OK (tout va bien)
    
  • 
    1 WARNING (le seuil d'alerte est dépassé)
    
  • 
    2 CRITICAL (le service a un problème)
    
  • 
    3 UNKNOWN (impossible de connaître l'état du service)
    
• 
  Les possibilités de tests deviennent donc infinies, il suffit d'écrire tout plugin qui n'existerait pas déjà sur les sites spécialisés.
  

http://www.monitoring-fr.org/supervision/standards/

Les standards de la supervision

Le monde de la supervision et du management des infrastructures en général possèdent ses normes et standards, pour la plupart émergeants, dont sont présentés ici les plus significatifs. Ces standards sont pour la plupart gérés par la DMTF.

Standards

IPMI – Intelligent Platform Management Interface

L’Interface de gestion intelligente de matériel, (ou IPMI, Intelligent Platform Management Interface) est un ensemble de spécifications d’interfaces communes avec du matériel informatique (principalement des serveurs) permettant de surveiller certains composants (ventilateur, sonde de température, …).

JMX – Java Management Interface

JMX (Java Management Extensions) est une API pour Java permettant de gérer le fonctionnement d’une application Java en cours d’exécution. JMX a été intégré dans J2SE à partir de la version 5.0. (Attention, JMX est, par défaut, désactivé en version 5.0. Utiliser : java -Dcom.sun.management.jmxremote). On peut voir JMX comme une espèce de SNMP pour Java.

CIM – Common Information Model

Standard de description des données administratives développé par le DMTF (Desktop Management Task Force).

SNMP – Simple Network Management Protocol

SNMP (Simple Network Management Protocol), protocole simple de gestion de réseau en Français, est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, superviser et de diagnostiquer des problèmes réseaux, matériels à distance.

Le système de gestion de réseau est basé sur trois éléments principaux: un superviseur, des nœuds (ou nodes) et des agents. Dans la terminologie SNMP, le synonyme manager est plus souvent employé que superviseur. Le superviseur est la console qui permet à l’administrateur réseau d’exécuter des requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface, connectant l’équipement managé (nœud) au réseau et permettant de récupérer des informations sur différents objets.

Switchs, hubs, routeurs et serveurs sont des exemples d’équipements contenant des objets manageables. Ces objets manageables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l’équipement en question. Ces objets sont classés dans une sorte de base de données arborescente appelée MIB (« Management Information Base »). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB.

L’architecture de gestion du réseau proposée par le protocole SNMP est donc fondée sur trois principaux éléments :

• 
  Les équipements managés (managed devices) sont des éléments du réseau (ponts, switches, hubs, routeurs ou serveurs), contenant des « objets de gestion » (managed objects) pouvant être des informations sur le matériel, des éléments de configuration ou des informations statistiques ;
  
• 
  Les agents, c’est-à-dire une application de gestion de réseau résidant dans un périphérique et chargé de transmettre les données locales de gestion du périphérique au format SNMP ;
  
• 
  Les systèmes de management de réseau (network management systems notés NMS), c’est-à-dire une console à travers laquelle les administrateurs peuvent réaliser des tâches d’administration.
  

ITIL – Information Technology Infrastructure Library

ITIL (Information Technology Infrastructure Library) est un ensemble de bonnes pratiques (en anglais, « best practice » NB: cette expression s’écrit au singulier en anglais, mais au pluriel en français) pour la gestion d’un système d’information (informatique), édictées par l’Office public britannique du Commerce.

Sont en particulier abordés les sujets ci-dessous :

• 
  une production informatique ?
  
• 
  Comment améliorer l’efficacité du système d’information ?
  
• 
  Comment réduire les risques ?
  
• 
  Comment augmenter la qualité des services informatiques ?
  

Assez populaire en Europe à la fin des années 1980, ITIL s’est implanté sur le marché nord-américain, via des entreprises proches de l’informatique, comme Andersen Consulting (appelée désormais BearingPoint), Ernst & Young, Hewlett-Packard, ou PricewaterhouseCoopers.

Les recommandations ITIL positionnent des blocs organisationnels et des flux d’informations. De nombreux logiciels d’exploitation informatique sont conformes à ces recommandations.

La CMDB, pour Configuration Management DataBase, est une base de données unifiant les composants d’un système informatique. Elle permet de comprendre l’organisation entre ceux-ci et de modifier leur configuration. La CMDB est un composant fondamental d’une architecture ITIL.

Une CMDB contient des informations sur les principaux composants du système d’information (appelés configuration items ou CI) et des détails sur les relations importantes entre eux. Un CI est une instance d’une entité disposant d’attributs modifiables : par exemple un ordinateur, un processus ou un employé. Un facteur de succès clé lors de l’implémentation d’une CMDB est la capacité à récupérer automatiquement des informations concernant les CIs (auto-discovery) et à suivre les changements au fur et à mesure.

Les CMDBs contiennent des métadonnées et par conséquent leur utilisation peut entrer en conflit avec le concept de dépôt de métadonnées tel que déployé dans les grandes organisations informatiques. La gestion des configurations en tant que processus traite de la manière dont les données sont mises à jour, ce qui est justement une faiblesse des dépôts de métadonnées. Les CMDBs apportent alors la gestion des historiques. De plus, elles s’intègrent dans le processus ITIL plus global et apportent une cohérence à la gestion du système d’information.

SBLIM – Standard Based Linux Instrumentation for Manageability

SBLIM – prononcez « sublime » – pour Standards Based Linux Instrumentation for Manageability. Il consiste à permettre aux machines Linux d’accéder à l’ensemble des technologies d’administration WBEM (Web Based Enterprise Management). IBM assure le développement et la promotion de ce standard.

• 
  SBLIM
  

WS-MANAGEMENT – Web Services for Management

WS-Management (Web Services for Management) addresses the cost and complexity of IT management by providing a common way for systems to access and exchange management information across the entire IT infrastructure. By using Web services to manage IT systems, deployments that support WS-Management will enable IT managers to remotely access devices on their networks – everything from silicon components and handheld devices to PCs, servers and large-scale data centers. WS-Management is the first specification in support of the DMTF initiative to expose CIM resources via a set of Web services protocols.

• 
  OpenWSman
  
• 
  WS-MAN sur le site de la DMTF
  

WBEM – Web Based Enterprise Management

WBEM (Web-Based Enterprise Management) est un ensemble de technologies et de standards Internet de gestion développé pour unifier la gestion des environnements d’informatique distribuée.

WBEM fournit la capacité aux industriels de délivrer un ensemble de standards de bases bien intégrés aux outils de supervision, facilitant l’échange de données à travers d’autres différentes technologies et plateformes. L’instance de normalisation DMTF (Distributed Management Task Force) accueille les impressions de leurs standards mais il requiert que les individus soumettant des commentaires soient agréés pour la politique d’impression du DMTF.

WMI – Windows Management Instrumentation

La technologie WMI (Windows Management Instrumentation) est une mise en œuvre de l’initiative WBEM (Web-Based Enterprise Management WBEM) de DMTF (Distributed Management Task Force) pour les plates-formes Windows. Cette initiative étend le modèle CIM (Common Information Model) pour représenter les objets de gestion dans les environnements Windows. CIM, qui est aussi un standard DMTF, est un modèle de données extensible qui permet d’organiser logiquement des objets de gestion d’une façon cohérente et unifiée dans un environnement géré.

Tout cela signifie que WMI améliore considérablement les capacités de gestion de Windows 2000 grâce à une interface unique, cohérente, extensible et orientée objet, qui utilise les normes de l’industrie. Par ailleurs, les applications et les scripts peuvent accéder aux données WMI sur un poste local ou distant de façon totalement transparente. Ce produit n’est pas uniquement destiné à Windows 2000 ; WMI est disponible pour Windows 95, Windows 98 et Windows NT 4.0. Certaines fonctionnalités de WMI permettront aux informaticiens de s’acquitter beaucoup plus facilement de leurs tâches de gestion.

• 
  API d’écriture de script uniforme. Tous les objets gérés sont définis dans un cadre objet commun fondé sur le modèle objet CIM. Les scripts n’ont besoin d’utiliser qu’une seule API (Application Programming Interface), WMI, pour accéder aux informations concernant des sources très diverses.
  
• 
  Administration à distance. Par définition, les objets gérés dans WMI sont disponibles pour les applications et les scripts aussi bien localement qu’à distance. La gestion à distance des objets ne requiert aucune tâche supplémentaire.
  
• 
  Recherche et navigation. Les applications et les scripts peuvent découvrir les informations disponibles sur un système en énumérant les classes disponibles. Les relations entre objets liés peuvent être détectées et parcourues afin de déterminer l’influence d’une entité gérée sur une autre.
  
• 
  Fonctionnalité de requête. L’infrastructure WMI traite les données qu’elle gère comme une base de données relationnelle et permet l’utilisation de requêtes SQL pour filtrer et concentrer les requêtes uniquement sur les données pertinentes.
  
• 
  Fonctionnalités puissantes de publication d’événements et d’abonnements. Des événements peuvent être demandés pour pratiquement toute modification apportée aux objets gérés du système, que ces objets disposent ou non de fonctionnalités internes d’événement. Les abonnés à des événements peuvent demander la notification d’événements très spécifiques en fonction de leurs intérêts particuliers (et non uniquement des événements prédéfinis par les développeurs). Grâce à une architecture très souple, toute action définie par l’utilisateur peut en principe être effectuée à réception d’un événement donné.
  

Comment superviser avec Nagios / Icinga ?

http://www.opendoc.net/solutions/comment-superviser-avec-nagios-icinga

1 Présentation

Nagios est un outil flexible et totalement paramétrable. De manière générale, il est pénalisant dans un projet d’être limité par les caractéristiques d’un élément. Bien délimiter un besoin permet d’orienter les recherches et de proposer une solution adéquate.

Nagios est un moniteur de supervision réseau Open Source. Anciennement nommé NetSaint, logiciel libre reconnu dans le monde de la supervision, il permet une supervision active et passive de serveurs, d'équipements réseaux, et surtout de services divers et variés.

Bien que Nagios utilise des principes simples, il est complexe à mettre en place (configuration des intervalles de notifications, des commandes de vérification, des services et des hôtes à surveiller, des contacts pour les notifications, etc.). De l'aveu même du concepteur (Ethan Galstad) : « Si vous ne voulez pas passer du temps à apprendre comment ça fonctionne et pensez voir les choses tourner facilement, ne prenez pas la peine d'utiliser ce logiciel. »

Cependant, Nagios n'est en soi qu'un moteur d'ordonnancement. Il repose entièrement sur un système de plugins.

Icinga est un fork de Nagios rétro-compatible. Ainsi, les configurations, plugins et addons de Nagios peuvent tous être utilisés avec Icinga. Bien qu'Icinga conserve toutes les caractéristiques existantes de son prédécesseur, il s'appuie sur celles-ci pour ajouter de nombreux correctifs et fonctionnalités longtemps attendues et demandées par la communauté des utilisateurs.

2 Principe de fonctionnement

Vous ne trouverez pas ici une documentation complète du produit, car la documentation officielle est déjà très fournie. Je vous propose de lire le ebook de Nicolargo concernant Nagios qui est très bien écrit et commenté.

2.1 Les fichiers textes

Comme nous l’avons dit précédemment Nagios est un ordonnanceur qui s’appui sur les fichiers textes suivants :

• 
  Nagios.cfg : est le fichier principal de configuration, il contient la liste des autres fichiers de configuration.
  
• 
  Resource.cfg : permet de définir des variables globales réutilisables dans les autres fichiers. Il n’est pas accessible par les scripts CGI qui génèrent l’interface graphique de Nagios. Ce fichier peut contenir des données sensibles comme les identifiants de connexion à la base de données.
  
• 
  Checkcommands.cfg : contient les alias des commandes définis par l’utilisateur. Le fichier peut utiliser les variables globales. Les alias seront ensuite utilisés pour définir les commandes complètes dans les fichiers hosts.cfg et services.cfg.
  
• 
  Hosts.cfg : contient l’ensemble des hôtes à tester. Il associe a chaque hôtes une structure composée de son nom, adresse ip…
  
• 
  Services.cfg : permet d’associer à chaque hôte les services à vérifier. Le plus simple étant de créer des services dit « générique » qui pourront être appliqué au plus grand nombre d’hôtes. Ensuite créer des services spécifiques pour un besoin particulier.
  
• 
  Hostsgroups.cfg : permet de regrouper des hosts selon des caractéristiques communes avec la possibilité d’associer un alias à un groupe. Il est obligatoire qu’un hôte appartienne à un groupe.
  
• 
  Contacts.cfg : contient les contacts à prévenir en cas d’incident. Il permet de configurer le moyen d’alerter (mail, sms…), la fréquence et la plage horaire des notifications.
  
• 
  Contactgroups.cfg : rassemble les contacts en un groupe pour simplifier l’administration.
  
• 
  Cgi.cfg : définit les paramètres de configuration pour les scripts CGI.
  
• 
  Timeperiods.cfg : définit les tranches horaires applicables aux vérifications de services et aux notifications.
  
• 
  Dependencies.cfg : définit les dépendances entre services (sur le même hôte ou sur des hôtes différents). Pour cela il se base sur l’état des autres services pour déclencher l’exécution d’un test ou une notification. Cela permet ainsi de supprimer les notifications d’un hôte basé sur le statut d’un ou plusieurs hôtes.
  
• 
  Escalations.cfg : définit l’escalade des avertissements et alertes pour un hôte ou un service donné. Il répartit ces notifications entre les différents groupes d’intervenants.
  
• 
  Hostextinfo.cfg et Serviceextinfo.cfg : sont des fichiers optionnels permettant l’affichage d’icônes et d’informations sur les machines. Dans notre cas, ils seront utilisés pour le « status_map ».
  

2.2 Interface Homme-Machine

L’ensemble de ces fichiers, correctement écris, permettent une véritable IHM à travers une interface web. Cette dernière permettra d’afficher les résultats des différentes sondes par l’intermédiaire de scripts CGI.

2.3 Les plugins

Les plugins sont des scripts ou programmes qui sont indépendants de Nagios. Ils sont chargés de réaliser des vérifications et de fournir un code retour de la manière suivante :

• 
  0 = tout va bien (OK)
  
• 
  1 = avertissement (WARNING)
  
• 
  2 = alerte (CRITICAL)
  
• 
  3 = inconnu (UNKNOWN)
  

Il est aussi possible d’inclure un court message pour aider au diagnostique. Les plugins peuvent être écrits dans plusieurs langage (C, Perl, Bash…). Il existe deux grandes familles de plugins, celle qui fonctionne avec des agents dédiés (NRPE, NSCA) et celle qui fonctionne grâce au protocole SNMP. Les deux méthodes intègrent la notion de surveillance active et passive. Il est possible de récupérer l’information directement sur la machine controllée ou d’attendre qu’elle nous envoie l’information. L’agent Nagios actif est NRPE (Nagios Remote Plugin Executor) et l’agent passif est NSCA (Nagios Service Check Acceptor). Les plugins se reposant sur le protocole SNMP sont dit « actifs », mais il est possible d’utiliser le SNMP TRAP (information envoyée par le client) pour les afficher dans Nagios.

2.4 Notions d’états

La notion d’ « état » concerne la situation d’un service ou d’un hôte. En effet, en plus du statut (OK, WARNING, UP, DOWN…) il faut prendre en compte l’état « SOFT » ou « HARD ». Cette notion d’état est indispensable à la logique de la supervision de Nagios car elle détermine quand les notification sont émises, tout en évitant les fausse alertes.

• 
  L’état SOFT : est un état qui retourne un résultat différent de 0 mais qui n’a pas pour autant atteint le nombre maximum d’essai défini dans « max_check_attempts ». Cependant, Nagios ne renvoie pas de notification car le problème ne s’est pas encore avéré sérieux. A ce moment là, il est possible d’appeler le gestionnaire d’événements (processus de correction de l’alerte).
  

• 
  L’état HARD : d’un service ou d’un hôte correspond à une vérification qui retourne toujours un résultat différent de 0 mais qui a dépassé la limite fixée dans « max_check_attempts ». A partir de ce moment, la notification est déclenchée.
  

Cette notion d’état est applicable à tous les changements de statuts imposés par les codes erreur des plugins. C’est un état dit « HARD » qui appelle la notification des contacts. De plus, si cet état perdure, Nagios continu les notifications, il faut donc bien paramétrer les espacements pour ne pas polluer la boîte mail.

2.5 Notion de dépendance

La notion de dépendance a pour but de rendre une alerte pertinente. Il existe deux types de dépendances :

• 
  entre services : Un service peut dépendre d’un ou plusieurs services de manière non héritée. Lorsque la dépendance est présente entre un service A et B, si B venait à passer en état « CRITICAL » la dépendance serait en erreur et les notifications ne seraient pas envoyées pour A. Ce principe de dépendance entre services est limité car elle est verticale. Nous verrons le procédé pour réaliser une dépendance horizontale.
  

• 
  entre hôtes : Le principe est le même que celui des services. Les dépendances entre hôtes permettent seulement de désactiver les notifications mais pas les contrôles actifs. Dans le cas où nous supervisons un ensemble de machines situées derrière un routeur, si ce dernier venait à être défaillant, nous ne voulons pas générer des notifications pour les serveurs se trouvant derrière.
  

/