Prometheus : Philosophie, Time Series et mécanique du modèle Pull

D-GothLeave a Comment on Prometheus : Philosophie, Time Series et mécanique du modèle Pull
Facebook Twitter Google Plus Instagram YouTube Twitch

Préambule — Un changement de paradigme

Aborder Prometheus demande d’oublier les réflexes du monitoring classique basé sur l’hôte. Ce n’est pas un simple collecteur d’états (OK/CRITICAL), c’est une base de données de séries temporelles (TSDB) dotée d’un moteur de calcul multidimensionnel.

Là où les systèmes traditionnels raisonnent en « objets », Prometheus raisonne en flux de données numériques. La philosophie est sans appel : si vous ne comprenez pas l’atome de la donnée, vous subirez l’explosion de votre infrastructure.

1. La Série Temporelle (Time Series) : L’atome de Prometheus

Tout, absolument tout dans Prometheus, est une série temporelle. Une série est un flux de valeurs numériques horodatées partageant une identité unique définie par son nom et ses dimensions (labels).

1.1 Anatomie et Identité Unique

Une série est identifiée par sa notation vectorielle :

http_requests_total{method="POST", service="api", env="prod"}

  • L’Identité (Identity) : La combinaison exacte des labels constitue l’ID unique de la série. Un seul label qui change génère une nouvelle série en base.

  • Le Cardinality Killer (Exemple de piège) : http_request_duration_seconds{client_ip="1.2.3.4", trace_id="abc123"}

    En incluant une IP client ou un ID de trace, vous créez des millions de séries uniques. C’est l’explosion de cardinalité : votre RAM sature et la TSDB s’effondre en quelques minutes.

1.2 La Dimensionnalité Matricielle

Les labels permettent de briser les silos hiérarchiques. On ne surveille plus « le serveur X », on interroge la capacité de « tous les serveurs du service API en environnement Prod ». Cette approche matricielle permet une agrégation chirurgicale sans jamais modifier la configuration de collecte.

2. Le modèle Pull : Maîtrise et inversion du flux

2.1 La mécanique du « Scrape »

Le modèle Pull signifie que le serveur Prometheus initie une requête HTTP vers une cible (target) pour lire une page de texte simple exposant les métriques.

2.2 Avantages structurels en production

  • Backpressure naturelle : Le serveur est maître de son rythme. Il évite le « Push Storm » (déluge de données) qui paralyse les systèmes lors d’incidents majeurs.

  • Santé native (Upstream check) : L’échec de contact d’une cible génère l’item up == 0. La connectivité est monitorée par défaut.

  • Service Discovery : Le Pull s’interface avec les API (Kubernetes, AWS, Consul). Prometheus découvre ses cibles et automatise le « Scraping ».

2.3 Évolutions 2026 : Remote Write & Agent Mode

  • Agent Mode : Standard pour la scalabilité. Un Prometheus léger (sans stockage local) scrape et forwarde les données via remote_write.

  • Pushgateway : Composant legacy pour les jobs batch. À éviter en 2026 au profit d’un remote_write direct depuis les applications pour éviter les métriques périmées (stale metrics) et les problèmes de déduplication.

3. Typologie des métriques : Comprendre pour calculer

Prometheus traite ses données selon quatre types logiques :

  • Counter (Compteur) : Ne fait que croître. Les fonctions rate() et irate() gèrent nativement les redémarrages de processus (counter reset).

  • Gauge (Jauge) : Peut varier dans les deux sens (ex: RAM, Température).

  • Histogram & Summary : Mesurent la distribution (latence).

    • Native Histograms (Stable 2026) : Utilise des buckets exponentiels dynamiques. C’est la recommandation actuelle pour obtenir une haute résolution sans explosion de séries.

    • Summary : Calcule les quantiles côté client. Précis, mais non agrégable mathématiquement entre plusieurs instances.

4. Architecture Interne : Le cycle de vie de la donnée

Le serveur Prometheus est une unité autonome composée de trois piliers :

  1. Retrieval (Scrape & Relabeling) : Le module de collecte. Le Relabeling est l’étape cruciale : c’est ici qu’on élimine les labels inutiles pour brider la cardinalité avant le stockage.

  2. TSDB (Storage) : Base optimisée. Les données sont compressées dans des blocs de 2h (~1.3 octet par échantillon). La rétention locale est courte (15j-2 mois) ; le long terme est déporté vers des backends comme VictoriaMetrics ou Mimir.

  3. PromQL (Query Engine) : Langage fonctionnel conçu pour les vecteurs. Il transforme des millions de séries en un résultat unique : sum(rate(http_requests_total[5m])) by (service).

5. Calculer plutôt que recevoir : L’alerting par analyse d’état

Dans le monitoring traditionnel (SNMP Traps, push d’événements), l’alerte est un « objet » envoyé par une cible quand elle détecte elle-même un problème. C’est un modèle passif : si la cible meurt brutalement ou si le réseau est coupé, elle ne peut rien envoyer. Le silence devient alors votre pire ennemi.

5.1 L’évaluation cyclique (Evaluation Loop)

Prometheus renverse ce flux. Le serveur n’attend rien ; il exécute des requêtes PromQL à intervalles réguliers (définis par evaluation_interval) sur sa propre base de données.

  • L’alerte n’est pas un signal entrant, c’est le résultat non-vide d’une équation.

  • Si la requête up == 0 renvoie un résultat, Prometheus constate l’état d’échec et initie le cycle d’alerte.

5.2 La puissance de l’abstraction mathématique

Parce qu’une alerte est une requête, elle bénéficie de toute la puissance de calcul du moteur :

  • Seuils dynamiques : On n’alerte pas sur un CPU > 90%, mais sur un CPU dont la tendance de croissance prédit une saturation dans les 2 prochaines heures : predict_linear(node_cpu_seconds_total[1h], 7200) > 0.9.

  • Corrélation de masse : On peut alerter si plus de 20% des instances d’un même service répondent en erreur 500, isolant ainsi un problème global d’une erreur locale isolée.

  • Gestion des « blips » : Grâce à la clause for: 5m, Prometheus vérifie que l’état critique est persistant sur plusieurs cycles de calcul avant de considérer l’alerte comme réelle (Firing), éliminant naturellement le bruit des micro-pics.

5.3 Séparation des préoccupations : Alertmanager

Prometheus calcule l’état (Firing), mais il ne gère pas la notification. Il délègue cette tâche à l’Alertmanager. Cette séparation permet :

  • Le Groupement : Recevoir un seul email pour 100 micro-services qui tombent simultanément (groupement par label cluster ou service).

  • L’Inhibition : Ne pas recevoir 500 alertes « Service DOWN » si l’alerte « Switch Réseau DOWN » est déjà active sur le même périmètre.

  • Le Silence Chirurgical : Éteindre les notifications pour un label spécifique (env="dev") sans modifier une seule ligne de code d’alerte.

La donnée comme juge de paix

En production, cette approche transforme votre équipe. On ne « reçoit » plus des problèmes, on interroge la santé du système. L’alerte devient une métrique comme les autres, historisée et analysable, permettant d’identifier non seulement quand ça casse, mais pourquoi la tendance a dérivé.

Leave a Reply