Que vous soyez administrateur système Linux ou ingénieur DevOps, vous passez beaucoup de temps à surveiller les métriques de performance de vos serveurs.  Vous pouvez parfois avoir des instances qui fonctionnent très lentement sans avoir de véritables indices sur la nature des problèmes.  Il est possible que certaines instances qui ne répondent pas puissent vous empêcher d’exécuter des commandes distantes telles que top ou htop.  Vous pouvez avoir un simple goulot d'étranglement sur votre serveur, mais vous ne pouvez pas l'identifier de manière simple et rapide.

L'objectif de ce didacticiel est de créer un tableau de bord de monitoring complet pour les administrateurs système Linux.  Ce tableau de bord présentera différents panneaux entièrement personnalisables et évolutifs en plusieurs instances pour les architectures distribuées.

Ce que vous apprendrez  

Avant de vous lancer dans cette aventure technique, voyons ce que vous allez apprendre en lisant cet article:  

  • Comprendre les méthodes actuelles pour surveiller les performances des processus sur les systèmes Unix;
  • Apprenez à installer les dernières versions de Prometheus v2.9.2, Pushgateway v0.8.0 et Grafana v6.2;
  • Construisez un script bash simple qui exporte les métriques vers Pushgateway;
  • Construisez un tableau de bord Grafana complet incluant les derniers panneaux disponibles, tels que le "Gauge" et le "Bar Gauge";
  • Bonus: implémentation de filtres ad-hoc pour suivre des processus ou instances individuelles.

Maintenant que nous avons un aperçu de tout ce que nous allons apprendre, et sans plus attendre, passons à une introduction sur ce qui existe actuellement pour les systèmes Unix.

Principes de base de la surveillance de processus Unix  

En ce qui concerne la surveillance de processus pour les systèmes Unix, vous avez plusieurs options.  Le plus populaire est probablement «top».  Top fournit un aperçu complet des métriques de performances de votre système, telles que l'utilisation actuelle du processeur, l'utilisation de la mémoire actuelle ainsi que des métriques pour des processus individuels.  Cette commande est largement utilisée par les administrateurs système et constitue probablement la première commande exécutée lorsqu'un goulot d'étranglement des performances est détecté sur un système (si vous pouvez y accéder bien sûr!).

La commande top est déjà assez lisible, mais il existe une commande qui rend tout encore plus lisible que cela: htop.  Htop fournit le même ensemble de fonctionnalités (processeur, mémoire, disponibilité) que le top, mais de manière colorée et agréable.  Htop fournit également des jauges qui reflètent l'utilisation actuelle du système.

Sachant que ces deux commandes existent, pourquoi voudrions-nous créer un autre moyen de surveiller les processus?

La raison principale en serait la disponibilité du système: en cas de surcharge du système, il est possible que vous n’ayez aucun accès physique ou distant à votre instance.  En externalisant la surveillance des processus, vous pouvez analyser les causes de la panne sans accéder à la machine.  Une autre raison est que les processus sont créés et tués tout le temps, souvent par le noyau lui-même.  Dans ce cas, exécuter une commande top ne vous donnerait aucune information car il serait trop tard pour que vous puissiez identifier qui est à l'origine des problèmes de performances sur votre système.  Vous devrez fouiller dans les journaux du noyau pour voir ce qui a été tué.  Avec un tableau de bord de surveillance, vous pouvez simplement remonter dans le temps et voir quel processus était à l'origine du problème.  Maintenant que vous savez pourquoi nous souhaitons créer ce tableau de bord, voyons l’architecture mise en place pour le construire.

Détailler notre architecture de monitoring

Avant de regarder l'architecture que nous allons utiliser, nous souhaitons utiliser une solution qui est:  

  • Ressources peu coûteuses: c’est-à-dire ne pas consommer beaucoup de ressources sur notre hôte;
  • Simple à mettre en place: une solution qui n’a pas besoin de beaucoup de temps pour être instanciée;
  • Évolutif: si nous surveillons un autre hôte, nous pouvons le faire rapidement et efficacement.

Ce sont les points que nous garderons à l'esprit tout au long de ce tutoriel. L'architecture détaillée que nous allons utiliser aujourd'hui est la suivante:

  • Un VPS Linux chez OVH à 2,99 euros/mois en Ubuntu 18.04
  • Eventuellement un deuxième serveur identique pour monter un cluster

Notre architecture utilise quatre composants différents:  

  • Un script bash utilisé pour envoyer périodiquement des métriques au Pushgateway;
  • Pushgateway: cache de métriques utilisé par des scripts individuels en tant que cible;
  • Prometheus :, qui instancie une base de données de séries temporelles utilisée pour stocker des métriques. Prometheus utilisera Pushgateway comme cible pour récupérer et stocker des métriques.
  • Grafana: un outil de surveillance de dashboard qui récupère les données de Prometheus via des requêtes PromQL et les trace. Pour ceux qui connaissent bien Prometheus, vous savez déjà que Prometheus élimine les métriques exposées par les instances HTTP et les stocke.  

Dans notre cas, le script bash a une durée de vie très réduite et n’expose aucune instance HTTP pour Prometheus.  C'est pourquoi nous devons utiliser le Pushgateway; conçu pour les tâches éphémères, Pushgateway mettra en cache les métriques reçues du script et les exposera à Prometheus.

Installer les différents outils  

Maintenant que vous avez une meilleure idée de ce qui se passe dans notre application, installons les différents outils nécessaires.  

a - Installation de Pushgateway  

Pour installer Pushgateway, exécutez une simple commande wget pour obtenir les derniers fichiers binaires disponibles.

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, extrayez-la et exécutez le fichier exécutable disponible dans le dossier pushgateway.

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

En conséquence, votre Pushgateway devrait commencer en tant que processus d'arrière-plan.

root@vps679545:~/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"

À partir de là, Pushgateway écoute les métriques entrantes sur le port 9091.

b - Installation de Prometheus

Comme indiqué dans la section "Mise en route" du site Web de Prometheus, accédez à la page https://prometheus.io/download/ et exécutez une simple commande wget afin d’obtenir l’archive Prometheus pour votre système d’exploitation.

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, extrayez-la et naviguez dans le dossier principal:

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

Comme indiqué précédemment, Prometheus élimine périodiquement les «cibles» pour en rassembler les métriques. Les cibles (Pushgateway dans notre cas) doivent être configurées via le fichier de configuration de Prometheus.

> vi prometheus.yml   

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

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

Dans la section "scrape_configs", ajoutez une entrée à la propriété de cibles sous la section static_configs.

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

Quittez vi ou nano et exécutez finalement l'exécutable prometheus dans le dossier. Prometheus devrait commencer lors du lancement de la commande finale Prometheus. Pour vous assurer que tout se passe correctement, vous pouvez vous rendre sur http://localhost:9090/graph.  Si vous avez accès à la console Web de Prometheus, cela signifie que tout s’est bien passé.  Vous pouvez également vérifier que Pushgateway est correctement configuré en tant que cible dans ‘Statut’> ‘Cibles’ dans l’UI Web.

c - Installation de Grafana  

Enfin et surtout, nous allons installer Grafana v6.2. Rendez-vous sur https://grafana.com/grafana/download/beta.  Comme auparavant, exécutez une simple commande wget pour l'obtenir.

wget https://dl.grafana.com/oss/release/grafana_6.2.1_amd64.deb

Puis on dépaquette :

sudo dpkg -i grafana_6.2.1_amd64.deb

Maintenant que vous avez extrait le fichier deb, Grafana doit s’exécuter en tant que service sur votre instance.  Vous pouvez le vérifier en exécutant la commande suivante:

root@vps679545:~# 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 Wed 2019-06-05 18:26:55 CEST; 4 days ago
     Docs: http://docs.grafana.org
 Main PID: 17207 (grafana-server)
    Tasks: 12
   Memory: 22.7M
      CPU: 2min 50.843s
   CGroup: /system.slice/grafana-server.service
           └─17207 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/run/grafana/grafana-server.pid --packaging=deb cfg:default.paths.logs=/var/log/grafa

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Vous pouvez également vérifier http://localhost: 3000, qui est l'adresse par défaut de l'interface utilisateur Web de Grafana.  Maintenant que Grafana est installé sur votre instance, nous devons configurer Prometheus en tant que source de données. Vous pouvez configurer votre source de données de cette façon:

C'est tout!  Cliquez sur «Enregistrer et tester» et assurez-vous que votre source de données fonctionne correctement.

Construire un script bash pour récupérer des métriques  

Votre tâche suivante consiste à créer un script bash simple qui récupère des métriques, telles que l'utilisation du processeur et la mémoire utilisée par des processus individuels.  Votre script peut être défini comme une tâche périodique qui sera exécutée toutes les secondes plus tard.  Pour effectuer cette tâche, vous avez plusieurs candidats.  Vous pouvez exécuter les commandes supérieures chaque seconde, l'analyser à l'aide de sed et envoyer les métriques à Pushgateway.  La partie difficile avec top est qu’il s’exécute sur plusieurs itérations, fournissant une moyenne de métriques au fil du temps. Ce n'est pas vraiment ce que nous recherchons.  Au lieu de cela, nous allons utiliser la commande ps et plus précisément la commande ps aux.

Cette commande expose les utilisations individuelles du processeur et de la mémoire, ainsi que la commande exacte qui les sous-tend.  C'est exactement ce que nous recherchons.  Mais avant d’aller plus loin, regardons ce que Pushgateway attend comme entrée.  Pushgateway, à peu près comme Prometheus, fonctionne avec des paires clé-valeur: la clé décrit la métrique contrôlée et la valeur est explicite.

Voici quelques exemples :

Comme vous pouvez le constater, le premier formulaire décrit simplement l'utilisation du processeur, mais le second décrit l'utilisation du processeur pour le processus java.  L’ajout d’étiquettes permet de spécifier plus précisément ce que votre métrique décrit.  Maintenant que nous avons cette information, nous pouvons construire notre script final.  Pour rappel, notre script effectuera une commande ps aux, analysera le résultat, le transformera et l'enverra à Pushgateway via la syntaxe décrite précédemment.  Créez un fichier de script, donnez-lui des droits et accédez-y.

> touch better-top
> chmod u+x better-top
> 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

Si vous souhaitez utiliser le même script pour la mémoire, remplacez simplement le libellé ‘cpu_usage 'par‘ memory_usage ’et le libellé $3z par $4z  Alors, que fait ce script?  Tout d'abord, il exécute la commande ps aux que nous avons décrite précédemment.  Ensuite, il itère sur les différentes lignes et le formate en fonction du format de paire clé / valeur étiqueté décrit précédemment.  Enfin, tout est concaténé et envoyé à Pushgateway via une simple commande curl.

Comme vous pouvez le constater, ce script rassemble toutes les mesures de nos processus, mais il n'exécute qu'une seule itération.  Pour l'instant, nous allons simplement l'exécuter toutes les secondes à l'aide d'une commande de veille.  Plus tard, vous êtes libre de créer un service pour l'exécuter toutes les secondes avec une minuterie (au moins avec systemd).

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

Maintenant que nos métriques sont envoyées à Pushgateway, voyons si nous pouvons les explorer dans la console Web Prometheus.  Rendez-vous sur http://localhost:9090. Dans le champ "Expression", tapez simplement "cpu_usage". Vous devriez maintenant voir toutes les statistiques dans votre navigateur.  Toutes nos félicitations! Les mesures de votre CPU sont maintenant stockées dans Prometheus TSDB.

Construire un tableau de bord avec Grafana  

Maintenant que nos métriques sont stockées dans Prometheus, nous devons simplement créer un tableau de bord Grafana afin de les visualiser.  Nous utiliserons les derniers panneaux disponibles dans Grafana v6.2: les jauges à barres verticales et horizontales, les jauges arrondies et les graphiques linéaires classiques.

1 - Construction de jauges arrondies  

Voici un aperçu de ce que les gabarits arrondis de notre panneau.

Pour l'instant, nous allons nous concentrer sur l'utilisation du processeur de nos processus, car il peut facilement être reflété pour l'utilisation de la mémoire.  Avec ces panneaux, nous allons suivre deux métriques: l'utilisation actuelle du processeur de tous nos processus et l'utilisation moyenne du processeur.  Afin de récupérer ces métriques, nous allons effectuer des requêtes PromQL sur notre instance Prometheus.

Alors .. qu'est-ce que PromQL?

PromQL est le langage de requête conçu pour Prometheus.  De même que ce que vous avez trouvé sur les instances InfluxDB avec InfluxQL (ou IFQL), les requêtes PromQL peuvent agréger des données à l'aide de fonctions telles que la somme, la moyenne et l'écart type.  La syntaxe est très facile à utiliser, comme nous allons le démontrer avec nos panneaux.  

a - Récupération de l'utilisation globale actuelle du processeur  

Afin de récupérer l’utilisation globale actuelle du processeur, nous allons utiliser la fonction somme PromQL.  À un moment donné, notre utilisation globale du processeur est simplement la somme des utilisations individuelles.

b - Récupération de l'utilisation moyenne du processeur  

Peu de travail à faire pour une utilisation moyenne du processeur, vous allez simplement utiliser la fonction avg de PromQL. Vous pouvez trouver le modèle ci-dessous.

2 - Construire des jauges horizontales  

Les jauges horizontales sont l’un des derniers ajouts de Grafana v6.2.  Notre objectif 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 les k premiers éléments d'une métrique.  De manière similaire à ce que nous avons fait auparavant, nous allons définir des seuils afin d’être informés lorsqu'un processus consomme trop de ressources.

3 - Construire des jauges verticales  

Les jauges verticales sont très similaires aux jauges horizontales; il suffit de modifier le paramètre d'orientation dans le panneau de visualisation de Grafana.

De plus, nous allons surveiller notre utilisation de la mémoire avec ce panneau afin que la requête soit légèrement différente.

4 - Graphes linéaires  

Les graphiques linéaires existent depuis longtemps chez Grafana et c’est le panel que nous allons utiliser pour dresser un historique de la façon dont nos processus ont évolué au fil du temps.  Ce graphique peut être particulièrement utile lorsque: Vous avez eu des pannes dans le passé et vous souhaitez savoir quels processus étaient actifs à ce moment-là. Un certain processus est mort mais vous voulez avoir une vue de son comportement juste avant que cela ne se produise.

À partir de là, nous avons tous les panneaux dont nous avons besoin pour notre tableau de bord final.  Vous pouvez les organiser comme vous le souhaitez ou simplement vous inspirer de celui que nous avons construit.

Bonus: Explorer les données en utilisant des filtres ad hoc  

Les données en temps réel sont intéressantes à voir - mais la véritable valeur réside dans l'exploration de vos données.  Dans cette section bonus, nous n’allons pas utiliser la fonction ‘Explorer’ (peut-être dans un autre article?), Nous allons utiliser des filtres ad hoc.  Avec Grafana, vous pouvez définir des variables associées à un graphique. Vous disposez de nombreuses options pour les variables: vous pouvez par exemple définir une variable pour votre source de données qui permette de basculer dynamiquement la source de données dans une requête.  Dans notre cas, nous allons utiliser de simples filtres ad hoc pour explorer nos données.

À partir de là, cliquez simplement sur "Variables" dans le menu de gauche, puis sur "Nouveau".

Jetez un coup d'œil au coin supérieur gauche du tableau de bord.

Filtres!  

Supposons maintenant que vous souhaitiez que certains processus de votre système soient performants: prenons Prometheus lui-même, par exemple.  Il suffit de naviguer dans les filtres et de voir le tableau de bord se mettre à jour en conséquence.

Vous avez maintenant un aperçu de la manière dont Prometheus se comporte sur votre instance.  Vous pouvez même remonter dans le temps et voir comment le processus s'est comporté, indépendamment de son pid!

Un mot rapide pour conclure  

Grâce à ce tutoriel, vous avez maintenant une meilleure compréhension de ce que Prometheus et Grafana ont à offrir.  Vous savez que vous avez un tableau de bord de surveillance complet pour une instance, mais il y a vraiment une petite étape pour le faire évoluer et surveiller tout un cluster d'instances Unix.  La supervision de DevOps est définitivement un sujet intéressant - mais elle peut se transformer en cauchemar si vous ne le faites pas correctement.