Vendredi 14 h, le monitoring est vert. CPU à 35 %, mémoire confortable, disque loin du plafond. Pourtant le support reçoit des captures d'écran : le checkout met huit secondes, parfois plus. L'équipe ouvre Grafana, scroll entre douze dashboards importés par défaut — node_exporter, nginx, quelques compteurs applicatifs — et ne trouve rien qui monte au moment des plaintes.
Ce n'est pas un échec de Prometheus. C'est un échec de choix de signaux. Vous mesurez l'état de la machine, pas le chemin que parcourt une commande quand elle ralentit.
Ce que Prometheus fait bien — et ce qu'il ne fera pas à votre place
Prometheus stocke des séries temporelles et les interroge en PromQL. Il excelle pour répondre à des questions du type « le p95 de /api/checkout a-t-il doublé depuis le déploiement de 11 h ? » ou « le pool de connexions PostgreSQL est-il saturé en permanence depuis hier ? ».
Il ne devine pas quelles métriques vous concernent. Avant d'installer un exporter de plus, posez une question simple : si le site est lent demain, quelle courbe doit monter pour que l'équipe sache où creuser ? Tout le reste est du bruit qui rassure.
Une métrique qui ne peut pas répondre « plus lent qu'hier, sur quel parcours ? » ne sert qu'à décorer un dashboard.
RED, USE et métriques métier : trois grilles, un ordre
Trois cadres reviennent souvent. Ils ne s'excluent pas — ils s'empilent.
| Cadre | Question | Exemples utiles |
|---|---|---|
| RED | Le service répond-il assez vite et sans erreur ? | http_requests_total, ratio 5xx, histogramme de durée par route |
| USE | La ressource sous-jacente est-elle saturée ? | CPU en attente I/O, disque, connexions DB idle = 0 |
| Métier | L'utilisateur atteint-il son objectif ? | checkout_started vs checkout_completed, panier abandonné |
Pour une API ou un site dynamique, commencez par RED sur les routes critiques — pas sur tout le catalogue. Un histogramme de latence sur /api/panier et /api/paiement vaut mieux que cent compteurs sur des endpoints admin rarement appelés.
La méthode USE devient indispensable dès que RED montre de la lenteur sans erreur HTTP : le serveur répond 200 en trois secondes parce que la base peine, pas parce que PHP calcule mal.
Histogrammes : calibrer les buckets sur votre SLO, pas sur les défauts
Une erreur fréquente : copier des buckets génériques (0.005, 0.01, 0.025…) alors que votre SLO interne dit « 95 % des requêtes checkout < 500 ms ». Des buckets mal choisis mentent sur le p95 : la quantile calculée tombe entre deux seaux et lisse une dégradation réelle.
Exemple de requête PromQL pour un p95 par route :
histogram_quantile(
0.95,
sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route)
)
Adaptez les buckets à votre réalité : si la plupart des requêtes tiennent sous 200 ms mais que le checkout peut monter à 2 s, vos seaux doivent couvrir cette plage — pas seulement la zone sub-seconde.
Alertez sur ce qui casse l'expérience, pas sur des seuils arbitraires : p95 checkout > 2 s pendant dix minutes, pool DB sans connexion idle disponible, lag de file Redis au-dessus d'un seuil métier. Un alerte « disque à 70 % » sans corrélation utilisateur alimente la fatigue d'alertes sans protéger le checkout.
Labels et cardinalité : le piège silencieux
Prometheus n'est pas un entrepôt de logs. Chaque valeur de label multiplie les séries temporelles. http_requests_total{user_id="8842"} ou {url="/produit/chaise-rouge-42"} peut faire passer une installation saine à un TSDB ingérable en quelques jours.
Règles pragmatiques :
- Route template oui (
/api/cart/{id}), URL complète non. - Code HTTP, méthode, environnement oui ; identifiant client non.
- Besoin de détail par utilisateur ou par commande ? Traces ou logs structurés, pas labels Prometheus.
Sur un VPS modeste, une cardinality incontrôlée coûte en RAM et en lenteur de requêtes PromQL — au moment où vous en avez le plus besoin.
Que instrumenter en premier selon votre hébergement
Sur mutualisé ou petit VPS, ne dupliquez pas la stack d'un hyperscaler :
- Application — durée par route critique, erreurs, saturation pool DB si vous la gérez.
- Nginx ou reverse proxy — latence amont, connexions actives.
- node_exporter — USE basique (CPU, RAM, disque) pour écarter une saturation évidente.
OpenTelemetry ou un client Prometheus natif (Go, Node, PHP avec bibliothèque adaptée) au cœur de l'app bat une collection d'exporters exotiques. Retention locale de quinze jours suffit souvent ; au-delà, Thanos ou Mimir n'ont de sens qu'avec du volume et une équipe ops dédiée.
Comparez les offres où vous pouvez installer vos propres agents via notre annuaire — mutualisé strict limite parfois Prometheus on-host ; un VPS ou cloud managé ouvre plus de marge.
Quand les métriques ne suffisent plus
Prometheus agrège. Une requête lente sur mille rapides peut rester invisible dans le p95. Les lenteurs sporadiques, les locks Redis ponctuels, la requête SQL oubliée dans un code path rare : là, il faut une trace (Tempo, Jaeger) ou des logs corrélés avec un request_id commun — sujet traité dans Logs centralisés.
Les trois piliers se complètent :
- Métriques — tendance, alerte, SLO.
- Logs — contexte textuel, stack trace, paramètres.
- Traces — chemin d'une requête à travers les services.
Prometheus seul n'est pas une observabilité complète. C'est le bon outil pour les signaux agrégés — à condition d'avoir choisi les bons signaux.
Le sommet : l'illusion des dashboards pleins
Voici ce que les tutos « Grafana en dix minutes » passent sous silence.
Choisir des métriques, c'est parier sur les goulots plausibles de votre architecture — et retirer le reste du bruit.
Décider et avancer sans angle mort
Sur une demi-journée, vous pouvez remettre Prometheus au service du diagnostic :
- Listez deux parcours critiques (checkout, login, API partenaire) — pas « tout le site ».
- Appliquez RED sur ces routes : compteur, erreurs, histogramme avec buckets alignés SLO.
- Ajoutez une métrique USE liée au soupçon principal (pool DB, Redis, file de jobs).
- Revoyez les labels — supprimez toute dimension à haute cardinalité.
- Remplacez une alerte CPU par une alerte p95 ou saturation pool ; testez en charge simulée.
- Documentez une requête PromQL que l'astreinte doit lancer en premier incident.
Pour comparer des hébergeurs où vous garderez la main sur l'installation (VPS, cloud, PaaS partiel), utilisez le comparateur et les guides. Si la lenteur reste opaque après métriques propres, enchaînez vers Tracing distribué plutôt que d'ajouter un quinzième dashboard.
Exercice concret : simulez une dégradation (pool DB réduit, latence artificielle) et vérifiez qu'une seule requête PromQL identifie la couche fautive en moins de cinq minutes. Si ce n'est pas le case, vos métriques racontent encore la mauvaise histoire.
Questions fréquentes
Quelles métriques minimum pour une API ?
RED : débit, erreurs, durée en histogramme. Complétez par la saturation du pool de connexions ou du cache si la lenteur y corrèle — pas seulement le CPU serveur.
Pourquoi éviter trop de labels ?
Chaque label multiplie les séries temporelles. Route template et code HTTP oui ; user_id et URL complète non. Le détail individuel va dans les traces ou les logs.
Counter, gauge ou histogram — que choisir ?
Counter avec rate() pour les volumes ; gauge pour un état instantané ; histogram pour les latences avec buckets calibrés sur votre SLO.
Prometheus seul suffit-il pour diagnostiquer une lenteur ?
Pour les tendances et alertes agrégées, oui. Pour les outliers sporadiques, complétez avec logs corrélés et traces — Prometheus ne remplace pas une investigation ligne par ligne.
La prochaine fois qu'un dashboard sera entièrement vert pendant que les utilisateurs ralentissent, posez une question : quelle métrique manque pour raconter ce qu'ils vivent ? C'est là que commence un Prometheus utile.