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 sur la page du livre depuis le site des Éditions ENI.

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 (ou récupération active) 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 (ou envoi avec récupération passive) 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 - lorsqu’il est couplé avec des agents de monitoring, comme avec la suite Beats - est plutôt passif dans son mode de fonctionnement : il attend que la donnée lui parvienne (soit directement, soit à travers un mécanisme d’acquisition plus complexe avec des pipelines de traitement). De son côté, 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 généralement basé sur la notion de pull : le moteur interroge les points de collecte configurés.

Il est également possible d’utiliser le mode push (dans certains cas spécifiques, notamment via PushGateway ou lors de l’utilisation d’un agent OpenTelemetry par exemple), même si la plupart des exemples de ce livre se feront avec le mode pull.

Il sera également question du composant Push Gateway qui permet d’exposer des métriques de manière passive afin de les récupérer de manière active. Le chapitre Surveillance blackbox, SNMP et Push Gateway aborde...

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 (’_’). En fonction des produits, la convention de nommage s’appuiera sur des notations en Camel Case (la séparation se fait en utilisant des caractères majuscules) ou en snake_case (tout est en minuscule et la séparation se fait à l’aide de 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...