blog.bressure.net

Dans le remplacement de Munin par Prometheus, les indicateurs systèmes (OS et docker) sont en place. Avant de supprimer munin de mes machines, il reste encore quelques éléments à reprendre commme les métriques de:

• Apache (frontal et reverse proxy)
• KVM
• Mail
• Fail2ban
• Queue d’impression (utile ?)

Commençons par la surveillance de apache

Apache exporter

Sur le site de Prometheus on trouve une liste de logiciels complementaires poir exporter des métriques des composants connus tels que apache. De nombreuses version de cet exporter pour apache sont disponibles, sur github notament, mais je retiendrais les 3 versions suivantes:

• httpd_exporter de https://github.com/kelein/httpd_exporter
• apache_exporter de https://github.com/Lusitaniae/apache_exporter
• prometheus-apache-exporter en paquet debian

Compiler avant d’utiliser…. pas user-friendly

En tant qu’informaticien et développeur à la base la compilation est une étape qui ne devrait pas effrayer. Cela tombe bien car la version de kelein est un exporter dockerisé et demande à faire une compilation avant se pouvoir etre utilisée.

Compiler en docker c’est quoi ?

Dans les projet docker, la phase build consiste à fabriquer l’image avant de pouvoir l’exécuter. Cette phase est normale lors du développement du logiciel mais ne devrait pas être imposée à l’utilisateur du logiciel.

Quand je vais acheter une voiture, elle n’est pas fournie en kit que je dois monter

Differentes stratégies de constructions

Comme l’informaticien est un utilisateur que la compilation n’effrait pas, un petit docker build . ne va pas nous gêner. Si le httpd_exporter de kelein se construit parfaitement du premier coût c’est parce qu’il embarque dans son Dockerfile tout ce qu’il faut: compilation du source en langage Go dans une image intermediaire et création de l’image finale.

httpd_exporter pas compatible avec les tableaux de bord Grafana

Le test de l’image obtenue est concluant pour peu que l’indique bien l’url cible du serveur apache accessible depuis le conteneur via l’argument

--scrape_uri="https://perso.bressure.net/server-status"

Malheureusement les métriques sont exportées sous des noms qui ne ne sont pas ceux attendus par les tableaux de bord Grafana disponibles en libre service. Ces derniers se basent sur l’exportation faite par apache_exporter de Lusitaniae.

Lusitaniae

Cette autre version semble être la plus ancienne dans la sphère Docker. De plus elle est reprise dans le paquet prometheus-apache-exporter de Debian. C’est un signe de qualité et utiliser un exporteur à la fois disponible en version conteneurisés et native permettrait de passer de l’un à l’autre plus simplement.

Autre stratégie de construction

Comme pour httpd_exporter il faut faire un buils avant d’utiliser. Je me sens comme revenu dans en 1998 où pour utiliser le mode graphique sous Linux il fallait parfois encore compiler et jouer du makefile… Cette fois-ci je déchante car le Dockefile attend un binaire dont on a bien le source Go mais pas les instructions de build…. sauf dans la documentation. Il eu été préférable de les avoir dans le source du projet même et idéalement dans un Dockerfile.

On est informaticien ? Alors on compile via les instructions données dans la documentation. Je choisi donc une version de Go un peu récente et lance la compilation via une image docker de Go. La déception ne tarda pas à venir. La construction échoue sur un problème de dépendance dans la définition du projet.

Docker c’est un peu la création de paquet

Cette mésaventure soulève un aspect non négligeable de docker. Contrairement à l’écosystème Java où un seule langage et une seule méthode (si on se réfère au temps glorieux de J2EE) permettent de construire, d’empaqueter et déployer une application, docker offre certe de repondre au problème des dépendances et d’intégration mais il ressemble sur bien des aspects à un mécanisme de paquet des distribution Linux.

Compétences multi-langage requise

En effet le mainteneur d’un paquet doit savoir compiler le logiciel à partir de son source. Cela necessite donc de connaître les mecanismes de constructions propres au langage dans lequel est écrit l’application. Dans le cas des exporter pour appache c’est le langage Go. Pour pouvoir construire l’image il ne suffit pas juste connaitre Docker mais il faut également connaitre Go. J’ai egalement expérimenté le même soucis avec un projet Rails dont l’écosystème avec les Gemfiles m’est totalement étranger.

Fournir des images au lieu des sources

Comme je vois Docker comme une couche au dessus de l’application permettant à celle-ci de s’exécuter sans que l’utilisateur ait à se soucier des dependances où autres plomberie d’intègration, cela me conforte dans l’idée de la nécessité de fournir des images à l’utilisateur et non des souces pour la commande docker build.

Paquet debian prometheus-apache-exporter

Heureusement que d’autres savent mieux que moi comment compiler des sources Go. Debian fournit d’ailleurs un paquet binaire de l’exporter apache basé sur Lusitaniae.

Cherchant la simplicité et puisque mon apache n’est de toute façon pas encore dockerisé, je me suis rabattu sur cette version native de l’exporter. Cela n’est pas sans conséquence car étant installé en service systemd le paramètrage de l’url nécessite de s’accomoder d’un paramétrage propre à l’OS. On fait du système.

Paramètrage de l’exporter apache en service

En allant consulter la documentation Debian, j’apprends que le fichier définition du service installé par le paquet est dans /lib/systemd/system/prometheus-apache-exporter.service et non pas dans /etc/systemd/system/

En allant voir ce fichier on découvre qu’un fichier de variable est utilisé et que la variable ARGS permettra de paramétrer notre exporter.

EnvironmentFile=/etc/default/prometheus-apache-exporter ExecStart=/usr/bin/prometheus-apache-exporter $ARGS

Il ne reste plus qu’à aller ajouter dans /etc/default/prometheus-apache-exporter le paramètre

ARGS='-scrape_uri https://perso.bressure.net/server-status/?auto'

Notez que l’argument ne contient qu’un seul tiret dans le service et deux en ligne de commande docker. Je passe sous silence la sécurisation qui rend l’url du status de apache accessible seulement en local.

Tableau de bord grafana

A ce stade les métriques suivantes sur apache peuvent être disponibles dans Prometheus. Il suffit de déclarer un nouveau job pointant sur le endpoint offert par l’exporter. Par exemple dans le fichier prometheus.yml:

- job_name: apache
  honor_timestamps: true
  scrape_interval: 15s
  scrape_timeout: 10s
  metrics_path: /metrics
  scheme: http
  static_configs:
    - targets:
      - 192.168.0.12:9117

On peut alors avoir ce genre de graphique:

En utilisant un tableau de bord en libre service sur le site de grafana, on peut avoir ce genre de graphiques sans aucune configuration supplémentaire:

On a réussi facilement à remplacer Munin par Prometheus pour surveiller apache. La prochaine étape sera de passer sous Prometheus la surveillance des VM. La suite au prochain billet.