Le monitoring sous Debian avec Nagios et Munin (Puppet en guest star) : de A à Z - Partie 4 : Munin
Par Mathieu le lundi 19 août 2013, 22:29 - Informatique - Lien permanent
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 :
Vous pouvez ajouter plusieurs de ces lignes, avec le nom d’utilisateur et l’adresse mail que vous souhaitez.
contact.root.command mail -s "Munin notification" root@localhost
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 :
Évidemment, changez l’adresse IP mentionnée ici par l’adresse IP de vos nodes à vous. ;)
[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
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 :
Précisez qui sera autorisé à venir collecter les données via le paramètre
host_name node01
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 :
Notez la variable
#
# 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
@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”. ;)
