|
Monitoring d'une infrastructure informatique Linux sur base d'outils libres( Télécharger le fichier original )par Geoffrey Lemaire Haute Ecole Rennequin Sualem (Belgique) - Bachelier en Informatique et Systèmes (finalité Réseaux et Télécommunications) 2003 |
Chapitre 6L'analyse de Nagios6 Présentation de NagiosNagios est un moniteur d'hôtes et de services destiné ã nous informer des problèmes du réseau avant les clients, les utilisateurs finaux et les managers. Il a été créé pour fonctionner sous des systèmes d'exploitations de type Linux, mais il fonctionne très bien sous la majorité des variantes *NIX. Le service de monitoring fonctionne par des vérifications intermittentes sur les hôtes et les services que l'on spécifie en utilisant des « plugins ? externes qui retournent des informations d'états vers Nagios. Quand des problèmes sont rencontrés, le service de monitoring peut envoyer des notifications vers des contacts par divers moyens (email, message instantané, SMS, etc.). Les informations sur le statut actuel, les logs, et rapports peuvent tous être atteints via un navigateur Internet. 6.1 CaractéristiquesNagios a un tas de caractéristiques faisant de lui un excellent outil de monitoring. Les possibilités majeures sont listées ci-dessous :
Surveillance des services réseaux (SMTP, POP3, HTTP, NNTP, PING, etc.) Surveillance des ressources des hôtes (charge processeur, utilisation des disques, etc.) Monitoring des facteurs environnementaux comme la température Système simple de plugins permettant aux utilisateurs de développer facilement leurs propres vérifications de services. Parallélisassions des vérifications des services. Possibilité de définir la hiérarchie du réseau en utilisant des hôtes "parents", ce qui permet la détection et la distinction entre les hôtes qui sont à l'arrêt et ceux qui sont injoignables. Notifications des contacts quand un hôte ou un service a un problème et quand celui-ci est résolu (via email, pager, sms, ou par tout autre méthode définie par l'utilisateur) Possibilité de définir des gestionnaires d'évènements qui s'exécutent pour des évènements sur des hôtes ou des services, pour une résolution proactive des problèmes Support pour l'implémentation de serveurs de monitoring redondants et distribués Interface de commandes externes qui permet des modifications rapides d'être faite vers le monitoring et le comportement des notifications ã travers l'utilisation de gestionnaires d'évènements, de l'interface Web , et d'applications tierces. Conserve le statut des hôtes et de services après un redémarrage Coupure planifiée pour la suppression des notifications d'hôtes et de services pendant les périodes de maintenance Capacité de confirmer un problème via l'interface Interface Web pour voir le statut actuel du réseau, notification et historique des problèmes, fichiers de logs, etc. Organisation simple des autorisations qui permet de restreindre ce que les utilisateurs peuvent voir et faire ã partir de l'interface. 6.2 Pré requis
6.3 Installation Il existe deux possibilités d'installation : en manuel par compilation des sources et via les packages RPM (dépôts de Dag Wieers10). Pour des raisons de facilité de maintenance, il m'a été demandé de l'installer en automatique via dépôts. 6.3.1 Ajout des dépôts Nagios n'étant pas disponible sur les dépôts officiels de Red Hat Entreprise Linux, j'ai dû rajouter le dépôt de Dag Wieers en modifiant le fichier /etc/sysconfig/rhn/ sources et en rajoutant ### Dag RPM Repository for Red Hat Enterprise Linux yum dag http://apt.sw.be/redhat/el4 /en/$ARCH/dag Suivi d'un # up2date -u 6.3.2 Modification des iptables IP_DAG=1 93.1 .193.67 iptables-A OUTPUT -d $IP_DAG -p tcp --syn --dport http -j LOG_OUTGOING iptables -A OUTPUT -d $IPRANGE_INTRANET_SERVERS -p udp --dport snmp -j LOG_OUTGOING iptables -A OUTPUT -d $IPRANGE_DMZ -p udp --dport snmp -j LOG_OUTGOING L'avantage de cette méthode est lors de la présence de mise ã jour, tout se fera automatiquement via un up2date. La méthode manuelle entrainait quand à elle, une recompilation obligatoire de Nagios et des plugins additionnels. 6.3.3 Téléchargement et installation # up2date -i nagios nagios-plugins net-snmp net-snmp-utils
6.4 Structure des répertoires et emplacement des fichiers Nagios s'installe par défaut dans plusieurs répertoires : Sous-répertoires Contenus /usr/bin/nagios/ Ensemble des programmes Nagios /etc/nagios/ Les fichiers de configurations
principaux, des ressources, des objets,
/usr/sbin/nagios/ CGIs 10 Dag Johan Maarten Wieers : http://dag.wieers.com/ Monitoring d'une infrastructure Linux sur base d'outils libres /usr/share/nagios/ fichiers HTML (pour l'interface web et la documentation en ligne) /var/log/nagios/ Répertoire vide pour les
fichiers de log, les fichiers de statuts, les /var/log/nagios/archives Répertoire vide pour les logs arch ivés /var/log/nagios/rw Répertoire vide pour le fichier de commandes externes 6.5 Accès à l'interface Web L'accès ã l'interface Web se fait par défaut sur le port 80 et est protégé par un .htaccess. Avec un des employés de Manex, nous avons rendu l'accès ã Nagios via une authentification LDAP. Ce point sera expliqué plus tard. On peut spécifier des droits d'accès aux différentes parties de l'interface.
Les Contacts authentifiés ont les droits suivants sur chaque service dont ils sont un contact (mais pas sur ceux dont ils ne sont pas un contact)...
6.6 Description des fichiers de configurations Il existe une dizaine de fichiers de configurations dans /etc/nagios/ dont le principal est nagios.cfg. Il contient un certain nombre de directives qui affectent la manière dont Nagios fonctionne. Ce fichier est lu par le processus Nagios et par les CGIs. 6.6.1 Configuration principal Le fichier principal est nagios.cfg11. C'est ce fichier que le daemon Nagios va lire en tout premier. Il contient divers paramètres pour le daemon en lui-même ainsi que les références vers les autres fichiers de configurations. Les variables importantes (à décommenter) : cfgjile=/etc/nagios/contactgroups.cfg cfgjile=/etc/nagios/contacts.cfg cfgjile=/etc/nagios/hostgroups.cfg cfgjile=/etc/nagios/hosts.cfg cfgjile=/etc/nagios/services.cfg cfgjile=/etc/nagios/timeperiods.cfg cfgjile=/etc/nagios/dependencies.cfg En fait, pour plus de clarté, j'ai suivi le modèle de configuration recommandé par Nagios à savoir bien séparer les différentes configurations. Je les détaillerai après. Cela dit, rien n'empêche de regrouper toutes les configurations dans un seul et même fichier... <= bonjour la maintenance ;o) Nagios permet aussi de lire la configuration de plusieurs fichiers dans un répertoire. Utile pour regrouper par exemple tout les serveurs d'un même LAN, ou encore d'une DMZ. Seule obligation pour que les fichiers quÐ l'on y mettra soient pris en compte, c'est qu'ils portent l'extension .cfg cfg_dir=/etc/nagios/servers cfg_dir=/etc/nagios/DMZ Le fichier resource.cfg est très important ! Il nous permettra de stocker les diverses Macros utiles dans la définition de commandes. resourcejile=/etc/nagios/resource.cfg Si l'on souhaite pourvoir utiliser les diverses commandes via l'interface Web de Nagios, il est obligatoire de mettre cette variable à 112. check_external_commands=1 Il s'agit en fait d'un fichier nagios.cmd qui sera placé (par les scripts CGI gérés par le daemon) dans /var/log/nagios/rw où toutes les commandes passées par l'interface Web seront écrites dedans jusqu'à leur exécution. Le fichier peut être lu autant que possible ou toutes les x secondes. La variable suivante défini la chose. command_check_interval=10s # remplacer 10s par -1 si check autant que possible Et on peut changer (si on le souhaite) l'emplacement du fichier précédemment cité... commandjile=/var/log/nagios/rw/nagios.cmd 11 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/configmain.html 12 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/extcommands.html 6.6.2 Configuration des CGIs Le fichier de configuration des CGIs cgi.cfg13 contient un certain nombre de directives qui affectent le mode de fonctionnement des CGIs. Il existe plusieurs façons de restreindre l'accès à Nagios. Par défaut, il s'agit du couple : .htaccess/.htpassword . Quel qu'en soit le choix, il faut modifier les lignes suivantes : use_authentication=1 # Forcera Nagios à
demander une
authentification authorizedjor_configuration_information=* authorizedjor_system_commands=* authorizedjor_all_services=* authorizedjor_all_hosts=* authorizedjor_all_service_commands=* authorizedjor_all_host_commands=* Dans notre cas, on autorise tout le monde car nous allons utiliser le LDAP pour restreindre l'accès. Mais pour ceux qui utilisent simplement le couple .htaccess/.htpassword on peut spécifier l'accès à certaines choses et pas à d'autres allant du simple affichage des pages Nagios à la capacité de arrêter/redémarrer le processus Nagios. 6.6.3 Configuration d'un vhost dans Apache Nous allons créer le fichier suivant : /etc/httpd/vhosts.d/ nagios.manex.be.conf Voici son contenu : <VirtualHost 192.168.1.14:80> ServerName nagios.manex.be ScriptAlias /nagios/cgi-bin "/usr/lib/nagios/cgi" ServerAdmin infrastructure-managers@manex.be ErrorLog /var/log/httpd/nagios.manex.be-error_log CustomLog /var/log/httpd/nagios.manex.be-access_log common <Directory "/usr/lib/nagios/cgi"> Options ExecCGI AllowOverride None Order deny,allow Allow from all AuthType Basic AuthName nagios.manex.be AuthLDAPEnabled on AuthLDAPURL ldap://192.168.1.11/dc=manex,dc=be?uid?sub?(objectclass=person) AuthLDAPBindDN "uid=apache,ou=special users,dc=manex,dc=be" AuthLDAPBindPassword apache Require group cn= nagios.manex.be,ou=web,ou=Applications,dc=manex,dc=be Require valid-user </Directory> Alias /nagios "/usr/share/nagios" 13 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/configcgi.html <Directory "/usr/share/nagios"> Options None AllowOverride None Order deny,allow Allow from all AuthType Basic AuthName nagios.manex.be AuthLDAPEnabled on AuthLDAPURL ldap://192.168.1.11/dc=manex,dc=be?uid?sub?(objectclass=person) AuthLDAPBindDN "uid=apache,ou=special users,dc=manex,dc=be" AuthLDAPBindPassword apache Require group cn= nagios.manex.be,ou=web,ou=Applications,dc=manex,dc=be Require valid-user </Directory> RedirectMatch ^(/)$ /nagios </VirtualHost> Prendre soin de donner les droits dans le LDAP. 6.6.4 Les contacts et groupes de contacts Les contacts sont les personnes qui seront prévenues lors d'un évènement (alerte warning, critical, ...). Commençons par créer un groupe d'utilisateurs dans le fichier contactgroups.cfg. define contactgroup{ contactgroup_name admins alias Nagios Administrators members nagios-admin On a dès lors un groupe nommé « admins » qui possède un alias (une description en fait) et un contact « nagios-admin ». Allons configurer ce contact dans le fichier contacts.cfg14. define contact{ contact_name nagios-admin alias LE Big Boss de Nagios service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,r service_notification_commands notify-by-email host_notification_commands host-notify-by-email email infrastructure-managers@manex.be I Ici, on se retrouve avec nagios-admin et son alias. Ensuite, la période pendant laquelle il peut être prévenu pour les services et les hôtes. Suivi des options de notification respectivement pour les services et les hôtes (Warning, Unknown, Critical,
Recovery, Down, Flapping,...). Ensuite, la conta cter. 14 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#contact 6.6.5 Définition des périodes de vérifications et de notifications On peut spécifier facilement des périodes dans le fichier timeperiods.cfg15 qui seront utilisées par les services lors des contrôles ou des notifications.
} Il est toujours utile de spécifier plusieurs périodes de temps. Prenons le cas du monitoring des imprimantes... Il n'est pas important d'être prévenu le week-end si l'imprimante s'est mise en veuille ou si elle n'a plus d'encre... Et inutile aussi d'exécuter certaines vérifications durant le week-end. 6.6.6 Définition des groupes d'hôtes et des templates hôtes Commençons par créer les groupes d'hôtes dans le fichier hostgroups.cfg16. define hostgroup( hostgroup_name thelanservers alias SERVERS Intranet members mxisrv1,mxisrv2,mxisrv4 15 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#timeperiod 16 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#host define hostgroup{ hostgroup_name thedmzservers alias SERVERS DMZ members
mx1srv1,mx1srv2,mx1srv3,mx1srv6,mx1srv7,mx1srv9 Et les Templates d'hôtes dans le fichier hosts.cfg17. Ces Templates sont utiles pour définir une configuration identique pour plusieurs hôtes. define host{ name generic-host ; The name of this host template notifications_enabled 1 ; Host notifications are enabled event_handler_enabled 1 ; Host event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status
information across program restarts notification_period 24x7 ; Send host notifications at any time register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! } 6.6.7 Définition des hôtes Pour définir un hôte, rien de plus simple : define host{ use linux-server ; Name of host template to use host _name mxisrv4 alias mxisrv4 (Monitoring) address
mxisrv4.manex.be L'emplacement de ces lignes est un peu plus particulier. Dans mon cas, j'ai suivi un certain nombre de personnes dont l'avis est de créer un fichier par hôte. Dans ce cas-ci, j'ai créé un répertoire « servers » dans lequel j'ai placé le fichier mxisrv4.cfg. 6.6.8 Définition des ressources Les fichiers des ressources resource.cfg18 sont utilisés pour stocker les macros définies par les utilisateurs. Ces fichiers peuvent aussi contenir d'autres informations (telle que la configuration des connexions de la base de données), bien que ceci dépend de la manière dont Nagios aura été compilé. L'avantage de ces fichiers est de pouvoir y mettre des données sensibles de configuration qui ne seront pas accessibles à travers les CGIs. Le fichier des ressources est bien utile car il permet de définir des macros qui seront utilisées dans les différentes commandes19. # Sets $USER1$ to be the path to the plugins $USER1$=/usr/lib/nagios/plugins 17 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#host 18 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/macros.html 19 Seront présentées juste après. # Macro - SNMPv3 ; chaine de connexion utilisée par le plugin ./check_snmp $USER4$=-P 3 -L authPriv -U UnUtilisateur -A UnBeauMot2Passe -X UnAutreBeauMot2Passe # Macro - SNMPv3 Login/Password => MD5 ; contenu CRYPTE => DES (ou AES) $USER5$=-l UnUtilisateur -x UnBeauMot2Passe -X UnAutreBeauMot2Passe -L md5,des # Macro - Authentification http $USER6$=-a UnUtilisateur:Encore1Mot2Passe La définition de macro est vraiment très pratique, notamment dans le cas des Logins/Mots de Passe utilisés par le ÐrotocolÐ SNMPv3 s'ils sont communs ÐntrÐ Ðux. 6.6.9 Définition des commandes Les commandes sont utilisées par les services et définies dans le fichier commands.cfg20. C'est une couche intermédiaire entre le Plugin en lui-même qui sera utilisé et le service. C'est ici que l'on va indiquer les paramètres que l'on passe au Plugin. Il y a deux sortes de Plugins, les locaux qui sont destinés à une utilisation locale. Donc pas besoin de renseigner l'adresse de la machine, ils ne donneront que les résultats de la machine sur laquelle ils se trouvent. define command{ command_name check_local_load command_line $USER1$/check_load -w $ARG1$ -c $ARG2$ I Ensuite, les Plugins qui vont récupérer des informations sur d'autres serveurs. define command{ command_name check_imaps command_line $USER1$/check_simap -H $HOSTADDRESS$ -S -w $ARG1$ -c $ARG2$ I Les champs $HOSTADDRESS$ $ARG1$ $ARG2$ sont des macros. Ils servent d'intermédiaire dans la définition. 6.6.10 Configuration des informations étendues Les fichiers de configuration des informations étendues (hostextinfo.cfg21 & serviceextinfo.cfg) sont utilisés pour définir des informations supplémentaires pour les hôtes et les services qui doivent être utilisés par les CGI. On peut notamment y définir des petites images et des coordonnées pour la Map. define hostextinfo{ host _name mxisrv4 notes Serveur de Monitoring - Nagios notes_url http://nagios.manex.be/nagios/cgi-bin/status.cgi?host=mxisrv4 icon_image redhat.jpg icon_image_alt Red Hat Entreprise Linux vrml_image redhat.jpg statusmap_image redhat.jpg 2d_coords 100,250 3d_coords 1 00.0,50.0,75.0 I Après beaucoup de chipotage, on arrive à une Map dans ce genre : 20 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#command 21 Plus d'i nfos : http://nagios.sourceforge.net/docs/2 0/xodtemplate. html#hostexti nfo
6.6-1 : Petit réseau de Manex 6.6-2 : Le réseau d'une entreprise inconnue Pour l'image de droite, je l'ai obtenu via une recherche sur Google démontrant la capacité de ce créateur de Map. Bien entendu, il existe encore des plus grandes? avec ce genre d'outils, il est difficile de se limiter. Monitoring d'une infrastructure Linux sur base d'outils libres 6.7 Les services Il existe deux sortes de services : publics et privés. 6.7.1 Les services publics Les services dits Ðubliques sont ceux que Nagios Ðeut monitorer sur les hôtes distants en n'ayant comme information, que leur adresse IP. Par exemple : HTTP, SMTP, DNS, IMAP, LDAP, ? 6.7.2 Les services privés Les services dits Ðrivés sont ceux qui demandent l'utilisation du Ðrotocole SNMP ou l'exécution des plugins sur les hôtes monitorés via NRPE, NSCA ou par SSH. Par exemple : Charge CPU, utilisation
du disque, utilisation de la mémoire virtuelle/SWAP, 6.7.3 Définition des templates et des services Tout comme les hôtes, il est utile de définir des templates pour les services. Ils permettent, je le rappelle, de faire une configuration similaire pour plusieurs services. La configuration se déroule dans le fichier services.cfg22. define service{ name generic-service ; The 'name' of this service template active_checks_enabled 1 ; Active service checks are enabled passive_checks_enabled 0 ; Passive service checks are enabled/accepted parallelize_check 1 ; Active service checks should be parallelized obsess_over_service 1 ; We should obsess over this service (if necessary) checkjreshness 0 ; Default is to NOT check service 'freshness' notifications_enabled 1 ; Service notifications are enabled event_handler_enabled 1 ; Service event handler is enabled flap_detection_enabled 1 ; Flap detection is enabled failure_prediction_enabled 1 ; Failure prediction is enabled process_perf_data 1 ; Process performance data retain_status_information 1 ; Retain status
information across program restarts is_volatile 0 ; The service is not volatile register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT
AREAL } define service{ name local-service ; The name of this service template use generic-service ; Inherit default values from the generic-service definition check_period 24x7 ; The service can be checked at any
time of the day normal_check_interval 5 ; Check the service every 5 minutes under normal conditions retry_check_interval 1 ; Re-check the service every minute until a hard state can be determined contact_groups admins ; Notifications get sent out to
everyone in the 'admins' notification_options w,u,c,r ; Send notifications
about warning, unknown, critical, and 22 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#service Monitoring d'une infrastructure Linux sur base d'outils libres notification_interval 60 ; Re-notify about service problems every hour notification_period 24x7 ; Notifications can be sent out at any time register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT
A REAL SERVICE, JUST } Le template host-service est le même local-service. C'est juste prévu si on souhaite modifier les paramètres globaux du service... La définition des services n'est pas des plus compliquée. Il suffit de néanmoins respecter la façon dont on a défini la commande avant. Voici pour le service local. define service( use local-service ; Name of service template to use host _name mxisrv4 service_description CPU Load check_command
check_local_load!10.0,10.0,10.0!20.0,20.0,20.0 Et pour l'autre : define service( use host-service host _name mx1srv1 service_description IMAPS check_command check_imaps!10!20 } On peut éventuellement définir des groupes de services dans le fichier servicegroups.cfg23, mais je n'ai pas encore vu d'intérêt à cela. 6.7.4 Déclaration d'un autre service Voici la déclaration d'un service qui contrôle la SWAP pour le localhost : define service ( use local-service host _name localhost service_description SWAP check_command check_local_swap!90!80 } Le service utilise un Template local-service qui permet de définir une foule de paramètres. define command ( command_name check_local_swap command_line $USER1$/check_swap -w $ARG1$ -c $ARG2$ } Dans la définition de la commande, on retrouve le nom de la commande check_local_swap et sa ligne de commande. Pour la ligne de commande, on utilise des macros qui sont définies dans le fichier des ressources. $USER1$ pointe vers le path où se trouvent les plugins. $ARG1$ et $ARG2$ sont les arguments passés au plugin check_swap. Ils correspondent dans ce cas-ci aux valeurs dit warning et critical qui sont des niveaux d'alertes en fonction de l'utilisation de la SWAP. 23 Plus d'infos : http://nagios.sourceforge.net/docs/2 0/xodtemplate.html#servicegroup Monitoring d'une infrastructure Linux sur base d'outils libres 6.7.5 Un dernierg Voici la déclaration d'un service qui contrôle la mémoire virtuelle sur un ordinateur distant sous Windows XP Pro SP2 : define service { use host-service host _name HOST A service_description Taille memoire Virtuelle check_command check_snmp_storage_v1 !public!"^
Virtual Memory$ "!80!90 Le service utilise un autre Template que précédemment, host-service qui permet notamment de définir la période où le service doit être utilisé. Cette fois-ci, on attache le service à HOST A, mon portable et du fait qu'il est sous Windows XP, on utilise le Ðrotocole SNMP (v1 dans ce cas-ci). define command { command_name check_snmp_storage_v1 command_line $USER1$/check_snmp_storage.pl -H
$HOSTADDRESS$ -C $ARG1$ -m } Ci-dessus, la définition de la commande qui se rapporte au service. On utilise plusieurs macros. Comme précédemment, $USER1$. Ensuite $HOSTADDRESS$ qui indique qui on va interroger. Cette fois-ci, $ARG1$ indiquera la communauté utilisé pour SNMP. Ensuite, $ARG2$ indiquera quel disque on souhaite interroger (dans le cas de ce plugin, la mémoire virtuelle est considérée comme un disque dur à part). $ARG3$ et $ARG4$ sont les valeurs warning et critical. On peut ajouter un $ARG5$ qui pourra éventuellement servir pour paramétrer plus précisément le service. 6.8 Méthodes pour démarrer Nagios Bien que lors de chaque chargement de Nagios, celui-ci fasse une vérification sur les fichiers de configurations, il est néanmoins recommandé de faire une vérification manuelle : # nagios -v /etc/nagios/nagios.cfg Nagios 2.9 Copyright (c) 1 999-2007 Ethan Galstad ( http://www.nagios.org) Last Modified: 04-10-2007 License: GPL Reading configuration data... Running pre-flight check on configuration data... Checking services... Checked 187 services. Checking hosts... Checked 17 hosts. Checking host groups... Checked 3 host groups. Checking service groups... Checked 0 service groups. Checking contacts... Checked 3 contacts. Checking contact groups... Checked 1 contact groups. Monitoring d'une infrastructure Linux sur base d'outils libres Checking service escalations... Checked 0 service escalations. Checking service dependencies... Checked 271 service dependencies. Checking host escalations... Checked 0 host escalations. Checking host dependencies... Checked 2 host dependencies. Checking commands... Checked 47 commands. Checking time periods... Checked 4 time periods. Checking extended host info definitions... Checked 17 extended host info definitions. Checking extended service info definitions... Checked 0 extended service info definitions. Checking for circular paths between hosts... Checking for circular host and service dependencies... Checking global event handlers... Checking obsessive compulsive processor commands... Checking misc settings... Total Warnings: 0 Total Errors: 0 Things look okay - No serious problems were detected during the pre-flight check Il y a cinq moyens différents de lancer Nagios:
Manuellement, en tant que processus prioritaire (utile pour les tests initiaux et le débogage) # nagios /etc/nagios/nagios.cfg Manuellement, en tant que processus d'arrière-plan # nagios /etc/nagios/nagios.cfg & Manuellement, en tant que un daemon # nagios -d /etc/nagios/nagios.cfg Manuellement via un script de démarrage Lors dÐ l'installation, un script dÐ démarragÐ Ðst placé dans le /etc/init.d/. On peut dès lors le lancer ainsi : # /etc/init.d/nagios Usage: nagios {start|stop |restart|reload|force-reload|status} Automatiquement au démarrage (boot) du système Pour qu'il démarre à chaque redémarrage du serveur, il suffit de taper cette commande : # chkconfig -level 345 nagios on 6.9 Plugins Les plugins sont des programmes compilés (C dans la majorité des cas) ou des scripts (Perl, Shell, etc..) qui peuvent être exécutés en ligne de commande pour tester l'état d'un hôte ou d'un service. Nagios utilise le résultat des plugins pour déterminer le statut actuel des hôtes ou services sur le réseau. Monitoring d'une infrastructure Linux sur base d'outils libres 6.9.1 Différentes sources Il existe un tas de plugins officiels et non officiels. Tout d'abord, les plugins officiels fournis par Nagios, sans quoi ce dernier ne fonctionnerait pas. Ensuite, il y a les plugins de Manubulon24 permettant d'effectuer des requêtes en utilisant le protocole SNMP (v1, 2c, 3). Enfin, il existe des sites communautaires dont NagiosExchange.org fait partie, qui regroupe les plugins développés par d'autres personnes. 6.9.2 Le principe de fonctionnement Nagios exécutera un plugin dès qu'il a besoin de vérifier un service ou un hôte supervisé. Le plugin fait quelque chose pour exécuter le contrôle et simplement renvoyer le résultat à Nagios. Nagios analysera le résultat provenant du plugin et prendra les mesures nécessaires (lancer les gestionnaires d'évènements, envoyer des notifications, etc).
6.9-1 : Montre comment les Ðlugins sont séÐarés du coeur logique de Nagios Nagios exécute les plugins qui vérifient ensuite des services ou des ressources locales ou distantes. Lorsque les plugins ont fini de vérifier la ressource ou le service, ils transmettent simplement le résultat de la vérification à Nagios. Avantages Inconvénients
Superviser des tâches automatisées avec Nagios Ne peut pas créer des graphes des ressources supervisées Beaucoup de plugins créés pour superviser les ressources basiques (CPU, Mem, Disk, Ping,...) Peut seulement suivre les changements d'état de ces ressources Seul les plugins savent exactement ce qu'ils supervisent et comment ils réalisent les vérifications 6.9.3 Utilisation des Plugins pour Contrôler des Services Quand Nagios a besoin de vérifier l'état d'un service défini, il exécutera le plugin spécifié dans l'argument « check_command » de la définition du service. Le plugin vérifiera l'état du service ou de la ressource et retournera le résultat à Nagios. 6.9.4 Utilisation des Plugins pour contrôler des hôtes Dans chaque définition d'hôte on utilise l'argument « host_check_command » pour spécifier un plugin qui devra être utilisé pour vérifier l'état de l'hôte. Les contrôles des hôtes ne sont pas effectués régulièrement : ils sont exécutés uniquement au besoin, typiquement lorsqu'il y a des problèmes avec un ou plusieurs services associés à l'hôte. 24 Manubulon est le pseudonyme de Patrick PROY : http://www.manubulon.com/nagios Monitoring d'une infrastructure Linux sur base d'outils libres Les contrôles des hôtes peuvent s'effectuer avec les mêmes plugins que les contrôles des services. La seule réelle différence entre les deux types de contrôles est l'interprétation des résultats du plugin. Si le résultat d'un plugin utilisé pour le contrôle d'un hôte est un état différent d'OK, alors Nagios croira que l'hôte n'est pas actif. Dans la plupart des cas, on peut utiliser un plugin permettant de contrôler si l'hôte répond à une requête ICMP (exemple : il répond au "ping") car c'est la méthode la plus courante pour savoir si un hôte est actif ou non. 6.9.5 L'analyse d'un plugin 6.9.5.1 Présentation Le code source qui suit est le code en langage C du plugin « check_users », plugin officiel de Nagios Ðermettant d'obtenir le nombre de Ðersonnes connectées sur la machine locale et générant un évènement si ce nombre est supérieur à un range défini. 6.9.5.2 Utilisation Pour afficher l'aide sur le fonctionnement, les Ðaramètres, etc. du plugin, il suffit de taper la commande suivante : # /usr/lib/nagios/plugins/check_users --help check_users (nagios-plugins 1.4.8) 1.22 Copyright (c) 1999 Ethan Galstad Copyright (c) 2000-2006 Nagios Plugin Development Team < nagiosplug-devel@lists.sourceforge.net> This plugin checks the number of users currently logged in on the local system and generates an error if the number exceeds the thresholds specified. Usage:check_users -w <users> -c <users> Options: -h, --help Print detailed help screen -V, --version Print version information -w, --warning=INTEGER Set WARNING status if more than INTEGER users are logged in -c, --critical=INTEGER Set CRITICAL status if more than INTEGER users are logged in Send email to nagios-users@lists.sourceforge.net if you have questions regarding use of this software. To submit patches or suggest improvements, send email to nagiosplug-devel@lists.sourceforge.net Il suffit de taper la ligne de commande du plugin ainsi que les paramètres appropriés pour avoir le résultat : # /usr/lib/nagios/plugins/check_users -w 2 -c 5 USERS OK - 1 users currently logged in |users=1;2;5;0 Sur le site nous avons :
6.9-2 : Vue de l'état des utilisateurs connectés sur la machine Monitoring d'une infrastructure Linux sur base d'outils libres Effectuons un autre test, connectons nous une deuxième fois sur ce serveur # /usr/lib/nagios/plugins/check_users -w 2 -c 5 USERS WARNING - 2 users currently logged in |users=2;2;5;0 Comme on Ðeut le voir, nous avons un Warning? allons voir du coté du site :
6.9-3 : Un état Warning pour le nombre d'utilisateurs connectés 6.9.5.3 Le mail d'alerte ***** Nagios 2.9 ***** Notification Type: PROBLEM Service: Users logged Host: mxisrv4 (Monitoring) Address: mxisrv4.manex.be State: WARNING Date/Time: Fri May 25 11:37:53 CEST 2007 Additional Info: USERS WARNING - 2 users currently logged in 6.9.5.4 Analyse Le Ðlugin est donc écrit en langage C. Il va tout d'abord vérifier les Ðaramètres qu'on lui a soumis lors de l'exécution. En fonction de ces Ðaramètres, il exécutera une fonction ou retournera une valeur. Ensuite, il créera un processus fils qui sera chargé d'aller récuÐérer (ã l'aide d'une boucle While) le résultat retourné par la commande linux : # who geoffrey pts/1 May 25 09:10 (192.1 68.2.32) Enfin, il comÐarera en fonction des Ðaramètres Warning et Critical, la valeur qu'il a Ðrécédemment comptée et retournera un état ainsi que le résultat sur la console. 6.9.5.5 Son code source En raison de la grandeur du code (pourtant le plus petit en nombre de ligne), je l'ai mis ã la suite sur deux pages. Monitoring d'une infrastructure Linux sur base d'outils libres /*************************************************** * * Nagios check_users plugin * * License: GPL * Copyright (c) 2000-2006 nagios-plugins team * * Last Modified: $Date: 2007/01/28 21:46:41 $ * const char *progname = "check_users"; const char *revision = "$Revision: 1.22 $"; const char *copyright = "2000-2006"; const char *email = " nagiosplug-devel@lists.sourceforge.net"; #include "common.h" #include "popen.h" #include "utils.h" if (child_stderr == NULL) printf (_("Could not open stderr for %s\n"), WHO_COMMAND); users = 0; while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, child_process)) { * Description: #define possibly_set(a,b) ((a) == 0 ? (b) : 0) /* increment 'users' on all lines except total * user count */ * This file contains the check_users plugin *
int process_arguments (int, char **); void print_help (void); void print_usage (void); int wusers = -1; int cusers = -1; int main (int argc, char **argv) { int users = -1; int result = STATE_UNKNOWN; char input_buffer[MAX_INPUT_BUFFER]; char *perf; setlocale (LC_ALL, ""); bindtextdomain (PACKAGE, LOCALEDIR); textdomain (PACKAGE); perf = strdup(""); if (process_arguments (argc, argv) == ERROR) usage4 (_("Could not parse arguments")); /* run the command */ child_process = spopen (WHO_COMMAND); if (child_process == NULL) { printf (_("Could not open pipe: %s\n"), WHO_COMMAND); return STATE_UNKNOWN; } child_stderr = fdopen (child_stderr_array[fileno (child_process)], "r"); if (input_buffer[0] != '#') { continue; } /* get total logged in users */ if (sscanf (input_buffer, _("# users=%d"), &users) == 1) break; } /* check STDERR */ if (fgets (input_buffer, MAX_INPUT_BUFFER - 1, child_stderr)) result = possibly_set (result, STATE_U NKNOWN); (void) fclose (child_stderr); /* close the pipe */ if (spclose (child_process)) result = possibly_set (result, STATE_U NKNOWN); /* else check the user count against warning and critical thresholds */ if (users >= cusers) result = STATE_CRITICAL; else if (users >= wusers) result = STATE_WARNING; else if (users >= 0) result = STATE_OK; Monitoring d'une infrastructure Linux sur base d'outils libres if (result == STATE_UNKNOWN) switch (c) { usage4 (_("Warning threshold printf ("%s\n", _("Unable to read output")); case '?': must be a positive integer")); else { /* print short else asprintf(&perf, "%s", perfdata ("users", usage statement if args not parsable */ cusers = atoi (argv[c]); users, "", usage5 (); } TRUE, wusers, TRUE, cusers, TRUE, 0, FALSE, 0)); printf (j "USERS %s - %d users currently logged in |%s\n"), state_text (result), users, perf); } return result; } /* process command-line arguments */ int process_arguments (int argc, char **argv) { int c; int option = 0; static struct option longopts[] = { {"critical", required_argument, 0, 'c'}, {"warning", required_argument, 0, 'w'}, {"version", no_argument, 0, 'V'}, {"help", no_argument, 0, 'h'}, {0, 0, 0, 0} }; if (argc < 2) usage ("\n"); case 'h': /* help */ print_help (); exit (STATE_OK); case 'V': /* version */ print_revision (progname, revision); exit (STATE_OK); case 'c': /* critical */ if (!is_intnonneg (optarg)) usage4 (_("Critical threshold must be a positive integer")); else cusers = atoi (optarg); break; case 'w': /* warning */ if (!is_intnonneg (optarg)) usage4 (_("Warning threshold must be a positive integer")); else wusers = atoi (optarg); break; } } c = optind; if (wusers == -1 && argc > c) { if (is_intnonneg (argv[c]) == FALSE) usage4 (_("Warning threshold return OK; } void print_help (void) { print_revision (progname, revision); printf ("Copyright (c) 1999 Ethan Galstad\n"); printf (COPYRIGHT, copyright, email); printf ("%s\n", _("This plugin checks the number of users currently logged in on the local")); printf ("%s\n", _("system and generates an error if the number exceeds the thresholds specified.")); printf ("\n\n"); print_usage (); printf (_(UT_HELP_VRSN)); printf (" %s\n", "-w, --warning=I NTEG ER"); printf (" %s\n", _("Set WARNING status if more than INTEGER users are logged in")); printf (" %s\n", "-c, --critical=INTEG ER"); printf (" %s\n", _("Set CRITICAL status if more than INTEGER users are logged in")); printf (_(UT_SUPPORT)); }
6.10 Contrôle des hôtes Pour le monitoring des hôtes, il existe 3 possibilités :
3. Via NSCA : Permet d'envoyer des résultats de contrôles passifs de services à un autre serveur sur le réseau sur lequel tourne Nagios 6.10.1 NRPE Les fichiers qui le constituent : Fichiers Description check_nrpe Plugin utilisé pour envoyer des requêtes sur l'agent nrpe de la machine distante. nrpe Agent qui tourne sur la machine distante et exécute les requêtes du plugin. nrpe.cfg Fichier de configuration pour les agents des machines distantes. Cet ajout est conçu pour permettre l'exécution de plugins sur une machine distante. Le plugin check_nrpe tourne sur la machine Nagios et est utilisé pour envoyer les requêtes d'exécution du plugin à l'agent nrpe de la machine distante. L'agent nrpe exécutera le plugin approprié sur la machine distante, et retournera les données de sortie et le code de retour au plugin check_nrpe de la machine Nagios. Le plugin check_nrpe envoit la sortie du plugin distant et le code de retour à Nagios comme si c'était le sien. Cela permet d'exécuter les plugins de manière transparente sur les machines distantes. L'agent nrpe peut soit fonctionner en mode daemon standalone, soit comme un service i netd. 6.10.2 NSCA Les fichiers qui le constituent : Fichiers Description
nsca.cfg Fichier de Configuration pour le daemon nsca.
send_nsca.cfg Fichier de configuration pour le client send_nsca. Cet ajout permet d'envoyer des résultats de contrôles de services passifs à partir de machines distantes à une machine centrale sur laquelle Nagios tourne. Le client peut être utilisé comme un programme séparé, ou peut être intégré dans des serveurs NAGIOS distants qui exécutent la commande ocsp pour créer un environnement de contrôles distribués. La communication entre le client et le daemon peut être cryptée par différents algorithmes (DES, 3DES, CAST, xTEA, Twofish, LOKI97, RJINDAEL, SERPENT, GOST, SAFER/SAFER+, etc.) si les bibliothèques mcrypt sont installées sur les systèmes. 6.10.3 Conclusion Par facilité et compatibilité, j'ai utilisé la première solution car :
6.11 Types de monitoring Il existe deux types de monitoring, actif et passif.
6.11-1: Utiliser les vérifications actives et passives Monitoring d'une infrastructure Linux sur base d'outils libres 6.11.1 Monitoring actif Le monitoring est actif lorsqu'il est demandé par Nagios. Nagios peut monitorer le server sur lequel il est ou des hôtes locaux ou distants. 6.11.2 Monitoring passif Le monitoring est passif lorsque le résultat est envoyé vers Nagios ã l'initiative du client. On utilise dès lors, soit le protocole SNMP Traps, soit le plugin NSCA (uniquement machine de type Linux). 6.12 Détection et gestion des changements d'états25 Nagios supporte la détection des hôtes et des services qui "oscillent". L'oscillation intervient quand un service ou un hôte change d'état trop fréquemment, provoquant une avalanche de notifications de problèmes et de rétablissement. L'oscillation peut être l'indice de problèmes de configuration ou de vrais problèmes sur le réseau. Exemple : des seuils positionnés trop bas (ce qui a été souvent mon cas). L'élaboration de cette technique a demandé, ã l'auteur, beaucoup de temps et de recherches. Je vous invite ã consulter la page suivante pour l'explication de la technique qu'il a dû élaborer. LIEN : http://nagios.sourceforge.net/docs/2 0/flapping.html 6.13 L'escalade des notifications Nagios supporte l'escalade des notifications envoyées aux contacts pour des services ou des hôtes. En résumé, on peut définir qu'au bout de 3 notifications, un premier groupe de contact sera prévenu. Ensuite au bout de 5 notifications, un autre groupe sera prévenu et ainsi de suite. 6.13.1 Recoupement des portées des escalades Les définitions d'escalade de notification peuvent avoir des portées qui se recoupent. Par exemple, définissons une escalade pour le service Status (En attente, Mode veille, Impression en cours, RemÐlacer cartouches, ...) de l'imprimante26 printer1 : define serviceescalation( host_name printer1 service_description Status first _notification 3 last _notification 5 notification_interval 20 contact_groups secretaire,users I define serviceescalation( host_name printer1 service_description Status first _notification 4 last _notification 0 notification_interval 120 contact_groups nagios-admin I Dans l'exemple ci-dessus : 25 En anglais, on utilise le terme : « flapping » 26 Le procédé pour monitorer les imprimantes réseaux sera expliqué ultérieurement dans un chapitre dédié.
6.13.2 Notifications de reprise d'activité Les notifications de reprise d'activité sont légèrement différentes des notifications de problème lorsqu'il s'agit d'escalade. Reprenons l'exemple d'avant... Admettons qu'après trois notifications de problème, une notification de reprise d'activité est envoyée au service qui reçoit la notification. La reprise d'activité est la quatrième notification envoyée. Cependant, le code d'escalade est suffisamment bien fait pour que seules les personnes qui ont reçu la troisième notification reçoivent celle de reprise d'activité. Dans ce cas, seul les groupes de contact secretaire et users recevront la notification de reprise d'activité. 6.13.3 Intervalles de notification Nous pouvons modifier la fréquence à laquelle les notifications escaladées sont émises pour un hôte ou un service particulier (avec notification_interval). Reprenons une dernière fois l'exemple d'avant. Admettons que l'intervalle de notification par défaut du service Status de l'imprimante printer1 soit 60 minutes. Quand la notification de ce service est escaladée lors des 3ème, 4ème, et 5ème notifications, un intervalle de 45 minutes sera utilisé entre les notifications. Lors de la 6ème notification et des suivantes, l'intervalle de notification sera de 120 minutes, comme il est spécifié dans la seconde définition d'escalade. 6.14 Les dépendances Les dépendances d'hôtes et de services sont une fonctionnalité avancée qui permet de contrôler le comportement des hôtes et des services selon l'état d'un ou plusieurs autres hôtes ou services. 6.14.1 Aperçu des dépendances de services
6.14.2 Comment les dépendances d'un service sont-elles testées ? Avant que Nagios n'exécute un contrôle de service ou n'envoie des notifications concernant un service, il vérifiera si le service comporte des dépendances. Si ce n'est pas le cas, le contrôle est exécuté ou la notification est envoyée comme en temps normal. Si le service a bien une ou plusieurs dépendances, Nagios vérifiera chacune de la manière suivante :
3. Si l'état courant du service dont il dépend correspond à une des options d'échec, la dépendance est réputée avoir échoué et Nagios sortira de la boucle de vérification des dépendances. Monitoring d'une infrastructure Linux sur base d'outils libres 4. Si l'état courant du service dont il dépend ne correspond à aucune des options d'échec de la dépendance, la dépendance est réputée avoir réussi et Nagios continuera avec la prochaine dépendance. Ce cycle continue jusqu'à ce que toutes les dépendances du service aient été vérifiées, ou jusqu'à ce qu'une dépendance échoue. 6.14.3 Exemple de dépendance de service define servicedependency { host _name HOST A service_description PING dependent_host_name HOST A dependent_service_description CPU Load,Process List,Memory notificationjailure_criteria w,u executionjailure_criteria c,u Dans cet exemple, admettons que le service PING de l'hôte A est en état Warning ou Unknown. Les notifications pour les services CPU Load, Process List et Memory sur l'hôte A seront désactivées. Dans le cas où le PING de l'hôte A est en Critical ou Unknown, l'exécution des services (CPU Load, ?) ne s'effectuera pas. 6.14.4 Dépendances d'exécution Les dépendances d'exécution permettent de limiter les vérifications de services actifs. Les vérifications de services passifs ne sont pas affectées par les dépendances d'exécution. Si tous les tests de dépendance d'exécution du service réussissent, Nagios exécute le contrôle du service comme d'habitude. Si ne serait-ce qu'une dépendance d'exécution du service échoue, Nagios arrêtera temporairement l'exécution des contrôles pour ce service (dépendant). Par la suite, les tests des dépendances d'exécution du service vont réussir. Alors, Nagios recommencera les contrôles de ce service de manière normale. Dans l'exemple ci-dessus, les dépendances d'exécution des services CPU Load, Process List, Memory échoueraient si le service PING est dans un état CRITICAL ou UNKNOWN. Si c'était le cas, le contrôle de service ne serait pas réalisé et serait prévu pour une future exécution (potentielle). 6.14.5 Dépendances de notification Si tous les tests de dépendance de notification du service réussissent, Nagios enverra les notifications pour ce service comme à l'accoutumée. Si, ne serait-ce qu'une dépendance de notification du service échoue, Nagios arrêtera temporairement l'émission de notifications pour ce service (dépendant). Plus tard, les tests des dépendances de notifications du service vont réussir. Alors, Nagios recommencera à envoyer des notifications pour ce service de manière normale. Dans l'exemple ci-dessus, les dépendances de notification des services CPU Load, Process List, Memory échoueraient si le service PING est dans un état WARNING, UNKNOWN. Si c'était le cas, les notifications pour ce service ne seraient pas envoyées.
6.14-1 : Dépendances des hôtes 6.14.6 Dépendances d'hôtes Les dépendances d'hôtes fonctionnent d'une manière similaire à celles de services. La principale différence est que ce sont des hôtes et pas des services. Une autre différence est que la dépendance d'hôte ne sert qu'à supprimer des notifications d'hôtes et non pas des contrôles d'hôtes. define hostdependency ( host _name HOST A dependent_host_name HOST B notificationjailure_criteria d,u } Les dépendances de notifications d'hôtes marchent d'une manière similaire à celles des services. Si toutes les notifications de dépendance d'un hôte réussissent, Nagios enverra les notifications comme à l'accoutumée. Si ne serait-ce qu'une de ces dépendances échoue, Nagios supprimera temporairement toutes les notifications pour cet hôte (dépendant). Par la suite, les dépendances réussiront à nouveau. Nagios recommencera alors à envoyer les notifications de manière habituelle. 6.15 L'héritage Il est possible de créer des relations d'héritage entre hôtes. Notamment entre des routeurs, switchs, firewalls. Dans ce cas, le simple ajout d'une ligne dans la configuration de l'hôte : define host( ... parents asa5510 ... } Si cet hôte est sur le même segment que l'hôte de supervision (sans routeur intermédiaire, etc.), il est considéré comme étant sur le réseau local et n'aura pas d'hôte parent. Laissez cette valeur vide si l'hôte n'a pas d'hôte parent (c.à.d. s'il est sur le même segment que l'hôte de Nagios). 6.16 Les notifications par mail Lors d'un évènement dans Nagios, il nous notifie par mail. Pour ce faire, il est nécessaire de configurer le serveur en conséquence. Dans le cas du serveur de monitoring, on m'a demandé d'installer Postfix pour sa simplicité de configuration et d'utilisation. 6.16.1 Son fichier de configuration Voici les lignes à modifier dans le fichier /etc/postfix/ main.cf : myhostname = mxisrv4.manex.be mydomain = manex.be myorigin = $mydomain mydestination = $myhostname, localhost.$mydomain, localhost relayhost = $mydomain Monitoring d'une infrastructure Linux sur base d'outils libres 6.16.2 Les mails de Nagios Voici un exemple de mail lorsque Nagios n'arrive pas ã accèder ã un site hébergé chez Manex (leur site Web) : Subject: ** PROBLEM alert - mx1srv9 (Web)/ manex.be is CRITICAL ** Date: Thu, 17 May 2007 03:44:41 +0200 (CEST) From: nagios@manex.be (nagios) ***** Nagios 2.9 ***** Notification Type: PROBLEM Service: manex.be Host: mx1srv9 (Web) Address: 217.117.50.179 State: CRITICAL Date/Time: Thu May 17 03:44:41 CEST 2007 Additional Info: CRITICAL - Socket timeout after 10 seconds Ou lorsqu'un hôte est injoignable. Par exemple, une imprimante : Subject: Host DOWN alert for mxiprn2! Date: Fri, 18 May 2007 09:00:10 +0200 (CEST) From: nagios@manex.be (nagios) ***** Nagios 2.9 ***** Notification Type: PROBLEM Host: mxiprn2 State: DOWN Address: 192.168.0.22 Info: PING CRITICAL - Packet loss = 100% Date/Time: Fri May 18 09:00:10 CEST 2007 Un problème de PING trop élevé pour accèder ã un serveur distant? Subject: ** PROBLEM alert - mx2rtr1 (ViKe)/PING is WARNING ** Date: Wed, 23 May 2007 18:37:27 +0200 (CEST) From: nagios@manex.be (nagios) ***** Nagios 2.9 ***** Notification Type: PROBLEM Service: PING Host: mx2rtr1 (ViKe) Address: mx2rtr1.manex.be State: WARNING Date/Time: Wed May 23 18:37:27 CEST 2007 Additional Info: PING WARNING - Packet loss = 0%, RTA = 474.21 ms Enfin, quand l'état change et revient ã la normal : Subject: ** RECOVERY alert - mx2rtr1 (ViKe)/PING is OK ** Date: Tue, 29 May 2007 21:29:20 +0200 (CEST) From: nagios@manex.be (nagios) ***** Nagios 2.9 ***** Notification Type: RECOVERY Service: PING Host: mx2rtr1 (ViKe) Address: mx2rtr1.manex.be State: OK Date/Time: Tue May 29 21:29:20 CEST 2007 Additional Info: PING OK - Packet loss = 0%, RTA = 50.31 ms
6.17 Utilisation du protocole SNMPv327 Avec les plugins de Manubulon, il est possible de monitorer via le protocole SNMPv3. Il peut se faire selon les deux modes : authNoPriv et authPriv. Pour authNoPriv, le login et le mot de passe de connexion sera encrypté en MD5 ou en SHA-1 et pour authPriv, les informations récupérées du protocole SNMPv3 sera encryptée en DES ou AES. 6.18 Des tas d'autres possibilités ! Du fait que je devais tester plusieurs programmes de monitoring, je n'ai pas eu le temps d'approfondir et tester certains plugins. Par exemple : Interception de Traps SNMP Utilisation de NMAP pour check les intrusions Monitoring du matériel (UPS28, switch, température matériel et ambiante, ?) Notification par SMS Utilisation d'Oreon (interface Web pour configurer les fichiers de Nagios) ? Il existe une grande communauté d'utilisateurs, développeurs, etc. autour de Nagios. La confection de plugins ã l'air simple vu les nombreux tutoriaux et la disponibilité de quasi tous en open source.
Ce plugin fonctionne depuis les premières versions de Nagios. LIEN : https://addons.mozilla.org/fr/firefox/addon/3607 J'ai soumis plusieurs « issues ? ã l'auteur de ce plugin pour la correction de bugs sous le pseudo « geolem1903 ».
LIEN : http://code.google.com/p/nagioschecker/issues/detail?id=17 27 Le chapitre suivant traitera du protocole SNMPv3 et de l'interaction avec Nagios. 28 Un chapitre traitera de cette configuration.
6.19-2 : Je fais partie des contributeurs du projet. 6.20 Conclusion Nagios a besoin de plusieurs programmes, librairies tierces qui elles aussi ont besoin d'autres librairies etc. mais une fois que l'on a tout, c'est relativement simple ã installer et d'autant plus simple si on installe via les dépôts (ce qui était mon cas). Au niveau de la configuration, on modifie directement les fichiers de configurations et on recharge la configuration au niveau de daemon. Pas très pratique car on doit à chaque fois revérifier la configuration. Cela dit, il est très modulaire et peut s'adapter ã énormément de type de réseaux. Il est puissant, léger et gratuit. On pourrait aussi envisager le développement de plugin pour les logiciels Ibats, etc. et la vente de services de monitoring. |
|
