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. Architecture de Prometheus
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

Architecture de Prometheus

Objectifs du chapitre et prérequis

1. Contexte et prérequis

Prometheus est un outil novateur qui offre des performances intéressantes dans son domaine si on le compare à des outils existants du marché. Avant d’aller plus loin dans la découverte de cet outil, il est intéressant de prendre un peu de recul pour comprendre son fonctionnement.

2. Fichiers téléchargeables

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

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

Architecture de Prometheus

1. Contexte

Lors de la mise en place d’un moteur de surveillance, il est généralement question du mode de collecte. En anglais, cette question prend la forme « pull vs push ». En français, cette affirmation est difficilement traduisible mais on peut la résumer au choix suivant :

  • Aller chercher la donnée (pull).

  • Attendre que la donnée arrive toute seule (push).

Les deux modes de fonctionnement ont leurs avantages et inconvénients mais les affirmations suivantes sont généralement admises :

  • Un modèle pull a généralement besoin de connaître beaucoup d’informations sur le système à surveiller : qui a généré la métrique ? D’où vient-elle ? Etc.

  • Un modèle push aura généralement tendance à nécessiter beaucoup moins de connaissances : la donnée est là mais on ne sait pas trop comment elle est arrivée.

Pour prendre exemple sur des outils existants, Elasticsearch utilise un modèle de type push ; un outil comme Nagios peut fonctionner avec ces deux modes mais fonctionnera généralement sur un modèle pull (avec le lancement de sondes).

Dans le cas de Prometheus, le fonctionnement du moteur est basé sur la notion de pull : le moteur cherche l’information par ses propres moyens.

Prometheus supporte dans une certaine mesure le modèle push en passant par une passerelle de type push (le composant Push Gateway). Le chapitre Surveillance blackbox, SNMP et Push Gateway aborde le sujet plus loin dans cet ouvrage.

2. Liste des composants de l’architecture de Prometheus

Prometheus s’appuie sur une architecture de type microservice pour fonctionner. Voici ci-dessous une liste non exhaustive des briques fréquemment utilisées :

  • Les agents ou exporteurs Prometheus.

  • Le moteur Prometheus.

  • Le gestionnaire d’alerte alertmanager.

  • L’application Grafana pour la restitution des données.

  • Le composant pushgateway.

Cette liste est très souple puisqu’en dehors de Prometheus, tous ces composants sont optionnels.

images/ep02-p4.png

Architecture de Prometheus - schéma en provenance de la documentation officielle du projet

3. Langage PromQL

La communication avec Prometheus se fait à...

Quelques notions sur le format YAML

Prometheus ou Grafana font énormément appel au format YAML. Ce chapitre rappelle quelques notions à son sujet.

Pour l’essentiel, le YAML permet d’écrire des structures de données. Ces données peuvent être sous la forme de listes ou de dictionnaires. Ce langage permet d’écrire les mêmes structures de plusieurs façons en fonction de l’approche désirée : lisibilité ou compacité (même si, généralement, la lisibilité est à privilégier).

Concernant le format JSON, ce dernier peut être utilisé en l’état dans du YAML. La principale différence entre le JSON et la notation YAML se trouve surtout au niveau de la lisibilité.

1. Déclaration de couples clés/valeurs

Le langage YAML sert à déclarer des couples clés/valeurs. La clé se présente sous la forme d’une suite de caractères suivie de deux-points (’:’) suivis eux-mêmes d’un caractère espace (’ ’).

Le nom de ces clés n’a pas de limitation. En revanche, il est préférable de privilégier des noms simples faisant appel à des lettres, des chiffres et les caractères tirets bas (’_’).

Voici des exemples de noms de clés : kind, apiVersion, spec, data.

Le contenu est ensuite stocké à la suite de la clé. Ce contenu peut prendre les formes suivantes :

  • Un contenu simple (chaîne de caractères, entier, chiffre à virgule, etc.).

  • Un sous-objet.

  • Un tableau d’éléments (lui-même...