La plupart des outils de journalisation et de supervision sont des outils auxquels vous envoyez des données. Prometheus, à l’inverse, est construit autour du pull : il va chercher, selon un calendrier, les chiffres actuels des éléments qu’il supervise. Cette seule décision de conception façonne presque tout le reste de la manière dont il est déployé et configuré, et ce guide présente l’architecture qui en découle.

Scraping : un pull plutôt qu’un push

Prometheus envoie périodiquement une requête HTTP à chaque système qu’il supervise et relit un instantané des valeurs actuelles des métriques de ce système. Prometheus appelle cela le scraping, et chaque élément qu’il scrape est une cible (target). Un scrape ne transporte que les valeurs à cet instant ; il n’y a aucun historique dans la réponse ; c’est Prometheus qui transforme une suite de scrapes, effectués à intervalles, en historique.

Le modèle pull a une conséquence pratique : tout ce que Prometheus supervise doit exposer un endpoint HTTP (/metrics par convention) qui renvoie ses valeurs actuelles dans un format que Prometheus comprend, au lieu que Prometheus ait besoin d’un listener entrant pour chaque source possible qui lui pousserait des données.

Cibles : applications instrumentées et exporters

Une cible relève de l’une de ces deux catégories :

• Applications directement instrumentées. Votre propre service, à l’aide de l’une des bibliothèques clientes officielles de Prometheus, suit et expose nativement ses propres métriques sur un endpoint /metrics.
• Exporters, pour tout ce qui n’expose pas (ou ne peut pas exposer) lui-même de métriques Prometheus : une base de données, un hôte Linux, un équipement réseau. Un exporter est un petit processus qui s’exécute à côté de l’élément supervisé et traduit ses statistiques natives au format de Prometheus. node_exporter pour les métriques au niveau de l’hôte (CPU, mémoire, disque, réseau) et cAdvisor pour les métriques par conteneur sont deux des plus utilisés.

Parce que le format d’exposition est volontairement du texte simple (traité dans le guide suivant), écrire un exporter, ou même produire des métriques à la main sans aucune bibliothèque cliente, est réaliste même pour quelque chose qui n’a aucune prise en charge officielle de Prometheus.

Trouver les cibles : configuration statique ou découverte de services

Prometheus a besoin d’une liste de cibles à scraper. Pour une poignée d’hôtes stables, les lister à la main dans le fichier de configuration de Prometheus convient. Pour quelque chose de plus grand ou de plus dynamique, avec des machines et des conteneurs qui vont et viennent, cela devient vite impraticable à maintenir à la main. Prometheus s’intègre plutôt à des mécanismes de découverte de services, le DNS, le serveur d’API Kubernetes, les API des fournisseurs cloud et d’autres, pour construire et mettre à jour en continu sa liste de cibles automatiquement à mesure que l’environnement change.

Stockage : la base de données de séries temporelles locale

Les échantillons scrapés atterrissent dans la propre base de données de séries temporelles locale de Prometheus (TSDB), sur disque. Par défaut, Prometheus conserve 15 jours de données ; c’est un flag configurable (--storage.tsdb.retention.time), pas une limite stricte, mais 15 jours suffisent à l’immense majorité des dépannages réels, puisque la plupart des incidents se comparent à il y a quelques minutes ou heures, rarement à des mois. Pour une rétention à long terme ou un stockage centralisé couvrant de nombreux serveurs Prometheus, Prometheus peut aussi être configuré pour transmettre (remote-write) les échantillons vers un système de stockage externe, avec des compromis différents de ceux de sa TSDB locale.

Ce qui entoure le serveur principal

Quelques composants complètent une installation typique :

• Alertmanager est un composant séparé auquel Prometheus transmet les alertes déclenchées. Il les dédoublonne, les regroupe et les achemine vers l’e-mail, Slack, PagerDuty ou tout autre canal que vous configurez, découplant « détecter un problème » de « décider qui est notifié et comment ».
• Grafana (ou l’interface web intégrée de Prometheus, ou d’autres outils) est ce que vous utiliseriez généralement pour explorer et visualiser les données ; Prometheus lui-même se concentre sur la collecte et le stockage fiables des métriques, pas sur le rôle de couche de tableaux de bord.
• PromQL, le langage de requête de Prometheus, est ce sur quoi reposent à la fois les tableaux de bord de Grafana et les règles d’alerte de Prometheus. L’alerting et les tableaux de bord ne sont pas deux systèmes différents collés ensemble ; ce sont deux consommateurs du même langage de requête sur les mêmes données. Les guides suivants de cette série couvrent directement le modèle de données et PromQL.

Assembler les pièces

   ┌──────────────┐        scrape via HTTP          ┌──────────────┐
   │  Serveur     │ ───────────────────────────────▶ │    Cible     │
   │  Prometheus  │                                    │ (/metrics)   │
   └──────┬───────┘                                    └──────────────┘
          │ stocke les échantillons dans
          ▼
   TSDB locale (rétention par défaut de 15j)
          │
   ┌──────┴───────────────┬───────────────────────┐
   ▼                       ▼                       ▼
règles d'alerte          requêtes PromQL         remote write
qui se déclenchent       (Grafana, ad hoc)       (optionnel, stockage externe)
   │
   ▼
Alertmanager → e-mail / Slack / PagerDuty / ...

Tout ce qui est en aval, alertes, tableaux de bord, débogage ad hoc, lit la même TSDB que le scraping remplit. Le reste de cette série commence par ce qui y est réellement stocké.