Supervision v2010 Avec Commentaires

JT SIARS 2010 3 & 4 Juin 2010
Prsentation de Nagios et de Centreon Installation et mise en uvre Intgration doutils supplmentaires
Mise en uvre dun portail de supervision des systmes et rseaux v 2.0

Thierry DOSTES
(Thierry.Dostes "@" ifr88.cnrs-mrs.fr)
SOMMAIRE
La principale ide de ce projet est de disposer, au final, dune interface unique permettant de grer nos systmes dinformation dans les meilleures conditions possibles. Bien entendu, il existe une multitude de solutions indpendantes les unes des autres, plus ou moins propritaires, pour assurer la supervision dquipements (imprimantes, commutateurs, serveurs, etc.). En revanche, il existe dj beaucoup moins de solutions globales, et la plupart dentre elles sont fort coteuses (ex: HPOpenView, Patrol de BMC). Nous ne chercherons donc pas rinventer la roue. Nous allons nous appuyer, autant que possible, sur des solutions dj existantes et, de surcrot, libres. Nous les intgrerons notre portail pour le rendre le plus complet et le plus pertinent possible. Ex : Nous dvelopperons ainsi un toolkit comprenant des applications telles que : Nmap, WOL, traceroute, reboot, ping.
Prsentation de Nagios et Centreon

Les enjeux de la supervision. Nagios : un outil de supervision modulaire et volutif. Centreon : une surcouche applicative conviviale et ergonomique.
Les enjeux de la supervision

Surveiller les systmes dinformation selon le type ou la fonction des quipements :
assurer la disponibilit des services. prvenir les dfaillances. dtecter les anomalies (scurit, systme). observer les performances. fdrer linformation dquipements htrognes en un portail unique.
Automatiser les tches :

alerter en cas dinterruption dun service. relancer des services interrompus.
Disposer de la vision globale dune infrastructure complexe.
Les concepts de la supervision

Diffrentes possibilits de supervision :
via le protocole SNMP. laide des journaux dexploitation. supervision active des services et infrastructures.
Les niveaux de supervision (1)

supervision rseau et matrielle :
commutateurs et routeurs : disponibilit, interrogation des sondes, alertes. serveurs : disponibilit, interrogation des sondes matrielles, alertes. onduleurs : disponibilit, charge, tat. imprimantes : disponibilit, tat de limprimante et des consommables.
supervision des systmes :

commutateurs : utilisation des ressources, mtrologie. serveurs : utilisation des ressources.
Les niveaux de supervision (2)

supervision des applications et services :
disponibilit. cohrence des rponses aux interrogations. performances.
Architecture systme de supervision
Prsentation de Nagios (1)

Nagios est un moniteur de supervision :
vrification des services rseau (SMTP, HTTP, etc.). surveillance des ressources des htes (charge CPU, espace disque, etc.). contrle des quipements rseau (CPU, ventilateurs, etc.).
Nagios est un ordonnanceur de vrifications et un analyseur grant les actions suivantes :
NAGIOS
systme complet de notification en fonction du service, de lheure et de la date. gestion des escalades. possibilit de paramtrer des ractions automatises. possibilit de dfinir des gestionnaires dvnements.
Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010
Thierry DOSTES Journes Thmatiques SIARS 13 & 14 Mars 2006
Nagios est le successeur de NetSaint. Il est dvelopp depuis plus de 10 ans. Il sagit dun moniteur de supervision trs puissant bien quil puisse parfois savrer complexe mettre en uvre. Gestionnaires dvnements : cela permet une rsolution des problmes directement sur la machine concerne.
10
Prsentation de Nagios (2)

Les tests sont laisss la charge de plugins /modules :
ils fonctionnent tels des programmes externes. cela permet de dvelopper ses propres modules.
Larchitecture de Nagios (1)

un ordonnanceur qui gre :
lordonnancement et les dpendances des vrifications. les actions entreprendre suite des incidents (alertes, escalades, corrections automatiques).
Il est possible de dfinir la hirarchie du rseau en utilisant le concept des htes parents . Nagios propose :
une interface Web avec gestion des droits pour la consultation. la gnration de rapports de surveillance.
une interface graphique de type client Web. des modules/sondes dont un grand nombre sont fournis de base ( ex : check_snmp, check_http, check_imap, etc.).
Nagios nest pas destin faire de la mtrologie.
Dfinir la hirarchie du rseau en utilisant des htes parents : permet la dtection et la distinction entre les htes qui sont larrt et ceux qui sont injoignables.
Interface graphique base sur des CGI.
11
12
Larchitecture de Nagios (2)

Nagios est un noyau :
ordonnanceur et analyseur. systme de modules/plugins pour les vrifications. collecte et analyse des informations. raction, prvention et rparation. souplesse et finesse de configuration.
Les modules/plugins Nagios (1)

Un module est un script/programme :
autonome. charg de raliser les vrifications. capable de fournir au moteur un code de retour :
0 = tout va bien 1 = avertissement 2 = alerte 3 = inconnu (OK) (WARNING) (CRITICAL) (UNKNOWN)
et un court message sur la sortie standard pour aider au diagnostic, langage au choix (Perl, C, WMI, etc.).
Contrairement beaucoup dautres outils de supervision, Nagios ne dispose pas de mcanismes internes pour vrifier ltat dun service, dun hte ou dun quipement rseau. On notera la flche en gris entre le serveur Nagios et la base de donnes destine stocker la configuration du serveur Nagios. En effet, la communaut Nagios souhaite abandonner le stockage dans une SGBD au profit de fichiers plats.
Comme nous lavons vu, Nagios ne dispose pas de mcanismes internes pour vrifier ltat dun service, dun hte ou dun quipement rseau. Pour ce faire, il utilise des programmes externes appels plugins/modules. Il lance ces modules et analyse les rsultats obtenus.
13
14

Tableau des tats dun hte :
Etat
UP DOWN

Le module fonctionne :
Signification
Hte disponible Hte indisponible
Code retour
0 1 ou 2
soit en utilisant le protocole SNMP pour interroger les MIBs.

ex : tat dun routeur, dun commutateur, dune imprimante.
Tableau des tats dun service :

Etat
OK WARNING
soit directement en local sur la machine supervise. Code retour

0 1 ex : vrification disques, interrogation des sondes matrielles, charge CPU.
Signification
Service disponible Avertissement sur le fonctionnement du service Alerte suite une erreur critique Etat inconnu
soit effectue des tests distance depuis le serveur Nagios en simulant le comportement dun client.
ex : tests sur des protocoles rseaux (SMTP, IMAP, POP).
CRITICAL UNKNOWN
2 3
15
16

Exemple : supervision dune imprimante rseau.
Nous interrogeons une imprimante qui supporte le protocole JetDirect. Le module Nagios check_hpjd est capable de dtecter les tats suivants :
bourrage ou manque de papier. imprimante offline . niveau des toners. capot ouvert, bac de sortie plein. etc.

Exemple : supervision dun commutateur ou dun routeur avec le protocole SNMP.
Nous interrogeons la MIB de lquipement rseau avec la commande :
check_snmp pour connatre le statut des ports ou les paramtres de fonctionnement du matriel. check_mrtgtraf pour surveiller la bande passante.
17
18
Lexcution de modules distance

Elle peut se faire par :
le biais dautres serveurs Nagios distants. des agents ddis : NRPE : Nagios Remote Plugin Executor NSCA : Nagios Service Check Acceptor lutilisation du module de base check_by_ssh. le recours au module natif check_snmp pour la supervision de valeurs SNMP.
Lagent NRPE : surveillance active

Cest un module Nagios part entire. Il permet lexcution dun autre module sur une machine distante. Il utilise le dmon NRPE pralablement install sur la machine distante. Le serveur Nagios envoie linstruction excuter au dmon NRPE. Les communications sont chiffres (SSL). La surveillance est active : le serveur Nagios est linitiateur des tests.
Comment commander depuis le serveur Nagios lexcution distance dun module install localement sur une machine que lon souhaite supervise ? Par exemple, nous souhaitons connatre loccupation des disques durs, sa charge CPU ou encore la temprature du systme. Le module de base check_by_ssh, qui permet lexcution dune commande sur un hte distant en utilisant SSH, impose au pralable la cration de comptes non privilgis sur les machines, accessibles par lutilisateur qui excute le daemon Nagios, et qui ont les droits suffisants pour lancer les plugins ncessaires. On en dduira trs vite que cette solution nest pas sans implications en termes de scurit.
Cryptage via SSL. Attention la possibilit dusurper ladresse puisque NRPE se sert de lIP pour vrifier que le requrant est autoris. Mais, avec SSL activ, ce problme est moins flagrant puisque lattaquant devra dchiffrer le trafic quil a captur. Le chiffrement est bas sur une routine de type AES-256 Bit utilisant SHA en Anon-DH. Puisque nous utilisons Anon-DH, cela permet de chiffrer entre le client et le serveur sans devoir gnrer des cls ou certificats au pralable. Le programme cre dynamiquement les cls au dmarrage du dmon partir des infos contenues dans le fichier dh.h qui se trouve dans le rpertoire source de NRPE.
19
20
Lagent NSCA : surveillance passive

Un client NSCA est excut sur chaque hte distant. Il envoie spontanment au serveur Nagios des rsultats de tests. Le serveur Nagios possde un dmon NSCA. Ce dernier pourra analyser ses informations entrantes sa convenance. Les communications sont chiffres. La surveillance est passive : le test est planifi en local et le rsultat est envoy Nagios.
Que choisir : NRPE ou NSCA ?

Le module NRPE :
reoit la demande de vrification du serveur. excute cette vrification. retourne le rsultat au serveur qui lattendait.
Avec lagent NSCA :

la vrification est planifie en local. le rsultat est envoy au serveur Nagios de manire asynchrone.
Lutilisation de lagent NSCA :

prsente lavantage de ne pas devoir ouvrir de ports sur le pare-feu en entre de rseau. permet de superviser des services de manire asynchrone (ex : traps SNMP).
Plusieurs modes de chiffrement des donnes sont possibles : DES, 3DES, CAST, xTEA, Twofish, LOKI97, RJINDAEL, SERPENT, GOST, SAFER/SAFER+. La condition : installer la librairie mcrypt sur la station.
Lutilisation de lagent NSCA prsente lavantage de ne pas avoir ouvrir de ports sur le firewall en entre de rseau (jonction internet/rseau). En effet, comme les informations sont envoyes par le client NSCA vers le dmon prsent sur le serveur Nagios, il suffit seulement de permettre le passage des informations dans le sens sortant sur le firewall.
21
22
Fonctionnement de NRPE et NSCA
Nagios 3.0 : les nouveauts

Amlioration des performances (dmarrage, interrogation des services, installation grande chelle). Les sondes/plugins peuvent retourner des informations sur plusieurs lignes. Ajout de nouvelles macros pour grer les tats des services et des htes. Nouvelle option pour introduire un dlai entre lapparition dun problme et sa notification. Possibilit de fixer des dpendances entre htes et services pour une dure dtermine. Les priodes de notification permettent dsormais dexclure des dates. Refonte dune partie de linterface Web en PHP.
Fonctionnement de NRPE : Le serveur Nagios, via son propre plugin NRPE, contacte le dmon NRPE install sur lhte distant. Il lui demande dexcuter une commande. Le dmon NRPE excute la commande en la sous-traitant au plugin requis. Il renvoie ensuite le rsultat au serveur Nagios, tjs par lintermdiaire de son module NRPE. Fonctionnement de NSCA : Le client NSCA, install directement sur la machine supervise, excute rgulirement des vrifications selon la planification qui a t dcide en local. Il envoie ensuite les rsultats au serveur Nagios qui les reoit via son dmon NSCA et qui pourra les traiter lorsquil le souhaitera.
23
24
Installation de Nagios (1)
Sur Debian Lenny, Nagios est disponible en version 3.0.6.

laika:~# apt-get install nagios3 nagios-plugins
En cours dinstallation :
cration du compte dadministration (nagiosadmin). activation de la gestion des commandes externes. installation des dpendances ncessaires (apache2, librairies Perl, SNMP, etc).,
Installation de Nagios
Actuellement, nous faisons tourner la solution Nagios + Centreon dans une machine virtuelle OpenVZ hberge sur un P4 2.3 Ghz avec 1 Go de mmoire. Cette configuration gre environ 90 htes et plus de 350 services associs. La charge de la machine est trs raisonnable. Nagios peut recevoir des commandes venant dapplication externes, parmi lesquelles des CGI (ex : command.cgi). Ces commandes peuvent modifier de nombreux aspects de ses fonctions de supervision. Par dfaut, Nagios ne traite pas les commandes externes. Les commandes externes peuvent tre utilises pour mener bien un certain nombre de tches pendant le fonctionnement de Nagios : - la dsactivation temporaire des notifications pour les services et les htes; - la dsactivation temporaire des tests de services; - l'obligation de contrler immdiatement un service; - l'ajout de commentaires aux htes et services, etc. Exemples de commandes externes Des scripts pouvant tre utiliss pour envoyer des commandes Nagios se trouvent dans le rpertoire /usr/lib/nagios/plugins/eventhandlers/. Vous pouvez les modifier pour les adapter aux diffrences de syntaxe des commandes, de localisation des fichiers et rpertoires, etc. command.cgi : Permet denvoyer des commandes au process Nagios. Pr-requis :
25
-autorisations pour lancer les commandes systmes,
26

Connexion au serveur Nagios :
http://serveur/nagios3/

Inventaire aprs installation :
/etc/nagios3/ contient les fichiers de configuration. /usr/sbin/nagios3 est lexcutable Nagios. /etc/nagios-plugins/config/ contient les fichiers de
dclaration des plugins fournis de base.

/usr/lib/nagios/plugins/ contient les modules de base de Nagios (les scripts ou les programmes binaires).
/usr/share/nagios3/plugins/eventhandlers/ contient
les gestionnaires dvnements.

/usr/share/nagios3/htdocs/ contient les pages et
lments de linterface Web.

/usr/lib/cgi-bin/nagios3/ contient les scripts CGI
utiliss par Nagios.
On peut accder au serveur Nagios en se connectant sur lURL http://nomserveur/nagios3/. On constate quil y a dj un hte prsent : gw . Cet hte correspond la passerelle indique dans les paramtres rseau.
27
28
Configuration de Nagios (1)

Nagios distingue 4 types de fichiers de configuration :
le fichier de configuration principal. les ressources dclares par lutilisateur. les fichiers de dfinition des objets utiliss pour la supervision. la dclaration et la configuration des scripts CGI.
Configuration de Nagios
Exemples de CGI : -statusmap.cgi cre une carte partir des htes dclars. -notifications.cgi pour afficher un inventaire des notifications qui ont t envoyes aux diffrents contacts. -showlog.cgi pour afficher sur linterface Web le contenu du fichier de logs. -etc.
29
30

Emplacement des fichiers de configuration :
rpertoire /etc/nagios3/

Prsentation des fichiers de configuration :
nagios.cfg :
fichier principal de paramtrage. contient la liste des autres fichiers de configuration. comprend lensemble des directives globales de fonctionnement du serveur Nagios.
(ex : nom et groupe de lutilisateur Nagios).
Une structure unique de configuration lexception des fichiers nagios.cfg et cgi.cfg :

define { param1 value param2 value }
resource.cfg :
permet de dfinir des variables utilisateur globales rutilisables dans les autres fichiers. nest pas accessible via les CGI qui gnrent linterface graphique de Nagios. peut contenir des donnes sensibles telles que les informations de connexion la base de donnes.
Une commande pour tester la cohrence des fichiers de paramtrage :

laika:~# /usr/sbin/nagios3 v /etc/nagios3/nagios.cfg
Cette structure unique de configuration implique quaucun espace ne peut tre insr dans les valeurs des paramtres !!
Fichier nagios.cfg : dclaration des sous-fichiers de configuration, des fichiers de logs, emplacement des caches et des fichiers temporaires, fichier de statut, ordonnancement Fichier resource.cfg : Exemples de variables globales : $USER1$=/usr/lib/nagios/plugins/ $USER2$=/usr/lib/nagios/plugins/eventhandlers Etant inaccessible depuis les CGI qui gnrent lIHM, ce fichier peut tre utilis pour stocker des informations sensibles de configuration, comme par exemple des informations relatives un compte utilisateur.
31
32

Prsentation des diffrents types dobjets de supervision :
Ce sont les lments impliqus dans la supervision et les notifications :
les htes et groupes dhtes. les services et groupes de services associs ces htes. les contacts et groupes de contacts qui sont informs de ltat de ces matriels et services. les commandes qui permettent dinterroger ces quipements ou dinformer les contacts. les concepts descalades et de dpendances.
Les commandes (commands.cfg) :

le fichier contient la dclaration des commandes de vrification, de notification et de gestion des vnements. ces commandes appellent les plugins de base ou les scripts crs par lutilisateur. elles peuvent utiliser les macros et les variables globales dfinies dans resource.cfg.
command[notify-by-email]=/bin/printf "$OUTPUT$" | /bin/mail -s '$SERVICESTATE$ alert for $HOSTALIAS$/$SERVICEDESC$' $CONTACTEMAIL$
Les htes (hosts.cfg) :

le fichier dfinit les diffrents htes du rseau surveiller (serveurs, postes de travail, routeurs, imprimantes, etc.). chaque hte est associe une structure particulire :
nom, adresse IP, le test effectuer pour caractriser ltat de lhte. dpendances et hritages. etc.
Ces objets peuvent tre dfinis dans plusieurs fichiers de configuration :

directives cfg_file et cfg_dir du fichier nagios.cfg. Sous Debian, ces fichiers sont stocks dans le rpertoire /etc/nagios3/conf.d.
Fichier nagios.cfg : dclaration des sous-fichiers de configuration, des fichiers de logs, emplacement des caches et des fichiers temporaires, fichier de statut, ordonnancement Fichier resource.cfg : Exemples de variables globales : $USER1$=/usr/lib/nagios/plugins/ $USER2$=/usr/lib/nagios/plugins/eventhandlers Etant inaccessible depuis les CGI qui gnrent lIHM, ce fichier peut tre utilis pour stocker des informations sensibles de configuration, comme par exemple des informations relatives un compte utilisateur.
Fichier commands.cfg : Les alias seront ensuite utiliss pour dfinir les commandes compltes dans les fichiers hosts.cfg et services.cfg. Lors de linstallation du paquet nagios-plugins, un fichier dexemple complet de commands.cfg est disponible : /usr/share/doc/nagios-plugins/examples/command.cfg.gz. Fichier hosts.cfg : On utilisera gnralement le ping pour caractriser ltat de lhte.
33
34

Les services (services.cfg) :
ce fichier associe chaque hte lensemble des services ou paramtres qui doivent tre vrifis : attributs de lhte (charge CPU, espace disque, etc.). services fournis par lhte (HTTP, POP3, FTP, SSH, etc.).
Les contacts (contacts.cfg) :

dclaration des contacts prvenir en cas dincident. dfinition des paramtres dalertes :
vnements dclencheurs (htes et services). frquences des notifications.
Les groupes de services (servicegroups.cfg) :

regroupe plusieurs services dans un mme groupe pour simplifier la configuration et optimiser laffichage.
moyens pour contacter ces personnes.

ex : messagerie, tlphone mobile, messagerie instantane.
plages horaires denvoi des alertes.
Les groupes dhtes (hostgroups.cfg) :

dfinit des groupes pour regrouper des htes selon des caractristiques communes. associe chaque groupe un alias. un hte doit obligatoirement appartenir un groupe. un hte peut appartenir plusieurs groupes.
Les groupes de contacts (contactgroups.cfg) :

rassemblement des contacts au sein dun groupe pour simplifier ladministration.
Fichier services.cfg : On dfinit lensemble des services qui devront tre tests en plus du service principal dfini dans hosts.cfg. Exemple : charge, nombre de processus dmarrs, tempratures de fonctionnements. Exemple de servicegroups : un groupe dbservices qui regroupe des services de vrification de la base SQL ou du dmon qui la gre. Fichier hostgroups.cfg : Le regroupement des hostgroups permet de simplifier, par exemple, la gestion des alertes. Si un hte appartient plusieurs groupes et quun problme intervient, Nagios avertit les contacts associs aux diffrents groupes de lquipement incrimin.
Fichier contacts.cfg : Exemple dvnement dclencheur : check_ping Fichier contactgroups.cfg : Il nest pas obligatoire quun contact appartienne un groupe.
35
36
Les dpendances (dependencies.cfg) : Les tranches horaires (timeperiods.cfg) :

ce fichier dfinit les tranches horaires applicables.
ex : heures ouvrables seulement, 24h/24 7j/7. ce fichier dfinit les dpendances entre services (sur le mme hte ou sur des htes diffrents). une dpendance se base sur ltat des autres services pour dclencher lexcution dun test ou lenvoi dune notification. elle permet ainsi de supprimer les notifications dun hte bas sur le statut dun ou plusieurs htes.
il est possible dexclure des priodes de temps. les tranches horaires sont utilises deux niveaux :
pour les vrifications de services. pour lenvoi de notifications.
Les escalades (escalations.cfg) :

dfinit lescalade des avertissements et alertes pour un hte ou un service donn. rpartit ces notifications entre les diffrents groupes dintervenants.
Fichier dependies.cfg : Exemple : on va crer une dpendance entre un quipement rseau et les serveurs qui sont placs derrire lui. Si lquipement est inaccessible, les serveurs ne le seront pas galement. Aussi, il est inutile de recevoir autant de notifications dalerte que dhtes prsents. La dpendance des services peut permettre damliorer les performances de Nagios. Ainsi, lorsque lon surveille plusieurs services, il nest pas toujours utile de les monitorer tous. Par exemple, si la vrification testant la connectivit naboutit pas (ping), alors il est inutile de vrifier les autres services, comme lespace disque ou la charge CPU, car la machine est injoignable. Fichier escalations.cfg : Nagios fait la distinction entre les alertes en tat soft et celles en tat hard . Ds quun service remonte une erreur, celle-ci est dabord dfinie dans un tat soft et Nagios met ses alertes sonores habituelles. Si aprs un certain nombre dessais infructueux, configurable, le service renvoie toujours le mme type derreur, lalerte passe alors en tat hard et Nagios envoie ses notifications. Ltat hard dfinit donc une alerte reconnue par Nagios comme posant rellement problme. define serviceescalation{ host_name service_description contact_groups first_notification last_notification notification_interval } define serviceescalation{ host_name service_description contact_groups first_notification last_notification notification_interval }
hermes_-_Serveur_Mail Serveur_POP Admin_par_mail 1 3 5
hermes_-_Serveur_Mail Serveur_POP Admin_par_SMS 2 3 5
37
38
Un premier bilan
Nagios offre la possibilit de dfinir :

des alias de commandes, des htes et groupes dhtes, des services et groupes de services, des dpendances entres ces htes, des contacts prcis ou des groupes de personnes, des politiques compltes dalertes.
Loutil est trs puissant, mais la configuration semble fastidieuse .
Les patrons de configuration
Si loutil savre sans aucun doute trs bien structur et trs puissant, il apparat clairement que sa configuration va savrer trs rapidement fastidieuse. En effet, malgr les divers mcanismes proposs (variables globales = macros, dfinition de groupes dhtes ou de personnes), pour toute configuration dun nouvel quipement ou dun nouveau service, il sera impratif dintervenir systmatiquement sur plusieurs fichiers.
39
40
Les patrons de configuration (1)

Dfinition de comportements unitaires rutilisables :
viter de dupliquer manuellement les mmes paramtres pour des services identiques. simplifier la lecture : seule linformation pertinente est visible la dfinition du service. faciliter la maintenance et les mises jour des services.

Un exemple pour un service :
define service{ name register active_checks_enabled passive_checks_enabled parallelize_check check_freshness notifications_enabled event_handler_enabled flap_detection_enabled retain_status_information retain_nonstatus_information notification_interval notification_period notification_options max_check_attempts is_volatile normal_check_interval retry_check_interval check_period contact_groups } generic-service 0 1 1 1 0 1 1 0 1 1 120 24x7 w,c,u,r 3 0 3 1 24x7 sysadmin
Hritage des paramtres dun autre patron. Utilisation des paramtres dun service classique lexception du champ register :
Il est positionn 0 car ce nest pas un vrai service.
define someobjecttype{ object-specific variables ... name template_name use name_of_template_to_use register [0/1] }
Les patrons de configuration : Comme tous les services doivent tre explicitement dfinis, autant rduire leurs dfinitions leur plus simple expression. Il en est de mme pour tous les serveurs. Si lon a une vingtaine de serveurs Linux, une dizaine de serveurs Windows et une trentaine dquipements rseau des mmes constructeurs, avec des contraintes identiques, alors il est inutile de dupliquer manuellement les mmes paramtres pour tout le monde. Cela simplifie la lecture et facilite la maintenance ou les mises jour si lon doit modifier manuellement les plages horaires dune cinquantaine de services sur plusieurs serveurs diffrents. Grce aux patrons, il suffit de modifier le patron des services de chaque serveur.
normal_check_interval : intervalle de temps entre deux vrifications du service par Nagios. Notification_options : o = OK w = WARNING c = CRITICAL u = UNKNOWN r = RECOVERY max_check_attempts : si le module renvoie un tat diffrent de OK, une alerte en tat soft est leve. Nagios vrifiera autant de fois que la directive max_checks_attempts lui indique, et ce avec un intervalle de temps entre deux vrifications spcifi par retry_check_interval. Si aprs un intervalle de temps dont la dure est indique en minutes par notification_interval le problme nest toujours pas rgl, Nagios enverra une nouvelle notification et continuera ainsi jusqu ce que le problme soit rsolu ou acquitt. Cest dans de tels cas quil est intressant de mettre en place un systme descalade des notifications.
41
42

Les hritages multiples :
Un exemple dhritage multiple :

define service{ name register use hostname }
Si les mmes variables sont dfinies dans plusieurs sources, Nagios utilise le paramtre de la premire source appele.
define host{ use 1, 4, 8 host_name serveur_web_1 ... }
switchHP-service 0 generic-service hp4108
define service{ use register service_description check_command }
switchHP-service 1 Ping check_ping!200,50%!400,80%
Nous verrons ultrieurement la syntaxe des modules dorigine de Nagios.
http://nagios.sourceforge.net/docs/3_0/objectinheritance.html
43
44
Configuration dune escalade Un exemple :
define serviceescalation{ host_name service_description first_notification last_notification notification_interval contact_groups } define serviceescalation{ host_name service_description first_notification last_notification notification_interval contact_groups }
hp4108 Ping 3 5 90 sysadmin, managers
hp4108 Ping 6 0 60 everybody
Un exemple de configuration
Dans le patron associ au service Ping, nous avions dfini les paramtres suivants : -les notifications sont envoyes toutes les deux heures (120 minutes), -elles sont adresses au groupe de contacts sysadmin. Grce la premire escalade que lon vient de configurer, si le problme est toujours prsent la troisime notification, celles-ci seront dsormais envoyes aux groupes sysadmin et managers toutes les 90 minutes. Enfin, lorsquon atteint un total de 6 notifications depuis le dpart, la seconde escalade intervient. Nagios alertera dsormais les personnes du groupes everybody. Celles-ci recevront lalerte toutes les 60 minutes et de manire indfinie (valeur 0 dans le champ last_notification). NB : La premire escalade a pris fin avec la cinquime notification. Dans tous les cas, toutes les personnes qui ont reu la notification de lincident seront informes du retour la normale du service. NB : si le champ notification_interval vaut 0, cela signifie quune seule notification sera envoye en cas de problme.
45
46
Retour linstallation sur Debian (1)
Retour linstallation sur Debian (2)
Un hte gw a t cr lors de linstallation de Nagios :

il correspond la passerelle dfinie dans les paramtres rseau.
Nous allons le renommer :

modification du fichier /etc/nagios3/hosts.cfg. mais pas seulement test de la cohrence de la configuration :
laika:~# /usr/sbin/nagios3 v /etc/nagios3/nagios.cfg
Il faut modifier au final 4 fichiers.
Modification du fichier /etc/nagios/hosts.cfg. Test de la cohrence de la configuration : /usr/bin/nagios v /etc/nagios/nagios.cfg Erreur car ne trouve plus dhte appel gw depuis le fichier /etc/nagios/hostgroups.cfg. Modification de hostgroups.cfg en consquence puis nouvelle vrification : Nouvelle erreur dans /etc/nagios/services.cfg. On corrige nouveau ce fichier. On reteste. Encore un souci : cette fois dans le fichier escalation.cfg. Une dernire modification et on relance ENFIN le serveur.
Nous avons d modifier 4 fichiers pour renommer lquipement gw et lappeler dsormais summit_5i .
47
48
Dclaration dun hte (1) Fichier hosts.cfg :

# dfinition dun hte define host{ host_name alias address max_check_attempts notification_interval notification_period notification_options notifications_enabled }
Dclaration dun hte (2) Fichier hosts.cfg :

define host{ name alias check_command max_check_attempts checks_enabled event_handler_enabled process_perf_data retain_status_information retain_nonstatus_information notification_interval notification_period notification_options notifications_enabled register } Template_Switches_HP Modeles HP ProCurve check_host_alive 5 1 0 1 1 1 120 24x7 d,u,r 1 0
Switch_Batiment_N sw-batn.ibsm.glm 10.234.244.11 5 120 24x7 d,u,r 1
# dfinition dun hte en utilisant un modle define host{ use host_name alias address }
Template_Switches_HP Switch_Bibliotheque sw-biblio.ibsm.glm 10.234.244.10
Une dfinition dhte sapplique un serveur physique , une station de travail, un priphrique (onduleurs, imprimantes) ou un quipement rseau. Dans le premier cas, on dclare un commutateur sans utiliser de patron/modle. host_name = nom identifiant lhte qui sera utilis dans les dfinitions de groupes dhtes et les dfinitions de services. Utilise dans le bon contexte, la macro $HOSTNAME$ contient ce nom court . alias = nom long permettant didentifier lhte plus facilement. Utilise dans le bon contexte, la macro $HOSTALIAS$ contient cette description. max_check_attempts = si le module renvoie un tat diffrent de OK, une alerte en tat soft est leve. Nagios vrifiera autant de fois que la directive max_checks_attempts lui indique, et ce avec un intervalle de temps entre deux vrifications spcifi par retry_check_interval (option absente dans cet exemple). Si aprs un intervalle de temps dont la dure est indique en minutes par notification_interval le problme nest toujours pas rgl, Nagios enverra une nouvelle notification et continuera ainsi jusqu ce que le problme soit rsolu ou acquitt. Notification_interval vaut 60 mn par dfaut. Si la valeur est positionne 0 alors il y aura UNE SEULE notification. notification_options : d= DOWN, u = UNKNOWN, r = RECOVERY Dans le second cas, nous utilisons un modle qui va dfinir des paramtres communs que lon appliquera tous nos commutateurs.
Tous les htes utilisant ce patron/modle auront, entre autres, la commande check_host_alive comme service de base. Elle permet de savoir si un hte est accessible.
49
50
Dclaration dun groupe dhtes Fichier hostgroups.cfg :
Dclaration dun service

Fichier services.cfg :
define service{ use STemplate_G_Ping service_description G_Ping host_name Switch_Batiment_N check_command check_graph_ping!382 contact_groups Admin_par_SMS, Admin_par_mail } define service{ name STemplate_G_Ping service_description STemplate_G_Ping is_volatile 0 check_command check_graph_ping max_check_attempts 5 normal_check_interval 3 retry_check_interval 1 active_checks_enabled 1 passive_checks_enabled 1 check_period 24x7 event_handler_enabled 0 flap_detection_enabled 0 process_perf_data 1 retain_status_information 1 retain_nonstatus_information 1 notification_interval 120 notification_period 24x7 notification_options w,u,c,r notifications_enabled 1 contact_groups Admin_par_mail register 0 }
define hostgroup{ hostgroup_name alias contact_groups members }
Switches Switches Admin_par_SMS, Admin_par_mail Switch_Batiment_N, Switch_Biblio
On associe un hte un groupe afin davoir un comportement commun et des ractions similaires.
On vient de crer un hte. On lui associe maintenant des services. Chaque service servira surveiller un point particulier de lhte : service logiciel, capteur matriel. Dans le cas prsent, on dclare un service pour notre commutateur rseau. Ce service utilise lui-mme un modle/patron/template. Nous identifions la commande qui doit tre utilise pour assurer cette vrification. Bien entendu, elle doit tre dclare dans le fichier checkcommands.cfg. define command{ command_name command_line } Avec $USER1$ = /usr/lib/nagios/plugins (fichier resource.cfg). Dans ce patron, on constate quon a dfini un groupe de contacts intitul Admin_par_mail . Il faut donc diter le fichier contactgroups.cfg pour le dclarer. check_graph_ping $USER1$/check_graph_ping.pl $HOSTADDRESS$ -g -S $ARG1$
51
52
Les tats de Nagios (1)
La situation dun service ou dun hte est dfinie par :

son statut (OK, WARNING, UP, DOWN, etc.) son tat : SOFT ou HARD
La notion dtat est indispensable la logique de supervision de Nagios :

dtermine quand les notifications sont mises. dclenche lexcution des gestionnaires dvnements.
Les tats selon Nagios

Etat UP DOWN
vite les fausses alertes.
Statut OK WARNING
Signification Service disponible Avertissement sur le service Erreur critique sur le service Etat inconnu
Code retour 0 1 2 3
Signification Hte disponible Hte indisponible
Code retour 0 1 ou 2
CRITICAL UNKNOWN
53
54
Les tats de Nagios : ltat SOFT (2)
Les tats de Nagios : ltat HARD (3)
Ltat SOFT correspond une vrification :

qui retourne un rsultat diffrent de OK ou de UP, mais na pas atteint le nombre maximum dessais spcifi par max_check_attempts.
Ltat HARD dun service correspond une vrification :

qui retourne toujours un rsultat diffrent de OK , alors que le service a t test le nombre maximum de fois spcifies par max_check_attempts. qui retourne un rsultat diffrent de OK tandis que lhte associ est DOWN ou UNREACHABLE . quand le service revient dun tat derreur critique.
Nagios nenvoie pas de notifications car le problme nest pas encore avr et srieux. Il positionne SOFT la valeurs de la macro associe lobjet concern :
macro $HOSTSTATETYPE$ pour un hte. macro $SERVICESTATETYPE$ pour un service.
Nagios :
enregistre dans ses logs ltat HARD. positionne la valeur HARD dans la macro $SERVICESTATETYPE$. dclenche un appel au gestionnaire dvnements. informe les contacts de lindisponibilit du service ou de son retour.
Ensuite, le gestionnaire dvnements est appel.

le script pourra adapter son comportement pour corriger le problme selon la valeur de la macro.
Grce cette diffrenciation entre tat SOFT et tat HARD, on va pouvoir viter de gnrer de fausses alertes. En tat soft , la seule chose vraiment marquante est la possibilit dexcuter un gestionnaire dvnements pour rsoudre de manire proactive un problme avant quil ne passe en tat hard . Les tats SOFT sont loggs seulement si les options log_service_retries et log_host_retries sont activs dans le fichier de configuration principal (/etc/nagios3/nagios.cfg).
Le dernier point est trs logique : si lhte est down , quoi bon tester nouveau le service ?
55
56
Ltat HARD dun hte correspond une vrification :

qui retourne toujours un rsultat diffrent de OK, alors que lhte a t test le nombre maximum dessais autoriss par max_check_attempts. quand lhte revient dun tat derreur critique.
Les changements dtats interviennent lors du :

passage dun tat OK stable un tat HARD diffrent de OK. passage dun tat HARD diffrent de OK un tat OK stable. changement de niveau dun tat HARD diffrent de OK. ex : WARNING -> UNKNOWN.
Time 0 Check 1 1 2 3 1 1 1 1 1 2 1 State OK CRITICAL WARNING CRITICAL WARNING WARNING OK OK UNKNOWN OK OK State Type HARD SOFT SOFT HARD HARD HARD HARD HARD SOFT SOFT HARD State Change No Yes* Yes* Yes* Yes No Yes* No Yes* Yes* No
Nagios :
enregistre dans ses logs ltat HARD. positionne la valeur HARD dans la macro $HOSTSTATETYPE$. dclenche un appel au gestionnaire dvnements. informe les contacts de lindisponibilit du service ou de son retour. si ltat HARD perdure, Nagios continue envoyer les notifications dalerte aux contacts identifis.
1 2 3 4 5 6 7 8 9 10
Pour le tableau ci-dessus, nous considrons que le service concern possde un max_check_attempts qui vaut 3 (nombre dessais conscutifs maximum avant de notifier le dysfonctionnement). 0. Initial state of the service 1. First detection of a non-OK state. Event handlers execute. 2. Service continues to be in a non-OK state. Event handlers execute. 3. Max check attempts has been reached, so service goes into a HARD state. Event handlers execute and a problem notification is sent out. Check # is reset to 1 immediately after this happens. 4. Service changes to a HARD WARNING state. Event handlers execute and a problem notification is sent out. 5. Service stabilizes in a HARD problem state. Depending on what the notification interval for the service is, another notification might be sent out. 6. Service experiences a HARD recovery. Event handlers execute and a recovery notification is sent out. 7. Service is still OK. 8. Service is detected as changing to a SOFT non-OK state. Event handlers execute. 9. Service experiences a SOFT recovery. Event handlers execute, but notification are not sent, as this wasn't a "real" problem. State type is set HARD and check # is reset to 1 immediately after this happens. 10. Service stabilizes in an OK state.
57
58
Lors dun retour depuis ltat HARD, Nagios :

enregistre le retour ltat normal du service ou de lhte dans le fichier de logs. appelle le gestionnaire dvnements. informe les contacts que la situation est de nouveau normale.
Les gestionnaires dvnements
59
60
Les gestionnaires dvnements (1)
Excution optionnelle de commandes lorsque un hte ou un service changent dtat. Paramtrage de ractions automatises :
corriger un dysfonctionnement ds son apparition, avant toute notification. enregistrer les traces de fonctionnement dun service ou dun hte dans une base de donnes externe.
Les commandes sont excutes par le gestionnaire dvnements lorsquun hte ou un service :
est dans un tat derreur SOFT. entre dans ltat derreur HARD. revient dun tat SOFT ou HARD.
Elles sont dfinies par des scripts qui prennent en entre les macros suivantes :
pour les services :
$SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$
Deux types de gestionnaires dvnements :

locaux, associs un service ou un hte et dclars dans leur dfinition. globaux (prioritaires), appels lors du changement dtat de nimporte quel hte ou service.
pour les htes :

$HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$
Lutilisation des gestionnaires dvnements est optionnelle. Ces gestionnaires dvnements peuvent tre considrs comme locaux lorsquils sont crs dans la dfinition mme des services et des htes. Si un gestionnaire dvnement est dfini pour un service ou pour un hte, il sera excut lorsque cet objet changera dtat. Les gestionnaires globaux, dfinis dans le fichier de configuration principal (/etc/nagios3/nagios.cfg), sont prioritaires par rapport aux gestionnaires dvnements locaux. Ils sont dfinis laide des primitives global_host_event_handler et global_service_event_handler. Les gestionnaires locaux, sils existent, sont excuts immdiatement aprs les gestionnaires dvnements globaux.
Dans la plupart des cas, nous utiliserons des scripts Perl ou bash pour implmenter ces commandes. Il est possible dappeler des excutables. tat soft : lhte ou le service sont dans un tat non-UP ou non-OK , mais Nagios est configur pour tester plusieurs reprises cet lment (max_check_attempt) avant de ragir cette anomalie et de passer en tat hard. $SERVICESTATE$ : une chane de caractres indiquant ltat du service. $SERVICESTATETYPE$ : une chane indiquant ltat du service (SOFT ou HARD). $SERVICEATTEMPT$ = nombre dessais effectus sur le service.
61
62

Exemple:
Les commandes sexcutent avec les mmes privilges que ceux du serveur Nagios. Si un script redmarre un service, il devra sexcuter avec les droits root. On utilise sudo pour attribuer lutilisateur nagios les droits ncessaires lexcution des commandes systme requises. Lors du tests de ces commandes, activez dans le fichier nagios.cfg les options de logs :
log_service_retries, log_host_retries, log_event_handler
# Dclaration du gestionnaire dvnement dans la dfinition # du service define service { host_name somehost service_description HTTP 4 max_check_attempts event_handler restart-httpd ...diffrentes variables ... } # Dfinition de la commande associe au gestionnaire define command{ command_name restart-httpd command_line /usr/share/nagios/plugins/eventhandlers/ restart-httpd $SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$ }
()
log_service_retries : Cette variable dtermine si un nouvel essai pour tester la disponibilit dun service doit tre logg. Typiquement, cela se produit quand une premire vrification a abouti un tat diffrent de OK et que nous avons configur Nagios pour quil essaye nouveau avant daffirmer quil sagit dune erreur. Les services dans cette situation sont considr comme tat dans ltat SOFT.
0 = ne pas logger l = logger
Dans cet exemple, nous souhaitons superviser un serveur HTTP et nous avons ajouter un gestionnaire dvnements que lon nomme restart-httpd. Nous avons fix le nombre de vrifications sur le service 4 en cas de retour dune valeur diffrente dOK. Ceci vite de dclencher une fausse alerte. Ainsi, le service sera test 4 fois avant de considrer quil y a rellement un problme et de passer en tat HARD . Lors du passage ltat HARD, le gestionnaire dvnement sera appel. Nous avons dclar la commande qui sera appele par le gestionnaire. Il nous reste crire le script associ.
log_host_retries : Cette variable dtermine si un nouvel essai pour tester la disponibilit dun hte doit tre logg.
0 = ne pas logger 1 = logger
log_event_handler : Cette variable dtermine si lintervention des gestionnaires dvnements sur un service ou sur un hte doit tre enregistre.
0 = ne pas logger. 1 = logger
63
64

case "$2" in # We're in a "soft" state, meaning that Nagios is in the middle of retrying the # check before it turns into a "hard" state and contacts get notified... SOFT) # What check attempt are we on? We don't want to restart the web server on the first # check, because it may just be a fluke! case "$3" in # Wait until the check has been tried 3 times before restarting the web server. # If the check fails on the 4th time (after we restart the web server), the state # type will turn to "hard" and contacts will be notified of the problem. # Hopefully this will restart the web server successfully, so the 4th check will # result in a "soft" recovery. If that happens no one gets notified because we # fixed the problem! 3) echo -n "Restarting HTTP service (3rd soft critical state)..." # Call the init script to restart the HTTPD server /etc/init.d/apache2 restart ;; esac ;; # The HTTP service somehow managed to turn into a hard error without getting fixed. # It should have been restarted by the code above, but for some reason it didn't. # Let's give it one last try, shall we? # Note: Contacts have already been notified of a problem with the service at this # point (unless you disabled notifications for this service) HARD) echo -n "Restarting HTTP service..." # Call the init script to restart the HTTPD server /etc/init.d/apache2 restart ;; esac ;; esac exit 0
#!/bin/sh # usage : restart-httpd $SERVICESTATE$ $STATETYPE$ $SERVICEATTEMPT$ # Note: This script will only restart the web server if the service is # retried 3 times (in a "soft" state) or if the web service somehow # manages to fall into a "hard" error state. # What state is the HTTP service in? case "$1" in OK) # The service just came back up, so don't do anything... ;; WARNING) # We don't really care about warning states, since the service is probably still running... ;; UNKNOWN) # We don't know what might be causing an unknown error, so don't do anything... ;; CRITICAL) # The HTTP service appears to have a problem - perhaps we should restart the server... # Is this a "soft" or a "hard" state? case "$2" in # We're in a "soft" state, meaning that Nagios is in the middle of retrying the # check before it turns into a "hard" state and contacts get notified... SOFT)
()
Ce script va essayer de relancer le serveur Apache dans deux cas : -lorsquon ressaye de contacter le service pour la troisime fois alors quon na pas pu le joindre une premire fois (tat SOFT), -lorsque le service passe en tat HARD pour la premire fois. Dans les faits, ltat HARD ne devrait pas se produire car le script a t crit pour relancer le service au bout de la troisime tentative, alors quil est encore en tat SOFT. Nanmoins, on gre ltat HARD au cas o. Une prcision importante : le gestionnaire dvnements sera excut seulement lorsque le service passe dans ltat HARD . Cela vite dexcuter en permanence le script lorsque le serveur Apache est en tat HARD .
65
66
Gestion des dpendances entre services (1)
Les possibilits offertes :

un service peut dpendre dun ou plusieurs services. un service peut dpendre de services qui ne sont pas associs au mme hte. les dpendances de services ne sont pas hrites. suppression des vrifications et des notifications en fonction de ltat dautres services. (OK, WARNING, UNKNOWN, CRITICAL)
Les dpendances selon Nagios
Les dpendances entre services sont contrles avant de lancer une vrification ou une notification.
Voyons maintenant une autre fonction avance de Nagios : la gestion des dpendances, soit pour les services, soit pour les htes. Cette fonctionnalit permet de supprimer des notifications et des contrles actifs en fonction de ltat dun ou plusieurs services.
67
68
Exemples :
la dpendance entre les services E et B :
Si B est en tat WARNING ou UNKNOWN, la vrification du service E nest pas applique. Si B est en tat CRITICAL, la dpendance est en erreur et les notifications pour le service E ne seront pas envoyes.
la dpendance entre les services F et D :

Si D est en tat OK, la vrification du service F nest pas applique. Si D est en tat WARNING ou UNKNOWN, la dpendance est en erreur et les notifications pour le service F ne seront pas envoyes.
Hritage des dpendances : Comme je lai dit prcdemment, les dpendances entre les services ne sont pas hrites par dfaut. Ainsi, dans cet exemple, on constate que le service F dpend du service E. Cependant, il nhrite pas automatiquement de la dpendance du service E vis--vis des services B et C. Si lon veut que F dpende de C, alors il nous faudra dclarer explicitement une dpendance laide de la directive inherits_parent. De mme, le service F na aucune dpendance vis--vis du service B, et nous avons certainement de bonnes raisons pour quil en soit ainsi.
69
70
Gestion des dpendances entre services (4) Exemples :

define servicedependency{ host_name service_description dependent_host_name dependent_service_description execution_failure_criteria notification_failure_criteria } define servicedependency{ host_name service_description dependent_host_name dependent_service_description execution_failure_criteria notification_failure_criteria }
Gestion des dpendances entre htes (1)
Les caractristiques :
host B Service D Host C Service F o n
mme principe de fonctionnement que celui des services :

un hte peut dpendre de plusieurs htes. les dpendances entre htes ne sont pas hrites par dfaut. elles permettent de dsactiver les vrifications et les notifications en fonction des circonstances. (UP, DOWN, UNREACHABLE). elles peuvent tre limites certaines priodes.
host B Service E Host C Service F n w,u,c
Les dpendances entre htes ne doivent pas tre confondues avec les relations parent/enfant.
(directive parents dans la dclaration dun hte)
dependent_host_name : nom de lhte sur lequel tourne le service dpendant dun autre. dependent_service_description : description du service dpendant execution_failure_criteria : situation(s) pour lesquelles le service dpendant ne doit pas tre excut. Les valeurs valides sont les combinaisons de un ou plusieurs des tats suivants : o (OK), w (WARNING), u (UNKNOWN), c (CRITICAL) (les options multiples sont spares par des virgules). Si on spcifie n (NONE) comme option, la dpendance dexcution nchouera jamais et le contrle du service dpendant aura toujours lieu. notification_failure_criteria : situations pour lesquelles les notifications du service dpendant ne sont pas envoyes. Si on spcifie n (NONE) comme option, alors les notifications pour le service indpendant sont toujours envoyes. Si on spcifie w (WARNING), alors les notifications ne sont pas envoyes si le service dont nous dpendons est dans ltat WARNING. BIEN ENTENDU, NAGIOS CONTINUERA A TESTER REGULIEREMENT LES CONDITIONS DE DEPENDANCES DEFINIES SELON LES ORDRES DE LORDONNANCEUR. QD LES CONDITIONS SERONT A NOUVEAU RESPECTEES, LES SERVICES SERONT EXECUTES OU LES NOTIFICATIONS ENVOYEES.
71
72
Gestion des dpendances entre htes (2)
Gestion des dpendances entre htes (3) Exemples :

define hostdependency{ host_name dependent_host_name notification_failure_criteria } define hostdependency{ host_name dependent_host_name notification_failure_criteria } host A Host C d
host B Host C d,u
Attention : il sagit dun diagramme de dpendances, et non pas dun schma illustrant lorganisation hirarchique dun rseau. Lhte A est dpendant de lhte C et de lhte B, pour autant il na pas hrit des dpendances entre lhte B et lhte C. Cest pour cette raison que nous avons d crer une dpendance directe entre lhte C et lhte A. Hritage des dpendances : De mme que pour les services, les dpendances entre les htes ne sont pas hrites par dfaut. Dans cet exemple, vous constatez que lhte C nhrite pas de lhte B. Pour que C soit dpendant de A, nous avons d crer une dpendance explicite entre eux.
dependent_host_name : nom de lhte dpendant de lun de ses pairs. notification_failure_criteria : situations pour lesquelles les notifications concernant lhte dpendant ne sont pas envoyes. BIEN ENTENDU, NAGIOS CONTINUERA A TESTER REGULIEREMENT LES CONDITIONS DE DEPENDANCES DEFINIES. QD LES CONDITIONS SERONT A NOUVEAU RESPECTEES, LES NOTIFICATIONS SERONT ENVOYEES.
73
74
Prsentation de NRPE
NRPE : Nagios Remote Plugin Executor. NRPE est un module Nagios qui permet dexcuter des sondes/plugins sur des serveurs distants. Il sinstalle sur les serveurs dont lon souhaite surveiller les ressources locales. Il est appel depuis le serveur Nagios via la commande check_nrpe.
Les dmons NRPE (Linux, Windows)
Les communications sont chiffres.
Il serait possible dinvoquer la commande check_by_ssh pour excuter des commandes sur le serveur distant. Cependant, elle consomme plus de puissance de traitement au niveau de la machine hbergeant le serveur Nagios (cls partages entre le client et le serveur distant).
75
76
Intgration de NRPE au serveur Nagios (1)
Utilisation de NRPE sur Linux (1)

Installation du dmon NRPE sur lhte distant :
Installer le module NRPE sur le serveur :

laika:~# apt-get install nagios-nrpe-plugin
tornado:~# apt-get install nagios-nrpe-server => Installation de 19 paquets complmentaires dont nagios-plugins.
ajoute le module check_nrpe dans le rpertoire des plugins Nagios. dclare la commande dans le fichier /etc/nagios/checkcommands.cfg.
Edition des fichiers de configuration :

/etc/nagios/nrpe.cfg : fichier principal. /etc/nagios/nrpe_local.cfg : configuration spcifique.
Redmarrer le serveur Nagios. Configurer les vrifications sur les postes distants dans le fichier de configuration des services. Redmarrage du dmon NRPE :
tornado:~# /etc/init.d/nagios-nrpe-server restart Stopping nagios-nrpe: nagios-nrpe. Starting nagios-nrpe: nagios-nrpe.
Nous avons vu prcdemment que NRPE est utilis pour permettre au serveur Nagios lexcution, sur une machine distante, dun module install sur cette dernire pour connatre, par exemple, le taux doccupation des disques durs, sa charge CPU ou encore la temprature du systme. On utilise le module NRPE qui doit tre install sur le serveur. Il envoie les requtes lagent NRPE install sur la machine distante, lequel se base sur le fichier nrpe.cfg pour savoir ce quil est habilit faire. Lagent NRPE : -reoit la demande de vrification du serveur. -excute cette vrification. -retourne le rsultat. define service { () check_command check_nrpe -c nt_antivirus }
Nous avons vu que pour effectuer des tests simples comme le ping, il nest pas ncessaire de dployer quoi que ce soit sur les htes distants (hormis bien entendu les fonctionnalits rseau). En revanche, pour conduire des tests plus complexes, il est ncessaire dinstaller un agent sur les htes distants. Nous avons vu que nous avons le choix NRPE et NSCA. Personnellement, en considrant mes besoins, jai fait le choix dutiliser NRPE. Comme je vous lai expliqu, le dmon NRPE va servir de relais au serveur Nagios pour excuter une vrification locale sur la machine distante. En fait, le serveur Nagios envoie des requtes au dmon NRPE qui effectue alors localement les requtes et renvoie leur rsultat au serveur Nagios.
77
78

Edition du fichier de configuration :
server_port=5666 allowed_hosts=10.234.244.205 nrpe_user=nagios nrpe_group=nagios dont_blame_nrpe=1 debug=0 command_timeout=60 command[check_users]=/usr/lib/nagios/plugins/check_users -w $ARG1$ -c $ARG2$ command[check_load]=/usr/lib/nagios/plugins/check_load -w $ARG1$ -c $ARG2$ command[check_disk]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ command[check_procs]=/usr/lib/nagios/plugins/check_procs -w $ARG1$ -c $ARG2$ -s $ARG3$ command[service_restart]=/usr/lib/nagios/plugins/service_restart $ARG1$ command[service_stop]=/usr/lib/nagios/plugins/service_stop $ARG1$ command[service_start]=/usr/lib/nagios/plugins/service_start $ARG1$ command[check_cpu_temp]=/usr/lib/nagios/plugins/check_cpu_temp command[check_cm_temp]=/usr/lib/nagios/plugins/check_cm_temp command[check_fan]=/usr/lib/nagios/plugins/check_fan command[check_vcore]=/usr/lib/nagios/plugins/check_vcore command[shutdown]=sudo /sbin/shutdown -h now command[reboot]=sudo /sbin/shutdown -r now command[chkrootkit]=sudo /usr/sbin/chkrootkit prout command[check_debian]=/usr/lib/nagios/plugins/check_debian command[check_fan]=/usr/lib/nagios/plugins/check_fan -w $ARG1$ -c $ARG2$

Test de la commande sur lhte distant :
tornado:~# /usr/lib/nagios/plugins/check_fan w 500:1000 c 0:500 t fan1 Ventilateur CPU OK - fan1: 2503 RPM
Test de la commande depuis le serveur Nagios :

Syntaxe de check_nrpe :
check_nrpe -H <host> [-n] [-u] [-p <port>] [-t <timeout>] [-c <command>] [-a <arglist...>] -n = Do no use SSL -u = Make socket timeouts return an UNKNOWN state instead of CRITICAL <host> = The address of the host running the NRPE daemon [port] = The port on which the daemon is running (default=5666) [timeout] = Number of seconds before connection times out (default=10) [command] = The name of the command that the remote daemon should run [arglist] = Optional arguments that should be passed to the command. Multiple arguments should be separated by a space. If provided, this must be the last option supplied on the command line. -l,--license Print licensing information. -n,--no-ssl Do not initial an ssl handshake with the server, talk in plaintext.
Appel de la commande.
laika:~# /usr/lib/nagios/plugins/check_nrpe -H 10.234.244.201 -c check_fan -a 500:1000 0:500 fan1 Ventilateur CPU OK - fan1: 2518 RPM
Redmarrage du service.
server_port : port sur lequel le serveur NRPE est en coute. allowed_hosts : Liste des serveurs Nagios autoriss interroger le dmon NRPE. dont_blame_nrpe : gestion des arguments des commandes 0 = naccepte pas les arguments. 1 = accepte les arguments spcifis par les clients. Cette option indique si le service NRPE doit accepter les arguments spcifis par les clients pour les commandes qui lui sont transmises. Cela nest pas sans implication au niveau de la scurit. Par consquent, il est conseill de fixer la valeur de cette option 0. Ainsi, NRPE utilisera seulement les paramtres des commandes dfinis dans son fichier de configuration. Cependant, si lon souhaite pouvoir utiliser les commandes dfinies cidessus avec des arguments, il faut absolument fixer la valeur 1. command_timeout : indique le nombre de secondes donnes une commande par le service NRPE pour que celle-ci sexcute. Au-del, le processus est tu. Dans ce fichier de configuration, nous avons non seulement la liste des modules/plugins fournis de base lors de linstallation du client NRPE mais aussi les scripts que nous avons-nous-mme ajouts. Par exemple, nous avons cr des scripts pour superviser le processeur de nos serveurs, pour relancer la machine ou larrter. Nous avons galement ajout un module pour effectuer une dtection de rootkit. Enfin, pour simplifier ladministration et le dploiement de nouveaux modules sur nos
Nous avons vu que pour effectuer des tests simples comme le ping, il nest pas ncessaire de dployer quoi que ce soit sur les htes distants (hormis bien entendu les fonctionnalits rseau). En revanche, pour conduire des tests plus complexes, il est ncessaire dinstaller un agent sur les htes distants. Nous avons vu que nous avons le choix NRPE et NSCA. Personnellement, en considrant mes besoins, jai fait le choix dutiliser NRPE. Comme je vous lai expliqu, le dmon NRPE va servir de relais au serveur Nagios pour excuter une vrification locale sur la machine distante. En fait, le serveur Nagios envoie des requtes au dmon NRPE qui effectue alors localement les requtes et renvoie leur rsultat au serveur Nagios. La politique de supervision du ventilateur est la suivante : -si le ventilateur tourne moins de 1000 tours par minute, le service passe en tat WARNING : nous supposons que laxe de rotation du ventilateur donne des signes de faiblesse. -si la vitesse du ventilateur est infrieure 500 tours par minute, le service sera dans un tat critique .
79
80
Utilisation de NRPE sur Windows (1)
Il existe plusieurs agents NRPE pour Windows :

NRPE-NT : http://www.miwi-dv.com/nrpent/ NSClient++ : http://nsclient.org/nscp/
Exemple : installation de lagent NRPE-NT sur lhte Windows distant :

tlcharger le fichier ladresse suivante : http://prdownloads.sourceforge.net/nrpent/nrpe_nt.0.8bin.zip?download. extraire le contenu de larchive dans le rpertoire C:\NRPE par exemple. se positionner dans C:\NRPE\bin. excuter la commande suivante pour installer le service NRPE:
C:\NRPE\bin>NRPE_NT.exe -i
Lagent agit tel un relais entre le serveur Nagios et lhte distant. Exemple : NSClient ++ Le serveur utilise la commande check_nt pour dialoguer avec le serveur.
Attention : NRPE-NT ne semble plus maintenu et il apparat que NSClient++ la supplant, dautant plus quil est capable de grer galement NSCA.
Aprs excution de la commande NRPE_NT.exe i, si vous consultez la liste des services de la machine, vous constaterez que le service Nagios Remote Plugin Executor for NT/W2K a t ajout. Pour consulter la liste des services depuis linvite de commandes : services.msc.
81
82

Edition du fichier de configuration : allowed_hosts=10.234.244.205, 193.50.234.4
dont_blame_nrpe=1 debug=0 command_timeout=60 server_port=5666
command[nt_antivirus]=C:\NRPE\Plugins\service_nrpe_nt.exe "Symantec AntiVirus" command[check_MSSQLServer]=C:\NRPE\Plugins\service_nrpe_nt.exe " MSSQLServer" command[nt_service]=C:\NRPE\Plugins\service_nrpe_nt.exe $ARG1$ command[nt_loadcpu]=C:\NRPE\Plugins\cpuload_nrpe_nt.exe $ARG1$ $ARG2$ command[nt_loadmem]=C:\NRPE\Plugins\memload_nrpe_nt.exe $ARG1$ $ARG2$ command[nt_diskspace]=C:\NRPE\Plugins\diskspace_nrpe_nt.exe $ARG1$ $ARG2$ $ARG3$ command[nt_eventlog]=C:\NRPE\Plugins\eventlog_nrpe_nt.exe -m 7200 -s "Service Control Manager"
Redmarrage du service. Depuis le serveur Nagios, lagent sera interrog via la commande check_nrpe :
laika:~# /usr/lib/nagios/plugins/check_nrpe -H 10.234.64.50 -c nt_diskspace -a C: 90 95 Used: 16107 MB (84%) Free: 2970 MB (15%)
Les modules/plugins Nagios
dont_blame_nrpe : gestion des arguments des commandes 0 = naccepte pas les arguments. 1 = accepte les arguments spcifis par les clients. Cette option indique si le service NRPE doit accepter les arguments spcifis par les clients pour les commandes qui lui sont transmises. Cela nest pas sans implication au niveau de la scurit. Par consquent, il est conseill de fixer la valeur de cette option 0. Ainsi, NRPE utilisera seulement les paramtres des commandes dfinis dans son fichier de configuration. Cependant, si lon souhaite pouvoir utiliser les commandes dfinies ci-dessus avec des arguments, il faut absolument fixer la valeur 1. Attention, si vous activez la fonction de dbogage (valeur 1), pensez contrler rgulirement la taille du fichier de logs gnr. command_timeout : indique le nombre de secondes donnes une commande par le service NRPE pour que celle-ci sexcute. Au-del, le processus est tu. Dfinition des commandes : On dfinit par exemple la commande nt_antivirus qui va tester sur le service du serveur antivirus est actif. Le module utilis teste ltat du service en se basant sur son nom. Il est donc essentiel de bien respecter lintitul du service et de mettre son nom entre guillemets dans lappel au module. La liste des services peut tre obtenue en tapant la commande services.msc depuis linvite de commandes. Pour redmarrer le service en ligne de commande : net start nrpe_nt
83
84
Utiliser les modules officiels (1)
Utiliser les modules officiels (2)
Les modules officiels Nagios sont disponibles sur SourceForge, projet nagios-plug.
http://sourceforge.net/projects/nagiosplug/
Emplacement des modules : /usr/lib/nagios/plugins Quelques exemples de modules :

check_dig, check_dns, check_http, check_imap, check_disk, check_swap, check_load, check_procs, check_sensors, check_ifstatus, check_log, check_ping, check_tcp, check_udp, check_nrpe, check_snmp, check_nt, check_by_ssh.
Nagios est fourni linstallation avec deux catgories de modules de base :

les modules principaux (maintenus). les modules contribus (pas forcment maintenus).
Dautres sources possibles de modules :

http://www.nagiosexchange.org/ http://www.manubulon.com/nagios/
check_dig = permet le test dun serveur DNS en utilisant Dig. check_dns = utilise nslookup pour le test dun serveur DNS. check_http = teste le service HTTP de lhte spcifi, mais aussi HTTPS. Peut galement suivre les redirections, rechercher des chanes de caractres et des expressions rgulires, vrifier le temps de connexion et renvoyer la dure dexpiration dun certificat. check_imap = teste les connexions IMAP avec lhte spcifi. check_disk = retourne le pourcentage dutilisation de lespace disque sur un systme de fichiers et met des alertes en fonction des valeurs retournes. check_swap = contrle le taux dutilisation de la mmoire swap. check_load = teste la charge moyenne du systme. check_procs = renvoie le nombre de processus lancs en local et le statut associ. check_sensors = vrifie le statut du matriel en utilisant le paquet lm_sensors. check_ifstatus = vrifie le statut de toutes les interfaces ( lexception de PPP) sur la machine cible. check_log = vrifie la prsence dune chane dans un fichier de logs. check_ping = utilise la commande ping pour vrifier la prsence sur le rseau dun hte distant. check_tcp = vrifie la connectivit sur un port donn pour un hte distant. check_udp = teste la disponibilit dun port UDP donn pour un hte distant. check_nrpe = permet lexcution dun autre module sur une machine distante. check_snmp = ce module rcupre des informations sur un systme distant par lintermdiaire de SNMP. check_by_ssh = permet lexcution dune commande sur un hte distant en utilisant ssh.
85
86
Ecrire son propre module
Exemple de cration dun module (1)
Lcriture dun module doit respecter trois rgles :

unicit du traitement effectu : une seule tche. lgret : ne pas affecter la charge de la machine. simplicit : renvoyer un code retour (tat) et un petit commentaire.
Dfinir le systme dexploitation en utilisant Nmap :

nmap -O $1>/usr/local/nagios/libexec/tmp OS=`cat /usr/local/nagios/libexec/tmp|grep "linux"|wc -l` if test "$OS" -ge 1; then $ECHO "OS=LINUX\n" exitstatus=$STATE_OK else OS=`cat /usr/local/nagios/libexec/tmp|grep "Windows"|wc -l` if test "$OS" -ge 1; then $ECHO "OS=WINDOWS\n" exitstatus=$STATE_OK else $ECHO "OS INCONNU\n" exitstatus=$STATE_OK fi fi rm /usr/local/nagios/libexec/tmp
Le choix du langage est libre : Perl, C, bash, etc. Exemple : dtecter le systme dexploitation de la machine teste avec Nmap ou SNMP.
On peut sinspirer des modules fournis de base avec Nagios:/usr/lib/nagios/plugins/.

nmap -O $1>/usr/local/nagios/libexec/tmp OS=`cat /usr/local/nagios/libexec/tmp|grep "linux"|wc -l` if test "$OS" -ge 1; then $ECHO "OS=LINUX\n" exitstatus=$STATE_OK else OS=`cat /usr/local/nagios/libexec/tmp|grep "Windows"|wc -l` if test "$OS" -ge 1; then $ECHO "OS=WINDOWS\n" exitstatus=$STATE_OK else $ECHO "OS INCONNU\n" exitstatus=$STATE_OK fi fi rm /usr/local/nagios/libexec/tmp
Ce script est inspir du module officiel check_sensors. nmap O IPaddress donne un certain nombre dinformations concernant la machine dont le type de systme dexploitation (0S). On fait un grep pour rechercher sil sagit dun Linux ou dun Windows. Si on le souhaitait, on pourrait essayer de dfinir la version de lOS ou de dtecter dautres OS. Pour lutiliser : > check_OS <adresse_IP> Cette mthode nest pas idale, car cette vrification va durer plusieurs secondes sur un Linux. Voyons maintenant ce quil en est avec SNMP (diapo suivante).
Script prsent sur la diapo suivante.
87
88
Exemple de cration dun module (2)
Dfinir le systme dexploitation en utilisant SNMP :

Nous dclarons la commande qui va effecteur une requte SNMP sur lOID pertinent :
define command{ command_name snmp_OS command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o system.sysDescr.0 -l OS }
Nous dclarons un service utilisant cette commande :

define service{ host_name service_description check_command use } diabolo OS_par_SNMP snmp_OS generic-service
Export des donnes
On cre cette commande dans le fichier checkcommands.cfg. La variable system.sysDescr.0 permet dobtenir le nom de lOS depuis la MIB. On peut imaginer de nombreux autres tests partir du mme modle. Ex : sysUpTime. La MIB tant tenue jour par lagent SNMP, lorsquon linterroge un moment donn, il y a forcment une valeur que lon peut rcuprer instantanment, contrairement la solution base sur Nmap.
89
90
Export des donnes

En complment des notifications, les donnes de supervision peuvent tre exportes. Deux mthodes possibles :
lexport en fichier plat :
emplacement : /var/cache/nagios3/status.dat le fichier est gnr rgulirement, toutes les 10 secondes. inconvnients : la taille du fichier et le temps de traitement (CPU) pour de grandes installations.
lexport en bases de donnes :

repose sur lutilisation de levent broker de Nagios. utilisation du module ndomod (paquet NDOUtils) qui exporte les donnes vers une base de donnes (MySQL ou PostgreSQL). avantages :
partage des donnes entre plusieurs Nagios ou dautres applications. meilleures performances lors de recherches.
CENTREON
NDO : Nagios Data Output.
91
92
Prsentation de Centreon
Architecture de Centreon
Centreon a vu le jour en 2003 sous le nom dOreon. Il sagit dune couche applicative qui se positionne audessus de Nagios. Elle intgre une interface multi-utilisateurs complte et intuitive :
gestion de la configuration Nagios. console de supervision avec ajout de fonctionnalits avances.
Centreon est divis en plusieurs composants :

CentreonWeb : linterface qui permet de configurer et de visualiser les objets de supervision. CentreonCore est le cur de la solution : il permet aux diffrents composants dinteragir. CentreonStorage est loutil de mtrologie : qui exploite les donnes envoyes par Nagios.
donnes exportes dans la base SQL. donnes de performances (service performance data). CentreonStorage est cod en PERL. les informations de mtrologie sont stockes dans deux bases :
les fichiers RRDTools pour conserver les donnes sur de grandes priodes. une base de donnes MySQL qui permet de regnrer les fichiers RRDTools en cas de problme.
Lapplication Web est code en langage PHP. Centreon est un projet franais bas sur la licence GPL v2 :
large communaut dutilisateurs. cration dune activit de services par les fondateurs du projet.
Pourquoi avoir choisi Centreon ? Centreon simplifie ladministration de Nagios grce la surcouche applicative quil apporte. Nous avons vu que la configuration de Nagios est clate sur une dizaine de fichiers de paramtrage diffrents. Centreon va nous apporter une interface multi-utilisateurs complte, intuitive et facilement volutive grce ladoption du langage PHP pour dvelopper lIHM. De plus, ce projet a beaucoup mri au fil des ans. Lquipe est plus structure et la socit sest dveloppe, offrant de nombreux services autour de ce produit. Une large communaut a adhr ce projet, ce qui permet de disposer de modules toujours plus nombreux et damliorer constamment le produit grce la dcouverte et la correction de bugs.
93
94
Les fonctionnalits de Centreon (1)

Interface de configuration des diffrents objets de Nagios :
modles, htes, services, contacts, notifications, etc. groupes, escalades, dpendances, etc. formulaires complets et intuitifs.
Les fonctionnalits de Centreon (2)

Politique de gestion des profils utilisateurs (droits, langues, accs aux ressources). Supervision en temps rel (dtection des pannes, disponibilit, prise en compte des pannes, etc.) Traitement des performances (graphiques, historique, export CSV/XML). Tableaux de bords (statistiques journalires, rapports selon les groupes). Modularit pour intgrer des modules supplmentaires :
CentreonSyslog, CentreonWeatherMap CentreonNTOP CentreonMap CentreonDisco etc.
Gestion graphique des fichiers de configuration et des plugins.

nagios.cfg et resource.cfg
Stockage des informations de configuration dans une base de donnes :

les fichiers de configuration de Nagios sont gnrs la demande. leur validit peut tre teste avant la mise en production.
Lensemble des fichiers de configuration de Nagios est accessible via linterface graphique. Les lments sont lis entre eux via des formulaires complets et intuitifs. Centreon gnre les fichiers de configuration de Nagios (/etc/nagios) partir des informations saisies dans linterface Web. Le stockage des informations de configuration se fait donc dans des fichiers textes. On rejoint ainsi la tendance initie par le projet Nagios lui-mme : abandonner les SGBD pour se limiter aux fichiers plats. Lapplication Centreon utilise, quant elle, un stockage dans des bases de donnes pour son fonctionnement interne (interface). Il est possible de faire interagir lensemble des donnes.
Gnration des graphes partir de RRD. => Supervision graphique des donnes, ce qui permet davoir un historique. Possibilit de comparer des graphes.
95
96
Installation de Centreon (1)
La dernire version stable est la 2.1.8. Larchive est disponible au format tar.gz :
http://www.centreon.com/Centreon/download.html
Un paquet de localisation en franais est disponible :

http://www.centreon.com/Centreon/language-packs.html
Linstallation se droule en plusieurs tapes.
Installation de Centreon
Au pralable, nous installons les pr-requis ncessaires au fonctionnement de Centreon.
97
98
Installation des pr-requis :

Pour permettre lutilisation des plugins graphiques :
RRDTOOL : systme de stockage et daffichage de donnes. librairie Net::SNMP : API Perl pour accder SNMP.
laika:~# apt-get install rrdtool libnet-snmp-perl
Pour faire fonctionner Centreon (suite) :

diffrentes librairies rseau, graphiques, de gestion des fichiers, etc. un dmon SNMP pour grer les requtes entrantes. PHP : interface Web et accs client /serveur. ()
laika:~# apt-get install php5 php5-mysql php-pear php5-snmp libapache2-mod-php5 php5-ldap libgd2-xpm libgd2-xpm-dev libpng3 libgd-gd2-perl libconfig-inifiles-perl libcrypt-des-perl libdigest-hmac-perl libdigest-sha-perl libio-socket-inet6-perl libnet-snmp-perl libsocket6-perl sudo snmpd
Pour faire fonctionner Centreon :

Apache : hbergement de lapplication Web. MySQL : bases de donnes. PHP : interface Web et accs client /serveur. sudo : pour lancer des traitements avec les droits requis. ()
On peut en profiter pour installer phpmyadmin pour simplifier de futures oprations dadministration. Par exemple, configurer le mot de passe administrateur. http://en.doc.centreon.com/Setup:Prerequisite/Debian/Ubuntu
libio-socket-inet6-perl - Object interface for AF_INET6 domain sockets libsocket6-perl - Perl extensions for IPv6
99
100
Aprs avoir dcompress larchive, nous lanons ensuite le script dinstallation :

laika:~# bash install.sh -i
Lorsque le script se termine, nous passons la partie graphique du processus dinstallation :

http://monserveur/centreon/
Il installe tour tour les diffrents composants de Centreon :

le Centreon Web Front. le Centreon CentCore. le Centreon Storage. les plugins Centreon pour Nagios. les processus de gestion des traps SNMP.
Les chemins proposs par dfaut sont relatifs une Fedora.
libio-socket-inet6-perl - Object interface for AF_INET6 domain sockets libsocket6-perl - Perl extensions for IPv6
Il faut sassurer que le serveur Apache est configur pour grer la sous-branche du site ddie Centreon : Alias /centreon /usr/local/centreon/www/ <Directory "/usr/local/centreon/www"> Options Indexes AllowOverride AuthConfig Options Order allow,deny Allow from all </Directory>
http://en.doc.centreon.com/Setup:Debian/Ubuntu
101
102

Linstallation termine, nous pouvons nous connecter Centreon.
Nous configurons et vrifions les diffrents paramtres de fonctionnement :

emplacement des diffrents composants et applications. paramtres daccs aux diffrentes bases de donnes. cration dun compte administrateur pour Centreon. peuplement des bases de donnes.
Nanmoins, de multiples retouches au niveau de la configuration peuvent simposer.
Il faut sassurer que le serveur Apache est configur pour grer la sous-branche du site ddie Centreon : Alias /centreon /usr/local/centreon/www/ <Directory "/usr/local/centreon/www"> Options Indexes AllowOverride AuthConfig Options Order allow,deny Allow from all </Directory>
103
104
DEMO CENTREON
FAN : Fully Automated Nagios
105
106
Prsentation de FAN
Prise en main de FAN
FAN est une image ISO base sur CentOS fournissant une installation complte de Nagios. Elle regroupe galement la plupart des outils recommands par la communaut des utilisateurs Nagios.
NagVis : module de reprsentation visuelle des informations retournes par Nagios. NaReTo : outil de reporting, organisation sous forme arborescente. NDOUtils : collecte des donnes Nagios pour les stocker dans une base de donnes. Centreon : surcouche applicative simplifiant ladministration et la consultation de Nagios.
Aprs linstallation de limage ISO sur une machine, les diffrents outils sont directement accessibles :
Nagios : Centreon : Nareto : Nagvis : http://serveur/nagios/ http://serveur/centreon/ http://serveur/nareto/ http://serveur/nagios/nagvis/
Ils sont prconfigurs.

ex : interface plus conviviale pour Nagios (Nuvola).
Son but : simplifier linstallation dun serveur Nagios.
107
108
FAN : pour et contre
Pour :
Les outils sont correctement intgrs et oprationnels aprs linstallation. Le gain de temps est loin dtre ngligeable. Il est possible de disposer rapidement dune solution de supervision oprationnelle.
Contre :
Les versions proposes ne sont pas les plus rcentes. Les dlais entre la sortie de deux versions peuvent sembler important.
Cration dun module SNMP
109
110
Prsentation du protocole SNMP (1)
SNMP signifie Simple Network Management Protocol. Il permet daccder, distance, en lecture et en criture la configuration dun matriel. Il transporte les informations entre un manager et lagent de lquipement. Lagent stocke ses donnes dans la MIB. La scurit dpend de la version de SNMP :
v1 & v2 : une requte contient un nom appel communaut utilis comme mot de passe. v3 : la scurit est fonde sur la notion dutilisateur (authentification + chiffrement).
Le protocole SNMP
SNMP (RFC 1157) : UDP port 161 Une requte SNMP contient un nom appel communaut, utilis comme un mot de passe. Il y a un nom de communaut diffrent pour obtenir les droits en lecture et pour obtenir les droits en criture. Dans bien des cas, les grosses lacunes de scurit que comportent les versions 1 et 2 de SNMP limitent l'utilisation de SNMP la lecture des informations. Le modle de scurit dcrit dans les v1 et v2 de SNMP apparat plus comme un modle de relations administratives entre managers et agents quun vritable schma de scurit. Les MIB sont dcrites en utilisant ASN.1. Par exemple, ifDescr est dcrite par : ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface. " ::= { ifEntry 2 } ASN.1 (Abstract Syntax Notation One) est un standard international destin l'origine dcrire les donnes changes dans les protocoles de tlcommunication (modle OSI).
111
112
Prsentation du protocole SNMP (2) La MIB : Management Information Base.

structure arborescente dont chaque nud est dfini par un OID (nombre) :
des informations standards dans une branche, une branche spcialement dfinie pour le stockage dinformations propritaires relatives la nature et aux fonctionnalits du systme administr.
La branche standard contient 11 sousbranches dont les principales sont :

system {mib2-1}, branche obligatoire, contient : des informations gnrales sur le systme (nom, localisation, contact). la description donne par le constructeur/diteur de la MIB (champ sysDescr). interface {mib-2 2} : fournit le nombre dinterfaces rseau du systme, dcrit pour chacune dentre elles des infos telles que ladresse physique, la vitesse, la MTU, le nombre de paquets mis ou reus,etc.
113
114
at {mib2- 3} : dfinit lensemble des informations permettant dtablir une correspondance entre une adresse physique et une adresse rseau, soit le cache ARP le plus souvent.
tcp et udp {mib2- 6}/{mib2-7} fournissent : la liste des connexions tablies. les adresses et ports en coute pour les deux protocoles de transport (quivaut la commande netstat an).
ip {mib-2 4} : contient la totalit des paramtres IP de chaque interface. dfinit une valeur permettant didentifier si le systme fait du routage. comporte des statistiques lies au volume de trafic et au nombre derreurs.
115
116
La branche propritaire :
Chaque diteur/constructeur dfinit sa MIB. La MIB est librement accessible donc on peut ltudier en dtails. Nous disposons doutils pour simplifier lexploration et la lecture des fichiers de MIB. Exemples :
pour Linux, la bibliothque libmsi et les programmes du projet Net-SNMP (snmpwalk, snmpget, etc.). pour Windows : Getif (Gratuit), OidView (Payant), SNScan (dcouverte des priphriques SNMP sur le rseau).
Ecriture dun module SNMP
Pour tlcharger Getif : http://www.wtcs.org/snmp4tpc/getif.htm Exemples : snmpwalk v 1 c public 10.234.160.9 snmpget v 1 -c public 10.234.160.9 mib-2.43.8.2.1.13.1.2 SNMPv2-SMI::mib-2.43.8.2.1.13.1.2 = STRING: "TRAY1" snmpwalk -v 1 -c public 10.234.128.4 1.3.6.1.4.1.11.2.14.11.1.2.6.1 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.1.1 = INTEGER: 1 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.2.1 = OID: SNMPv2SMI::enterprises.11.2.3.7.8.3.2 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.3.1 = INTEGER: 1 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.4.1 = INTEGER: 4 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.5.1 = Counter32: 0 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.6.1 = Counter32: 0 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.7.1 = STRING: "Fan Sensor"
117
118
Ecriture dun module SNMP (1)
Ecriture dun module SNMP (2)
On veut superviser les ventilateurs dun commutateur HP 4000. Il nous faut parcourir la MIB de lquipement la recherche des informations pertinentes. Nous avons besoin :
dun outil SNMP (ex : Getif pour Windows). de la description de la MIB prive de lquipement.
http://www.oidview.com/mibs/11/HP-ICF-CHASSIS.html
On explore la MIB prive de HP. Cette branche semble prometteuse :
la MIB proprement dite pour lexplorer.
On intgre la MIB du HP dans Getif : on linsre dans C:\Program Files\Getif 2.3.1\MIB\.
Un OID dcrit des dfaillances sur les capteurs : hpicfSensorFailures. On explore cette sous-branche.
Getif est tlchargeable ladresse suivante : http://www.wtcs.org/snmp4tpc/getif.htm La MIB prive des commutateurs HP peut tre tlcharge ladresse suivante : http://www.hp.com/rnd/software/MIBs.htm?jumpid=reg_R1002_USEN
On peut explorer cette sous-branche, soit en utilisant Getif, soit en utilisant la commande snmpwalk sous Linux. La description de la MIB prive indique ci-dessus correspond au chssis des commutateurs HP. snmpwalk -v 1 -c public 10.xxx.xxx.xxx 1.3.6.1.4.1.11.2.14.11.1.2.6.1
119
120
Ecriture dun module SNMP (3) On constate quun ventilateur est dfectueux sur cet quipement.
Intgration Nagios/Centreon (1)
Nous savons dsormais quelle valeur de la MIB prive interroger pour connatre ltat des ventilateurs. Nous crons une commande qui va utiliser le module de base check_snmp.
LOID .1.3.6.1.4.1.11.2.14.11.1.2.6.1.4.1 permet de connatre ltat du premier ventilateur.
()
Le premier ventilateur est dfectueux. Comme nous avons intgr les MIBs prives HP dans Getif, celui-ci est capable dindiquer directement ltat correspondant la valeur numrique qui a t obtenue lors de linterrogation de lOID. snmpget -v 1 -c public 10.xxx.xxx.xxx 1.3.6.1.4.1.11.2.14.11.1.2.6.1.4.1 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.4.1 = INTEGER: 2 La valeur numrique 2 correspond un tat BAD daprs la description de la MIB HP. Toutes les valeurs peuvent tre visualises depuis Getif via le champ Enums (en haut droite de la fentre). Pour connatre le statut du second ventilateur, on interrogera lOID
.1.3.6.1.4.1.11.2.14.11.1.2.6.1.4.2.
Maintenant que nous sommes capables de savoir o se trouve dans la MIP prive de HP linformation pertinente pour connatre ltat dun ventilateur, intgrons la supervision de ces lments Centreon/Nagios. Pour ce faire, nous allons utiliser le module de base de Nagios check_snmp.
snmpget -v 1 -c public 10.xxx.xxx.xxx 1.3.6.1.4.1.11.2.14.11.1.2.6.1.4.2 SNMPv2-SMI::enterprises.11.2.14.11.1.2.6.1.4.2 = INTEGER: 4
121
122

Le service ou modle cr par nos soins doit tre invoqu avec trois paramtres :
la communaut SNMP de lquipement ($ARG1$). la valeur numrique qui correspond un ventilateur en bon tat ($ARG2$). la ou les valeurs (un intervalle par exemple) qui correspondent un dysfonctionnement ($ARG3$).
Les paramtres accepts par la commande check_snmp sont :

check_snmp -H <ip_address> -o <OID> [-w warn_range] [-c crit_range] [-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e retries] [-l label] [-u units] [-p port-number] [-d delimiter] [-D output-delimiter] [-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a authproto] [-A authpasswd] [-X privpasswd]
Notre commande lappelle avec les arguments suivants :

$USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -o .1.3.6.1.4.1.11.2.14.11.1.2.6.1.4.1 -w $ARG2$ -c $ARG3$ -l 'Fan status'
()
Daprs la description de la MIB prive HP, les valeurs possibles pour le capteur associ un ventilateur sont les suivantes : -1 = tat unknown , -2 = tat bad , -3 = tat warning , -4 = tat good , -5 = aucun ventilateur prsent. NB : Le sparateur utilis pour identifier les paramtres des commandes Nagios est le point dexclamation ( ! ). Les : sparent plusieurs valeurs possibles pour un argument. Ex : Dans notre exemple, le ventilateur sera considr dfectueux sil prend les valeurs numriques 3 ou 5.
123
124
Prsentation du WOL (1)
WOL = Wake on Lan. Technologie permettant de rveiller distance une machine via le rseau. La machine doit tre compatible ACPI. Linterface rseau doit grer le WOL. Le WOL agit au niveau 2 du modle OSI (couche liaison de donnes).
Le WOL
Il ne ncessite linstallation pralable daucun agent.
ACPI = Advanced Configuration Power Interface (ACPI)
125
126
Prsentation du WOL (2)
Compatibilit WOL (1)

Consulter le BIOS de sa machine et activer loption concerne. Pour vrifier si WOL est actif depuis une machine Linux : utiliser le paquet ethtool.
laika:~# apt-get install ethtool laika:~# ethtool eth0 Settings for eth0: () Supports Wake-on: g Wake-on: g ()
Le principe : envoi dun paquet magique en direction de la machine cible, repre par son adresse Ethernet. Le paquet contient :
une squence fixe qui sera reconnue par la machine. 16 fois ladresse Ethernet de linterface rseau cible.
Les autres interfaces de la machine connectes au rseau ignoreront le paquet.
Analyse des champs :

Supports Wake-on : g signifie que la machine gre le WOL. Wake-on :
g d signifie que loption WOL est active. indique que la fonctionnalit est dsactive.
Ecoute du WOL : tcpdump udp port 9 and dst 193.50.234.128 Nomenclature du "Paquet Magique" C'est une squence de 6 octets FF:FF:FF:FF:FF:FF suivie de 16 fois l'adresse MAC de la carte rveiller. Pour une adresse MAC 00:50:8D:B4:BC:4B, la squence a la forme suivante : FFFFFFFFFFFF00508DB4BC4B00508DB4BC4B00508DB4BC4B00508DB4B C4B00508DB4BC4B00508DB4BC4B00508DB4BC4B00508DB4BC4B 00508DB4BC4B00508DB4BC4B00508DB4BC4B00508DB4BC4B00508DB4B C4B00508DB4BC4B00508DB4BC4B00508DB4BC4B
ethtool eth0 Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) Link detected: yes
127
128
Compatibilit WOL (2)
Utiliser WOL sur un sous-rseau

Deux exemples doutils :
Pour activer le WOL sous Linux :

laika:~# ethtool s eth0 g
Le paquet wakeonlan pour Linux. Lutilitaire WolCMD pour Windows. (http://www.depicus.com)

wakeonlan [-h] [-v] [-i IP_address] [-p port] [-f file] [[hardware_address]...] > wakeonlan 00:0C:76:51:8C:E7
wolcmd [mac address] [ip address] [subnet mask] [port number] > wolcmd 000C76518CE7 255.255.255.255 255.255.255.255
Il existe galement etherwake sous Linux. Celui-ci prsente, lavantage ou linconvnient, selon son point de vue, de requrir les droits root pour pouvoir sexcuter. Pour connatre ladresse Ethernet dune machine, on peut : 1) Lancer tout dabord un ping sur cette machine 2) Excuter ensuite la commande arp a pour connatre la table de correspondance entre les adresses IP et les adresses Ethernet.
129
130
Utiliser WOL via Internet

Il faut encapsuler le paquet magique pour lui permettre de traverser les routeurs. Cependant, il peut tre intercept par les routeurs :
trafic de type Broadcast, assimil des attaques de type DoS.
Il est ncessaire de configurer le routeur pour quil autorise le trafic sur un port dfini au choix.
ex : dfinir une redirection de port.
Ces diapositives relatives NUT datent de Mars 2006. Elles nont pas t mis jour pour intgrer les nouveaux pilotes NUT pour les onduleurs.
Une astuce : envoyer le paquet magique une machine dj active sur le mme sous-rseau.
NUT : supervision des onduleurs
En effet, il est trs rare que les routeurs soient configurs pour diffuser les broadcasts adresss leurs diffrents sous-rseaux. Pour passer le routeur, une astuce consiste envoyer le paquet magique ladresse IP dune machine qui est dj active sur le mme sous-rseau. Cette machine ignorera le paquet. Mais, ce dernier sera galement reu par le poste en sommeil que nous souhaitons rveiller et qui reconnatra son adresse ethernet. wakeonlan i 193.50.234.128 00:0C:76:51:8C:E7 Extrait dun texte Cisco : "IP directed broadcasts are used in the extremely common and popular "smurf" denial of service attack, and can also be used in related attacks. An IP directed broadcast is a datagram which is sent to the broadcast address of a subnet to which the sending machine is not directly attached. The directed broadcast is routed through the network as a unicast packet until it arrives at the target subnet, where it is converted into a link-layer broadcast. Because of the nature of the IP addressing architecture, only the last router in the chain, the one that is connected directly to the target subnet, can conclusively identify a directed broadcast. Directed broadcasts are occasionally used for legitimate purposes, but such use is not common outside the financial services industry. In a "smurf" attack, the attacker sends ICMP echo requests from a falsified source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the falsified source. By sending a continuous stream of such requests, the attacker can create a much larger stream of replies, which can completely inundate the host whose address is being falsified. If a Cisco interface is configured with the no ip directed-broadcast command, directed broadcasts that would otherwise be "exploded" into link-layer broadcasts at that interface are dropped instead. Note that this means that no ip directed-broadcast must be configured on every interface of every router that might be connected to a target subnet; it is not sufficient to configure only firewall routers. The no ip directed-broadcast command is the default in Cisco IOS software version 12.0 and later. In earlier versions, the command should be applied to every LAN interface that isn't known to forward legitimate directed broadcasts."
131
132
Prsentation de NUT (1)
Prsentation de NUT (2)
NUT = Network UPS Tools. Cest une collection de programmes distribus sur un rseau TCP/IP. NUT offre une vue unifie et homogne dun ensemble donduleurs htrognes. Il permet de grer larrt des ordinateurs quil protge en cas de coupure prolonge dlectricit.
Principe de fonctionnement :
Un ordinateur dit matre communique avec un ou plusieurs onduleurs. Il surveille ltat des onduleurs et le communique aux autres ordinateurs dits esclaves .
NUT peut sadapter de multiples configurations :

simple onduleur protgeant un poste de travail, onduleur dans une salle rseau, un serveur protg par plusieurs onduleurs.
Les perturbations du rseau lectrique sont de plusieurs ordres : coupures de secteur, variations de tension, surtensions ou baisses de tensions, parasites et variations de frquence. On distingue 3 technologies donduleurs. Technologie PASSIVE STAND-BY : Utilise par des onduleurs de faible puissance (250VA 1400VA) pour des quipements non stratgiques. Lors dune coupure de courant, londuleur bascule sur la batterie. Cest la seule perturbation quil puisse traiter. Technologie LINE INTERACTIVE : Utilise pour des onduleurs de moyenne puissance (420VA 5000VA). Londuleur ne se contente pas dassurer lalimentation permanente des quipements qui sont connects. Il est galement capable de rguler les variations de tension. Un filtre limine les parasites. Technologie DOUBLE CONVERSION : Utilise par des onduleurs de moyenne et forte puissance (1000VA 1000kVA) pour des quipements et applications critiques. Ces onduleurs sont gnralement associs des groupes lectrognes. Cette technologie traite toutes les perturbations lectriques.
Cette flexibilit dutilisation sexplique par une architecture modulaire. Un serveur protg par plusieurs onduleurs, signifie que cet quipement possde plusieurs alimentations, chacune tant branche sur un onduleur diffrent.
133
134
Architecture de NUT
Installation de NUT (1)
NUT est compos de plusieurs programmes classs en quatre catgories :

les pilotes assurent la communication entre londuleur et lordinateur, le serveur qui stocke les informations des onduleurs et les communique aux clients et scripts CGI (communications non chiffres), les clients collectent ces informations pour surveiller et administrer les onduleurs, les scripts CGI qui permettent de surveiller et dadministrer plusieurs onduleurs depuis un navigateur.
Installation du serveur sur la machine connecte londuleur : machine matre . Procdure :

On installe les paquets ncessaires NUT :
nut : le paquet de base, suffisant pour une solution simple . nut-usb : pilotes USB de plusieurs fabricants. nut-snmp : pilotes SNMP. nut-cgi : ncessaire pour utiliser un client Web.
laika:~# apt-get install nut
Concernant la scurit des changes entre les clients et le serveur, une version de NUT supportant le protocole SSL est ltude.
Le serveur UPSD communique aux clients et scripts CGI les donnes collectes par les pilotes. On linstalle donc sur lordinateur connect londuleur, que lon appellera dsormais le matre . Les clients et les CGI interrogent le serveur sur le port TCP 3493.
135
136
Installation de NUT (2) Procdure (suite):

On configure les paramtres de dmarrage du service en ditant le fichier /etc/default/nut.
# start upsd START_UPSD=yes # start upsmon START_UPSMON=yes

Procdure (suite):
On dfinit les listes de contrle daccs au dmon NUT dans le fichier /etc/nut/upsd.conf.
ACL all 0.0.0.0/0 ACL localhost 127.0.0.1/32 ACL glouton 10.234.160.50/32 ACL geronimo 10.234.244.205/32 ACCEPT localhost glouton geronimo REJECT all
On dfinit les paramtres des onduleurs qui seront surveills dans le fichier /etc/nut/ups.conf.
[onduleur1] driver = mge-utalk port = /dev/ttyS0 desc = "Onduleur des serveurs critiques"
On cre les profils des utilisateurs autoriss se connecter au serveur : fichier /etc/nut/upsd.users.
Ce fichier contient des mots de passe en clair, il faut donc sassurer que les droits sont bien positionns :
Le fichier appartient lutilisateur root. Il est accessible par lui seul.
()
Configuration du fichier /etc/default/nut : Le dmon upsd correspond au serveur NUT proprement dit. Upsmon nest autre que le client qui a pour principal rle de surveiller ltat de londuleur et darrter proprement lordinateur avant lpuisement des batteries de londuleur. On linstallera donc sur toutes les machines dpendantes du ou des onduleurs. Des exemples de fichiers de configuration sont disponibles dans le rpertoire /usr/share/doc/nut/examples/. Le plus simple est de les copier dans le rpertoire /etc/nut/ pour sen inspirer. Configuration du fichier /etc/nut/ups.conf : Le nom de londuleur indiqu entre crochet sera celui utilis partir de toutes les autres composantes de NUT pour linvoquer. Aussi, si vous le modifiez, noubliez surtout pas de rpercuter cette modification dans tous les fichiers de configuration. driver = pilote adapt londuleur que vous possdez. port = sa valeur dpend du pilote utilis : - /dev/ttyS0, /dev/ttyS1, pour les pilotes mge-utalk et mge-shut, - le nom de la communaut SNMP pour le pilote snmp-ups, - auto pour le pilote newhiupds car ce dernier dtecte automatiquement londuleur auquel il est connect. Description = une information destine faciliter la relecture.
Le fichier /etc/nut/upsd.conf contient la liste des htes autoriss se connecter au serveur NUT. Par dfaut, ce fichier est configur pour autoriser uniquement la supervision depuis le poste local. La description dbute par la dclaration des htes. Une fois ceux-ci identifis, on dfinit les droits. Ainsi, si on veut autoriser la supervision depuis une autre station, il faut lautoriser explicitement dans la section ACL de ce fichier de configuration. Ensuite, on emploiera la directive ACCEPT ou son contraire REJECT selon que lon veut, respectivement, autoriser une machine ou linterdire.
137
138
Installation de NUT (4) Procdure (suite):

Configuration du fichier /etc/nut/upsd.users
# Supervision user [admin] password = ******* allowfrom = localhost actions = SET instcmds = ALL [nagios] password = N,jnapodelm2p! allowfrom = localhost geronimo instcmds = ALL upsmon master

Configuration du client UPSmon :
client le plus important de la collection NUT. lanc par le script de dmarrage. surveille ltat de londuleur. arrte lordinateur avant puisement des batteries. communique directement avec le dmon. se configure partir du fichier /etc/nut/upsmon.conf. la configuration diffre selon que la machine est matre ou esclave .
Chaque utilisateur dfini dans ce fichier est dcrit dans une section commenant par son nom entre crochets. Les paramtres qui doivent tre configurs sont les suivants : password = le mot de passe de lutilisateur (en clair !!). allowfrom = liste des htes partir desquels lutilisateur est autoris se connecter. actions = deux valeurs possibles : - SET = autorise lutilisateur changer les valeurs de certaines variables de londuleur. - FSD = autorise lutilisateur changer le drapeau darrt forc de londuleur. instcmds = liste des commandes autorises pour lutilisateur : - ALL = toutes les commandes sont autorises. Pour obtenir la liste des commandes : upscmd l nom_onduleur@nom_serveur upsmon = deux valeurs possibles : - master : le systme est aliment par londuleur et est connect lui par la liaison data. - slave : le systme est aliment par londuleur mais nest pas connect lui par la liaison data. Il connat ltat de londuleur en communiquant avec le matre. En cas de panne de courant, ce systme sera arrt avant le matre. - monitor-only : le systme est aliment par londuleur et notifie les changements dtat sans devoir sarrter en fin dautonomie.
Puisque le client UPSmon doit communiquer directement avec le dmon UPSD, on retrouve dans son fichier de configuration (/etc/nut/upsmon.conf) lidentifiant et le mot de passe de lutilisateur autoris surveiller le matre. Il convient donc dappliquer ce fichier les mmes rgles de scurit que celles appliques au fichiers upsd.users. Heureusement, la Debian fait bien les choses et nous simplifie la tche en y veillant ds linstallation du paquet nut .
139
140

Configuration du client UPSmon (suite):
directive MONITOR : dclare le systme qui doit tre surveill :
MONITOR <system> <powervalue> <username> <password> { master | slave }

Configuration du client UPSmon (suite):
Quelques autres directives :
MINSUPPLIES : nombre minimal dalimentations effectives du
systme avant de dclencher son arrt.

POLLFREQ : frquence dinterrogation du dmon UPSD.
system : nom de londuleur surveiller. powervalue : indique le nombre donduleurs directement reli lordinateur. username, password : identifiants pour se connecter au serveur UPSD. master : indique que le systme doit sarrter en dernier, aprs larrt des esclaves. slave : le systme doit sarrter ds quil reoit une notification de fin dautonomie.
POLLFREQALERT : frquence dinterrogation du dmon UPSD
lorsque londuleur est sur batterie.

DEADTIME : la dure en seconde partir de laquelle
londuleur est considr comme mort .

SHUTDOWNCMD : commande utilise pour arrter le
systme.
NOTIFYCMD : commande utilise pour mettre des
notifications.
Etudions rapidement quelques directives de configuration du fichier /etc/nut/upsmon.conf. Abordons lun des paramtres les plus importants de ce fichier de configuration : la directive MONITOR. Le nom du systme est celui qui a t dfini dans le fichier /etc/nut/ups.conf Les identifiants de lutilisateur doivent tre identiques ceux dclars dans le fichiers /etc/nut/upsd.users.
La valeur DEADTIME doit tre un multiple des deux valeurs prcdentes, en gnral trois fois la plus grande de ces valeurs. Par exemple, par dfaut POLLFREQ et POLLFREQALERT ont pour valeur 5 secondes. Par consquent, DEADTIME vaut 15 secondes par dfaut. En gnral, la directive SHUTDOWNCMD vaut : SHUTDOWNCMD " /sbin.shutdown h +0 " Directive NOTIFYCMD : pour utiliser un script shell local : NOTIFYCMD /usr/local/sbin/nut_notifier On cre alors le script /usr/local/sbin/nut_notifier : #! /bin/bash echo " $*" | sendmail F "$UPSNAME" admin@mondomaine
141
142

Exemple pour une machine matre :
MONITOR onduleur1@localhost 1 nagios ******* master MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -h +0" NOTIFYCMD /usr/local/sbin/nut_notifier NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC
NOTIFYFLAG : associe un vnement des NOTIFYFLAG mthodes denvoi de notification :

<notify type> <flag>
SYSLOG :criture dune trace dans le fichier syslog. WALL : envoi dun message sur la console des utilisateurs connects au systme (commande wall). EXEC : excute la commande dfinie par NOTIFYCMD.
notify type indique le type dvnement qui affecte londuleur :

ONLINE : onduleur aliment par le secteur. ONBATT : onduleur sur batteries. LOWBATT: la batterie de londuleur est faible. SHUTDOWN : arrt du systme. FSD : le matre demande larrt forc de londuleur. REPLBATT : batteries dfectueuses.
Exemple pour une machine esclave :

MONITOR onduleur1@remotehost 1 user_slave ******* slave
La principale diffrence de configuration entre une machine matre et une machine esclave intervient au niveau de la directive MONITOR. Rappel : Lors de linstallation de NUT sur une machine esclave, noubliez pas de modifier les valeurs du fichier de configuration du service : /etc/default/nut. Il faut passer la directive START_UPSMON la valeur yes tandis que START_UPSD reste no (en effet, on na pas besoin de dmon UPSD sur cette machine). On relance ensuite le service NUT de la machine cliente : /etc/init.d/nut restart
143
144

Un mmo des autres commandes/clients :
upsc : interroge un dmon UPSD et obtient les valeurs dun onduleur gr par ce serveur.
ex : upsc onduleur1@localhost

Utilisation des scripts CGI :
On copie les fichiers contenus dans le rpertoire /usr/share/doc/nut-cgi/examples dans /etc/nut.
hosts.conf, upsset.conf, upsstats-single.html, upsstats.html
upslog : dmon de journalisation qui interroge rgulirement le serveur et enregistre les valeurs dans un journal dvnements.
ex : upslog l /var/log/ups.log s onduleur1@localhost
On dite le fichier hosts.conf pour dclarer les onduleurs. ex : MONITOR onduleur1@localhost "MGE" On limite laccs aux scripts aux seuls htes autoriss en configurant le serveur Apache.
On utilise un fichier .htaccess dans le rpertoire /usr/lib/cgibin/nut qui contient les scripts.
upsrw : permet dafficher et de modifier les valeurs des variables accessibles en lecture/criture dun onduleur.
ex : upsrw onduleur1@localhost
upscmd : envoie des commandes londuleur.

ex : upscmd l onduleur1@localhost
On configure le fichier autorisant les scripts effectuer des modifications : /etc/nut/upsset.conf.
On crera par exemple un script de dmarrage pour que le client upslog soit relanc chaque dmarrage du systme. Il est possible de dfinir prcisment le format de la ligne inscrite dans le fichier de traces. Attention : bien entendu, pensez inclure ce fichier de traces dans la rotation des logs du systme. Exemples de commandes pouvant tre mises via upscmd : -dmarrer un test de batteries -passer londuleur sur batteries -arrter londuleur -etc.
upscmd l onduleur1@localhost permet dobtenir la liste des commandes disponibles pour londuleur.
Pour tester les scripts CGI : http://localhost/cgi-bin/nut/upstats.cgi Il est recommand de configurer le serveur Web pour limiter laccs des scripts CGI aux seuls htes autoriss. Lutilisation dun fichier .htaccess dans le rpertoire contenant les scripts CGI est fortement conseille. Une fois la configuration scurise, on peut dcommenter la ligne I_HAVE_SECURED_MY_CGI_DIRECTORY du fichier /etc/nut/upsset.conf
145
146
Network Weathermap
Voici un exemple de consultation des valeurs de fonctionnement de londuleur via les pages gnres par les scripts CGI.
147
148
Prsentation (1)
Les fonctions de Network Weathermap :
Il affiche sous une forme graphique intuitive la charge de vos principaux liens rseau. Les flux sur un lien sont matrialiss par deux flches dont la couleur varie en fonction des volumes de donnes changes. Il dfinit une image de fond pour matrialiser la topologie de votre rseau. Il est possible de grer des pop-ups en fonction de la position de la souris sur le graphique.
Prsentation (2)
Ce projet a donn naissance de multiples adaptations (ex : PHP Weathermap).
149
150
Prsentation (3)
Network Weathermap est un outil dvelopp en langage Perl (librairie graphique Perl GD). Il neffectue aucune requte SNMP auprs des quipements rseau. Il recueille les informations ncessaires la cration du graphique partir de MRTG. MRTG stocke les rsultats de sa dernire requte dans la page HTML gnre sous forme de commentaires.
       
Installation (1) Installation :

Tlcharger le fichier ladresse suivante : Dcompresser larchive dans le rpertoire /usr/local/ par exemple. Configurer le script weathermap :
localisation de la commande wget. emplacement du fichier de configuration de loutil (weathermap.conf). le chemin complet vers le fichier image qui sera gnr. lactivation du dbogage. la taille de limage de sortie dans le cas o vous navez pas dfini dimage de fond dans le fichier de configuration. http://netmon.grnet.gr/weathermap/dist/weathermap1.1.1.tar.gz
Network Weathermap utilise la librairie PERL GD pour gnrer les images. Cette librairie requiert le module graphique de la libraire GD (libgd), lui-mme imposant la prsence dautres composants tels que freetype, libjpeg, libpng et libz. Il peut interroger directement les fichiers HTML gnrs par MRTG depuis le systme de fichiers ou via la commande wget si ces donnes se trouvent sur un serveur distant. Il les analyse et il en extrait les valeurs des flux en entre et en sortie (cuind d et cuout d).
Les paramtres sont dfinis directement dans le script Perl qui sappelle weathermap (sans extension .pl).
151
152
Installation (2)
Exemple de configuration :
$WGET = "/usr/bin/wget -qO -"; $CONFIG = "/usr/local/weathermap-1.1.1/weathermap.conf"; $OUTPUT = "/var/www/weathermap/weathermap.png"; $DEBUG = 0; $WIDTH = 880; $HEIGHT = 750;
Installation (3)
Exemple de configuration :
# /usr/local/weathermap-1.1.1/weathermap.conf BACKGROUND /usr/local/weathermap-1.1.1/campus_reduit.png KEYPOS 1 520 # low SCALE 1 SCALE 10 SCALE 25 SCALE 40 SCALE 55 SCALE 70 SCALE 85 high 10 25 40 55 70 85 100 red green blue 140 0 255 32 32 255 0 192 255 0 240 0 240 240 0 255 192 0 255 0 0
Configurer le fichier weathermap.conf :

dfinir limage de fond. dclarer et positionner les diffrents nuds. crer les liens entre ces nuds et associer chacun ladresse du fichier HTML gnr par MRTG utilis pour dfinir loccupation de la bande passante. fixer les couleurs de lchelle dutilisation des liens.
NODE summit5i POSITION 700 400 LABEL Summit5i NODE alpine POSITION 900 400 LABEL Alpine LINK summit5i-alpine NODES summit5i alpine TARGET http://10.xxx.xxx.xxx/mrtg-backbone/summit5i_alpine.html BANDWIDTH 100000
Suite la configuration des paramtres du fichier weathermap, il ne faut pas oublier de crer le rpertoire dans lequel se trouve limage gnre par weathermap. En loccurrence, il sagit de /var/www/weathermap. Un fichier weathermap.conf dont on peut sinspirer est fourni dans le rpertoire example.
153
154
Installation (4)
Configurer la page de rsultats : deux exemples de pages sont fournis dans le rpertoire example :
une page statique avec des liens vers les graphes gnrs par MRTG : weathermap.html. une page dynamique avec non seulement des liens vers les graphes MRTG, mais aussi des popups affichant limage MRTG actuelle : weathermap-overlib.html.
Bibliographie
Projet Nagios :www.nagios.org Projet Centreon : www.centreon.com Modules : www.nagiosexchange.org Cartographie avance : www.nagvis.org
Intgrer le script weathermap dans la crontab :

1,6,11,16,21,26,31,36,41,46,51,56 * * * * root if [ -x /usr/local/weathermap-1.1.1/weathermap ]; then /usr/local/weathermap-1.1.1/weathermap > /var/log/weathermap.log 2>&1; fi
Lutilisation de la page dynamique weathermap-overlib.html requiert lutilisation de la bibliothque JavaScript overlib_mini.js qui se trouve galement dans le rpertoire dexemples de Weathermap. Pour finir, on pourra intgrer linterface graphique dOreon un lien vers la page de rsultats gnre par Weathermap.
155
156

Supervision v2010 Avec Commentaires

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Supervision v2010 Avec Commentaires

Uploaded by

Copyright:

Available Formats

JT SIARS 2010 3 & 4 Juin 2010

Prsentation de Nagios et de Centreon Installation et mise en uvre Intgration doutils supplmentaires

Mise en uvre dun portail de supervision des systmes et rseaux v 2.0

Prsentation de Nagios et Centreon

Les enjeux de la supervision

Automatiser les tches :

Disposer de la vision globale dune infrastructure complexe.

Les concepts de la supervision

Les niveaux de supervision (1)

supervision des systmes :

Les niveaux de supervision (2)

Architecture systme de supervision

Prsentation de Nagios (1)

Nagios est un ordonnanceur de vrifications et un analyseur grant les actions suivantes :

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

Thierry DOSTES Journes Thmatiques SIARS 13 & 14 Mars 2006

Prsentation de Nagios (2)

Larchitecture de Nagios (1)

Nagios nest pas destin faire de la mtrologie.

Interface graphique base sur des CGI.

Larchitecture de Nagios (2)

Les modules/plugins Nagios (1)

Les modules/plugins Nagios (2)

Les modules/plugins Nagios (3)

soit en utilisant le protocole SNMP pour interroger les MIBs.

Tableau des tats dun service :

soit directement en local sur la machine supervise. Code retour

Les modules/plugins Nagios (4)

Les modules/plugins Nagios (5)

Lexcution de modules distance

Lagent NRPE : surveillance active

Lagent NSCA : surveillance passive

Que choisir : NRPE ou NSCA ?

Avec lagent NSCA :

Lutilisation de lagent NSCA :

Fonctionnement de NRPE et NSCA

Nagios 3.0 : les nouveauts

Installation de Nagios (1)

Sur Debian Lenny, Nagios est disponible en version 3.0.6.

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

-autorisations pour lancer les commandes systmes,

Installation de Nagios (2)

Installation de Nagios (3)

dclaration des plugins fournis de base.

les gestionnaires dvnements.

lments de linterface Web.

utiliss par Nagios.

Configuration de Nagios (1)

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

Configuration de Nagios (2)

Configuration de Nagios (3)

Une structure unique de configuration lexception des fichiers nagios.cfg et cgi.cfg :

Une commande pour tester la cohrence des fichiers de paramtrage :

Configuration de Nagios (4)

Configuration de Nagios (5)

Les commandes (commands.cfg) :

Les htes (hosts.cfg) :

Ces objets peuvent tre dfinis dans plusieurs fichiers de configuration :

Configuration de Nagios (6)

Configuration de Nagios (7)

Les contacts (contacts.cfg) :

Les groupes de services (servicegroups.cfg) :

moyens pour contacter ces personnes.

plages horaires denvoi des alertes.