Archives pour la catégorie Tuto

Utili­ser les données de Munin dans Grafana

Munin est un super outil de métro­lo­gie. Simple à instal­ler (présent dans toutes les bonnes distri­bu­tions), simple à confi­gu­rer (à un tel point que c’en est risible) et simple à étendre (on peut écrire des plugins pour tout, même pour surveiller une cafe­tière).

Mais on entend souvent « Ouais, mais les graphes RRDtool, c’est moche » (RRDtool est un outil permet­tant de faire plein de choses avec des bases de données RRD (Round Robin Data­base, bases de données tempo­relles), qui donne des graphiques au look vieillot).

Genre des graphes comme ça :

Du coup on n’en­tend plus parler que de Prome­theus, NetData et autres trucs de hips­ter bran­chouilles (mode vieux con assumé).

Ok, vous voulez du joli dash­board ? On va vous en donner.

La réfé­rence du machin qui fait des jolis graphes, c’est Grafana. Donc je suis parti sur ça.

Permettre à Grafana d’avoir accès aux données de Munin

Parce que Grafana ne sait pas taper dans des bases de données RRD, on va instal­ler Grafana RRD Server. Celui-ci va four­nir une API JSON à Grafana pour aller taper dans les bases RRD de Munin.

apt install librrd-dev

Ensuite

cd /tmp
wget https://github.com/doublemarket/grafana-rrd-server/releases/download/v0.0.5/grafana-rrd-server_linux_amd64.gz -O grafana-rrd-server.gz
gunzip grafana-rrd-server.gz
mv grafana-rrd-server /usr/bin/

On le lance ainsi (regar­dez le -h pour le détail des options) :

grafana-rrd-server -r /var/lib/munin/

Il écou­tera par défaut sur toutes les IPs, sur le port 9000. Libre à vous de le mettre derrière un Nginx ou autre, avec ou sans authen­ti­fi­ca­tion.

Pour le service systemd :

[Unit]
Description=Grafana RRD Server
Documentation=https://github.com/doublemarket/grafana-rrd-server
Requires=network.target
After=network.target

[Service]
Type=simple
User=munin
ExecStart=/usr/bin/grafana-rrd-server -r /var/lib/munin/
SyslogIdentifier=grafana-rrd-server

[Install]
WantedBy=multi-user.target

(Je ne l’ai pas testé, je viens de l’écrire à l’os)

systemctl daemon-reload
systemctl start grafana-rrd-server
systemctl status grafana-rrd-server
systemctl enable grafana-rrd-server

Instal­ler Grafana

Grafana four­nit un dépôt APT, ce qui est bien pratique :

apt install -y apt-transport-https
echo "deb https://packagecloud.io/grafana/stable/debian/ stretch main" > /etc/apt/sources.list.d/grafana.list
curl https://packagecloud.io/gpg.key | sudo apt-key add -
apt update
apt install grafana
systemctl daemon-reload
systemctl start grafana-server
systemctl status grafana-server
systemctl enable grafana-server

Hop, il écoute par défaut sur toutes les inter­faces, sur le port 3000. Encore une fois, à vous de le mettre derrière un Nginx, etc.

Le couple login / mot de passe par défaut est admin et admin.

Faire la liai­son entre les deux

Il faut encore que Grafana soit capable d’in­ter­ro­ger l’API JSON de Grafana RRD Server. Pour ça, on va lui instal­ler le plugin SimpleJ­son :

grafana-cli plugins install grafana-simple-json-datasource

Confi­gu­rer Grafana

Allez sur votre Grafana, allez dans la section « Data sources », cliquez sur « Add data source », choi­sis­sez le type SimpleJ­son, mettez l’adresse de votre Grafana RRD Server et hop, c’est tout bon. Vous n’avez plus qu’à ajou­ter des graphes prove­nant de cette source de données dans vos dash­boards.

Bon pis voilà, ça permet d’avoir un truc comme ça :

Conclu­sion

J’ai fait ça pour le fun, parce que j’en avais marre d’en­tendre des critiques sur Munin et des « Nan mais Prome­theus, c’est vache­ment mieux tu vois ». Non, je ne vois pas. Oui, les nouveaux outils sont jolis. Oui, ils ont une super granu­la­rité. Mais des points qu’on oublie souvent, c’est :

  • Munin est telle­ment simple à instal­ler et confi­gu­rer ;
  • Des jolis graphes, ouais, c’est cool, mais sérieux, qui se touche la nouille sur ses graphes toute la jour­née ? Ok, Munin, c’est assez moche, mais ça fait le job, je suis informé en regar­dant les graphes, et c’est tout ce que je lui demande ;
  • Prome­theus, NetData et compa­gnie, ça surveille telle­ment de trucs en perma­nence que ça ne se fait pas oublier sur le serveur. Si, si, j’ai bien vu ces outils me ralen­tir mes serveurs. Quand le serveur est à la peine, ces deux outils ont empiré les choses, là où Munin ne fait ses checks que toutes les cinq minutes. #TrueS­tory

Donc voilà : on est capable d’avoir de jolis graphes avec Munin, avec un mini­mum de taf. Bon, c’est en place, je vais pas jeter le boulot que j’ai fait, mais à moins qu’on me dise au boulot « C’est méga top, je vais m’en servir tout le temps », je vais le désac­ti­ver.

Bon, y a quand même un truc pas mal avec cette histoire, c’est qu’on peut affi­cher sur le même graphe des données qui ne sont pas agré­gées sur Munin. Genre empi­ler les nombres de mails envoyés par jour par toutes les machines qui envoient du mail, comme sur le graphe en bas à gauche de l’image ci-dessus. C’est pas complè­te­ment dénué d’in­té­rêt.

NB : Prome­theus et NetData ont d’autres quali­tés que les jolis graphes, comme par exemple des alertes intel­li­gentes. Contrai­re­ment à Munin (ou Nagios, ou autre système de moni­to­ring clas­sique) qui alerte quand les valeurs dépassent un certain seuil, ces nouveaux outils vont dire « Atten­tion, si le disque conti­nue à se remplir à ce rythme là, il sera plein dans 4h », même si le disque n’est rempli qu’à 50%. Et c’est bien. Mais pour moi, Munin, c’est de la métro­lo­gie (on enre­gistre, on peut consul­ter le passé et le présent), pas de la super­vi­sion au sens Nagios. Il peut le faire, mais c’est clai­re­ment pas son usage premier. Donc du coup, les nouveaux outils vont se compa­rer à mon instal­la­tion de Shin­ken, pas à mon Munin. Compteur Dolomon

Mettre à jour un serveur umap vers Debian Stretch

Ayant bien galéré, voici un petit guide pour mettre à jour un serveur Debian Jessie héber­geant umap vers Debian Stretch.

Commen­cez à mettre à jour votre Debian de façon clas­sique et redé­mar­rez. C’est après que tout est cassé.

Mise à jour du virtua­lenv

Vous aviez créé votre virtua­lenv avec virtua­lenv­wrap­per en choi­sis­sant python3, mais malheu­reu­se­ment, c’était la version 3.4 et main­te­nant c’est la 3.5 qui est instal­lée dans Debian. Bah, rien de plus simple : relan­cez la commande de créa­tion de votre virtua­lenv.

mkvirtualenv umap --python=`which python3`

Par contre, umap n’est toujours pas installé pour python 3.5. Hop, on le réins­talle (à exécu­ter dans le virtua­lenv) :

pip install umap-project

C’est tout pour la partie python. Par contre uwsgi plante lamen­ta­ble­ment à coup de

could not access file "$libdir/postgis-2.1": No such file or directory

C’est la faute à la version de l’ex­ten­sion post­gis de Post­greSQL : la mise à jour a provoqué l’ins­tal­la­tion de Post­greSQL 9.6, ce qui a provoqué la mise à jour du paquet postgresql-9.4-postgis-2.1 en postgresql-9.6-postgis-2.3.

Réins­tal­la­tion de post­gis pour Post­greSQL 9.4

Malheu­reu­se­ment, il n’y a pas de paquet postgresql-9.4-postgis-2.3 et vous ne pouvez pas réins­tal­ler postgresql-9.4-postgis-2.1.

La solu­tion est de passer par les paquets four­nis par les dépôts de Post­greSQL :

echo "deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main" \
  | sudo tee /etc/apt/sources.list.d/pgdg.list
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc \
  | sudo apt-key add -
sudo apt update

À ce moment-là, j’ai voulu instal­ler postgresql-9.4-postgis-2.3, mais je me suis retrouvé avec postgresql-9.4-postgis-2.4, donc autant y aller gaie­ment en mettant à jour post­gis pour Post­greSQL 9.6 :

sudo apt install postgresql-9.4-postgis-2.4 postgresql-9.6-postgis-2.4

Connec­tez-vous à votre base de données Post­greSQL :

su postgres
psql umapdb

Véri­fiez la version de post­gis que vous indique Post­greSQL :

umapdb=# SELECT name, default_version, installed_version FROM pg_available_extensions WHERE name = 'postgis';
  name   | default_version | installed_version 
---------+-----------------+-------------------
 postgis | 2.4.0           | 2.4.0
(1 row)

Et mettez à jour l’ex­ten­sion :

umapdb=# ALTER EXTENSION postgis UPDATE TO "2.4.0";

Avec ça, ça devrait rouler. MAIS ! (bah oui, y a un « mais »)

Mais vous savez que vous avez main­te­nant deux versions de Post­greSQL sur votre serveur et qu’il vaudrait mieux passer sur la 9.6. J’y ai d’ailleurs consa­cré un article derniè­re­ment.

EDIT : atten­tion, le problème ci-dessous n’ar­ri­vera que si vous avez ajouté l’in­dex search_idx en suivant la recom­man­da­tion pour une grosse base. Ne modi­fiez pas les fonc­tions unaccent et to_tsvector sur votre nouveau clus­ter si vous n’aviez pas précé­dem­ment créé l’in­dex, cela risque­rait d’avoir des effets de bords indé­si­rables si jamais vous avez d’autres bases de données que celle d’umap sur votre Post­greSQL.

Problème : un index sur la table leaflet_storage_map empêche la migra­tion, et vous vous retrou­ve­rez avec le message

ERROR: functions in index expression must be marked IMMUTABLE

Réso­lu­tion du problème de l’in­dex

Ce n’est pas compliqué : on va suppri­mer l’in­dex sur le clus­ter 9.4 et le recréer une fois la migra­tion vers 9.6 effec­tuée.

umapdb=# DROP INDEX search_idx;

Hop, on fait la migra­tion en suivant mon tuto (ne suppri­mez pas tout de suite le clus­ter 9.4, faut d’abord véri­fier que tout fonc­tionne norma­le­ment).

Recon­nec­tons-nous sur la base d’umap, mais cette fois, ce sera sur le clus­ter 9.6 et tant qu’à faire, véri­fions que nous sommes bien connec­tés sur le bon clus­ter).

umapdb=# SELECT version();

Il est temps de recréer l’in­dex. Mais un bête

umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);

échouera avec le même problème que tout à l’heure. Il faut faire :

umapdb=# ALTER FUNCTION unaccent(text) IMMUTABLE;
umapdb=# ALTER FUNCTION to_tsvector(text) IMMUTABLE;
umapdb=# CREATE INDEX search_idx ON leaflet_storage_map USING gin(to_tsvector(unaccent(name)), share_status);

Et là on est bon ! Redé­mar­rez peut-être uwsgi pour qu’il prenne en compte le chan­ge­ment de clus­ter, mais je ne suis pas sûr que ce soit néces­saire.

Testez votre umap et si tout est bon, vous pour­rez virer votre clus­ter 9.4 et les paquets asso­ciés 🙂

Crédits : image d’illus­tra­tion by Himesh Kumar Behera on Unsplash