IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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.

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

1 commentaire Donner une note à l´article (5)

Article lu   fois.

L'auteur

Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

1. Introduction

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 ?

Image non disponible

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.

2. Ce que vous allez apprendre

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.

3. Base de la surveillance des processus 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 !).

Image non disponible

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.

Image non disponible

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.

Vous connaissez maintenant les bases de la surveillance de processus Unix.

4. Détails de notre architecture de surveillance

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 :

Image non disponible

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.

Image non disponible

Vous avez maintenant une vue complète de l'architecture Grafana – Prometheus – PushGataeway.

Suite : installer tous les outils nécessaires.

5. Installer les outils nécessaires

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

De manière à installer Pushgateway, lancez une simple commande wget de manière à récupérer les derniers binaires disponibles :

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

Maintenant que vous avez l’archive, décompressez-la et lancez l’exécutable disponible dans le dossier Pushgateway :

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

Pushgateway devrait démarrer en arrière-plan.

 
Sélectionnez
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"

Nous avons maintenant une instance de Pushgateway qui attend des mesures sur le port 9091.

5-2. Installer Prometheus

Comme décrit dans la partie “ Getting Started”du site de Prometheus, dirigez-vous vers le site officiel et lancez une commande wget de manière à récupérer Prometheus sur votre instance :

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

Maintenant que vous avez l’archive, décompressez-la et naviguez dans le dossier principal :

 
Sélectionnez
tar xvzf prometheus-2.9.2.linux-amd64.tar.gz
cd prometheus-2.9.2.linux-amd64/

Comme expliqué précédemment, Prometheus inspecte des « cibles » périodiquement et récupère les mesures disponibles. Les cibles (Pushgateway dans notre cas) doivent être configurées via le fichier de configuration de Prometheus.

 
Sélectionnez
vi prometheus.yml

Dans la section global, modifiez la propriété scrape_interval à une seconde.

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

Dans la section scrape_configs, ajoutez une entrée à la propriété targets, juste en dessous de la ligne static_configs :

 
Sélectionnez
static_configs:
            - targets: ['localhost:9090', 'localhost:9091']

Sortez de vi et lancez l’exécutable disponible dans le dossier de Prometheus.

Prometheus devrait démarrer. Pour vous en assurer, dirigez-vous vers http://localhost:9090/graph et vérifiez qu’une interface se présente à vous.

Si la console web de Prometheus se lance, cela signifie que tout s’est bien déroulé.

Vous pouvez aussi vérifier que Pushgateway est correctement configuré en vous rendant dans la section « Status > Targets ».

Image non disponible

5-3. Installer Grafana

Enfin, nous allons installer Grafana v6.2. Rendez-vous sur https://grafana.com/grafana/download/beta. De la même manière que précédemment, exécutez une commande wget pour récupérer les binaires.

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

Maintenant que vous avez extrait le fichier .deb, Grafana devrait démarrer en tant que service sur votre machine.

Il est possible de le vérifier en exécutant cette commande :

 
Sélectionnez
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

Vous pouvez aussi vérifier http://localhost:3000 qui est l’adresse par défaut pour l’interface de Grafana.

Maintenant que vous avez Grafana sur votre instance, nous devons configurer Prometheus en tant que source de données. La configuration se fait de cette manière :

Image non disponible

C’est tout ! Cliquez sur « Save and Test » et vérifiez que votre source de données fonctionne correctement.

Vous savez maintenant installer les outils Grafana – Prometheus – PushGateway.

Suite : écrire un script pour récupérer nos données.

6. Écrire un script Bash pour récupérer nos mesures

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.

Image non disponible

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 :

Image non disponible

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 :

 
Sélectionnez
vi better-top

Voici le script :

 
Sélectionnez
#!/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 :

 
Sélectionnez
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).

 
Sélectionnez
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.

Image non disponible

Vous avez maintenant un script qui exporte les mesures vers PushGateway.

La suite : créer un graphique avec Grafana.

7. Créer un dashboard avec Grafana

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.

Image non disponible

7-1. Construire les jauges

Voici une vue plus précise de nos jauges dans le panel final.

Image non disponible

Pour l’instant, nous allons nous concentrer sur l’utilisation processeur de nos processus, mais la démarche sera la même pour l’utilisation mémoire.

Avec ces panneaux, nous allons surveiller deux mesures : l’utilisation CPU de l’ensemble de nos processus et la consommation CPU moyenne.

De manière à récupérer ces mesures, nous allons lancer des requêtes PromQL sur Prometheus.

7-1-1. Mais… qu’est-ce que PromQL?

PromQL est le langage de requête conçu pour Prometheus. De la même manière que vous lanceriez des requêtes IFQL pour InfluxDB, les requêtes PromQL permettent d’agréger les données en utilisant des fonctions comme sum, average ou la standard deviation.

La syntaxe est assez facile et c’est ce que nous allons montrer dans nos panneaux.

7-1-2. Récupérer la consommation CPU globale

De manière à récupérer la consommation CPU globale, nous allons passer par la fonction PromQL.

À un instant t, la consommation globale est la somme des consommations individuelles.

Voici le résumé :

Image non disponible

7-1-3. Récupérer la consommation CPU moyenne

Il n’y a pas beaucoup de travail pour récupérer la consommation moyenne, nous allons simplement utiliser la fonction PromQL.g

Voici le résumé :

Image non disponible

7-2. Concevoir les jauges horizontales

Les jauges horizontales sont parmi les derniers panels ajoutés à Grafana v6.2.

Notre but avec ce panneau est d’exposer les 10 processus les plus consommateurs de notre système. Pour ce faire, nous allons utiliser la fonction topk qui récupère le top k des éléments d’une mesure.

Similairement à ce que nous avons fait précédemment, nous allons définir des seuils de manière à être informé quand un processus consomme trop de ressources.

Image non disponible

7-3. Concevoir les jauges verticales

Les jauges verticales sont très similaires aux jauges horizontales, il suffit simplement de changer l’orientation dans le panel de visualisation de Grafana.

Nous allons aussi surveiller l’utilisation mémoire grâce à ce panneau, la requête est un peu différente.

Voici le résumé :

Image non disponible

Super ! Il ne nous reste plus qu’un panneau à réaliser.

7-4. Concevoir les graphiques en ligne

Les graphiques en ligne sont inclus dans Grafana depuis longtemps et c’est ce panneau que nous allons utiliser pour avoir une vue historique de l’évolution de nos processus en fonction du temps.

Ce graphe est particulièrement intéressant quand :

  • vous avez une panne dans le passé et vous souhaitez enquêter sur les processus actifs à cette époque ;
  • un certain processus est mort, mais vous voulez avoir une vue de son comportement juste avant que le noyau ne le stoppe.

Okay, voici le résumé :

Image non disponible

À partir de là, nous avons tous les panneaux nécessaires pour notre dashboard.

Vous pouvez les arranger comme vous le souhaitez ou vous inspirer de celui que nous avons construit ensemble.

Vous avez construit un système de surveillance complet avec Grafana.

Bonus : implémenter les filtres ad hoc.

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

Les données temps réel sont intéressantes à observer, mais le vrai gain vient souvent du fait qu’il est possible d’explorer nos données passées.

Dans cette section bonus, nous n’allons pas utiliser la fonction « Explore » (peut-être dans un autre article), nous allons utiliser les filtres ad hoc.

Avec Grafana, vous pouvez définir des variables associées à un graphe. Différentes options existent pour les variables : il est par exemple de définir une variable pour la source de données qui vous permettrait de changer la source de données à la volée.

Image non disponible

À partir de là, cliquez simplement sur « Variables » dans le menu à gauche, puis sur « New » :

Image non disponible

Comme décrit, les filtres ad hoc sont automatiquement appliqués aux dashboards dont la source de données est Prometheus. De retour à notre dashboard.

Observez le coin à gauche de votre dashboard :

Image non disponible

Des filtres !

Supposons maintenant que nous vouliez observer les performances d’un certain processus dans votre système : prenons Prometheus lui-même par exemple.

Naviguez simplement dans les filtres ad hoc et le dashboard s'actualisera automatiquement.

Image non disponible

Vous avez maintenant une vue sur la manière dont Prometheus se comporte sur votre instance.

Vous pourriez aussi retourner un peu dans le passé et voir comment Prometheus se comportait, indépendamment de son PID.

Vous avez construit un dashboard complet avec Grafana pour surveiller votre système.

8. Pour aller plus loin

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.

9. Un mot pour conclure

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!

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2019 schzn. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.