Catégories
Application Paramétrage

Docker sur VM et réseau

J’ai eu surprise de voir que ma surveillance ne fonctionnait plus avant hier. Pourtant d’après la capture prise vendredi soir tout semblait fonctionner.

Il y a 2 jours la connexion entre mon conteneur Prometheus et les conteneurs prom-node et cAdvisor situés sur des VM étaient devenu impossible. Toute la configuration reseau est du standard à savoir:

  • conteneur avec reseau bridge dédié par défaut avec docker-compose
  • VM avec reseau NAT par défaut avec virsh/KVM
connexion conteneur sur hôte vers conteneur sur VM impossible

Un test avec telnet m’a alors montré que depuis la machine hôte on pouvait joindre les conteneurs sur VM avec l’IP des VM gérée par KVM. Cependant depuis le conteneur sur l’hôte si l’accès à l’hôte lui-même était possible, un telnet vers les IP des VM échouait

Il faut dire que tout le paramètrage réseau mis en place par KVM et docker est un peu mystèrieux pour moi et je fais confiance à ceux qui savent plus que moi paramétrer le réseau…

Solution rapide

Comme depuis l’hôte la connexion vers les conteneurs sur VM NAT est possible alors une solution rapide est d’indiquer à Docker de mettre le conteneur Prometheus dans un réseau de type hôte. Dans le fichier docker-compose.yml au même niveau que image ajouter:

network_mode: "host"
Solution rapide, passer par l’hôte

Solution pérenne : le réseau overlay

La solution précédente enlève l’isolation reseau du conteneur Prometheus avec l’hôte et cela me gêne. De plus le conteneur grafana ne pouvait plus accéder à prometheus par son nom. Il fallait le faire passer par l’IP de l’hôte.

Une autre solution serait de mettre le conteneur prometheus dans une VM, car les VM se voient entre-elles par défaut. Un test telnet m’avait montré que les conteneurs d’une VM pouvait via l’IP des autres VM accéder aux conteneurs de ces VM.

Cette autre solution me gêne également car elle fait reposer la connectivité sur un paramétrage réseau géré par virsh/KVM. Idealement on voit aisément que les conteneurs dévolus au monitoring doivent être dans le même réseau et ce réseau doit chevaucher plusieurs démons docker sur des hôtes différents. C’est un réseau overlay !

Solution idéale : le reseau overlay

La mise en place du reseau overlay est une opération un peu complexe car il faut initialiser un neoud swarm maître sur l’hôte de prometheus, créer un réseau overlay dédié au monitoring, sur les hôtes de cAdvisor/prom-node il faut déclarer docker comme membre du swarm et enfin indiquer des les fichiers docker-compose que tous les conteneurs doivent utiliser le reseau overlay précédemment créé. Ici on avait créé un réseau appelé monitoring-net

networks:
  default:
    external:
       name: monitoring-net

Je ne suis pas allé au bout de la solution idéale de l’overlay car en créant seulement le reseau overlay et en y mettant prometheus, tout est retombé en marche. Je suis alors revenu en arrière et tout continue de fonctionner comme vendredi soir…. Je n’aime pas quand les choses tombent en marche. Affaire à suivre en gardant ce billet sous le coude.

Catégories
Application Paramétrage

Monitorer ses applications (docker) avec Prometheus et Grafana

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
Trio gagnant des sondes à métriques

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.

Catégories
Uncategorized

Monitorer ses applications avec Prometheus et Grafana

Jusque là j’utilisais le bien connu munin pour suivre l’état de mes serveurs et services. Cet outil assez ancien se positionne bien en tant que surveillance système et pour des alertes en cas de détection de valeurs anormales. Étant depuis plusieurs mois passé à une infra dockerisé, mon outils de monitoring était encore en natif. De plus son ihm n’était plus dans l’air du temps et il ne permet pas de faire des requêtes arbitraires sur l’historique des valeurs voire de d’agréger des indicateurs comme ce que ElasticSearch/Logstash/Kibana, ELK le poids lourd de la catégorie, permet.

Alternative légère

Avant de se lancer dans ELK plus fait pour de l’analyse de log que le suivi d’indicateur métriques, je souhaitais me limiter à une solution plus moderne que munin mais également peu gourmande en ressources tout en offrant la monitoring système de base de munin: les indicateurs mémoire, cpu, système de fichiers etc.

Prometheus est la solution mise en avant dans GitLab pour surveiller les performances des applications dans leurs environnement d’exécution. Un tour sur le site de Prometheus permet de voir que son architecture est bien au goût du jour c’est-à-dire à la sauce épicée des conteneurs:

On remarque le brique Grafana qui permet d’ajouter des capacités de visualisation et d’export des données en plus de l’interface web basique de Prometheus. Je vais également l’utiliser pour avoir de jolis graphiques dans l’air du temps.

Prometheus, Grafana, Docker

Comme je suis dans un univers dockerisé maintenant, je vais donc installer le couple Prometheus et Grafana en version conteneurisée. Dans un premier temps pour me familiariser avec ces outils, je vais installer la solution pour monitorer mes démons docker et les indicateurs systèmes de mes machines.

Mais avant tout, fidèle au principe de s’appliquer à soit même ses précepte, je commence par créer un projet dans mon GitLab et sera destiné à mettre en place mon application de monitoring. Ainsi toute ma phase de mise au point sera sous IC/DC comme dans un monde idéal.

https://gitlab.bressure.net/docker/applications/monitoring

La suite de mes aventures avec Prometheus, Grafana et docker dans le prochain billet… pour très bientôt.