Supervision v2010 Avec Commentaires

  • Upload
    -

  • View
    435

  • Download
    0

Embed Size (px)

Citation preview

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.0Thierry 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.

1

2

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.

3

4

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.

5

6

Les niveaux de supervision (2) supervision des applications et services : disponibilit. cohrence des rponses aux interrogations. performances.

Architecture systme de supervision

7

8

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.

9

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

Les modules/plugins Nagios (2) Tableau des tats dun hte :EtatUP DOWN

Les modules/plugins Nagios (3) Le module fonctionne :

SignificationHte disponible Hte indisponible

Code retour0 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 :EtatOK WARNING

soit directement en local sur la machine supervise. Code retour0 1 ex : vrification disques, interrogation des sondes matrielles, charge CPU.

SignificationService 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

Les modules/plugins Nagios (4) 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.

Les modules/plugins Nagios (5) 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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Installation de Nagios (2) Connexion au serveur Nagios : http://serveur/nagios3/

Installation de Nagios (3) 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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Configuration de Nagios (2) Emplacement des fichiers de configuration : rpertoire /etc/nagios3/

Configuration de Nagios (3) 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

Configuration de Nagios (4) 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.

Configuration de Nagios (5)

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

Configuration de Nagios (6) 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.).

Configuration de Nagios (7)

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

Configuration de Nagios (8)

Configuration de Nagios (9)

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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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.

Les patrons de configuration (2)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 patrons de configuration (3)

Les patrons de configuration (4) 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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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 serviceFichier 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 NagiosEtat 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

Les tats de Nagios : ltat HARD (4)

Les tats de Nagios : ltat HARD (5)

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

Les tats de Nagios : ltat HARD (6)

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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

59

60

Les gestionnaires dvnements (1)

Les gestionnaires dvnements (2)

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

Les gestionnaires dvnements (3)

Les gestionnaires dvnements (4)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

Les gestionnaires dvnements (5)

Les gestionnaires dvnements (6)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.

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Gestion des dpendances entre services (2)

Gestion des dpendances entre services (3)

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.

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Utilisation de NRPE sur Linux (2) 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$

Utilisation de NRPE sur Linux (3) 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 [-n] [-u] [-p ] [-t ] [-c ] [-a ] -n = Do no use SSL -u = Make socket timeouts return an UNKNOWN state instead of CRITICAL = 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)

Utilisation de NRPE sur Windows (2)

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

Utilisation de NRPE sur Windows (3) Edition du fichier de configuration : allowed_hosts=10.234.244.205, 193.50.234.4dont_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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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 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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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.

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

97

98

Installation de Centreon (2)

Installation de Centreon (3)

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

Installation de Centreon (4)

Installation de Centreon (5)

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/ Options Indexes AllowOverride AuthConfig Options Order allow,deny Allow from all

http://en.doc.centreon.com/Setup:Debian/Ubuntu

101

102

Installation de Centreon (5)

Installation de Centreon (6) 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/ Options Indexes AllowOverride AuthConfig Options Order allow,deny Allow from all

103

104

DEMO CENTREON

FAN : Fully Automated Nagios

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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).Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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.

Prsentation du protocole SNMP (3)

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

Prsentation du protocole SNMP (4)

Prsentation du protocole SNMP (5)

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

Prsentation du protocole SNMP (6)

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

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

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

Intgration Nagios/Centreon (2)

Intgration Nagios/Centreon (3) 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 -o [-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.

Thierry DOSTES Journes Thmatiques SIARS 3 & 4 Juin 2010

ACPI = Advanced Configuration Power I