Aller au contenu
Retour au glossaire
Observabilité

Qu'est-ce que Prometheus ?

Prometheus est le système open-source de monitoring et d'alerting devenu le standard de fait pour les environnements Kubernetes. Modèle pull, base de données time-series, langage PromQL.

À quoi sert Prometheus

Prometheus est un système de supervision open-source créé chez SoundCloud en 2012, donné à la CNCF en 2016 (le 2e projet après Kubernetes lui-même) et Graduated dès 2018. Il collecte et stocke des métriques (séries temporelles de valeurs numériques) et permet de les requêter pour bâtir des dashboards et déclencher des alertes.

Le succès de Prometheus tient à un modèle architectural simple et adapté aux infrastructures dynamiques : le serveur Prometheus tire les métriques depuis les applications cibles (modèle pull) en interrogeant régulièrement un endpoint HTTP /metrics. Pas besoin d'agent à déployer sur chaque hôte, pas de file d'attente intermédiaire à gérer, pas de configuration push à maintenir côté applicatif.

Le modèle de données

Prometheus stocke chaque métrique comme une série temporelle identifiée par un nom et un ensemble de labels (couples clé/valeur). Exemple :

http_requests_total{method="POST", status="200", service="checkout"}

Cette structure permet une grande granularité : on peut filtrer, agréger, comparer les métriques selon n'importe quelle dimension sans avoir prévu cette analyse à l'avance.

Le langage PromQL exploite cette structure. rate(http_requests_total[5m]) calcule le taux de requêtes par seconde sur les 5 dernières minutes ; sum by (status) (rate(http_requests_total[5m])) agrège par code HTTP. Les requêtes complexes (latence p95, taux d'erreur par service, capacity planning) se construisent en quelques lignes.

L'écosystème Prometheus

Prometheus seul est rarement déployé seul. La stack standard chez les clients Hidora combine généralement :

  • Prometheus Server : collecte, stockage time-series, évaluation des règles d'alerte.
  • Alertmanager : routage des alertes vers Slack, PagerDuty, email, avec déduplication, regroupement et silences.
  • Grafana : visualisation des métriques via dashboards interactifs.
  • Node Exporter : expose les métriques système (CPU, RAM, disque, réseau) de chaque hôte.
  • kube-state-metrics : expose l'état des objets Kubernetes (pods, deployments, nodes) pour supervision.
  • Service Monitor / Pod Monitor : ressources Kubernetes pour auto-découvrir les cibles à scraper.

Pourquoi Prometheus est devenu le standard Kubernetes

Service discovery native. Prometheus s'intègre nativement à Kubernetes via le ServiceMonitor : déclarer une nouvelle application à superviser revient à créer une ressource YAML, sans modifier la configuration du serveur Prometheus. Cette dynamicité est essentielle dans des environnements où les pods naissent et meurent à la minute.

Format ouvert. Le format de métrique OpenMetrics (dérivé du format Prometheus) est devenu standard CNCF. Toutes les briques majeures (Kubernetes, etcd, kube-apiserver, NGINX, PostgreSQL, RabbitMQ, etc.) exposent leurs métriques nativement au format Prometheus.

Couplage SLO/SRE. Les outils comme Pyrra ou Sloth génèrent automatiquement des règles Prometheus depuis une déclaration SLO. Le couple Prometheus + PromQL est la fondation technique de toute pratique SRE moderne.

Limites à connaître

Prometheus reste un système de monitoring, pas un système de logs ou de traces. Pour ces autres signaux, il est complété par :

  • Loki ou Elastic Stack pour les logs.
  • Tempo ou Jaeger pour le traçage distribué.

Côté scalabilité, un Prometheus monolithique gère bien jusqu'à 1 à 2 millions de séries actives. Au-delà, des architectures comme Thanos ou Mimir offrent une persistance long-terme, un stockage objet S3-compatible et une haute disponibilité.

En pratique chez Hidora

Sur les missions clients, nous déployons systématiquement la stack kube-prometheus-stack (chart Helm officiel) avec Alertmanager configuré pour escalader vers les équipes oncall. Les SLO sont déclarés en YAML et générés en règles Prometheus via Sloth, ce qui permet aux équipes produit de modifier leurs objectifs de fiabilité par pull request.

Services Hidora associés

  • Managed Services : exploitation 24/7 d'une stack Prometheus avec 200+ métriques supervisées par environnement.
  • Consulting : conception de la stratégie d'observabilité, choix des SLI, conception des dashboards Grafana.
  • Observabilité, Kubernetes, SRE : briques techniques et méthodologiques associées.