L’outil de métrologie Munin, dont le site est http://munin-monitoring.org/ est bien pratique pour faire des tests. Lorsqu’on a une infrastructure à gérer avec des dizaines, centaines ou milliers de noeuds, on fait de la métrologie à 5 minutes. C’est à dire qu’on relève les valeurs de chaque noeud toutes les 5 minutes. De manière synchrone ou pas. Généralement on a de la métrologie, de la surveillance et des alertes. Donc souvent un outil assez sensible dont on ne peut pas modifier les réglages pour faire des tests.
Donc si on a besoin d’accélérer la fréquence de récupération des valeurs pour un test de charge ou de rajouter un noeud pour 2 jours, d’effacer des valeurs, de bricoler des graphes, on est coincé.
Alors, dans ce cas, rien de mieux qu’un serveur Munin dédié aux tests et indépendant de l’infrastructure. Surtout si on veut gagner du temps et avoir des réponses rapides avec des métriques à la minute.
L’outil Munin est très léger, c’est du scripting Perl, les plugins sont très simples à faire fonctionner, on ne consomme pas trop de ressources. C’est l’outil idéal pour mesurer les ressources pendant les tests de charge.
Descendre le monitoring à la minute est essentiel, car pour les tests de charge, si on veut des graphes significatifs, il faut une bonne dizaine de points. Avec des points toutes les 5 minutes, on arrive facilement à 1 heure par test. Donc faire des tests dans ces conditions devient excessivement long, car avant d’avoir 2 ou 3 belles courbes significatives, il faudra lancer au moins une dizaine de tests…. Une opération de deux jours au moins.
Par contre, si on passe à la minute, en 15 minutes on a des graphes. En une journée on aura peut-être terminé nos tests, avec l’impression d’avoir moins perdu son temps, surtout lorsque les tests ne se passent pas bien et que la mise au point est délicate !
Que faut-il modifier pour passer Munin à une minute de fréquence ?
La source de cet article provient de Daniel Watrous : One minute sampling. Avec notre version de Munin par contre, on ne touche pas les noeuds (munin-node).
Dans notre cas, le serveur Munin va chercher les métriques, stocke les valeurs dans les fichiers RRD et fait les graphes. Il n’y a rien à changer sur les noeuds. On ne modifie que le serveur Munin.
La version de Munin utilisée ici est la 2.0.49 fournie par la distribution Debian Buster.
Etape 1 : modifier munin.conf
Dans le fichier /etc/munin/munin.conf il faut ajouter les 2 lignes suivantes :
|
1 2 |
graph_data_size custom 1d, 1m for 1w, 5m for 1t, 15m for 1y update_rate 60 |
Etape 2 : modifier le cron
Il faut passer le cron de récupération des valeurs des noeuds à la minute. Modifier la ligne du fichier /etc/cron.d/munin comme suit :
|
1 |
*/5 * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi |
en
|
1 |
* * * * * munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi |
de manière à passer de 1 fois toutes les 5 minutes à toutes les minutes.
Etape 3 : supprimer les RRD
Les fichiers RRD sont les fichiers qui contiennent les valeurs des métriques des noeuds graphés par Munin. Comme les RRD stockent la fréquence des données en entête, une fois le fichier créé, on ne peut plus modifier cette fréquence. Il faut donc effacer les fichiers RRD des noeuds pour lesquels on va passer à une minute. Ces fichiers se trouvent dans le répertoire /var/lib/munin/nom_du_domaine/
Si on efface ces fichier RRD, on perd tout l’historique pour les noeuds qui se trouvent dans le domaine. On comprend pourquoi il vaut mieux ne pas faire ces opérations sur un serveur qui gère la métrologie d’une infrastructure de production.
C’est la commande /usr/bin/munin-cron qui se lance toute les minutes sur le serveur Munin qui crée les fichiers RRD et qui va stocke les valeurs.
On peut vérifier que les fichiers RRD sont corrects en affichant les informations qui se trouvent à l’intérieur, en particulier le step qui doit être à 60 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
debian-munin-2:~# rrdtool info /var/lib/munin/arditi.net/aa2.arditi.net-memory-buffers-g.rrd | head filename = "/var/lib/munin/arditi.net/aa2.arditi.net-memory-buffers-g.rrd" rrd_version = "0003" step = 60 last_update = 1613941863 header_size = 2872 ds[42].index = 0 ds[42].type = "GAUGE" ds[42].minimal_heartbeat = 120 ds[42].min = NaN ds[42].max = NaN debian-munin-2:~# |
Etape 4 : relancer le serveur Munin
Il suffit de lancer la commande suivante pour relancer Munin
|
1 2 3 4 5 6 7 8 9 10 11 |
debian-munin-2:~# systemctl restart munin.service debian-munin-2:~# systemctl status munin.service ● munin.service - LSB: Create munin master directories on boot Loaded: loaded (/etc/init.d/munin; generated) Active: active (exited) since Sun 2021-02-21 22:06:13 CET; 8s ago Docs: man:systemd-sysv-generator(8) Process: 1402 ExecStart=/etc/init.d/munin start (code=exited, status=0/SUCCESS) Feb 21 22:06:13 debian-munin-2 systemd[1]: Starting LSB: Create munin master directories on boot... Feb 21 22:06:13 debian-munin-2 systemd[1]: Started LSB: Create munin master directories on boot. debian-munin-2:~# |
et d’attendre quelques minutes avant de regarder les graphes qui doivent afficher des variations à la minute :
Si on fait un test de charge avec l’outil JMeter, qu’on a un « Thread plan » de 100 threads avec une montée de 0 à 100 en 10 minutes et un plateau de 5 minutes comme ci-dessous :
on récupère des graphes comme celui-ci en moins de vingt minutes, avec la granularité à la minute comme JMeter :
