Créer un dashboard pour monitorer ses processus Linux avec Prometheus et Grafana

Que vous soyez un administrateur système Linux ou un ingénieur DevOps, vous passez probablement beaucoup de temps à surveiller les performances de vos serveurs.

Vous avez parfois des instances dont la performance est dramatique sans avoir la moindre idée de l’origine du problème.

Parfois, les instances ne répondent plus et il est impossible d’exécuter la moindre commande à distance, comme top ou htop.

Il arrive que le problème soit simple, mais il vous manque les outils pour identifier clairement la source du problème.

Et si vous aviez un dashboard qui nous permet facilement de surveiller les performances de vos serveurs, mais aussi chaque processus individuellement ?

Le but de ce tutoriel est de créer un dashboard de surveillance à destination des administrateurs système Linux.

Le dashboard sera composé de différents panneaux personnalisables et scalables à plusieurs instances dans le cadre d’architectures distribuées.

Avant de commencer ce tutoriel, nous allons d’abord détailler tout ce que vous allez apprendre en lisant cet article :

• comprendre globalement les méthodes récentes de surveillance des systèmes Unix ;
• installer les dernières versions de Prometheus, Pushgateway et de Grafana ;
• concevoir un script bash qui exporte ses mesures vers le Pushgateway ;
• créer un dashboard avec Grafana composé des derniers panneaux disponibles comme le panneau « Gauge » ou le « Bar Gauge » ;
• Bonus : implémenter des filtres ad hoc de manière à surveiller les performances individuelles des processus.

Maintenant que vous avez une vue globale de tout ce que vous allez apprendre, sans plus attendre, commençons par une introduction de ce qui existe actuellement pour les systèmes Unix.

Lorsqu’il s’agit de surveiller les processus sur des systèmes Unix, vous disposez de plusieurs options. La plus connue est probablement la commande top.

top fournit une vue complète des performances de votre système, comme l’utilisation CPU actuelle, la consommation mémoire, ainsi que les statistiques pour chacun de vos processus.

Cette commande est très utilisée par les administrateurs système. Elle est bien souvent la première commande lancée lorsqu’un problème de performance est détecté sur un système (si vous y avez accès, bien sûr !).

La commande top est relativement lisible, mais il existe une commande qui rend la lecture encore plus facile : htop.

htop fournit le même panel de fonctionnalités (processeur, mémoire…) mais les informations sont présentées de manière plus colorée et plaisante. htop met à disposition des jauges qui reflètent l’utilisation courante du système.

Maintenant que vous savez que ces deux commandes existent, pourquoi vouloir créer une manière alternative de surveiller nos processus ?

La raison principale est probablement liée à la disponibilité de vos systèmes : en cas de panne majeure, il est souvent impossible d’avoir un accès physique ou à distance à votre instance.

En externalisant la surveillance de vos processus, il est possible d’analyser la raison de la panne sans accéder directement à la machine.

Une autre raison réside dans le fait que les processus naissent et meurent en permanence, souvent par l’action du noyau.

Dans ce cas, lancer la commande top ne vous donnera aucune information, parce qu’il sera trop tard pour observer la raison des problèmes de performance.

Il faudrait alors examiner les journaux (logs) du noyau pour essayer de trouver quels processus ont été tués. Avec un dashboard de surveillance, il est possible très simplement de revenir un peu dans le temps et de détecter simplement quel processus a causé l’interruption.

Maintenant que vous savez pourquoi nous allons créer ce dashboard, place à l’architecture mise en place pour un tel système.

Avant de détailler l’architecture que nous allons utiliser, nous savons que nous voulons une solution :

• économique : qui ne consomme pas trop de ressources sur notre hôte ;
• simple à mettre en place : une solution qui ne requiert pas beaucoup de temps à instancier ;
• scalable : si un autre hôte s’ajoute, nous devons pouvoir le surveiller simplement et efficacement.

Ce sont les points à garder en tête tout au long de ce tutoriel.

L’architecture détaillée est la suivante :

Notre architecture utilise quatre composants différents :

• un script Bash qui envoie périodiquement ses mesures vers Pushgateway ;
• Pushgateway : un cache qui agrège les mesures. Les scripts l'utiliseront comme destination de leurs mesures ;
• Prometheus, qui instancie une base de données temporelle. Prometheus inspecte périodiquement Pushgateway et récupère les mesures stockées par ce dernier.
• Grafana : un outil pour créer des dashboards et qui pourra présenter les données en exécutant des requêtes PromQL sur l’instance Prometheus.

Pour ceux qui ne sont pas familiers avec Prometheus, vous savez déjà que Prometheus inspecte via des appels HTTP les mesures exposées par les instances compatibles.

(Vous souhaitez un tutoriel complet sur Prometheus, c’est par ici !)

Dans notre cas, le script Bash a une durée de vie limitée et il n’expose pas directement ces mesures pour Prometheus.

C’est la raison pour laquelle nous allons utiliser le Pushgateway : conçu pour les processus à durée de vie faible, Pushgateway met les mesures en cache et les expose à Prometheus par la suite.

Maintenant que vous avez une idée plus claire de la manière dont fonctionne notre application, il est temps d’installer les outils nécessaires.

5-1. Installer Pushgateway▲

wget https://github.com/prometheus/pushgateway/releases/download/v0.8.0/pushgateway-0.8.0.linux-amd64.tar.gz

tar xvzf pushgateway-0.8.0.linux-amd64.tar.gz
cd pushgateway-0.8.0.linux-amd64/
./pushgateway &

me@schkn-ubuntu:~/softs/pushgateway/pushgateway-0.8.0.linux-amd64$ ./pushgateway &
[1] 22806
me@schkn-ubuntu:~/softs/pushgateway/pushgateway-0.8.0.linux-amd64$ INFO[0000] Starting pushgateway (version=0.8.0, branch=HEAD, revision=d90bf3239c5ca08d72ccc9e2e2ff3a62b99a122e)  source="main.go:65"
INFO[0000] Build context (go=go1.11.8, user=root@00855c3ed64f, date=20190413-11:29:19)  source="main.go:66"
INFO[0000] Listening on :9091.                           source="main.go:108"

5-2. Installer Prometheus▲

wget https://github.com/prometheus/prometheus/releases/download/v2.9.2/prometheus-2.9.2.linux -amd64.tar.gz

tar xvzf prometheus-2.9.2.linux-amd64.tar.gz
cd prometheus-2.9.2.linux-amd64/

vi prometheus.yml

global:
  scrape_interval:     1s # Set the scrape interval to every 1 second.

static_configs:
            - targets: ['localhost:9090', 'localhost:9091']

5-3. Installer Grafana▲

wget https://dl.grafana.com/oss/release/grafana_6.2.0-beta1_amd64.deb
sudo dpkg -i grafana_6.2.0-beta1_amd64.deb

sudo systemctl status grafana-server
  grafana-server.service - Grafana instance
   Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-05-09 10:44:49 UTC; 5 days ago
     Docs: http://docs.grafana.org

La tâche suivante consiste un écrire un script Bash qui récupère les mesures comme l’utilisation CPU et la consommation mémoire des processus individuels.

Le script pourra ensuite être défini comme une tâche cron qui tournera toutes les secondes.

Pour réaliser cette tâche, il existe plusieurs candidats. Il serait possible d’exécuter des commandes top toutes les secondes, de les parser avec sed et de les envoyer au Pushgateway.

La partie sensible avec top réside dans le fait qu’il nécessite plusieurs itérations successives, fournissant ainsi une moyenne des mesures en fonction du temps. Ce n’est pas ce que nous recherchons.

À la place, nous allons utiliser la commande ps et plus précisément la commande ps aux.

Cette commande expose les consommations individuelles de processeur et de mémoire ainsi que la commande lancée par le processus. C’est ce que nous recherchons.

Mais avant d’aller plus loin, analysons ce que Pushgateway attend comme mesure d’entrée.

Pushgateway, comme Prometheus, fonctionne avec un système clé-valeur : la clé décrit la mesure que nous surveillons. Ce que représente la valeur va de soi.

Voici quelques exemples :

Comme vous pouvez le remarquer, la première forme décrit simplement l’utilisation CPU, mais la seconde décrit celle pour le processus spécifique java.

En ajoutant des labels, il est possible de décrire les mesures plus précisément.

Maintenant que nous possédons cette information, construisons notre script final.

Pour rappel, notre script exécute la commande ps aux, parser le résultat, le transformer et l’envoyer au Pushgateway en utilisant la syntaxe décrite précédemment.

Créez un fichier script, donnez-lui les droits nécessaires et éditez-le :

vi better-top

Voici le script :

#!/bin/bash
z=$(ps aux)
while read -r z
do
   var=$var$(awk '{print "cpu_usage{process=\""$11"\", pid=\""$2"\"}", $3z}');
done <<< "$z"
curl -X POST -H  "Content-Type: text/plain" --data "$var
" http://localhost:9091/metrics/job/top/instance/machine

Nous affectons ensuite les droits :

chmod u+x better-top

Si vous voulez le même script pour l’utilisation mémoire, changez simplement le cpu_usage en memory_usage et $3z en $4z.

Quelle est la fonction de ce script ?

• Premièrement, il exécute une commande ps aux comme décrit précédemment.
• Par la suite, il itère sur les lignes successives et les formate en utilisant le format clé-valeur décrit précédemment.
• Enfin, l’ensemble est concaténé et envoyé au Pushgateway avec une simple commande curl.

Simple, n’est-ce pas ?

Comme vous pouvez le remarquer, le script agrège les mesures pour nos processus une seule fois.

Pour l’instant, nous allons simplement exécuter notre script toutes les secondes via la commande sleep.

Par la suite, vous pouvez créer un service de manière à ce que le script soit exécuté toutes les secondes (avec un timer par exemple).

while sleep 1; do ./better-top; done;

Maintenant que nos mesures sont envoyées au Pushgateway, voyons si nous pouvons les explorer dans la console Web de Prometheus.

Rendez-vous sur http://localhost:9090. Dans le champ “Expression”, tapez cpu_usage. Vous devriez voir à présent vos mesures dans le navigateur.

Félicitations ! Les statistiques de votre CPU sont maintenant dans Prometheus.

Maintenant que nos mesures sont stockées dans Prometheus, nous devons concevoir un dashboard Grafana pour les visualiser.

Nous allons utiliser les derniers panneaux disponibles dans Grafana v6.2 : les jauges verticales et horizontales, les jauges « simples » et les graphiques en ligne.

Pour faciliter la lecture, j’ai annoté le dashboard final avec des chiffres de 1 à 4. Ils correspondent aux différentes sous-sections de ce chapitre. Si vous êtes intéressé par un certain panel, rendez-vous directement à la sous-section correspondante.

7-1. Construire les jauges▲

7-2. Concevoir les jauges horizontales▲

7-3. Concevoir les jauges verticales▲

7-4. Concevoir les graphiques en ligne▲

7-5. Bonus : explorer ses données avec les filtres ad hoc▲

La surveillance de la consommation CPU et mémoire des processus n'est parfois pas suffisante.

De ce fait, il peut être intéressant de la compléter avec une surveillance des disques, en lecture ou en écriture, ainsi que des systèmes de fichiers.

À ce titre, le « Node Exporter » fournit des exportateurs qui permettent de mettre en place une surveillance des disques, dont l'utilisation sera expliquée dans un futur tutoriel.

Par ailleurs, le node exporter possède de multiples possibilités de customisation si la liste des exporteurs ne répond pas exactement à ce que vous souhaitez surveiller.

Grâce à ce tutoriel, vous avez maintenant une vue plus complète de la manière dont fonctionnent Prometheus et Grafana.

Vous avez un système complet pour surveiller une instance, mais il n’y a qu’un pas pour étendre ce projet à de multiples instances différentes.

Le monitoring Devops est un sujet passionnant, mais il peut s’agir d’un véritable cauchemar s’il est mal réalisé.

C’est en ayant conscience de ce point que nous écrivons cet article : pour vous aider à être efficace avec le magnifique potentiel de ces outils.

Nous croyons que de beaux outils peuvent être mis en valeur avec des articles comme celui-ci.

Si vous partagez ces valeurs, n’hésitez pas à lire nos autres articles sur devconnected.

J’espère que ce tutoriel vous a plu.

Have fun!