blog.bressure.net

Après avoir réglé mes soucis de mise à jour de Owncloud, je me suis remis à mes aventures avec Prometheus et Grafana.

Config de Prometheus embarquée

Comme mon infrastructure ne change pas entre mes environnements, j’ai tout d’abord pensé mettre le fichier de configuragion /etc/prometheus/prometheus.yml dans l’image docker de prometheus. Le code source final de cette petite manipulation se trouve ici https://gitlab.bressure.net/docker/services/prometheus

Enrichissement de la couche infra

Puis il suffit de construire l’application monitoring avec docker-compose en ajoutant le service grafana. Le tout devra s’executer sur mon instance docker que je qualifie d’infrastructure car sémantiquement ce n’est ni un poste de développement (bien qu’il ait aussi ce rôle dans les faits), ni de la production.

Nous obtenons alors une application de monitoring dont la seule source de métrique est l’instance de prometheus elle-même qui expose ses propres valeurs. Quand à grafana il faudra lui ajouter une source de données de type prometheus qui sera désignée par son url http://prometheus:9090/. La résolution du nom prometheus sera faite par le DNS de docker au sein du réseau construit par ses soin grâce au docker-compose.yml.

Mon objectif est de faire de prometheus le centralisateur de toutes les métriques et grafana sera le traceur de graphique avec comme unique source de données prometheus.

Ajout des sources à monitorer

Il faut donc ajouter des sources de données dans prometheus. C’est ce qui s’appelle dans la terminologie de prometheus des job avec pour chacun d’eux des endpoints c’est-à-dire des adresses exposant au bon format les valeurs des métriques. Ainsi prometheus lui-même est un endpoint comme vu plus haut.

Gitlab

Mon conteneur GitLab est capable d’exposer des métrique applicative (données métiers) au format prometheus. Cela sans grand effort. Il suffit d’activer prometheus dans GitLab…. même pas c’est sans déjà la cas ! Il ne faut même pas chercher à modifier la configuration dz Gitlab pour rendre le endpoint visible de l’exterieur du conteneur, GitLab fournit déjà une url avec un token secret pour accéder aux metriques. La contrepartie de cette facilité est que le endpoint prometheus du GitLab sera accédé via une url externe ie celle du gitlab !

Voilà pourquoi ma configuration de Prometheus ne peut pas être entièrement dans l’image Prometheus car le token secret dépend de l’instance GitLab c’est donc applicatif et pas structurel. De plus ce secret ne doit pas aller dans le code source que je veux public !

Métriques systèmes

Sur le schéma précédent on voit en vers Prometheus servant à lui lui-même de endpoint et en bleu la liaison avec GitLab.

Une fonction de munin, qui est sans doute la première, est le monitoring des constantes du système (mémoire, cpu, disque ….). Avec prometheus, ce sont les node exporter installé sur chaque machine qui vont exposer ses métriques sous forme de endpoint Prometheus. J’installe donc ces node exporter sur chacune de mes VM, bien entendu dans leur version dockerisée what else ? Le source trivial de cette manipulation se trouve ici https://gitlab.bressure.net/docker/applications/prom-node

Métriques docker

L’application docker, le démon docker, est elle-même une application intéressante à surveiller. Avec munin j’utilisais une sonde qui remontait l’utilisation cpu et mémoire de chaque conteneur. Pour Prometheus j’ai testé 2 solutions.

Le démon docker lui-même peut exporter des métriques prometheus. Il faut activer cette fonction expérimentale dans le fichier /etc/docker/daemon.json

{
"metrics-addr" : "IP_HOTE:9323", "experimental" : true
}

L’autre solution s’appelle cAdvisor une image docker dont google est à l’origine et qui expose un plus grand nombre de métrique que celles exposées par le démon docker lui-même. Comment ce fait-il ? En montant les répertoires systèmes de l’hôte dans le conteneur cAdvisor:

sudo docker run \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:ro \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --volume=/dev/disk/:/dev/disk:ro \ --publish=8080:8080 \ --detach=true \ --name=cadvisor \ gcr.io/google-containers/cadvisor:latest

Node exporter, cAdvisor, démon docker

Le trio gagnant des outils d’export de métriques semble être:

• Le démon docker lui-même mais exporte seulement les données essentielles et ce n’est pas une fonctionnalité pérenne
• cAdvisor qui est beaucoup plus complet mais demande un accès également complet au système de fichiers hôte en lecture certes mais….
• Le node exporter de prometheus moins riche que cAdvisor mais avec une possibilité d’extension

On voit que les sondes node exporter de prometheus et cAdvisor de google, sont des composants réutilisables et installables en bloc sur mes différents environnements: infra, staging et production. Je vais donc avantageusement les regrouper dans un projet docker compose prom-node. Finalement l’architecture de monitoring devient la suivante:

Bilan

Avec quelque configuration qui se résument à assembler des conteneurs entre eux, j’arrive à avoir une solution uniquement visuelle pour l’instant, de surveillance de mon infra. Je m’appuie pour cela sur:

1. une image de Prométheus avec une configuration taillée sur mesure. Ce point est facultatif et je pouvais me contenter de l’image originale https://gitlab.bressure.net/docker/services/prometheus
2. une application combinant Prometheus pour la collecte et Grafana pour la restitution https://gitlab.bressure.net/docker/applications/monitoring
3. Des sondes sous forme de conteneur qui expose les métriques pour Prometheus https://gitlab.bressure.net/docker/applications/monitoring
4. Un configuration des démons docker pour exposer des métriques Prometheus. Attention fonctionnalité expérimentale selon docker.

La prochaine étape sera d’ajouter des alertes afin de reproduire toutes les fonctions de munin.