Métriques & le modèle pull

Le concept en une phrase

Une métrique est une valeur numérique horodatée que Prometheus vient chercher (pull) à intervalle régulier auprès d’exporters.

Sur la VM monitoring de Port-aux-Français, des dizaines de conteneurs, de bases et de services tournent en continu. Personne ne va lire leur état un par un. Prometheus s’en charge lui-même : toutes les 15 secondes, il interroge chaque cible connue, note un chiffre daté, et construit dans le temps une courbe qui raconte l’histoire du système — CPU qui grimpe, connexions qui chutent, disque qui se remplit.

Les grands principes

1. Une série temporelle, pas un chiffre isolé

Une métrique brute ressemble à ça : container_cpu_usage_seconds_total{container="postgres-af"} 842.3. Seule, cette valeur ne dit rien. Ce qui compte, c’est la série : la même mesure répétée toutes les 15 secondes, avec ses labels (container, instance, job…) qui permettent de la filtrer et de la croiser. Une métrique sans historique est une photo ; une série temporelle est un film.

2. Pull vs push — pourquoi Prometheus va chercher l’info

Deux philosophies s’opposent pour collecter une métrique :

Push — chaque service envoie lui-même ses métriques vers un collecteur central.
Pull — le collecteur (Prometheus) va interroger chaque cible à intervalle régulier.

Prometheus a choisi le pull, et ce choix a deux conséquences concrètes :

La santé du scrape devient elle-même une métrique. Si Prometheus n’arrive plus à interroger une cible, il le sait immédiatement (up == 0) — la panne de collecte est aussi visible que la panne surveillée.
La découverte de cibles est centralisée. On déclare la liste des cibles à un seul endroit (le fichier de configuration Prometheus), plutôt que de configurer chaque service pour qu’il sache où pousser ses données.

Le revers : Prometheus doit pouvoir joindre réseau chaque cible. Sur un lien satellite intermittent, une base injoignable pendant une coupure n’enverra tout simplement rien à collecter — le pull s’arrête tout seul, proprement.

3. L’exporter — le traducteur universel

Tous les logiciels ne savent pas nativement parler le format Prometheus. Un exporter est un petit programme qui traduit l’état d’un système dans ce format, prêt à être interrogé :

node_exporter — l’état de la machine hôte (CPU, RAM, disque, réseau).
postgres_exporter — les métriques internes de PostgreSQL (connexions actives, requêtes lentes).
cAdvisor — les métriques des conteneurs Docker (celui qu’on utilise dans la VM monitoring TAAF).

Sans exporter, il n’y a rien à scraper : c’est la première pièce à poser avant même de penser dashboard.

4. Les 4 signaux d’or — quoi mesurer en priorité

Face à un système inconnu, quatre métriques donnent 80 % du diagnostic :

Latence — combien de temps une opération prend.
Trafic — combien de requêtes ou de connexions par seconde.
Erreurs — quelle proportion échoue.
Saturation — à quel point une ressource (CPU, disque, mémoire) est pleine.

Avant d’instrumenter un service en détail, commencer par ces quatre signaux évite de se noyer dans des métriques accessoires.

5. Agréger dans le temps — l’instantané ne suffit pas

Une valeur brute à un instant T ne dit pas si la situation s’améliore ou se dégrade. PromQL fournit des fonctions pour lire la tendance :

rate() — le taux de variation par seconde d’un compteur, sur une fenêtre glissante. Indispensable pour transformer un compteur qui ne fait qu’augmenter (container_cpu_usage_seconds_total) en une vitesse lisible.
Moyennes, quantiles, sommes — pour résumer plusieurs séries (tous les conteneurs, toutes les bases) en une lecture globale.

Une métrique isolée est un point ; agrégée dans le temps, elle devient une tendance qu’on peut alerter dessus.

Où ça sert dans TAAF

TP1 — Rendre la vue au SOC — premier scrape Prometheus + cAdvisor, premier dashboard Grafana sur les conteneurs de Port-aux-Français.
TP2 — Lire l’état des stations dans leurs données métier — transformer les métriques et les tables de base_af en dashboards qui aident à décider, pas seulement à constater.
TP bonus — Supervision énergie polaire de Dumont d’Urville — un cas où la cible n’est pas nativement Prometheus : on y voit un modèle de collecte différent (SNMP/Zabbix), utile en contraste avec le pull.

Ressources associées

Ces liens sont des points de départ pour vos propres recherches — voir la bibliothèque complète sur la page Ressources, section Observabilité.

Prometheus — documentation officielle : le modèle pull, les types de métriques et PromQL expliqués à la source.
Google SRE Book — chapitre Monitoring : l’origine des 4 signaux d’or (golden signals).

À chercher par vous-même : « Prometheus pull vs push », « PromQL rate vs irate », « node_exporter metrics list », « the four golden signals SRE ».