Blog

Installation de Collectd, Graphite et Grafana - Partie 1

Écrit le 24 07 2017 par Kévin MET _

Ce tutoriel sera séparé en plusieurs parties sinon il risque d'être un peu trop indigeste. Comme le titre l'indique, nous allons voir comment installer et configurer Collectd, Graphite et Grafana sur des serveurs sous Debian (Jessie et Stretch). Dans cette première partie nous allons nous attarder sur la partie Collectd. Ensuite nous verrons comment configurer Graphite et Grafana dans une seconde partie puis nous verrons comment créer nos premiers graphiques dans Grafana dans une troisième partie. Nous verrons ensuite comment collecter des données spécifiques en utilisant un script maison dans une quatrième partie et enfin on abordera le plugin java et plus particulièrement la partie GenericJMX afin de monitorer une application en Java via JMX dans une cinquième partie. Si j'ai le temps, je ferais une sixième et dernière partie sur Seyren qui se connecte à Graphite afin de faire de l'alerting en fonctions de certains seuils.

Afin de vous faire une idée globale du sujet voici le rôle de chaque composant de cette stack :

  • Collectd : Il réalise la collecte des données sur les différents serveurs
  • Graphite : Il concentre les données dans une base whisper (assez similaire à du rrd) via carbon-cache et présente une API REST à Grafana afin d'utiliser les données en base
  • Grafana : Il utilise l'API de graphite afin de mettre en forme différents types de graphiques
  • Seyren : Il utilise également l'API de graphite afin de générer des alertes en cas de dépassement de certains seuils

Présentation de Collectd

Collectd permet de collecter des données de multiples sources et de les agréger sous plusieurs types de stockage. Dans notre cas, il s'agira de ces bons vieux fichiers rrd. Collectd est un logiciel très léger auquel on ajoute un système de plugin qui permet de collecter certains types de données. Par exemple le plugin load permet de collecter le load average sur un serveur. Il existe un grand nombre de plugins et cela permet de couvrir des besoins très variés comme nous allons le voir dans les différentes partie de cette série. Dans notre série nous allons utiliser une architecture de type client/serveur dans laquelle un serveur va collecter les données de tous les clients. Nous allons configurer un seul serveur et un seul client avec les informations suivantes :

  • Serveur -> hostname : serveur.mnt-tech.fr ip : 11.22.33.44
  • Client -> hostname : client1.mnt-tech.fr

Installation et configuration de collectd sur le serveur

Dans cet exemple, mon serveur est sous Debian Stretch mais cela ne change pas grand chose car la configuration est la même. On commence par une basique installation de paquets :


apt install collectd collectd-utils

On va ensuite éditer le fichier de configuration principal, /etc/collectd/collectd.conf :

On commence par changer la variable Hostname (qui est par défaut à localhost) pour indiquer le hostname du serveur. Dans mon cas :


Hostname "serveur.mnt-tech.fr"

On peut également changer le BaseDir pour le stockage des rrd qui seront collectés si on estime que l'on va avoir un gros volume (beaucoup de serveurs à superviser avec beaucoup de points de supervision). Par défaut sur Debian, il s'agit du dossier /var/lib/collectd. Dans mon cas je n'y touche pas.

L'option TypesDB permet de spécifier un ou plusieurs fichiers spécifiant le type de données collectées. Par défaut, il s'agit du fichier standard /usr/share/collectd/types.db et du fichier vide /etc/collectd/my_types.db qui permet d'ajouter les définitions de nouvelles données mais on verra ce point plus en détails dans la quatrième partie de cette série.

Pour le reste de la configuration, on va laisser les valeurs par défaut car cela me convient très bien pour cet exemple mais je vous encourage à aller voir le man de collectd.conf (5) qui est vraiment super détaillé. En gros, on peut définir un intervalle global qui définit l'intervalle de temps entre lequel les sondes seront appelées par collectd et cet intervalle peut également être définit par plugin. Je vous épargne les détails et je vous laisse chercher vous même le reste des options disponibles.

Pour simplifier cet exemple, nous allons nous concentrer uniquement sur le load, on va donc commenter tous les autres plugins qui ne le seraient pas par défaut à par le plugin syslog qui permet d'envoyer les logs de collectd dans syslog et le plugin rrdtool qui permet d'envoyer les valeurs dans des fichiers rrd. Le plugin load renvoie les valeurs du load average à 1 minute, 5 minutes et 15 minutes, la base quoi. On ne touche pas aux réglages par défaut de ce plugin, c'est à dire qu'il va faire un appel à la fonction getloadavg() toutes les 10 secondes car c'est la valeur globale de l'option Interval. Par défaut, dans le fichier de configuration fournit avec le paquet Debian, il existe une configuration prédéfinit pour le plugin df, il faut donc également commenter cette configuration.

Une fois qu'on a fait tout cela ,on relance collectd :


systemctl restart collectd.service 

On vérifie également les logs de collectd en faisant un tailf chaîné avec un grep pour être sur que tout est OK :


tailf /var/log/syslog | grep -i collectd

Si tout est ok, on devrait avoir un fichier rrd dans le dossier /var/lib/collectd/rrd/ :


ls -l /var/lib/collectd/rrd/serveur.mnt-tech.fr/load/
total 432
-rw-r--r-- 1 root root 441816 Jul 23 16:08 load.rrd

On peut même commencer à voir les valeurs bruts des mesures avec rrdtool et son option dump:


rrdtool dump /var/lib/collectd/rrd/serveur.mnt-tech.fr/load/load.rrd | grep -v NaN

On peut ainsi voir que collectd collecte bien 3 valeurs shortterm, midterm et longterm qui correspondent bien à nos 3 valeurs habituels du load average.

On peut donc continuer et configurer maintenant le plugin network en tant que serveur qui nous permettra de recevoir les données provenant des collectd clients. On commence par dé-commenter la ligne LoadPlugin network. Ensuite, il existe plusieurs façons de le configurer et si vous êtes dans un réseau qui vous appartient de bout en bout il est beaucoup plus simple de laisser passer le trafic en clair. Dans ce cas, il suffit d'utiliser cette simple configuration :


<Plugin network>
	Listen "11.22.33.44"
</Plugin>

Dans ce cas, votre serveur écoutera en UDP sur l'adresse 11.22.33.44 et le port 25826 et acceptera tous les paquets correctement formés. Il faut donc bien faire attention à la configuration de votre pare-feu dans ce type de configuration. Cela présente l'énorme avantage de pouvoir faire des tcpdump pour voir ce qu'il se passe et voir les données passées en clair mais ce n'est pas forcément possible pour tout le monde. Dans mon cas, les paquets passent par internet et je souhaite donc pouvoir chiffrer et accepter uniquement les paquets provenant de mes clients. Nous allons donc utiliser la configuration suivante :


<Plugin network>
	<Listen "11.22.33.44">
		SecurityLevel Sign
		AuthFile "/etc/collectd/passwd"
		Interface "eth0"
	</Listen>
</Plugin>

Les options sont, je pense, assez explicites pour ne pas avoir besoin de les expliquer. La seule difficulté réside dans le format du fichier d'authentification qui se présente sous la forme suivante :


user1:password1
user2:password2

Dans mon exemple avec un seul client je vais donc le définir comme cela :


# cat /etc/collectd/passwd

client1.mnt-tech.fr:monpasswordencarton

Une fois que c'est fait, on peut relancer collectd encore une fois et vérifier dans les logs que tout se passe bien :


systemctl restart collectd.service 

Si tout est ok, on devrait pouvoir voir que collectd écoute bien en UDP sur 25826


# netstat -ntulape | grep 25826
udp        0      0 11.22.33.44:25826     0.0.0.0:*                           0          9717748    19549/collectd 

C'est bon signe, on va donc pouvoir configurer notre client !

Installation et configuration de collectd sur le client

Comme pour le serveur, on commence par installer les paquets collectd et collectd-utils :


apt-get install collectd collectd-utils

Ensuite, on change la valeur de Hostname, dans mon cas, j'indique :


Hostname "client1.mnt-tech.fr"

On dé-commente ensuite tous les plugins sauf load, syslog, rrdtool et network comme sur le serveur et on va pouvoir configurer le plugin network. Dans le cas d'une configuration en clair, on utilise ce simple bloc :


<Plugin network>
	Server "11.22.33.44"
</Plugin>

Dans le cas où on a utilisé le chiffrage et la signature des paquets, on utilise ce bloc :


<Plugin network>
	<Server "11.22.33.44">
		SecurityLevel Sign
		Username "client1.mnt-tech.fr"
		Password "monpasswordencarton"
		Interface "eth0"
	</Server>
</Plugin>

Si tout se passe bien, on devrait obtenir un nouveau dossier portant le nom de la variable Hostname du client dans le dossier /var/lib/collectd/rrd/ sur le serveur :


# ls /var/lib/collectd/rrd/
client1.mnt-tech.fr  serveur.mnt-tech.fr

C'est donc la fin de la mise en place de collectd sur le serveur et le client. Dans cet exemple, j'ai délibérément utilisé un seul plugin pour simplifier la mise en place au maximum mais il existe un tas de plugins qui sont très bien documentés dans le man de collectd.conf (5).

Petite différence entre Jessie et Stretch

Il existe tout de même une petite différence entre la version collectd de Debian Stretch et celle de Debian Jessie. Sous Jessie, collectd est lancé par collectdmon, un espèce de supervisor qui lance et vérifie que le démon tourne bien et le relance dans le cas contraire. Sous Stretch, on utilise la fonction Restart=always disponible dans systemd afin de relancer le démon en cas de crash. Ce n'est pas très important mais c'est toujours sympa de le savoir si on supervise les process avec nagios ou autre. Voici le fichier de définissant le service :


[Unit]
Description=Statistics collection and monitoring daemon
After=local-fs.target network.target
Requires=local-fs.target network.target
ConditionPathExists=/etc/collectd/collectd.conf
Documentation=man:collectd(1)
Documentation=man:collectd.conf(5)
Documentation=https://collectd.org

[Service]
Type=notify
NotifyAccess=main
EnvironmentFile=-/etc/default/collectd
ExecStartPre=/usr/sbin/collectd -t
ExecStart=/usr/sbin/collectd
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Intégration avec Nagios

On peut également utiliser un petit binaire bien pratique nommé collectd-nagios qui permet de faire des requêtes via un socket de collectd sur les valeurs récupérées par ce dernier. Il renvoie une sortie qui s'intègre parfaitement à nagios comme dans l'exemple suivant :


# collectd-nagios -s /var/run/collectd-unixsock -n  load/load -H serveur.mnt-tech.fr -d shortterm -w 0:1 -c 1:5 -g none

WARNING: 0 critical, 1 warning, 0 okay | shortterm=1.820000;;;;

Pour pouvoir utiliser cet outil il faut auparavant activer le plugin unixsock de collectd et configurer ce plugin. J'utilise la configuration par défaut :


<Plugin unixsock>
    SocketFile "/var/run/collectd-unixsock"
    SocketGroup "collectd"
    SocketPerms "0660"
    DeleteSocket false
</Plugin>

Cela permet d'ouvrir une socket qui permet de passer des commandes au démon collectd. Dans le cas du binaire nagios, il ne s'agit que de lire certaines valeurs mais on peut également pousser de nouvelles valeurs via ce socket. La documentation complète du fonctionnement de ce socket est disponible ici : Collectd unixsock documentation.

Une fois ce plugin activé et le démon collectd relancé, il ne reste plus qu'à lancer des requêtes avec l'outil collectd-nagios. Pour cela, on utilises les options suivantes :

  • -s : le chemin vers le socket
  • -n : la valeur à lire dans collectd sous la forme plugin/type
  • -H : le hostname du serveur à superviser
  • -d : la source de données, par défaut toutes les sources sont utilisées et on peut en spécifier plusieurs en enchaînant cette option
  • -w et -c : les seuils de warning et critical sous la forme habituelle des plugins nagios, des intervalles sous la forme x:y
  • -g : la façon dont on va traiter les source de données si on en utilise plusieurs

Et pour finir un exemple qui renvoie un OK :


# collectd-nagios -s /var/run/collectd-unixsock -n  load/load -H serveur.mnt-tech.fr -d midterm -w 2 -c 3 -g none

OKAY: 0 critical, 0 warning, 1 okay | midterm=0.150000;;;;

Cette dernière partie concernant nagios sort clairement du thème de cette série mais il me semblait intéressant d'en toucher un mot à la fin de cet article. On voit de suite l'intérêt que cela peut avoir pour éviter le doublon de collection de métriques. Pas besoin de collecter une fois avec nagios pour l'alerting et une autre fois avec collectd pour faire les graphiques des métriques.

Dans le prochain épisode nous verrons comment installer et paramétrer Graphite et Grafana sur le serveur

Sources :

♥ Partage sur tes réseaux sociaux ♥
Kévin MET
Kévin MET

Auteur de ce blog et gérant de la société MNT-TECH, je publie sur ce blog lorsque le temps me le permet et lorsqu'un sujet qui me parait intéressant n'a pas encore été abordé en français. Toutes les informations techniques présentes sur cette page peuvent être réutilisées moyennant le fait de citer la source.