Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Prometheus et Grafana
  3. Agrégation et archivage
Extrait - Prometheus et Grafana Surveillez vos applications et composants système
Extraits du livre
Prometheus et Grafana Surveillez vos applications et composants système
2 avis
Revenir à la page d'achat du livre

Agrégation et archivage

Objectifs du chapitre et prérequis

1. Contexte et prérequis

Les précédents chapitres ont été consacrés à la mise en place de la collecte des différents éléments du système d’information. En revanche, les aspects sur la centralisation ou l’archivage des données n’ont pas été abordés.

Ce chapitre aborde le mécanisme de fédération de Prometheus ainsi qu’un exemple de solution d’archivage s’appuyant sur la base de données InfluxDB.

2. Fichiers téléchargeables

Vous pouvez récupérer les exemples sur le repository GitHub suivant : https://github.com/EditionsENI/prometheus-grafana

Vous pouvez également récupérer ces fichiers dans l’archive chapitre-17.tar.gz depuis la page Informations générales.

Fédération d’instances Prometheus

1. Contexte

Lors des chapitres précédents, l’utilisateur a abordé la mise en place de Prometheus dans plusieurs contextes :

  • Utilisation d’un serveur classique.

  • Déploiement au sein d’un container à l’aide de Docker Swarm.

  • Déploiement au sein d’un cluster Kubernetes.

Prometheus fonctionne parfaitement dans un container du moment qu’un mécanisme de persistance est en place. Toutefois, le fait d’avoir des métriques dispersées dans différentes instances rend difficile l’exploitation dans l’interface de Grafana.

Afin de corriger cet aspect, il est possible de créer une instance chapeau qui se charge de collecter les métriques des différentes instances à l’aide du mécanisme de fédération.

2. Mise en place de la fédération

a. Consultation du point de fédération

Prometheus dispose d’un point d’entrée /federate. Ce dernier permet de récupérer les métriques collectées par le moteur.

Voici ci-dessous un exemple de consultation du contenu à l’aide de la commande curl :

$ curl http://localhost:9090/federate 

Par défaut, la commande ne renvoie rien. En effet, il est nécessaire de spécifier quels sont les éléments à récupérer à l’aide du paramètre match. Ce dernier est un tableau : dans le cas de la consultation via un navigateur ou à l’aide de curl, le paramètre doit être postfixé par des crochets (’[’ et ’]’).

Il reste ensuite à utiliser un sélecteur de métriques. Ainsi, pour récupérer toutes les métriques sans distinction, utilisez l’expression suivante :

{job!=""} 

Ce paramètre doit être passé sous la forme d’une requête HTTP à l’aide de l’option --data-urlencode suivie de la concaténation du champ match[] et de la requête de sélection séparées par un signe égal (’=’).

Autre aspect, l’option --data-urlencode enclenche automatiquement l’utilisation du verbe HTTP POST alors qu’il faut utiliser le verbe...

Archivage dans InfluxDB

1. Contexte

Prometheus est spécialisé dans l’acquisition de séries temporelles. Toutefois, au bout d’un certain temps, la quantité de données peut devenir un frein à l’utilisation de ce dernier. En effet, une métrique collectée toutes les 30 secondes engendre 86 400 points sur un mois et environ un million de points sur un an.

Une telle quantité de points dans un tableau de bord Grafana n’est pas raisonnable :

  • Prometheus prend plus de temps à répondre et consomme beaucoup de ressources. 

  • Grafana met beaucoup de temps à afficher les données.

  • Le navigateur de l’utilisateur devient inutilisable.

Prometheus n’est pas fait pour stocker beaucoup de métriques et il vaut mieux aborder son utilisation en tant que simple cache sur une période d’environ un mois.

Dans ce qui va suivre, l’utilisateur abordera une technique permettant de réduire ce nombre de points par sous-échantillonnage. Prometheus en lui-même ne supporte pas ce mécanisme. En revanche, il offre la possibilité de stocker ses métriques dans un espace de stockage distant.

Pour la suite, le lecteur abordera la mise en place de cette technique dans le cas de la base InfluxDB.

2. Présentation d’InfluxDB

InfluxDB est une base de données de séries temporelles dont le fonctionnement est assez similaire à celui de Prometheus. Elle permet également de mettre en place de la surveillance mais en utilisant un mécanisme basé sur la publication de données (push mode) alors que Prometheus est basé sur une publication active (pull mode).

Autre grande différence d’InfluxDB : elle est souvent utilisée comme une base de données pour des applications classiques. Elle dispose également de capacités supplémentaires par rapport à Prometheus :

  • Résolution des données temporelles plus fine (nanosecondes contre millisecondes pour Prometheus).

    Stockage de nombres à virgule (float64), entiers (int64), booléens et chaînes de caractères (Prometheus ne supporte que les nombres à virgule).

  • Possibilité de manipuler la donnée une fois acquise (notamment le sous-échantillonnage).

Les différences...