Découverte de la supervision avec Nagios

Transcription

1 Découverte de la supervision avec Guillaume Lohez Cet article traite de la configuration de, ce logiciel de supervision dont il est tant question depuis quelques années. À cela deux raisons. Premièrement, les besoins grandissants en supervision dans toutes les sociétés, qu'elles soient petites ou grandes et deuxièmement, la maturité que a acquis et cela sera encore plus vrai avec la version trois qui est en release candidate à l'heure où j'écris cet article. linux@software.com.pl est un outil de supervision qui permet de surveiller l'état de serveurs distants. Il utilise le principe des plugins pour être le plus compatible possible avec un grand nombre de services. Ainsi, il n'empêche pas celui ou celle qui le désire d'écrire un plugin pour un service atypique dans un language spécifique. Je vais commencer par configurer le daemon luimême ainsi que son interface en Web en cgi. Puis j'aborderai le création des différents objets de qui représenteront les personnes, les serveurs et leurs services associés. Toutes les configurations et manipulations décrites dans cet article ont été réalisées sur une Ubuntu 7.10 à jour au moment de la rédaction. est en version 2.9, installé depuis les paquets officiels. Comme je décrirai aussi la procédure d'installation depuis les sources, vous pourrez, si vous le préférez, utiliser une version de plus récente. Les configurations présentées dans ce document fonctionneront aussi bien avec installé avec les paquets précompilés de votre distribution favorite que si vous le compilez depuis les sources tant que vous prenez une version 2.x de et une version 1.4.x pour les plugins. Je ne présenterai que les options principales de, car il y a une grande quantité d'options possibles, mais le but de cet article n'est pas de ré-écrire la documentation officielle. Pour compléter ce document, je présenterai aussi la configuration d'un agent SNMP sous GNU/Linux. Il vous servira à superviser vos serveurs à distances. Enfin, pour pouvoir être averti à tout moment, je parlerai d'une méthode pour l'envoi des alertes par SMS. Installation de Pour commencer, je parlerai de l'installation de. Cet article explique... La configuration générale du daemon et de l'interface Web, La configuration des différents objets les plus courants, La configuration d'un daemon NetSNMP sous GNU/Linux, La configuration de SMSTools pour l'envoi des alertes par SMS. 40 Linux+ 5/2008

2 Sur une distribution deb based J'entends par là une distribution qui utilise les paquets au format Debian et son outil de gestion aptitude. Rien de plus simple grâce à la commande suivante : # aptitude install nagios2 # nagios-plugins Les dépendances seront automatiquement installées, cela inclut le serveur Web Apache. Ils seront configurés automatiquement pour servir les pages de. Vous pouvez passer directement à la configuration de. Depuis les sources Les étapes sont les suivantes, cela reste assez simple : Téléchargez les sources sur le site Web de. Dans ce cas, il s'agira de la version 2.10 qui est la dernière stable actuellement, Placez l'archive dans le répertoire /usr/ local/src, Décompressez l'archive dans ce répertoire, Créez l'utilisateur nagios qui nous servira pour exécuter la partie daemon de, Créez un répertoire pour installer : /usr/local/nagios, Donnez les droits sur ce répertoire à l'utilisateur nagios, Vous devez donner les droits sur le fichier de commande de à Apache. Cela permet de configurer des alarmes depuis l'interface Web par exemple. Pour cela : Trouvez l'utilisateur qui exécute le daemon Apache, Créez un groupe nagcmd, Ajoutez l'utilisateur d'apache et celui de à ce groupe. Installez les dépendances nécessaires à la compilation de : les fichiers de développement de la librairie GD, Placez-vous dans le répertoire des sources de. Vous allez maintenant pouvoir compiler. Ce qui se fera en plusieurs étapes : Le script de configuration réalisée avec cette commande :. /configure prefix=/usr/local/nagios with-cgiurl=/nagios/cgi-bin with-htmlurl=/nagios with-nagios-user=nagios with-nagiosgroup=nagios --with-nagios-group=nagcmd Les options sont : --prefix : le chemin d'installation, --with-cgiurl : le chemin Web des CGI, --with-htmlurl : le chemin Web des pages statiques, --with-nagios-user : l'utilisateur qui va exécuter le daemon de, --with-nagios-group : le groupe qui va exécuter le daemon de, --with-nagios-group : le groupe à qui appartient le fichier de commande externe de, La compilaton en elle-même dont voici la commande : make all, L'installation de et de son script de démarrage avec cette commande : make install make install-init L'installation de est terminée, vous devriez trouver tout le nécessaire dans le répertoire /usr/local/nagios. Ce qu'il faut savoir... Un minimum de commandes Linux de base, Se servir d'un éditeur de texte, Avoir les notions de base en réseau pour la supervision des machines distantes, Un minimum de connaissance des services à superviser. Lisitng 1. Une timeperiod qui correspond aux horaires de travail sur une semaine define timeperiod { timeperiod_name horaires_bureau # le nom de la timeperiod définie dans alias Les horaires normaux # le nom long monday 08:00-19:00 # de 08h00 à 19h00 tuesday 08:00-19:00 # de 08h00 à 19h00 wednesday 08:00-19:00 # de 08h00 à 19h00 thursday 08:00-19:00 # de 08h00 à 19h00 friday 08:00-19:00 # de 08h00 à 19h00 Listing 2. Les horaires de l'astreinte pour les nuits et les week-ends define timeperiod { timeperiod_name horaires_astreinte # le nom de la timeperiod définie dans alias Les horaires d'astreinte # le nom long sunday 00:00-24:00 # toute la journée de dimanche monday 00:00-08:00,19:00-24:00 # de minuit à 08h00 et 19h00 à minuit tuesday 00:00-08:00,19:00-24:00 # de minuit à 08h00 et 19h00 à minuit wednesday 00:00-08:00,19:00-24:00 # de minuit à 08h00 et 19h00 à minuit thursday 00:00-08:00,19:00-24:00 # de minuit à 08h00 et 19h00 à minuit friday 00:00-08:00,19:00-24:00 # de minuit à 08h00 et 19h00 à minuit saturday 00:00-24:00 # toute la journée de dimanche 41

3 Vous allez maintenant devoir installer les plugins de que vous téléchargez depuis le site de. Dans ce cas, il s'agira de la version La procédure d'installation est assez proche de celle de : Placez l'archive dans le répertoire /usr/ local/src, Décompressez l'archive dans ce répertoire, Placez-vous dans le répertoire qui vient d'être créé. Vous allez maintenant pouvoir compiler les plugins de, et ce, en plusieurs étapes : Le script de configuration, j'utiliserai la commande suivante :./configure prefix=/usr/local/nagios - -enable-perl-modules Les options sont les suivantes : --prefix : le chemin d'installation, --enable-perl-modules : active l'installation de la librairie :: Plugin. La compilaton en elle-même dont voici la commande : make, L'installation des plugins : make install. L'installation des plugins de est terminée, ils seront installés dans le répertoire /usr/local/nagios/libexec. Vous allez maintenant pouvoir passer à la configuration de à proprement parler. Le fichier nagios.cfg Ce fichier fixe le comportement général de. Voici quelques directives à ne pas rater au milieu de ce fichier assez long. Définition des fichiers Vous allez spécifier où se trouvent certains fichiers nécessaires à grâce à ces directives : log_file indique où se trouve le fichier de log principal, cfg_dir indique un répertoire où tous les fichiers se terminant par.conf seront lus par pour charger les objets, cfg_file indique un fichier que traitera comme un fichier de configuration. Les directives cfg_dir et cfg_file peuvent apparaître plusieurs fois. Commandes externes Ces paramètres vont définir si tient compte des événements qu'il reçoit de l'extérieur comme : arrêter les checks d'un service ou d'un host, arrêter les notifications, les reprendre, etc. Je recommande de l'activer. Ces commandes viendront principalement de l'interface Web par l'intermédiaire du daemon HTTP ou alors de scripts externes dans des configurations plus évoluées. Les paramètres sont les suivants : check_external_command doit être mis à 1 pour tenir compte des commandes externes, command_check_interval spécifie la fréquence de vérification du fichier qui reçoit les commandes externes. -1 indique à de le vérifier aussi souvent qu'il le peut, command_file indique où se trouve le fichier ainsi que son nom. Les fichiers de logs Grâce à ces directives, vous allez indiquer ce que doit mettre ou ne pas mettre dans le fichier de log. Elles sont les suivantes : log_rotation_method permet de choisir la fréquence de rotation. d pour daily est correct dans la plupart de cas. Sinon, il faut choisir h pour hourly sur les systèmes chargés, log_archive_path indique où stocker les anciens fichiers après leur rotation, use_syslog n'est à mettre à 0 que si des fichiers de log de sont utilisés, Je conseille d activer une série de paramètres pour choisir ce qui est loggé. Listing 3. Définition de contact define contact { contact_name guillaume # le nom du contact défini dans alias Guillaume LOHEZ # le nom long service_notification_period 24x7 # la timeperiod de notification pour les services host_notification_period 24x7 # la timeperiod de notification pour les hosts service_notification_options w,u,c,r # les critčres de notification: w pour warning, u pour # unknown, c pour critical, r pour recovery host_notification_options d,u,r # les critčres de notification: d pour down, # u pour unreachable, r pour recovery service_notification_commands notify-by- # la commande utilisée pour notifier en cas de nécessité # pour un service host_notification_commands host-notify-by- # la commande utilisée pour notifier en cas de nécessité # pour un host silencer@free-4ever.net # l'adresse du contact pager silencer@free-4ever.net # l'adresse de pager du contact Listing 4. Définition de contactgroup define contactgroup { contactgroup_name admins # le nom du contact défini dans alias Groupes des administrateurs # le nom long members guillaume # la liste des membres séparés par des virgules 42 Linux+ 5/2008

4 Rétention des états Il est important de souligner que permet de retenir les états des services ainsi que les informations volatiles même après un redémarrage du service. Les états sont écrits à l'arrêt de et lus au démarrage. Pour cela, il faudra utiliser sur les paramètres suivants : retain_state_information doit être mis à 1 pour retenir les états des services et des hosts, u s e _ r e t a i n e d _ p r o g r a m _ s t a t e doit être mis à 1 pour retenir les changements qui auraient été faits sur les services ou hosts. Cela inclut les désactivations par l'interface Web par exemple, use_retained_scheduling_info doit être forcement mis à 1 pour retenir les replanifications des checks, retention_update_interval permet de spécifier à quel interval écrira les états dans le fichier de rétention en cas d'arrêt non prévu de. Les checks gère 2 types de checks : les actifs et les passifs. Les premiers sont déclenchés par lui-même. Pour les seconds, ne fait qu'attendre les résultats envoyés par d'autres serveurs ou des scripts. Pour cela, les résultats sont envoyés par le fichier de commandes externes. Les paramètres sont les suivants : execute_service_checks doit être mis à 1 pour que utilise les checks actifs de services, execute_hosts_checks doit être mis à 1 pour que utilise les checks actifs de hosts, accept_passive_service_checks doit être mis à 0 dans notre cas, accept_passive_host_checks doit être mis à 0 dans notre cas. Les notifications est capable d'informer par ses contacts. Il faudra activer le paramètre enable_notifications à mettre à 1 pour activer les notifications. Le fichier cgi.cfg La plupart des valeurs par défaut de ce fichier n'auront pas besoin d'être modifiées dans la mesure où l'authentification est activée par défaut et qu'elle est le paramètre le plus important. Il pourra être nécessaire de changer certaines variables pour définir le compte admin. Par défaut, il s'agit du compte nagiosadmin. Il est préférable de le changer surtout si le serveur est accessible depuis l'extérieur. Voici la liste des variables : authorized_for_system_information, authorized_for_configuration_ information, authorized_for_system_commands, authorized_for_all_services, authorized_for_all_hosts, a u t h o r i z e d _ f o r _ a l l _ s e r v i c e s_ commands, authorized_for_all_hosts_commands. Pour tous ces paramètres, il sera toujours possible de mettre plusieurs utilisateurs, qui ne correspondent pas forcément à des contacts, en les séparant par des virgules. Listing 5. Définition de template pour un host define host { name generic-host # le nom du template défini dans check_command check-host-alive # La commande pour vérifier l'état max_check_attempts 2 # le nombre maximum d'essais check_interval 5 # l'intervalle de vérification active_checks_enabled 1 # les checks actifs sont effectués passive_checks_enabled 0 # les checks passifs ne sont pas pris en compte check_period 24x7 # la période de vérification retain_status_information 1 # la rétention des états est activée retain_nonstatus_information 1 # la rétention des états est activée contact_groups admins # le contactgroup associé à tous nos hosts notifications_enabled 1 # les notifications sont activées notification_interval 60 # l'intervalle de renotification est fixé à une heure notification_period 24x7 # la période de notification notification_options d,r,u # les critères de notification: d pour down, u pour # unreachable, r pour recovery register 0 # désactive l'enregistrement en tant que host Listing 6. Définition d'un host define host { use generic-host # le nom de notre template à utiliser host_name gateway # le nom du host défini dans alias Router # le nom long address gateway.free-4ever.net # l'adresse ip ou le nom dns de la machine parents nagios-server # le parent de ce host 43

5 Vous désactiverez l'accès guest en retirant tout login du paramètre default_user_name. Accès à l'interface Web Bien évidemment, n oubliez que pour qu'un utilisateur puisse se connecter sur l'interface Web, il faudra qu'il soit authentifié par Apache. Que cela soit un utilisateur qui corresponde à un contact de ou à un utilisateur du fichier cgi.cfg. Pour ajouter des entrées dans ce fichier, utilisez la commande htpasswd : # htpasswd /etc/nagio2/htpasswd.users # user1 # New password: <secret password> # Re-type new password: # <secret password> # Adding password for user user1 Les autres types d'authentification Apache, comme MySQL ou LDAP, fonctionnent aussi. Les objets de Vous allez maintenant définir les différents de objets de qui peuvent représenter entre autres, les contacts, les hosts, les services, etc. L'ordre dans lequel je vais les présenter est pour moi l'ordre logique pour les créer à partir de rien. Les commands Les commands servent à relier les plugins avec les services et les hosts à superviser. Prenons la commande check-host-alive qui vérifie si un objet de type host répond bien au niveau réseau : define command { command_name check-host-alive # le nom de la command définie # dans command_line /usr/lib/nagios/ plugins/check_ping -H $HOSTADDRESS$ -w 5000,100% -c 5000,100% -p 1 # La ligne de commande à exécuter Voici maintenant le détail de la ligne de commande : le plugin check_ping avec son chemin complet, -H $HOSTADDRESS$ : l'adresse du host passée en paramètre au plugin avec l'option -H, -w 5000,100% : le seuil pour l'état warning. Il est de cinq secondes ou 100% de paquets perdus, -c 5000,100% : le seuil pour l'état critical. Il est de cinq secondes ou 100% de paquets perdus, -p 1 : un seul paquet ICMP est envoyé. Les seuils de cette commande ne servent qu'à vérifier qu'un host répond bien et ne mesure en aucun cas les performances du réseau. Prenons un autre exemple avec une commande qui utilise un plugin SNMP : define command { command_name check_netsnmp_process Lisitng 7. Définition de template de service define service { name generic-service # le nom du service défini dans active_checks_enabled 1 # les checks actifs sont effectués passive_checks_enabled 0 # les checks passifs ne sont pas pris en compte check_period 24x7 # la période de vérification normal_check_interval 5 # l'intervalle de vérification max_check_attempts 3 # le nombre maximum d'essais retry_check_interval 1 # l'intervalle entre les essais successifs retain_status_information 1 # la rétention des états est activée retain_nonstatus_information 1 # la rétention des états est activée contact_groups admins # le contactgroup associé à tous nos hosts notifications_enabled 1 # les notifications sont activées notification_interval 60 # l'intervalle de renotification est fixé à une heure notification_period 24x7 # la période de notification notification_options w,u,c,r # les critčres de notification: w pour warning, # u pour unknown, c pour critical, r pour recovery register 0 # désactive l'enregistrement en tant que service Listing 8. Dependency pour un service define servicedependency { host_name gateway # le nom du host maître service_description dns # le nom du service maitre sur ce host dependent_host_name gateway # le nom du host dépendant dependent_service_description mail # le nom du service dépendant sur ce host execution_failure_criteria w # quand le maître est dans l'état warning # le service dépendant n'est plus vérifié notification_failure_criteria w # quand le maître est dans l'état warning # le service dépendant n'est plus vérifié 44 Linux+ 5/2008

6 # le nom de la command # définie dans command_line /usr/lib/nagios/ plugins/check_snmp_process_ servers.pl -H $HOSTADDRESS$ -C $ARG1$ -w $ARG2$ -c $ARG3$ # La ligne # de commande à exécuter Voici la ligne de commande décomposée : check_snmp_process_servers.pl est le nom du plugin précédé de son chemin complet, -H $HOSTADDRESS$: l'adresse du host passée en paramètre au plugin avec l'option -H, -C $ARG1$ spécifie la communauté SNMP pour interroger le host distant. Elle sera le premier paramètre sur la ligne de commande dans la déclaration du service, -w $ARG2$ : le seuil pour l'état warning. Cela sera un nombre de processus, -c $ARG3$ : le seuil pour l'état critical. Cela sera aussi un nombre de processus. Il ne reste plus qu'à définir toutes les autres commandes dont vous aurez besoin. La façon la plus simple de définir proprement ces commandes est d'utiliser les plugins en ligne de commande pour tester les paramètres possibles puis de les déclarer dans en les remplaçant par les arguments. Les timeperiods Les timeperiods servent à définir des plages horaires où les hosts et services seront vérifiés. Elles servent aussi à définir les moments où envoie les notifications. Prenons un exemple avec une timeperiod qui correspond aux horaires de travail sur une semaine (Listing 1). Un autre exemple avec les horaires de l'astreinte pour les nuits et les weekends est présenté sur le Listing 2. Les contacts Les contacts servent à définir qui doit être notifié et qui a le droit de voir les hosts et services sur l'interface Web. Cela se fait en conjonction avec une authentification Apache. Prenons un exemple de définition de contact (Listing 3). Pour gérer l'authentification depuis l'interface Web, il sera nécessaire d'utiliser une authentification Apache. Le plus simple est d'utiliser une authentification avec stockage en fichier htpasswd. Dans ce cas, pour ajouter un utilisateur guillaume, il suffit d'utiliser la commande suivante : # htpasswd2 /etc/nagios2/htpasswd. # users guillaume # New password: "type a very secret # password" # Re-type new password: "retype the # very secret password" # Adding password for user user1 L'utilisateur guillaume devra donc être un contact dans et il ne verra sur l'interface Web que les hosts et services avec qui il sera en contact. Les contactgroups Les contactgroups (Listing 4) servent à faciliter l'administration de pour regrouper les contacts. Les contactgroups seront mis comme contact au niveau des hosts et services. Les hosts Les hosts servent à définir les machines avec leur IP ou leur nom DNS. Toutes les vérifications de services sont associées à des hosts dans. Pour définir les hosts, il est plus simple d'utiliser un template, car la plupart des hosts utiliseront les mêmes paramètres. Dans le Listing 5, vous trouverez un exemple de définition de template pour un host. L'une des choses les plus importantes est qu'il ne faut surtout pas oublier le register à 0, car un template n'est pas vraiment un host. Maintenant que le template est défini, vous allez pouvoir l'utiliser pour définir un host (Listing 6). La notion de parents sert pour la carte de, pour avoir les bonnes liaisons. Il sert également à ce que considère que les Listing 9. Les escalations define serviceescalation { host_name gateway service_description processus first_notification 4 last_notification 0 notification_interval 30 contact_groups managers # le nom du host sur lequel l'escalade est définie # le nom du service sur lequel l'escalade est définie # ŕ la deuxičme notification, l'escalade est utilisée # l'escalade sera toujours utilisée ensuite # la notification pour l'escalade est de trente minutes # le contactgroup managers est notifié Listing 10. Extrait de fichier de configuration com2sec readonly /8 pouet # définition de la communauté pouet # accessible depuis les machines qui ont une ip en /8 # cette communauté sera lecture seule group MyROGroup v1 readonly # définition d'un groupe en version 1 view all included.1 # définition d'une vue qui a le droit de tout voir # context sec.model sec.level match read write notif access MyROGroup "" any noauth exact all none none # association de notre groupe # avec notre vue syslocation mon serveur est la # l'indication sur l'emplacement du serveur syscontact Administrateur <guillaume@mon_domaine.net># le contact pour ce serveur # Ces deux paramètres sont affichés par la plupart des outils de supervision SNMP lors de la découverte d'une machine. 45

7 hosts connectés derrière un host down ne sont pas forcement down, mais juste non joignables, ce qui est matérialisé par l'état unreachable. Les hostgroups Les hostgroups servent à grouper les hosts dans l'interface Web de. Prenons un exemple de définition d'un hostgroup : define hostgroup { hostgroup_name routers # le nom du hostgroup # défini dans alias Routers # le nom long members gateway # la liste des hosts séparés # par des virgules Les services Les services permettent de définir la vérification qui sera faite pour tester le fonctionnement d'un daemon particulier sur un serveur. Ils seront associés à un ou plusieurs hosts. Les services vont représenter par exemple la vérification d'une réponse sur le port 80 pour un serveur Web. De la même façon que pour les hosts, vous allez définir un template pour les services, car la plupart utiliseront les mêmes paramètres. Le Lisitng 7 vous présente un exemple avec une définition de template de service. Comme pour les hosts l'une des choses les plus importantes est qu'il ne faut surtout pas oublier le register à 0 car un template n'est pas vraiment un service. Maintenant que notre template est défini, vous allez l'utiliser dans la définition d'un service : define service { use generic-service # le nom de notre template à utiliser host_name gateway # le host sur # lequel appliquer le service service_description processus # une description de # ce service check_command check_snmp_ process!public!200!300 # la command de La ligne check_command pointe vers une commande définie dans. Entre les! Il y a les arguments à lui envoyer grâce aux macros $ARGV1$ à $ARGV3$ de. Ils sont pris dans l'ordre et vous retrouvez votre communauté SNMP, puis les seuils warning et critical qui représentent des nombres de processus. Les servicegroups Les servicegroups servent à grouper les services dans l'interface Web de. Prenons un exemple : define servicegroup { servicegroup_name nombre_de_ processus # le nom du # servicegroup défini dans # alias Ping Services # le nom long # members gateway,process # la liste des services # membre # du servicegroup La liste des services séparés par des virgules. Comme cela a été dit précédemment, pour Listing 11. Fichier de configuration devices = GSM1 logfile = /var/log/smsd.log loglevel = 7 [queues] [provider] [GSM1] device = /dev/ttyusb0 incoming = no baudrate = 9600 rtscts = no # déclaration de notre téléphone # le fichier de log # le niveau de log utilisé pour parler à syslog # le mot clé est nécessaire # pas de configuration avancée des providers # configuration de notre device GSM1 # le device créé par Linux au moment de la connexion en USN du portable # les SMS entrants ne sont pas utilisés # vitesse de communication avec le téléphone # pas de contrôle de flux Listing 12. Configuration du contact define contact { contact_name guillaume # le nom du contact défini dans alias Guillaume LOHEZ # le nom long service_notification_period 24x7 # la timeperiod de notification pour les services host_notification_period 24x7 # la timeperiod de notification pour les hosts service_notification_options w,u,c,r # les critères de notification : w pour warning, # u pour unknown, c pour critical, r pour recovery host_notification_options d,u,r # les critères de notification : d pour down, # u pour unreachable, r pour recovery service_notification_commands notify-by- ,notify-by-sms # la commande utilisée pour notifier en cas # de nécessité pour un service host_notification_commands host-notify-by- ,host-notify-by-sms # la commande utilisée pour notifier # en cas de nécessité pour un host silencer@free-4ever.net # l'adresse du contact pager # l'adresse de pager du contact 46 Linux+ 5/2008

8 identifier un service précis dans, il faut le nom du host et du service. Donc la liste est de la forme suivante : host,service,host,service, etc. Les dépendances Les dépendences dans servent à définir que si un service sur un host est down, ne doit plus déclencher de vérification active sur un certain nombre de services. Par exemple, si le service DNS est down, cela n'est plus nécessaire d'essayer de faire des requêtes MX pour envoyer des s. Le Listing 8 vous montre un exemple de dependency pour un service. Les escalades Les escalations permettent de définir dans que si un service reste dans un état anormal trop longtemps, le contact associé au service n'est plus notifié mais un autre contact (Listing 9). Il existe un mécanisme similaire pour les hosts. Là aussi, il n'y a pas de service à spécifier. Application de la configuration Après tout cela, vous devriez avoir un qui fonctionne correctement... Pour vérifier, la commande suivante : nagios -v /etc/ nagios2/nagios.cfg est très pratique. Elle produit sur la console un état des lieux de avec tous les objets qui ont été définis et la liste des différentes incohérences qu'il pourraient y avoir dans la configuration. Dans le cas où il y aurait des erreurs, est assez explicite en précisant le host ou le service en faute. En obtenant zéro erreur et avertissement, il ne reste plus qu'à redémarrer le daemon, sur une Ubuntu avec la commande # /etc/init.d/nagios2 restart. Supervision par SNMP SNMP veut dire Simple Network Management Protocol. Il permet de se connecter à distance sur une machine pour récupérer différentes valeurs mais différentes choses peuvent aussi être configurées. Utilisez la partie qui permet de lire l'état d'un serveur distant. Le protocole SNMP définit 3 versions : la version 1 et 2c qui sont très proches et la version 3 qui implémente un système d'authentification et cryptage des données. J'utiliserai la version 1 dans la mesure où les données qui transitent ne sont pas critiques. Dans le protocole SNMP, les informations sont identifiées par leur OID. Il y a comme pour plusieurs méthodes pour installer le daemon SNMP. Sur une distribution deb based Comme pour, utilisez aptitude avec la commande : # aptitude install snmpd. Les dépendances seront automatiquement installées. Depuis les sources Les étapes sont les suivantes : Téléchargez les sources sur le site Web du projet NetSNMP. Dans ce cas, il s'agira de la version 2.10 qui est la dernière stable actuellement, Placez l'archive dans le répertoire /usr/ local/src, Décompressez l'archive dans ce répertoire, Placez-vous dans le répertoire des sources de NetSNMP. Vous allez maintenant pouvoir compiler NetSNMP, et ce, en plusieurs étapes : Le script de configuration, vous utiliserez la commande suivante :./configure, Pas d'option particulière, les valeurs par défaut sont bien, La compilation en elle-même dont voici la commande : make, L'installation de NetSNMP : make install. L'installation du daemon NetSNMP est terminée. Les différentes commandes se trouvent dans le répertoire /usr/local/bin, le binaire du daemon se trouve dans le répertoire /usr/local/ etc et pour finir, le fichier de configuration du daemon se trouvera dans /usr/local/etc. Configuration Le fichier de configuration (Listing 10) s'appelle snmpd.conf. Il contient une très grande quantité de paramètres possibles mais je ne présenterai que les principaux qui vont vous servir ici. Utilisation du SNMP Dans ce cas, c'est qui parlera à votre daemon SNMP donc vous n'aurez pas à savoir comment cela se passe mais sachez qu'il existe les commandes suivantes : snmpget : pour récupérer une valeur, la quantité de données passée sur une interface réseau par exemple, Snmpwalk : pour lire une série de valeurs qui se suivent, la liste des interfaces réseau par exemple, Snmpset : pour changer une valeur sur le serveur distant mais dans l'exemple de configuration précedent, cela n'est pas implémenté. Comme je le disais, c'est qui va parler au daemon SNMP grâce à ses plugins. Vous n'aurez donc pas à connaître les OID qui sont utilisés. Il vous suffira de spécifier la communauté SNMP. Envoi des alertes par SMS Pour cela, vous allez utiliser un outil qui s'appelle SMStools. C'est un daemon à installer sur un serveur. Il faudra ensuite connecter un téléphone portable par USB, infrarouge ou encore bluetooth mais la solution de l'usb paraît la plus fiable dans Listing 13. Nouvelles commandes de notification define command { command_name host-notify-by-sms command_line /usr/bin/printf "%b" "To: $CONTACTPAGER$\n\n** NAGIOS**\nType: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\n \ Info: $HOSTOUTPUT$\nTime: $SHORTDATETIME$" >"/var/spool/sms/outgoing/nagios-$contactpager$- $HOSTNAME$-`/bin/date +%s`" define command { command_name notify-by-sms command_line /usr/bin/printf "%b" "To: $CONTACTPAGER$\n\n** NAGIOS**\nType: $NOTIFICATIONTYPE$\nService: $SERVICEDESC$\nHost: $HOSTNAME$\n \ State: $SERVICESTATE$\nInfo: $SERVICEOUTPUT$\nDate: $SHORTDATETIME$" >"/var/spool/sms/outgoing/ nagios-$contactpager$-$hostname$-$servicedesc$-`/bin/date +%s`" 47

9 un environnement serveur. Pourquoi faire cela plutôt que d'utiliser un passerelle vers SMS sur Internet? Pour la bonne et simple raison que cela est beaucoup plus fiable. Dans le cas d'une panne, il se peut très bien que votre connexion Internet ne fonctionne plus donc ne pourrait plus vous avertir de la panne! Alors que dans cette configuration, le seul point de faiblesse est le serveur de supervision lui-même. Comme pour et NetSNMP, SMStools est intégré dans la plupart des distributions mais s'installe aussi depuis les sources. Sur une distribution deb based Comme précédemment, j'utiliserai aptitude : # aptitude install smstools. Les dépendances seront automatiquement installées. Depuis les sources Les étapes sont les suivantes, cela reste assez simple : Téléchargez les sources sur le site Web du projet SMStools. Dans ce cas, il s'agira de la version 2.10 qui est la dernière stable actuellement, Placez l'archive dans le répertoire /usr/ local/src, Décompressez l'archive dans ce répertoire, Placez-vous dans le répertoire des sources de SMStools.meinemullemaus. Vous allez maintenant pouvoir compiler NetSNMP et ce, en plusieurs étapes : Ici, pas de script de configuration, la compilation en elle-même dont voici la commande : make, L'installation de SMStools : make install. L'installation du daemon SMStools est terminée. La daemon se trouve dans le répertoire /usr/local/bin. Son fichier de configuration est dans le répertoire /etc. Configuration Je n'ai bien évidement par pu tester tous les portables qui existent mais la configuration que je vais présenter ici devrait fonctionner sur la plupart des téléphones portables récents. Les problèmes viendraient plus de la reconnaissance du téléphone en lui-même par le système Linux. Pour ma part, cela fonctionne bien avec le Sony Ericsson K610i. Le fichier de configuration est présenté sur le Listing 11. Avec cela, SMStools est capable de parler à notre téléphone pour envoyer des SMS. Utilisation L'utilisation est très simple, il suffit d'écrire un fichier avec les règles de formatage suivantes : première ligne: To:, un espace puis le numéro au format international donc sans 0 mais avec l'indicatif de pays. Cela donne par exemple : pour le , une ligne vide, le message sur plusieurs lignes éventuellement. Ce fichier est à placer dans le répertoire /var/ spool/sms/outgoing. Ce répertoire est lu toutes les secondes par le daemon. Quand il trouve un fichier au bon format, il l'envoie en utilisant le numéro de portable qui est sur la première ligne. Au cas où le message serait trop long, le daemon le coupe automatiquement en plusieurs SMS. Utilisation dans Par rapport à la configuration de présenté dans ce document, vous allez : modifier un contact pour ajouter le numéro de portable, ajouter deux commandes de notification. Je n'avais par touché à ces commandes, car celles d'origine fonctionnent très bien pour les s. En regardant le Listing 12, vous apprendrez comment configurer le contact. Les modifications sont simples : il faut mettre le numéro de portable dans la variable pager et ajouter une deuxième commande au niveau de la notification pour les services : notify-by-sms et pour les hosts : host-notify-by-sms. Vous allez maintenant définir les nouvelles commandes de notification. Elles sont à placer dans le fichier misccommands.cfg (Listing 13). Il ne reste plus qu'à redémarrer le daemon de pour appliquer les modifications. Autre notification par SMS Il est aussi possible, comme je le disais, de configurer pour être alerté par SMS depuis l'envoi d'un grâce à une passerelle vers SMS. La solution la plus propre pour cela est de mettre une autre adresse au niveau de la variable pager du contact et d'ajouter une deuxième commande de notification comme je viens de le faire pour les SMS. Cette commande utilisera l'adresse mise sur la variable pager. L'intérêt de définir une deuxième commande est que le texte de ce sera plus court pour qu'il puisse être contenu dans un SMS. Conclusion Vous venez de découvrir qui est un outil très simple à configurer grâce à son mécanisme de templates. Mais permet aussi d'aller beaucoup plus loin. Vous pouvez par exemple faire une configuration de serveurs redondants avec deux dont un est actif et l'autre passif. Le daemon est démarré sur les deux serveurs mais sur le serveur passif tous les checks sont désactivés sauf celui qui vérifié l'état du serveur principal. En cas de défaillance du serveur principal, il active tous les checks sur le serveur passif, puis les désactive quand le serveur principal revient en ligne. Vous pouvez également faire une configuration distribuée dans le cas où vous auriez trop de checks à faire pour un seul serveur. Imaginez un serveur qui s'occupe du matériel réseau et un autre des serveurs. Sur ces deux serveurs sont désactivées les notifications et l'interface Web. Toutefois, ils remontent leurs informations à un troisième serveur qui se chargent de faire l'interface avec les utilisateurs. Comme vous avez pu le comprendre, il y a un grand nombre de configurations possibles avec. Cet article ne présente que la partie visible de l'iceberg. Sur le réseau Le site officiel de : Un site pour trouver de nombreux plugins pour : Le site officiel de NetSNMP : Le site officiel de SMStools : À propos de l'auteur Guillaume Lohez est utilisateur de logiciels libres depuis plus de 10 ans et est administrateur systèmes et réseaux depuis 5 ans. 48 Linux+ 5/2008

10