# uname -a - Mot-clé - serie-monitoring-nagios-munin-puppet

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 4 : Munin

Mathieu — Mon, 19 Aug 2013 22:29:00 +0200

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

Dans l’article précédent, nous avons vu une manière simple de configurer Puppet pour des opérations de réplication base de la configuration.

Dans cette partie nous allons détailler l’installation et la configuration de Munin et de ses plugins, en utilisant bien sûr notre Puppet fraîchement installé.

Principe

Munin est basé tout comme Nagios et Puppet sur le modèle maître-esclave : le “master” Munin va récupérer à intervalle régulier les données des “nodes” et remplir des fichiers contenant les données reçues. Ces fichiers sont au format RRD, qui est un standard utilisé par beaucoup de logiciels de collecte de données.

Nous allons donc devoir configurer d’une part le “master” et ensuite les “nodes”. Pour les nodes, nous utiliserons Puppet pour répliquer la configuration.

Munin, tout comme Nagios, a une architecture modulaire basée sur des plugins. Cela veut dire que le programme principal ne fait que de la collecte et de la transmission de données. Toutes les données collectées sont en réalité fournies par des plugins, qu’il va falloir configurer un par un. Rassurez vous, la plupart des plugins possèdent déjà une configuration par défaut.

Pour la suite, je vais supposer que le serveur accueillant le master munin est nommé “master” sur le réseau et ceux accueillant les nodes “node01”, “node02”, etc. Je vais aussi supposer que vous avez correctement installé Puppet sur l’ensemble des futurs nodes Munin.

Note importante : les données qui sont échangées entre les nodes Munin et le Master ne sont pas chiffrées. Si c’est un problème pour vous, vous devriez étudier attentivement la configuration TLS pour Munin.

Le “master”

L’installation du master Munin ne présente pas de difficultés particulières : sudo apt-get install munin

Munin possède une interface de visualisation de ses graphes, mais il faut configurer le serveur web pour y accéder. La configuration pour Apache fournie avec le paquet est prête à être installée dans /etc/munin/apache.conf

Configuration générale

Le fichier de configuration principal se trouve dans /etc/munin/munin.conf

La configuration par défaut n’a pas besoin d’être beaucoup retouchée. Renseignez toutefois les adresses de contact, par exemple :

contact.root.command mail -s "Munin notification" root@localhost

Vous pouvez ajouter plusieurs de ces lignes, avec le nom d’utilisateur et l’adresse mail que vous souhaitez.

Configuration des nodes

Vers la fin du fichier /etc/munin/munin.conf , vous trouverez un exemple de configuration pour un node en local. Nous allons rajouter les nôtres !

Tout d’abord, les nodes en eux même, il s’agit simplement de les déclarer à la suite de cette façon :

[node01] address 172.16.0.1 use_node_name yes [node02] address 172.16.0.2 use_node_name yes [node03] address 172.16.0.3 use_node_name yes

Évidemment, changez l’adresse IP mentionnée ici par l’adresse IP de vos nodes à vous.

Configuration des groupes de nodes

Si votre parc est hétérogène, vous aurez rapidement très envie de faire des groupes pour rassembler vos hôtes et naviguer facilement dans les graphes.

Pour cela, toujours dans le fichier /etc/munin/munin.conf, il suffit de rajouter un “pseudo-hote” de cette façon :

[monparc;Totals] # Pour les graphes totaux update no # Pas de collecte de données sur cet hôte [monparc;] # Groupement des nodes node_order Totals node01 node02 node03

N’oubliez pas de relancer Munin après avoir modifié la configuration : service munin restart

Les “nodes”

D’abord la configuration pour un node, et après on s’occupera de la réplication de la configuration avec Puppet.

Configuration générale

Le nodes n’ont besoin que de très peu de configuration, pratiquement tout est fait par les plugins, et la récupération des données est faite par le Master.

Dans le fichier /etc/munin/munin-node.conf, renseignez si besoin le nom du node dans le paramètre host_name :

host_name node01

Précisez qui sera autorisé à venir collecter les données via le paramètre allow ou cidr_allow si vous autorisez tout votre sous-réseau (note : fonctionne aussi en ipv6) :

allow ^172\.16\.0\.200$ # On suppose que le Master est à l'adresse 172.16.0.200 cidr_allow 172.16.0.0/16 # Là on autorise carrément tout le sous-réseau /16

Enfin, vérifiez bien que le node est en écoute sur toutes les adresses :

bind *

N’oubliez pas de relancer munin-node après avoir changé la configuration : service munin-node restart

Les plugins

L’ensemble des plugins disponibles réside dans le dossier /usr/share/munin/plugins/, il est fortement déconseillé de les lancer directement.

Pour activer un plugin, il suffit de créer un lien symbolique dans le dossier /etc/munin/plugins/, et de relancer le démon munin-node. par exemple :

ln -s /usr/share/munin/plugins/apt /etc/munin/plugins/apt

service munin-node restart

Pour tester l’exécution d’un plugin, il suffit de lancer la commande munin-run suivi du nom du plugin. Le plugin doit être activé et c’est le nom du lien symbolique qui est à spécifier lors de l’appel à munin-run. munin-run a d’autres options intéressantes, comme par exemple “munin-run <nomduplugin> config”, qui permet de lister tous les paramètres spécifiques à un plugin.

Certains plugins prennent des paramètres directement depuis le lien symbolique. Par exemple le plugin “ping” se nomme “ping_” mais ne fonctionnera pas si votre lien symbolique s’appelle “ping_”. Le nom du lien symbolique doit préciser l’hôte à pinguer :

ln -s /usr/share/munin/plugins/ping_ /etc/munin/plugins/ping_ipv4.google.com

À noter que ça marche aussi pour un ping en ipv6 :

ln -s /usr/share/munin/plugins/ping_ /etc/munin/plugins/ping6_ipv6.google.com

De la configuration peut être nécessaire pour faire remonter les alertes des plugins. Dans le dossier /etc/munin/plugins-conf.d/ se trouve la configuration des plugins. je vous conseille de faire un fichier de configuration par plugin, nommé comme le plugin présent dans /etc/munnin/plugins/. On peut y configurer l’ensemble des paramètres retournés par la commande munin-run <nomduplugin> config à l’exception qu’il faut rajouter “env.” devant et préciser le nom du plugin ciblé. Par exemple :

[ping_*] env.ping_warning 0.030 env.ping_critical 0:0.100 env.packetloss_warning 1 env.packetloss_critical 10

Et comme d’habitude, pour aller plus loin, rien de tel qu’un petit tour dans /usr/share/doc/munin-node/

Un coup de Puppet magique !

Ça y est, on est calé sur la configuration des nodes ! Et si on répliquait ?

Reprenons les fichiers que nous avons préparés dans la partie précédente. Le fichier /etc/puppet/manifests/classes/munin.pp contient le prototype pour notre configuration. nous allons rajouter dans ce fichier de quoi paramétrer directement les nodes Munin :

class munin { # S'assurer que munin-node soit bien toujours à la dernière version des dépôts disponible package {'munin-node': ensure => 'latest', } # S'assurer que le démon munin-node tourne sur la machine service {'munin-node': ensure => 'running', enable => 'true', hasrestart => 'true', require => Package['munin-node'], } # En cas de modification de la configuration, redémarre munin-node file { '/etc/munin/munin-node.conf': ensure => 'file', notify => Service['munin-node'], # this sets up the relationship mode => 644, owner => 'root', group => 'root', require => Package['munin-node'], content => template('munin/munin-node.conf.erb'), # Ça on explique juste après } # On configure un plugin qui n'est pas par défaut, histoire de dire qu'on l'a fait # Le lien symbolique file { '/etc/munin/plugins/apt': ensure => 'link', group => '0', mode => '777', owner => '0', target => '/usr/share/munin/plugins/apt', notify => Service['munin-node'], # Ah oui, si on change ce fichier, on redémarre munin-node } # La configuration file { '/etc/munin/plugin-conf.d/apt': ensure => 'present', group => '0', mode => '644', owner => '0', content => "[apt]\nenv.pending.warning 0:0", notify => Service['munin-node'], # Là aussi on redémarre } }

Parlons de template('munin/munin-node.conf.erb'). Puppet nous permet d’utiliser des templates de configuration pour éviter d’avoir à fournir tout le contenu du fichier de configuration au milieu des règles Puppet. C’est le cas pour le fichier /etc/munin/plugin-conf.d/apt, mais pour ce fichier qui est volumineux et nécessite l’emploi d’une variable, créez le dossier munin dans le dossier /etc/puppet/templates/ et remplissez le avec le contenu suivant :

# # Example config-file for munin-node # log_level 4 log_file /var/log/munin/munin-node.log pid_file /var/run/munin/munin-node.pid background 1 setsid 1 user root group root # Regexps for files to ignore ignore_file [\#~]$ ignore_file DEADJOE$ ignore_file \.bak$ ignore_file %$ ignore_file \.dpkg-(tmp|new|old|dist)$ ignore_file \.rpm(save|new)$ ignore_file \.pod$ host_name <%= @hostname %> allow ^172\.16\.0\.200+$ host * port 4949

Notez la variable @hostname employée dans le fichier, et qui doit être déclarée dans le node Puppet (voir ci-après).

Finalement, n’oubliez pas de créer un “node” Puppet dans le dossier /etc/puppet/manifests/nodes/ pour chaque node Munin, et de le configurer comme dans l’exemple :

node 'node01' { $hostname = 'node01' include munin }

Sinon la configuration ne sera tout simplement pas propagée par Puppet.

Pour conclure

Nous avons terminé notre petit tour de la configuration de Munin. Nous avons répliqué les nodes Munin avec Puppet, mais il nous manque encore quelque chose pour terminer le travail : pour l’instant notre Nagios est toujours muet et les alertes de Munin vous parviennent, mais ne sont pas centralisées dans Nagios.

C’est l’objet de la dernière partie : NSCA. Nous terminerons la configuration de Nagios pour mettre en place des contrôles passifs, et nous ferons le lien entre Munin et Nagios, comme “par magie”.

Lire la partie suivante : NSCA.

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 3 : Puppet

Mathieu — Sat, 17 Aug 2013 16:00:00 +0200

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

Dans l’article précédent, nous avons vu comment écrire une configuration de base pour Nagios.

Dans cette partie, je vais aborder un sujet un peu transverse mais nécessaire à la création de notre solution d’ensemble : Puppet.

Introduction

Puppet est un logiciel de gestion de configuration. C’est à dire qu’il permet de répliquer et conserver à l’identique un ensemble de paramètres (des fichiers de configuration) sur un ensemble de machines.

Puppet a été créé pour un besoin simple : répliquer de la configuration à grande échelle sur un ensemble de machines, et en assurer la consistance. Nous allons principalement l’utiliser pour répliquer notre configuration de Munin sur l’ensemble des machines du parc, pour faciliter le déploiement de notre solution de monitoring.

Puppet fonctionne sur le modèle maître-esclaves : un serveur principal va contenir l’ensemble des paramètres à répliquer, et des serveurs esclaves vont interroger le serveur maître pour récupérer leur configuration. Il est possible de configurer le maître afin de différencier la configuration fournie à chaque esclave.

La communication entre le maître et ses esclaves est chiffrée et signée (le maître connaît ses esclaves, les esclaves connaissent leur maître), évitant que des informations sensibles ne se baladent sur le réseau, ou ne soit fournies accidentellement à des tiers.

Éléments en présence

Nous allons considérer les éléments suivants :

Le maître, aussi appelé PuppetMaster, est la machine qui va stocker les configurations à répliquer et fournir ce dont ellesont besoin aux machines esclaves.
Les machines esclaves, ou “clients Puppet”, sont les machines sous le contrôle du PuppetMaster, elles vérifient périodiquement auprès du PuppetMaster si leur configuration a besoin d’être mise à jour et appliquent les directives fournies par le PuppetMaster.

Pour ce tutoriel, nous allons considérer deux machines : le PuppetMaster que je vais appeler “master” et une machine cliente que je vais appeler “slave01”.

Je suppose que les machines “master” et “slave01” sont correctement mises en place dans le parc (qu’elles sont présentes dans le fichier /etc/hosts ou qu’elles ont un enregistrement DNS valide). Je suppose également que le FQDN des machines est correct (mis en place dans /etc/hostname ou avec la commande hostname -b).

Installation du Maître et de l’Esclave

Installation du Maître

À noter que dans le cas de la configuration qui est décrite, le maître ne sera pas son propre esclave. Il est néanmoins possible de gérer certains aspects de la configuration du maître via le maître lui-même en effectuant après l’installation du maître l’installation d’un esclave sur la même machine (mais attention aux migraines).

Sous Debian, Puppet est dans les dépôts. Pour installer le maître il suffit de taper : sudo apt-get install puppetmaster

Pour des raisons de sécurité, le PuppetMaster n’est pas configuré pour se lancer au démarrage de la machine. Éditez le fichier /etc/defaults/puppetmaster et placez la variable START à “yes”.

Lancez ensuite le serveur maître de Puppet avec la commande service puppetmaster start

Installation de l’esclave

De la même manière que le maître, lancez sur l’esclave : sudo apt-get install puppet

Comme pour le PuppetMaster, il faut préciser à l’esclave Puppet qu’il doit se lancer au démarrage de la machine : éditez /etc/defaults/puppet et placez la variable START à “yes”.

Ouvrez à présent le fichier de configuration /etc/puppet/puppet.conf et rajoutez la ligne suivante dans la section [main] :

server=master

J’utilise ici le domaine court (“master”) en supposant que celui-ci se résout correctement, mais vous pouvez mettre l’adresse IP du serveur “master” ou son FQDN à la place

C’est le moment d’essayer notre configuration ! Lancez la commande :

sudo puppetd --test --waitforcert 60

Si tout va bien, l’esclave va interroger le maître pour récupérer sa configuration. Comme c’est la première fois qu’il le fait, l’esclave va attendre que son certificat soit signé par le maître, qui le reconnaîtra alors comme un de ses esclaves.

Pour débloquer la situation, lancez la commande suivante sur le maître :

puppet cert --list

Vous devriez alors voir une liste de certificats en attente de signature. Toujours sur le maître, signez le certificat de votre esclave :


puppet cert --sign slave01

Sur l’esclave, la situation se débloque, et il vous informe que son certificat a été signé, tout est prêt !

Lancez finalement le démon Puppet sur l’esclave :

service puppet start

Le lancement du démon est nécessaire pour une propagation automatique des opérations que nous allons faire sur le maître. Un lancement manuel de la mise à jour de l’esclave peut cependant être fait avec la commande puppetd --test .

Comment ça marche ?

Sur le Maître, le point d’entrée principal de la configuration est /etc/puppet/manifests/site.pp

Le répertoire /etc/puppet/templates/ sert à stocker les templates de configuration qui pourront être lu par le moteur de Puppet (plus pratique de fournir le chemin vers un fichier template plutôt que de renseigner le contenu du fichier au milieu des règles de Puppet).

Le répertoire /etc/puppet/modules/, oubliez le pour l’instant.

Notre modèle de configuration pour la suite

Comme nous ne souhaitons pas mettre TOUTE la configuration dans /etc/puppet/manifests/site.pp, nous allons créer des répertoires dans le dossier manifests et inclure les fichiers qui sont présents dans ces répertoires, histoire de ranger un peu.

Créez les dossiers classes et nodes dans le dossier manifests .

Le dossier classes contiendra les éléments de configuration génériques, potentiellement paramétrables, que nous allons appliquer à nos esclaves.

Dans le dossier nodes, je vous conseille de créer un fichier par esclave, afin de personnaliser efficacement les classes requises pour chacun des esclaves.

Le fichier /etc/puppet/manifests/site.pp contiendra donc les appels aux fichiers présents dans ces répertoires :

# import many manifest files with node definitions import 'classes/*.pp' import 'nodes/*.pp'

Et nous auront donc dans le dossier /etc/puppet/manifests/classes un fichier munin.pp qui ressemblera à ça :

class munin { ... }

Et dans le dossier /etc/puppet/manifests/nodes un fichier slave01.pp qui ressemblera à ça :

node 'slave01' { $hostname = 'slave01' include munin }

C’est tout ! La configuration des esclaves pour servir de nœuds Munin via Puppet sera détaillé dans le prochain article.

À noter : La commande “import” de Puppet ne fait que déclarer les fichiers à lire, la commande “include” exécute la classe et donc applique effectivement la configuration du fichier.

Pour aller plus loin avec Puppet

Pour aller plus loin avec Puppet, vous pouvez lire la documentation issue du site de Puppetlabs.

Pour conclure

Nous avons posé les bases de notre solution de monitoring, notre serveur Nagios est en place, et Puppet est prêt à répliquer la configuration des nœuds Munin. Il nous reste à créer cette configuration, et à effectuer le lien entre le Master Munin et Nagios, pour que les alertes puissent remonter.

Dans le billet suivant, nous détaillerons la configuration des nœuds Munin avec Puppet et la configuration du Master Munin pour les alertes.

Lire la partie suivante : Munin.

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.