Pour l’installer, rien de plus simple, il suffit de faire un lien symbolique sur un des « aspects » disponibles pour ce plugin, qu’on obtient par la commande :

aa2:~# munin-run varnish_transfer_rates suggest
memory_usage
request_rate
backend_traffic
transfer_rates
threads
bad
uptime
expunge
objects
hit_rate
aa2:~#

Mais avant de pouvoir lancer cette commande pour connaître les « aspects » de ce plugin, il fallait déjà faire un lien symbolique, donc lire le contenu du plugin ! La on choisit l’aspect « transfer_rates ». Pour installer le plugin qui va fournir les « transfer_rates » de Varnish, il faut faire le lien suivant :

aa2:~# ln -s /usr/share/munin/plugins/varnish_ /etc/munin/plugins/varnish_transfer_rates
aa2:~#

A cette étape, la configuration est prête pour tester le plugin. On lance la commande suivante pour vérifier les valeurs que renvoie le plugin :

aa2:~# munin-run varnish_transfer_rates 
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Pas de réponse, on attend les ….. puis on obtient une erreur ! Cette erreur provient de varnishstat. Quand on lance varnishstat pourtant tout fonctionne :

aa2:~# varnishstat  -x
<?xml version="1.0"?>
<varnishstat timestamp="2021-03-08T22:33:50">
	<stat>
		<name>MGT.uptime</name>
		<value>520285</value>
		<flag>c</flag>
		<format>d</format>
		<description>Management process uptime</description>
	</stat>
	<stat>
		<name>MGT.child_start</name>
		<value>1</value>
		<flag>c</flag>
		<format>i</format>
		<description>Child process started</description>
	</stat>
...
...
</varnishstat>
aa2:~#

Alors que se passe-t-il ? On essaie avec les options de débug :

aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/65534/
# Setting /egid/euid/ to /113 113/65534/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
.....
Could not get hold of varnishd, is it running?

no element found at line 1, column 0, byte 0 at /usr/lib/x86_64-linux-gnu/perl5/5.28/XML/Parser.pm line 187.
aa2:~#

Toujours la même erreur. En y regardant de plus près on s’aperçoit que le plugin est lancé avec l’euid 113 qui est l’id de l’utilisateur munin sur ma machine. Mais comme le process Varnish tourne sous l’utilisateur vcache, le plugin ne peut pas contacter Varnish, d’où l’erreur. La méthode pour corriger ce problème est de lancer le plugin Varnish avec l’utilisateur « vcache ». Pour ceci, on crée un fichier de configuration du plugin qui indique d’utiliser « vcache » :

aa2:~# cat /etc/munin/plugin-conf.d/varnish_ 
[varnish_*]
    user vcache
aa2:~# 
aa2:~# munin-run varnish_transfer_rates 
aa2:~# 
aa2:~# munin-run --debug --pidebug varnish_transfer_rates 
# Processing plugin configuration from /etc/munin/plugin-conf.d/README
# Processing plugin configuration from /etc/munin/plugin-conf.d/dhcpd3
# Processing plugin configuration from /etc/munin/plugin-conf.d/munin-node
# Processing plugin configuration from /etc/munin/plugin-conf.d/spamstats
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish4_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish5_
# Processing plugin configuration from /etc/munin/plugin-conf.d/varnish_
# Setting /rgid/ruid/ to /113/109/
# Setting /egid/euid/ to /113 113/109/
# Setting up environment
# About to run '/etc/munin/plugins/varnish_transfer_rates'
aa2:~#

Le plugin fonctionne, mais ne renvoie rien !!!
On tombe sur le bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959812

En cherchant les plugins Varnish pour Munin, on trouve beaucoup de choses. Qui vont de Varnish 2 à Varnish 5. Mais sous Buster, on est en Varnish 6. Tous les plugins Varnish ont la même source, la version de 2009. Mais on ne sait pas exactement avec quelle version de Varnish ils fonctionnent. J’en ai essayé 3 différents, et sans aucun doute, le bon est celui-ci : https://gallery.munin-monitoring.org/plugins/munin-contrib/varnish5_/

Il faut récupérer le source, faire le lien dans le répertoire des plugins et mettre l’utilisateur « vcache » ou « root » dans la configuration. Là, j’ai utilisé le hit_rate comme « aspect » :

aa2:~# ln -s /usr/share/munin/plugins/varnish5_ /etc/munin/plugins/varnish5_hit_rate
aa2:~#
aa2:~# cat /etc/munin/plugin-conf.d/varnish5_ 
[varnish5_*]
    user vcache
aa2:~#
aa2:~# munin-run varnish5_hit_rate 
client_req.value 2955
cache_hitpass.value 0
cache_hitmiss.value 12
cache_hit.value 2228
cache_miss.value 715
aa2:~#

On a bien un résultat cette fois !
Remarque, le client_req est calculé comme la somme des 4 valeurs cache_*. Alors que la commande varnishstat renvoie un client_req de 9585 ! Cette dernière valeur représente toutes les requêtes reçues par Varnish, y compris les « pass ». Donc avec le plugin « varnish5_ » on n’a que les requêtes qui sont sensées être en cache. Ce qui est logique pour un calcul de hit ratio, mais qui ne montre pas la totalité des requêtes reçues.

On retrouve ci-dessus un hit ratio dont la somme des 4 composantes fait 100.

Références :
Munin
Paquet Munin pour Debian Buster

L’article Munin : le plugin Varnish sous Debian Buster est apparu en premier sur Alain ARDITI's blog.

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 :

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 :

*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi

en

* * * * *     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 :

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

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 :

L’article Passer Munin à la minute est apparu en premier sur Alain ARDITI's blog.