# uname -a - Mot-clé - nagios

Push Nagios incidents to Cachet status page

Mathieu — Mon, 10 Aug 2015 21:45:00 +0200

Cachet is an opensource status page. It displays incidents, manually or automaticaly created to inform users of what is going on the monitored service.

Note that Cachet does not do any monitoring, that’s why Nagios will be used to send incidents events through its API.

The code can be downloaded at : https://github.com/mpellegrin/nagios-eventhandler-cachet

Prerequisites

Have a working Cachet installation
Have created some Cachet components to play with
Have a Nagios instance with PHP CLI and php-curl installed

Installation

Get a Cachet API key: Create a new user in Cachet dashboard, login with this user, and get the API key in his profile.
Copy cachet_notify to /usr/share/nagios3/plugins/eventhandlers (depending on your configuration)
Change URL and API key in cachet_notification source code
Try it: ./cachet_notify ‘My Cachet component’ ‘My nagios service’ CRITICAL HARD ‘The service is Critical’

Configuration

Make a Nagios command:

  define command {
      command_name    cachet_notify
      command_line    /usr/share/nagios3/plugins/eventhandlers/cachet_notify '$ARG1$' '$SERVICEDESC$' '$SERVICESTATE$' '$SERVICESTATETYPE$' '$SERVICEOUTPUT$'
  }

Add an event handler on your services:

  define service {
      service_description             My nagios service
      ...
      event_handler                   cachet_notify!My Cachet component
  }

Restart nagios

Addendum

Feel free to ask questions or open issues for this code on Github.

Nagios : quick and dirty patch to enable (force) SSL on check_mysql_health

Mathieu — Sat, 06 Jun 2015 16:10:00 +0200

Sometimes you don’t want to set up a VPN just to safely monitor your MySQL servers. Because SSL should be implemented in check_mysql_health, here is a quick and dirty patch for SSL connexion. I assume you already configured your MySQL server to use SSL if client wants to (or if user requires ssl).

File /usr/lib/nagios/plugins/check_mysql_health at line 1863, after the following block :

    } else {
      $self->{dsn} .= sprintf ";host=%s", $self->{hostname};
      $self->{dsn} .= sprintf ";port=%s", $self->{port}
          unless $self->{socket} || $self->{hostname} eq 'localhost';
      $self->{dsn} .= sprintf ";mysql_socket=%s", $self->{socket}
          if $self->{socket};

Add these lines :

    $self->{dsn} .= ";mysql_ssl=1";
    $self->{dsn} .= ";mysql_ssl_client_key=/etc/ssl/mysql/client.key";
    $self->{dsn} .= ";mysql_ssl_client_cert=/etc/ssl/mysql/client.crt";
    $self->{dsn} .= ";mysql_ssl_ca_file=/etc/ssl/mysql/ca.crt";

Where /etc/ssl/mysql/client.key is the path to client key, /etc/ssl/mysql/client.crt the path to client certificate, and /etc/ssl/mysql/ca.crt the path to the CA certificate.

It should work, while there is still no “SSL switch” on that plugin.

EDIT : actually there is an undocumented param named “—mycnf” which should allow you to enable SSL for client connection in a prettier way.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 5 : NSCA

Mathieu — Sun, 13 Oct 2013 16:04:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Munin.

Cet article est le dernier de la série.

Dans l’article précédent, nous avons vu comment configurer Munin pour qu’il collecte des données et affiche ses graphes. Il nous reste à présent à configurer la communication entre Munin et Nagios, grâce à l’agent NSCA.

Introduction

Tests passifs, tests actifs

Nagios distingue deux type de tests à effectuer sur les hôtes, par le biais de ses déclarations de services : les tests actifs et les tests passifs.

Les tests actifs sont les tests réalisés par Nagios via un de ses plugins : ça peut être le test d’un port ou le contrôle de la réponse d’un service. Ces tests sont synchrones (effectués à intervalle fixe).
Les tests passifs sont les tests dont les résultats sont reportés à Nagios par d’autres programmes : là ça sera NSCA. Ces tests sont asynchrones (effectués “quand on peut”, pas forcément régulièrement).

NSCA

NSCA est littéralement « Nagios Service Check Acceptor ». C’est un démon qui tourne en arrière plan, et qui va recevoir les résultats des tests passifs, pour le retransmettre à Nagios.

Pour plus de simplicité, NSCA sera installé sur la même machine que le serveur Maître de Nagios.

Munin <=> NSCA

Le serveur maître de Munin va communiquer à NSCA les résultats des tests grâce à la commande send_nsca, utilisant le protocole NSCA.

Pour encore plus de simplicité, nous allons supposer que le serveur maître de Munin et le serveur NSCA (et donc Nagios aussi) se trouvent sur la même machine (comme ça, pas besoin de chiffrer les communications entre Munin et NSCA).

NSCA <=> Nagios

NSCA va communiquer avec Nagios via un tube nommé, c’est à dire un fichier dans lequel il va écrire, et qui va être lu par Nagios à intervalle régulier.

On peut faire porter ce tube par une socket pour réaliser une installation de NCA et Nagios sur deux machines différentes, mais ce n’est pas le sujet de cet article.

Installation et configuration de NSCA

Installation

NSCA se trouve dans les dépôts : sudo apt-get install nsca

Configuration

La configuration de NSCA se trouve dans /etc/nsca.cfg. Voici les valeurs à retenir :

#Ne jouez pas à changer ça pid_file=/var/run/nsca.pid # Notre master Munin se trouve sur la même machine, donc on bind sur 127.0.0.1 et ça suffit server_address=127.0.0.1 # Il est important que cet utilisateur puisse écrire dans le tube nommé pour communiquer avec Nagios ! nsca_user=nagios # Ce fichier spécial devra aussi être mentionné dans la configuration de Nagios, et le nsca_user doit pouvoir y écrire command_file=/var/lib/nagios3/rw/nagios.cmd

Ouvrez le fichier /etc/init.d/nsca et vérifiez que le PIDFILE est le même que celui de la configuration :

PIDFILE="/var/run/nsca.pid"

Configuration de Munin

Ouvrez le fichier /etc/munin/munin.conf.

Normalement, vus avez déjà configuré un “contact” pour être avertit en cas de défaillance d’un service contrôlé par Munin. Nous allons à la suite en rajouter un second :

contact.nagios.command /usr/sbin/send_nsca -H localhost contact.nagios.always_send ok warning critical contact.nagios.max_messages 1

Petite information qui vous fera gagner une journée de travail : max_messages doit être à 1 sous Debian 7. Ceci parce que le NSCA des dépôts a été mis jour, et est devenu incompatible avec la version du protocole NSCA implémentée par Munin. On peut bidouiller NSCA pour corriger ça, mais la solution de contournement la plus simple est de n’envoyer qu’un message à la fois à NSCA.

Ici Munin enverra les résultats “OK”, “Warning” et “Critical” de ses module. Nous allons également faire en sorte qu’un Munin muet déclenche une erreur UNKNOWN chez Nagios, pour s’assurer que le “OK” correspond bien à un test “OK” et non à l’absence de “Warning” et de “Critical”.

Ok, on triche un peu. En fait, les tests de Munin sont synchrones. On a donc un mécanisme synchrone (Munin) qui va envoyer de manière synchrone les résultats au mécanisme asynchrone de collecte (NSCA). L’aspect synchrone va nous permettre de détecter le moment où on aurait dût recevoir un résultat, et alerter si ce n’a pas été le cas.

Configuration de Nagios

Communication avec NSCA

Ouvrez le fichier de configuration /etc/nagios3/nagios.cfg et vérifiez que la ligne suivante est bien présente et dé-commentée :

command_file=/var/lib/nagios3/rw/nagios.cmd

Les services

Si vous avez déjà redémarré les services après chaque modification de la configuration, vous pourrez voir dans les logs de Nagios les erreurs suivantes :

[1381670602] Warning: Passive check result was received for service 'some service' on host 'hostname.ext', but the service could not be found!

La bonne nouvelle c’est que Nagios reçoit les notifications de NSCA !

La mauvaise c’est qu’il ne peut pas le lier à un service et à un hôte, parce qu’ils ne sont tout simplement pas déclarés. Il va nous falloir déclarer un service Nagios pour chaque service Munin que nous lui transmettons, sinon celui-ci ne sera pas capable de le traiter.

Créez le fichier /etc/nagios3/conf.d/services/munin-services.cfg et placez à l’intérieur la configuration suivante :

# generic service template definition define service{ name generic-munin-service ; The 'name' of this service template use generic-service check_command return-unknown!"No Data from passive check" active_checks_enabled 0 ; Active service checks are disabled check_freshness 1 freshness_threshold 360 flap_detection_options n max_check_attempts 2 register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE! ;first_notification_delay 6 ; Delay first notification for false positives (will execute 2 checks : munin sends 1 check every 5 minutes) } define service { hostgroup_name munin service_description Disk latency per device :: Average latency for /dev/sda use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { service_description Disk latency per device :: Average latency for /dev/sdb use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Disk usage in percent use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Inode usage in percent use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description File table usage use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description eth0 errors use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified } define service { hostgroup_name munin service_description Exim Mailqueue use generic-munin-service notification_interval 0 ; set > 0 if you want to be renotified }

Ce fichier est bien évidemment à compléter selon les plugins et les checks que vous avez activé dans Munin. Le service_description est le nom complet du service dans Munin.

La configuration du template générique nous assure qu’une erreur “UNKNOWN : No data from passive check” sera retournée en cas d’absence de résultat après le délai du “freshness_threshold”, avec 2 essais avant d’alerter du problème.

Les groupes d’hôtes

Les plus attentifs d’entre-vous ont remarqué la présence d’un hostgroup dans la configuration, mais nous ne l’avons pas encore déclaré. Allons-y, rajoutez dans le fichier /etc/nagios3/conf.d/groups.cfg :

# Hostgroup for Munin define hostgroup { hostgroup_name munin alias Munin reporting clients }

Les hôtes

Maintenant qu’on a le hostgroup, il ne reste plus qu’à modifier vos fichiers /etc/nagios3/conf.d/hosts/*.cfg pour rajouter le hostgroup sur les hôtes sur lesquels munin-node est installé.

Débuggage

En principe, après avoir redémarré tous les services, vous devriez recevoir assez vite les notifications de NSCA et voir passer vos indicateurs du gris vers le vert dans Nagios.

Si ce n’est pas le cas et que ces derniers passent au orange, c’est qu’il y a un problème de communication entre Nagios et Munin. Mon problème principal a été le non démarrage de NSCA au démarrage de la machine, pour de histoires de PID que le script de démarrage n’arrivait à écrire ou à supprimer.

Il arrive aussi que le tube nommé soit inaccessible en écriture à l’utilisateur qui lance NSCA, vérifiez bien que l’utilisateur nagios est celui qui fait tourner à la fois Nagios et NSCA.

Enfin, pour vérifier que le problème ne vient pas d’une mauvaise configuration de Nagios, faites un envoi de données “manuellement” avec la commande send_nsca :

echo -e "monhote.ext\tNom complet du service Munin\t1\t0\n\n" | /usr/sbin/send_nsca -H localhost

Pour conclure

En conclusion, nous avons terminé notre installation de Munin, Nagios, et NSCA ! Munin communique à présent ses alertes à Nagios, et Nagios est capable d’alerter si ces alertes ne sont pas remontées. Le reste est dans les billets précédents !

N’hésitez pas à me faire part dans les commentaires des problèmes que vous pourriez rencontrer en déroulant cette suite d’articles, ou à me corriger si vous constatez des erreurs dans la série d’article.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 2 : Nagios

Mathieu — Sun, 07 Jul 2013 19:59:00 +0200

Voir l’ensemble des articles de la série — Voir l’article précédent : Introduction.

Dans l’épisode précédent, nous avons vu les généralités d’usage sur le monitoring, Nagios, et Munin.

Dans cette partie, je vais tenter de détailler la réalisation d’une configuration fonctionnelle de Nagios, avec quelques sondes, pour servir de base pour la suite.

Installation de Nagios

Je travaille sous Debian GNU/Linux par habitude. Avec ce système d’exploitation, il est très facile d’installer Nagios :

sudo apt-get install nagios3

Attention : la configuration pour Nagios ne s’écrit pas de la même façon selon la version majeure considérée. Ici pour la version 3, les fichiers de configuration seront différents de ceux pour Nagios 2, pensez à bien vérifier la version des exemples que vous copiez-collez sur Internet.

Nagios s’administre depuis une interface Web ; pour pouvoir y accéder, le paquet de Nagios installe automatiquement les dépendances permettant à un serveur Web de tourner (Apache 2 par défaut), mais vous pourriez avoir envie de faire autrement. Vérfiiez alors que vous avez bien un serveur web installé pour pouvoir faire tourner Nagios en CGI (python).

Nagios installe par défaut un ensemble de plugins pour les sondes mais pas seulement. Nagios est très modulaire, et permet de faire beaucoup de chose. Si vous avez besoin des plugins supplémentaires, ceux-ci sont dans les paquets nagios-plugins-* .

Par défaut, après l’installation Nagios est accessible à l’URL http://votreserveur/cgi-bin/nagios3/status.cgi. Le login et le mot de passe sont à changer avec la commande suivante htpasswd /etc/nagios3/htpasswd.users leloginsouhaite.

Où est la configuration ?

Le premier réflexe après avoir installé un logiciel, aussi automatisé que soit l’installation, c’est de regarder dans /etc/ si il y a pas un ou plusieurs fichiers de configuration.

Gagné, il y a /etc/nagios3/ et /etc/nagios-plugins/ .

Dans /etc/nagios3/ il y a la configuration générale de nagios : les hosts et les services à surveiller, l’interaction avec les systèmes externes, les personnes à prévenir en cas d’accident, etc.

Dans /etc/nagios-plugins/, il y a la configuration du comportement des plugins. Je m’en sers principalement pour avoir de la documentation sur les plugins disponibles et leurs arguments, mais vous pourriez en avoir besoin pour modifier le comportement d’un plugin, ou créer le vôtre.

C’est quoi ce bordel…

Si vous commencez à plonger dans la configuration de /etc/nagios3, vous allez vite déchanter : il y a des fichiers de configuration aux noms pas très évocateurs, de services par défaut et génériques qui ne veulent rien dire. Par de panique, on va vous aider.

Le point d’entrée de la configuration dans Nagios est le fichier /etc/nagios3/nagios.cfg. Pour des raisons évidentes, la configuration de Nagios n’est pas intégralement présente dans ce fichier. Nagios inclut tous les fichiers qui se trouvent dans le dossier /etc/nagios3/conf.d/ (et récursivement dans les sous-dossiers).

Les hôtes

Les hôtes dans Nagios sont les machines à surveiller. Ce sont des éléments identifiés par leur nom. Il peut y avoir des hotes “virtuels” qui ne correspondent pas à une machine en particulier mais à un ensemble de résultat provenant de sondes que vous pouvez configurer.

La configuration par défaut de Nagios définit un hôte générique. Cet hôte n’est pas affiché dans l’interface car c’est un “template” de configuration. Vous faites “hériter” vos hôtes de ce service générique qui contient tout ce dont la plupart des hôtes ont besoin, et vous y rajoutez votre grain de sel.

La configuration des hôtes dans Nagios se fait dans /etc/nagios3/conf.d/. je vous conseille de créer un dossier /etc/nagios3/conf.d/hosts/ et de créer ensuite un fichier par hôte, par commencer. Une fois que vous serez plus à l’aise avec le concept d’hôte générique, vous pourrez faire vos propres hôtes génériques, et factoriser un peu votre configuration.

Les services

Les services dans Nagios sont les appels aux sondes que vous allez définir. Ces sondes sont déclarées dans les fichiers de configuration de /etc/nagios-plugins/config/ pour pointer vers des exécutables (généralement en Perl ou en Python) présents dans le répertoire /usr/lib/nagios/plugins/, qui vont réaliser effectivement les tests.

Je vous conseille, pour définir vos services, de créer le dossier /etc/nagios3/conf.d/services/ et placer un fichier par service à l’intérieur.

Les sondes des services peuvent prendre des arguments. Le plus courant est de leur donner (implicitement) l’adresse de l’hôte à tester, mais on peut aussi passer explicitement des arguments, comme par exemple le port à tester. (Si jamais vous avez déplacé le port d’écoute de SSH. Comment ça vous l’avez pas fait ?)

Pour ceux qui en ont, les arguments des sondes sont déclarés dans /etc/nagios-plugins/config/.

Les groupes

Voilà le point central de votre configuration : les groupes. Les groupes sont déclarés dans /etc/nagios3/config/groups.cfg.

Un groupe dans Nagios est un moyen d’appliquer un ensemble de services à un hôte “d’un coup”. En gros, vous avez trois moyens d’attacher vos services à vos hôtes :

Quand vous déclarez vos hôtes, vous mentionnez explicitement les services qu’il doit posséder.
Quand vous déclarez les services, vous mentionnez explicitement les hôtes sur lesquels le service doit s’appliquer
Vous déclarez vos “groupes”, qui sont des ensembles de services, prêt à être appliqués à vos hôtes, vous spécifiez à quels groupes le service appartient, et vous spécifiez les hôtes présents dans le groupe.

Dans la suite, nous appliquerons la troisième solution.

Un petit exemple pour commencer

Sans commentaires, voici un petit exemple :

Groupes

/etc/nagios3/groups.cfg :

# A list of your web servers define hostgroup { hostgroup_name http-servers alias HTTP servers members host1 ; Link host to hostgroup } # A list of your ssh-accessible servers define hostgroup { hostgroup_name ssh-servers alias SSH servers members host1,host2 ; Link host to hostgroup }

Hôtes

/etc/nagios3/conf.d/hosts/host1.cfg :

define host { use generic-host ; Name of host template to use host_name host1 alias host1 address 192.168.1.11 ; Replace with your real host1 address ! }

/etc/nagios3/conf.d/hosts/host2.cfg :

define host { use generic-host ; Name of host template to use host_name host2 alias host2 address 192.168.1.12 ; Replace with your real host2 address ! }

Services

/etc/nagios3/conf.d/services/ssh.cfg :

# check that ssh services are running define service { hostgroup_name ssh-servers ; Link service to hostgroup service_description SSH check_command check_ssh_port!22 use generic-service notification_interval 0 ; set > 0 if you want to be renotified }

/etc/nagios3/conf.d/services/http.cfg :

# check that ssh services are running define service { hostgroup_name http-servers ; Link service to hostgroup service_description HTTP check_command check_http use generic-service notification_interval 0 ; set > 0 if you want to be renotified }

Toutes les sondes que vous voulez !

Dans l’exemple ci-dessus, j’ai utilisé deux sondes génériques : check_ssh_port et check_http. Toutes les sondes disponibles sont déclarées dans /etc/nagios-plugins/conf/, ces sondes se présentent sous la forme de “commandes” que l’on peut utiliser moment de la déclaration des services.

Les sondes déclarées appellent en général les exécutables qui se trouvent dans /usr/lib/nagios/plugins/. Souvent, plusieurs sondes sont déclarées pour un même exécutable, mais avec des paramètres différents (par exemple check_ssh et check_ssh_port qui permet de spécifier le port en argument).

Pour afficher les paramètres déclarés par les sondes, vous pouvez éditer les fichiers de configuration présents dans /etc/nagios-plugins/conf/.

Pour déclarer vos propres sondes à partir des exécutables, vous pouvez afficher les arguments disponible pour les exécutables de /usr/lib/nagios/plugins/ en lançant simplement le fichier exécutable avec le paramètre --help.

Les alertes

Pour l’instant notre Nagios est muet. Il peut alerter sur l’interface web, mais ne vous envoie pas de mails pour se plaindre que l’un des services est tombé.

Les alertes dans Nagios se configurent dans /etc/nagios3/conf.d/contacts.cfg, dans ce fichier sont définis les personnes à contacter en cas de problème, et quels sont les types d’alertes à recevoir par ces personnes.

Vous pouvez prendre exemple sur le contact par défaut pour créer vos propres contacts :

define contact { contact_name root alias Root service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email email root@localhost }

N’oubliez pas de rajouter vos nouveaux contact au groupe de contact de Nagios :

define contactgroup { contactgroup_name admins alias Nagios Administrators members root }

Une configuration plus fine peut être réalisée au niveau des alertes, ou de l’escalade des alertes, suivez ce lien pour en savoir plus : Notifications Escalations.

Pour conclure

En guise de conclusion et pour aller plus loin, je vous conseille de faire comme vous en avez l’habitude sous Debian : lire les documentations qui sont incluses avec le paquet dans /usr/share/docs/nagios*.

Dans le prochain billet de cette série, je détaillerai l’installation et la réalisation d’une configuration simple pour Puppet, qui nous servira pour pouvoir installer facilement Munin sur l’ensemble des machines du parc.

Ah oui, n’oubliez pas de relancer le service nagios3 après avoir changé la configuration pour l’appliquer !

Lire la partie suivante : Puppet.

Voir l’ensemble des articles de la série.

Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 1 : introduction

Mathieu — Thu, 04 Jul 2013 19:33:00 +0200

Voir l’ensemble des articles de la série.

Le monitoring. Graal des administrateurs système dès qu’un parc de machines commence à se constituer. Avec ce petit guide, vous allez découvrir que même avec seulement trois machines, on peut faire du monitoring. Même avec des machines mobiles ou pas toujours allumées, on peut faire du monitoring. Même avec les machines des clients, on peut faire du monitoring.

Pour pouvoir intervenir en cas de problème, il faut déjà savoir qu’il y a un problème, c’est le but du monitoring.

Cas d’étude

Vous gérez un parc. Ça peut être vos propres machines, ou les machines de vos clients. Vous pouvez avoir des serveurs ou des postes de travail, ces machines ne sont pas forcément toujours allumées, mais quand elles fonctionnent il faut avoir un retour sur leur état de santé. Vous aimeriez bien centraliser tout ça, mais vous ne savez pas comment faire. Voici comment.

Définitions / Présentations

Lorsqu’on parle de monitoring, on parle bien entendu de surveillance du système. Mais pour s’assurer de l’état du système, il faut deux choses :

Un collecteur (“node”), qui va au moyens de différentes sondes remonter les informations brutes sur les composants du système à surveiller. Ça peut être très bas niveau la température du CPU, ou une sonde élaborée comme le temps de réponse à un ping. Dans tous les cas, le collecteur seul ne suffit pas à dire “je fais du monitoring”.

Le concentrateur (“master”), qui va récupérer les informations du collecteur, et générer les alertes, le concentrateur va pouvoir vous afficher une vue synthétique de l’ensemble des machines que vous surveillez.

Dans ce petit guide, le collecteur sera Munin (en partie), et le concentrateur sera Nagios 3 (en partie). Je dis “en partie” parce que tout n’est pas aussi simple, et que Nagios et Munin vont assurer des rôles complémentaires étant chacun dans leur domaine à la fois “collecteur” et “concentrateur”.

Munin : le surveillant dans la cour

Munin est à la base un collecteur, c’est à dire qu’il va, au moyens de sondes déployées sur les postes à surveiller (“munin-node”), écrire des fichiers RRD. Ces fichiers pourront ensuite être exploités par un concentrateur (“munin” tout court) pour dessiner des graphes (“munin-graph”) et/ou envoyer des alertes à des systèmes externes.

Nagios : le mirador

Même si on peut installer un client Nagios servant de collecteur sur les postes à surveiller, Nagios n’a pas pour vocation d’observer directement les systèmes. Il est prévu pour effectuer des sondages “externes” des systèmes (tel port est-il ouvert, tel service répond-il correctement…).

De ce fait, Nagios va être limité dans les accès au système (comment remonter des alertes sur la température du disque, en conservant un point de vue externe ?) et va donc dépendre des sondes locales, comme celles fournies par Munin.

Puppet : le directeur de l’établissement

On ne l’a pas encore présenté. Puppet est un logiciel permettant de répliquer de la configuration sur un ensemble de postes. Puppet permet de définir une certaine granularité dans la configuration : il est possible de créer des “groupes” de configuration, pour donner aux postes gérés la configuration qu’il leur faut, potentiellement différente d’une machine à l’autre (un serveur web et un serveur mail n’ont pas les mêmes besoins).

Le fonctionnement

En résumé

Nagios va collecter des informations externes sur le système et recevoir des alertes de Munin.

Munin (“munin-node”) va collecter des informations plus précises sur le fonctionnement de la machine “à chaud”.

Un “master” Munin va centraliser toutes les informations récoltées par les sondes “munin-nodes” et envoyer les alertes à Nagios.

Puppet va se charger d’uniformiser la configuration sur l’ensemble des machines sur lesquelles Munin (munin-node) est installé (mieux que le copier/coller : on change une fois et c’est toutes les machines qui changent).

Les machines

Les machines que l’on suppose présentes sont :

Les machines à administrer (“nodes”) sur lesquelles on mettra les “munin-nodes” et les “puppet-nodes”.

Le “puppet-master” qui va envoyer aux “nodes” la configuration à appliquer

Le “master” Munin qui va centraliser les informations des sondes, et éventuellement faire des graphes.

Le concentrateur nagios, qui va également effectuer les tests externes sur les machines.

Notez que le Puppet master, le master Munin, et Nagios peuvent être portés par la même machine (puppet master, master munin, nagios).

Dans la partie suivante

Dans la prochaine partie, nous verront comment installer et configurer Nagios et ses sondes. Nous verront ensuite dans les parties suivantes le détail de la configuration de Munin, sa communication avec Nagios, et la réplication de sa configuration avec Puppet.

Lire la partie suivante : Nagios.

Voir l’ensemble des articles de la série.