J’ai enfin pris le temps de configurer un serveur de monitoring; pour diverses raisons j’ai choisi zabbix.Je vais détailler dans une suite d’article les différents check que j’ai mis en place afin de garder une trace et qui sait aider quelqu’un 🙂 Je ne traiterai pas de l’installation de Zabbix, de multiple tutoriaux étant disponible sur le web; cela serai une perte de temps.

Mysql & Zabbix
Par défaut Zabbix propose un template pour monitorer la base de données. Comme je n’ai pas de gros besoins en terme de supervision sur Mysql, j’ai décidé de partir sur quelque chose de simple plutôt que des check plus lourds qui font appel à des scripts externes.

Voici comment utiliser le template par défaut :
Dans un premier temps on va créer utilisateur dédié sur chaque serveur Mysql que l’on souhaite monitorer :

Linux#> Mysql -u root -p
Mysql#> GRANT USAGE ON *.* TO 'zabbix'@'%' IDENTIFIED BY 'super_password';

Une fois celui-ci créé on va paramétrer l’agent Zabbix pour qu’il prenne en compte les « Key » fourni par le serveur.

CentOS

On commence par copier le fichier d’exemple fourni par les repository EPEL :

cp /usr/share/doc/zabbix20-agent-2.0.5/userparameter_mysql.conf /var/lib/zabbixsrv/

Puis à la fin du fichier on ajoute les lignes suivantes :

UserParameter=mysql.ping,HOME=/var/lib/zabbix mysqladmin ping | grep -c alive
UserParameter=mysql.version,mysql -V
UserParameter=mysql.uptime,HOME=/var/lib/zabbix mysqladmin status | cut -f2 -d":" | cut -f1 -d"T"
UserParameter=mysql.threads,HOME=/var/lib/zabbix mysqladmin status | cut -f3 -d":" | cut -f1 -d"Q"
UserParameter=mysql.questions,HOME=/var/lib/zabbix mysqladmin status | cut -f4 -d":" | cut -f1 -d"S"
UserParameter=mysql.slowqueries,HOME=/var/lib/zabbix mysqladmin status | cut -f5 -d":" | cut -f1 -d"O"
UserParameter=mysql.qps,HOME=/var/lib/zabbix mysqladmin status | cut -f9 -d":"

Afin que le fichier soit pris en compte on l’inclus dans le fichier de configuration de l’agent :

Include=/var/lib/zabbix/userparameter_mysql.conf

A ce moment précis le check fonctionne, mais sans utilisateur; il faut donc stipuler à l’utilisateur zabbix quel utilisateur utiliser lors de la connexion à la base. Pour cela je vais reprendre ce qu’a fait Tiramiseb car à mon sens c’est la plus correcte et surtout la plus élégante !

On créer le fichier /var/lib/zabbix/dot.my.cnf  (home directory de votre user zabbix) puis on ajoute le contenu suivant :

[client]
user= »zabbix »
password= »super_password »

Ensuite, on fait un lien symbolique pour qu’il soit reconnu par MySQL :

cd /var/lib/zabbix
ln -s dot.my.cnf .my.cnf
chown zabbix.zabbix dot.my.cnf .my.cnf
chmod 600 dot.my.cnf

Et enfin on redémarre l’agent Zabbix

service zabbix-agent restart

Debian

Sur Debian on créer le fichier Mysql pour l’agent avec le contenu suivant :

UserParameter=mysql.status[*],echo "show global status where Variable_name='$1';" | HOME=/etc/zabbix mysql -N | awk '{print $$2}'
UserParameter=mysql.size[*],echo "select sum($(case "$3" in both|"") echo "data_length+index_length";; data|index) echo "$3_length";; free) echo "data_free";; esac)) from information_schema.tables$([[ "$1" = "all" || ! "$1" ]] || echo " where table_schema='$1'")$([[ "$2" = "all" || ! "$2" ]] || echo "and table_name='$2'");" | HOME=/etc/zabbix mysql -N
UserParameter=mysql.ping,HOME=/etc/zabbix mysqladmin ping | grep -c alive
UserParameter=mysql.version,mysql -V
UserParameter=mysql.uptime,HOME=/etc/zabbix mysqladmin status | cut -f2 -d":" | cut -f1 -d"T"
UserParameter=mysql.threads,HOME=/etc/zabbix mysqladmin status | cut -f3 -d":" | cut -f1 -d"Q"
UserParameter=mysql.questions,HOME=/etc/zabbix mysqladmin status | cut -f4 -d":" | cut -f1 -d"S"
UserParameter=mysql.slowqueries,HOME=/etc/zabbix mysqladmin status | cut -f5 -d":" | cut -f1 -d"O"
UserParameter=mysql.qps,HOME=/etc/zabbix mysqladmin status | cut -f9 -d":"

Et comme pour la configuration sous CentOS on l’inclus dans le fichier de configuration de l’agent:

Include=/etc/zabbix/userparameter_mysql.conf

Et enfin on reprend l’astuce de Tiramiseb :

Création du fichier /etc/zabbix/dot.my.cnf avec le contenu :

[client]
user="zabbix"
password="super_password"

Ensuite, on fait un lien symbolique pour qu’il soit reconnu par MySQL :

cd /var/lib/zabbix
ln -s dot.my.cnf .my.cnf
chown zabbix.zabbix dot.my.cnf .my.cnf
chmod 600 dot.my.cnf

Et enfin on redémarre l’agent Zabbix

/etc/init.d/zabbix-agent restart

Et maintenant il ne reste plus qu’a affecter le template Mysql dans l’interface web a notre serveur Mysql.

J’ai expérimenté lors de l’une des dernières mises à jour de wordpress des lenteurs extrême lors de la connexion à l’interface d’administration.

Après m’être battu avec NGINX et PHP-FPM pour voir si cela venait d’un des deux éléments (aussi bien en reverse proxy qu’en serveur web), j’ai finalement trouvé (grâce à ce post) la solution. Il suffi de créer le fichier /etc/php.d/apc.ini avec le contenu suivant :

extension=apc.so
apc.shm_size="196"
apc.ttl=0
apc.max_file_size="10M"

et redémarrer le service php-fpm

service php-fpm restart

Il ne vous reste plus qu’à profiter d’une interface d’administration rapide.

A chaque version de Zimbra, de nouvelles fonctionnalités apparaissent sans que l’annonce soit faite.
Dans la version 7 de Zimbra, deux scripts ont fait leurs apparitions : vmware-appmonitor et vmware-heartbeat.
Le premier est l’exécutable développé par VMware permettant le dialogue avec l’hôte physique grâce aux vmware tools, le second est, quant à lui, un script de vérification applicatif. Dans notre cas celui-ci vérifie que les composants de Zimbra fonctionne correctement.
Si ceux-ci sont « OK » alors, le script renvoi à vSphere le statut « OK » via l’applicatif vmware-appmonitor.
Si un des services critique est « KO » alors le script renvoi l’erreur au vSphere qui au bout de 3 fois (paramétrage par défaut), redémarre la machine.

Attention, ne pas mettre en production ceci est à des fins de tests !

Mise en place

Dans un premier temps, vérifiez que votre cluster vSphere comprend bien l’option de surveillance d’application.

Puis connectez-vous a votre serveur Zimbra et exécutez les commandes suivantes :

1. sed -i -e '146 s/^/#/' -e '145 s/^#//' /opt/zimbra/libexec/vmware-heartbeat

2. echo "export LD_LIBRARY_PATH=/opt/zimbra/lib" >> /opt/zimbra/.bashrc

Explication

1. Par défaut le script de check retourne en permanence OK au vSphere, on modifie donc celui-ci pour qu’il exécute zmcontrol et retourne la bonne valeur.

2. Lorsque l’on exécute le scipt en tant qu’utilisateur Zimbra, celui-ci n’a pas le chemin vers les dépendances. On ajoute donc le chemin dans le PATH.

On peut maintenant lancer le script.

su - zimbra

/opt/zimbra/libexec/vmware-heartbeat start

Si l’on veut suivre l’exécution du script, on peut regarder dans /opt/zimbra/log/vmware-heartbeat.log. Si tout ce passe bien, alors vous aurez quelque chose comme ça :

Fri Jul  6 20:10:16 2012: Checking ZCS status
Fri Jul  6 20:10:25 2012: Sending heartbeat to VM

Nous allons provoquer un arret de service de Zimbra :
su - zimbra
ldap stop

Dans le fichier de log vous verrez que le service ne retourne rien, c’est au bout de trois fois que le script renvoi au vSphere de redémarrer la machine.

Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:37:47 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Mon Jul  9 01:38:12 2012: Checking ZCS status
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.

Au niveau du vSphere vous aurez l’erreur suivante :

Et le serveur sera redémarré dans la foulée !

Cette fonctionnalité est intéressante, mais n’est pas encore mure. En effet, elle vérifie l’intégralité  des services via la commande zmcontrol, celle-ci est relativement longue et c’est pour cela qu’elle est commenté dans le script d’origine.

Ce script nous montre un bout de ce que sera la prochaine version de Zimbra.