Prometheus : configuration des alertes, métriques et requêtes PromQL

Table des matières :

1. Architecture Prometheus/Alertmanager : ce que vous déployez réellement
2. Exposer des métriques : types, conventions et pièges de l’écosystème PHP/PrestaShop
3. prometheus.yml : scrapes, relabeling, sécurité et contrôle de la cardinalité
4. PromQL : écrire des requêtes exploitables (et pas des screenshots Grafana)
5. Règles d’enregistrement et alertes : construire des signaux stables et actionnables
6. Alertmanager : routage, inhibition, déduplication et “hygiène” anti-alert storm
7. Mise en production : validation, performance PromQL, rétention et sizing

Architecture Prometheus/Alertmanager : ce que vous déployez réellement

Prometheus n’est pas un “monitoring” monolithique : c’est une base de séries temporelles (TSDB) couplée à un moteur de scraping (pull) et un langage de requête (PromQL). Dans les termes de la doc officielle : « Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. » (Prometheus, Overview : https://prometheus.io/docs/introduction/overview/). En pratique, si vous le branchez sur un stack e-commerce (PrestaShop + PHP-FPM + MySQL/MariaDB + Redis + reverse proxy), la valeur vient surtout de la discipline sur les métriques et les règles, pas de l’outil.

Concrètement, vous déployez généralement au minimum :

• Prometheus : scrape, stockage local (TSDB), exécution PromQL, évaluation des règles.
• Alertmanager : routage et “gestion du bruit” (grouping, déduplication, silences, inhibition).
• Un ou plusieurs exporters : pour l’hôte (nodeexporter), la base (mysqldexporter), Redis, reverse proxy, et un blackbox pour tester une URL “comme un utilisateur”.

Un point souvent sous-estimé : Prometheus écrit en continu (WAL puis compaction en blocs). Même sur une “petite” boutique, l’I/O disque et la RAM deviennent vite limitants quand la cardinalité explose ou quand on multiplie les targets. C’est pour cela qu’il faut penser design de métriques (labels), rétention, et recording rules dès le début.

Versioning et prérequis (ce qui suit a été validé sur un environnement Linux x8664, Ubuntu 24.04, Docker Engine 26.x, Prometheus 2.54.x, Alertmanager 0.28.x). Le cœur PrestaShop (y compris PrestaShop 9) n’expose pas de métriques “observability-ready” par défaut : vous devrez soit instrumenter (client Prometheus côté PHP/Symfony), soit vous reposer sur des exporters (nodeexporter, mysqldexporter, redisexporter, blackbox_exporter…). Pour l’orchestration, vous pouvez vous appuyer sur votre approche Compose (voir Docker Compose : orchestrer des services multi-conteneurs en production : https://www.expertise-prestashop.fr/2026/07/31/docker-compose-orchestrer-des-services-multi-conteneurs-en-production/).

Le modèle de données Prometheus impose une contrainte structurante : chaque métrique est une série temporelle identifiée par un nom + des labels. La doc le résume sans ambiguïté : « Prometheus implements a multi-dimensional data model with time series data identified by metric name and key/value pairs. » (Prometheus, Overview : https://prometheus.io/docs/introduction/overview/). Traduction opérationnelle : la cardinalité (nombre de combinaisons de labels) est votre budget le plus fragile. Si vous exposez shop_id, customer_id ou cart_id en label, vous allez tuer votre TSDB (RAM + index + temps de requête), même avec un VPS “correct”.

Mini-scénario typique en e-commerce : vous ajoutez un label path sur une métrique de latence HTTP ; en période “soldes” ou campagne Ads, vous passez de quelques dizaines à des milliers d’URLs distinctes (produits, filtres, paramètres). Résultat : explosion du nombre de séries actives, requêtes Grafana de plus en plus lentes, puis alertes évaluées en retard. C’est rarement un “problème Prometheus” : c’est presque toujours un problème de labels.

# docker-compose.yml (extrait minimaliste)
services:
  prometheus:
    image: prom/prometheus:v2.54.1
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./prometheus/rules:/etc/prometheus/rules:ro
      - prom_data:/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.retention.time=15d
      - --web.enable-lifecycle
    ports: ["9090:9090"]

  alertmanager:
    image: prom/alertmanager:v0.28.0
    volumes:
      - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports: ["9093:9093"]

  node_exporter:
    image: prom/node-exporter:v1.8.1
    pid: host
    network_mode: host
    command:
      - --path.rootfs=/host
    volumes:
      - /:/host:ro,rslave

volumes:
  prom_data:

Astuce “propre” en prod : ajoutez un healthcheck Docker (ou une sonde externe) sur les endpoints /-/ready et /-/healthy de Prometheus. Cela évite de diagnostiquer “Grafana ne montre plus rien” alors que le vrai problème est un Prometheus non prêt ou en erreur de config.

Exposer des métriques : types, conventions et pièges de l’écosystème PHP/PrestaShop

Prometheus ne “déduit” rien : il scrape des endpoints HTTP (souvent /metrics) qui renvoient du texte (OpenMetrics/Prometheus exposition). Côté modèle, retenez les 4 types : counter (compte monotone, reset possible au restart), gauge (valeur instantanée), histogram (distribution via buckets), summary (quantiles côté client). En production, pour faire des percentiles fiables et agrégables, privilégiez histogram + histogram_quantile() : les summaries cassent l’agrégation inter-instances.

Sur une boutique PrestaShop, la plupart des “métriques utiles” ne sont pas au niveau applicatif mais à l’interface : latence HTTP, taux d’erreur 5xx, saturation CPU/RAM, pool PHP-FPM, timeouts MySQL, queue jobs (Messenger), erreurs paiement, et surtout disponibilité d’un endpoint métier (checkout). Prometheus est très bon pour corréler ces dimensions… si vous choisissez des métriques stables. Exemple : instrumenter des métriques “par URL exacte” (path=/product/123) est un anti-pattern ; normalisez via route (route=product_show) ou groupe fonctionnel (endpoint=checkout).

Quelques conventions qui évitent 80% des problèmes (issues de bonnes pratiques Prometheus) :

• Nommez avec un préfixe de domaine (prestashop_…) et un suffixe d’unité quand pertinent (_seconds, _bytes).
• Pour les compteurs : suffixe _total (ex. prestashop_checkout_errors_total).
• Pour les histograms : vous obtiendrez automatiquement *_bucket, *_sum, *_count (c’est normal).
• Gardez les labels courts, bornés et documentés (ex. endpoint, method, status_class), et évitez les labels “explosifs” (id, URL complète, email, user-agent brut…).

Pour référence (utile si vous instrumentez côté PHP/Symfony), les conventions de nommage sont détaillées ici : https://prometheus.io/docs/practices/naming/ (Prometheus, Naming and labels).

Table simple (e-commerce PrestaShop) : quels types pour quels besoins ?

Besoin	Type recommandé	Exemple de métrique	Labels raisonnables
Taux d’erreur checkout	Counter	prestashop_checkout_errors_total	type
Volume de requêtes	Counter	prestashop_http_requests_total	endpoint, method, status_class
Latence HTTP	Histogram	prestashop_http_request_duration_seconds	endpoint, method, status_class
Taille d’une file de jobs	Gauge	prestashop_messenger_queue_depth	transport
Disponibilité endpoint “vue utilisateur”	Gauge (via blackbox)	probe_success	instance (URL), module

Dans un stack PrestaShop 9 (Symfony 6.4 côté back-office/architecture), l’angle le plus rentable est souvent la file de jobs. Si vous utilisez Messenger, surveillez backlog, latence de traitement, et taux d’échec par handler (cf. Symfony Messenger : configuration avancée, choix du transport et performances : https://www.expertise-prestashop.fr/2026/08/05/symfony-messenger-configuration-avancee-choix-du-transport-et-performances/). Le core n’expose pas ça : soit vous ajoutez un middleware + métriques Prometheus, soit vous scrapez des métriques de transport (ex. RabbitMQ exporter) et vous reconstruisez des signaux à partir du broker.

Exemple minimal (PHP 8.2/8.3) : compteur d’erreurs checkout + histogram de latence. (L’implémentation exacte dépendra du client Prometheus choisi, mais la structure est la même : labels à faible cardinalité, et buckets maîtrisés.)

// Pseudo-code : éviter les labels dynamiques (customer_id, order_id, etc.)
$checkoutLatency = $registry->getOrRegisterHistogram(
  'prestashop',
  'http_request_duration_seconds',
  'Latence HTTP par endpoint logique',
  ['endpoint','method','status_class'],
  [0.05,0.1,0.2,0.5,1,2,5]
);

$checkoutErrors = $registry->getOrRegisterCounter(
  'prestashop',
  'checkout_errors_total',
  'Erreurs checkout (fonctionnelles + techniques)',
  ['type']
);

$start = microtime(true);
try {
  // ... traitement checkout
} catch (Throwable $e) {
  $checkoutErrors->inc(['type' => 'exception']);
  throw $e;
} finally {
  $duration = microtime(true) - $start;
  $checkoutLatency->observe($duration, [
    'endpoint' => 'checkout',
    'method' => 'POST',
    'status_class' => '2xx',
  ]);
}

Deux pièges courants côté PHP/PrestaShop :

• Mesurer trop bas niveau (micro-timers partout) et finir avec un bruit inexploitable. Commencez par les parcours qui “cassent le business” : checkout, login BO, recherche/catalogue, paiement.
• Mélanger statut HTTP et statut métier : un checkout peut répondre 200 mais échouer “fonctionnellement” (paiement refusé, stock insuffisant). D’où l’intérêt d’un type ou reason borné (ex. payment_refused, validation_failed, exception) plutôt qu’un message libre.

Enfin, même si vous instrumentez l’app, conservez une mesure “externe” : un blackbox_exporter sur une URL de healthcheck (ou une page de checkout minimaliste) détecte des pannes que l’app ne voit pas (DNS, certificat, LB, WAF…).

prometheus.yml : scrapes, relabeling, sécurité et contrôle de la cardinalité

La configuration Prometheus se joue essentiellement dans prometheus.yml : global (intervalle de scrape), jobs, et discovery/relabel. Sur un e-commerce, vous voulez généralement un scrape interval court sur les signaux critiques (15s) et plus long sur le reste (30s/60s), sinon vous payez en CPU/disque sans gain. Ne mettez pas 1s “par principe” : vous augmenterez le bruit (surtout sur irate) et le coût de stockage.

Complément utile : ajustez aussi scrape_timeout (par défaut 10s). Si un exporter met parfois 12–15s, Prometheus va le marquer en erreur et vous aurez des trous. À l’inverse, un timeout trop haut masque un endpoint dégradé.

Le relabeling est sous-utilisé, alors que c’est l’outil natif pour : (1) filtrer des targets, (2) normaliser des labels, (3) supprimer des labels toxiques, (4) construire des labels “environnement” (env=prod, stack=prestashop). Dans un contexte multi-boutique, évitez de pousser shop_url en label (cardinalité + valeurs longues). Préférez shop=shopA|shopB + documentation/runbook qui fait la correspondance.

Deux mécanismes à distinguer :

• relabel_configs : agit sur les targets (avant scrape) — pratique pour réécrire instance, filtrer des endpoints, etc.
• metric_relabel_configs : agit sur les métriques scrappées (après scrape) — pratique pour drop une métrique entière trop coûteuse, ou supprimer un label côté métrique.

Exemple : scrapper un node_exporter + un endpoint applicatif exposé derrière TLS avec basic-auth (à adapter : idéalement mTLS, ou réseau privé + reverse proxy). Ce volet sécurité doit être cohérent avec votre durcissement (voir Audit sécurité PrestaShop : méthodologie, livrables et durcissement : https://www.expertise-prestashop.fr/2026/07/31/audit-securite-prestashop-methodologie-livrables-et-durcissement/).

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  scrape_timeout: 10s

rule_files:
  - /etc/prometheus/rules/*.yml

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["127.0.0.1:9100"]
        labels:
          env: prod
          stack: prestashop

  - job_name: prestashop_app
    scheme: https
    metrics_path: /metrics
    static_configs:
      - targets: ["app.example.internal:443"]
        labels:
          env: prod
          app: prestashop

    basic_auth:
      username: prometheus
      password_file: /run/secrets/prometheus_basic_auth

    relabel_configs:
      # Supprimer les labels exportés côté app qui explosent la cardinalité
      - action: labeldrop
        regex: "(customer_id|cart_id|order_id|url|path)"

Si vous êtes en Docker (sans Kubernetes), vous pouvez faire du file_sd_configs (fichiers JSON/YAML de targets) générés par votre CI/CD. C’est souvent plus maintenable que du “scrape static” à la main : vous versionnez la liste de targets, vous la déployez en même temps que votre infra, et vous évitez les oublis lors d’une montée en charge (nouvelle instance PHP-FPM, nouveau worker, etc.).

Autre bonne pratique : normaliser le label instance. Par défaut, il contient host:port. Pour vos dashboards et alertes, c’est parfois trop “technique”. Vous pouvez le remplacer par un nom stable (ex. ps-prod-app-1) via relabeling, tout en gardant l’original dans un autre label si nécessaire.

Et si vous prévoyez HA/scale long terme, réfléchissez tôt à la brique “remote_write” (Mimir/Thanos/Cortex) : Prometheus seul n’est pas un data lake. Même si vous n’y allez pas tout de suite, cela influence déjà votre stratégie de nommage/labels (éviter les labels “local-only” qui n’ont plus de sens à l’échelle).

PromQL : écrire des requêtes exploitables (et pas des screenshots Grafana)

PromQL n’est pas SQL : vous ne requêtez pas des lignes, vous manipulez des vecteurs de séries temporelles. Deux erreurs classiques : (1) appliquer rate() à un gauge (sens faux), (2) oublier l’agrégation par labels (sum by(...), avg by(...)) et se retrouver avec 500 séries non lisibles. La règle empirique : une requête de dashboard doit expliciter son niveau d’agrégation et ses labels “de sortie”.

Sur des compteurs applicatifs, utilisez rate() (par seconde) ou increase() (sur une fenêtre). Exemple : taux d’erreur checkout sur 5 minutes.

sum by (env) (rate(prestashop_checkout_errors_total[5m]))

Pour les latences, ne faites pas “moyenne d’une moyenne”. Si vous exposez un histogram *_bucket, calculez un percentile. Exemple : p95 de latence checkout sur 10 minutes.

histogram_quantile(
  0.95,
  sum by (le, env) (rate(prestashop_http_request_duration_seconds_bucket{endpoint="checkout"}[10m]))
)

Pour éviter les ratios “NaN” (zéro trafic) dans des environnements qui ont peu de volume la nuit, vous pouvez protéger le dénominateur :

(
  sum(rate(prestashop_checkout_errors_total[5m]))
/
  clamp_min(sum(rate(prestashop_http_requests_total{endpoint="checkout"}[5m])), 1e-6)
)

Côté infra (node_exporter), quelques requêtes très utiles et stables :

• CPU (toutes cores) : pour voir la saturation (et distinguer “idle” vs “busy”)

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

• Mémoire disponible (signal de pression mémoire) :

node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes

• Espace disque (éviter les pannes “bêtes” : logs, cache, volumes Docker) :

node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}

Côté base de données, l’intérêt est de lier symptômes et causes probables. Par exemple, si votre checkout génère des timeouts MySQL, vous aurez souvent un pattern : hausse de 5xx + hausse de latence + saturation I/O. Pour l’axe base de données, un bon complément est l’analyse du slow query log et des index (voir PrestaShop MySQL : analyser slow query log et optimiser index : https://www.expertise-prestashop.fr/2026/07/31/prestashop-mysql-analyser-slow-query-log-et-optimiser-index/). PromQL peut vous donner le signal, mais la remédiation est côté schéma/requêtes.

Enfin, gardez en tête la lisibilité : si une requête sort 200 séries, ce n’est pas “plus précis”, c’est souvent inexploitable en incident. En dashboard, vous voulez des séries qui répondent à une question claire (“Le checkout est-il lent ?”, “Les erreurs montent-elles ?”, “Est-ce infra ou applicatif ?”).

Règles d’enregistrement et alertes : construire des signaux stables et actionnables

Prometheus évalue des règles à intervalle fixe. Deux catégories : recording rules (pré-calcul de séries) et alerting rules (déclenchement d’alertes). Si vous avez des requêtes coûteuses (histogrammes + gros sum by), enregistrez-les en séries dérivées ; c’est un moyen direct d’abaisser le temps de requête et d’éviter d’exploser le CPU Prometheus.

Exemple de recording rule : calculer en continu le taux d’erreur 5xx global côté reverse proxy (ou applicatif), puis réutiliser cette série dans des alertes et dashboards.

# rules/http.yml
groups:
  - name: http_recording
    interval: 15s
    rules:
      - record: job:http_requests_5xx_rate5m
        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (job, env)

En e-commerce, c’est aussi un bon endroit pour enregistrer des séries “métier” simplifiées, par exemple :

• job:checkout_p95_latency10m
• job:checkout_error_ratio5m
• job:mysql_threads_running_avg5m (si vous avez mysqld_exporter)

Cela rend vos alertes plus courtes, et vos dashboards plus rapides.

Pour les alertes, ne partez pas “métrique brute > seuil”. Pour de la prod e-commerce, les meilleures alertes sont orientées symptômes et reliées à un runbook. Google formalise cette approche via les “golden signals” : « The four golden signals are latency, traffic, errors, and saturation. » (Google SRE Book, Monitoring Distributed Systems : https://sre.google/sre-book/monitoring-distributed-systems/). Un exemple simple : alerter sur un burn rate d’erreurs ou sur une latence p95 qui dépasse un SLO, avec un for pour filtrer le bruit.

# rules/alerts.yml
groups:
  - name: checkout_alerts
    rules:
      - alert: CheckoutHighErrorRate
        expr: |
          (
            sum(rate(prestashop_checkout_errors_total[5m]))
            /
            sum(rate(prestashop_http_requests_total{endpoint="checkout"}[5m]))
          ) > 0.02
        for: 10m
        labels:
          severity: page
          team: ecommerce
        annotations:
          summary: "Taux d'erreur checkout > 2% (10m)"
          description: "Vérifier MySQL (timeouts/locks), PHP-FPM (max_children), et logs applicatifs."

Deux enrichissements qui rendent les alertes plus “actionnables” en prod :

• Ajoutez une alerte d’absence de métrique (instrumentation cassée, endpoint /metrics down) : absent(up{job="prestashop_app"} == 1) ou plus simplement une alerte sur up == 0 avec un for.
• Utilisez des annotations qui donnent une piste immédiate (“regarder tel graphe”, “vérifier telle commande”, “lien logs”) plutôt qu’une description vague.

Exemple (très courant) : une alerte “App metrics down” permet de distinguer rapidement un souci “observabilité” d’un vrai incident prod.

      - alert: PrestashopMetricsEndpointDown
        expr: up{job="prestashop_app"} == 0
        for: 5m
        labels:
          severity: ticket
          team: ecommerce
        annotations:
          summary: "Endpoint /metrics PrestaShop indisponible"
          description: "Vérifier le réseau interne, le TLS/reverse proxy, et l'auth Basic (/metrics)."

Alertmanager : routage, inhibition, déduplication et “hygiène” anti-alert storm

Alertmanager n’est pas un simple “envoi Slack”. Il prend les alertes Prometheus, déduplique, groupe, route, gère les silences et l’inhibition. Si vous ne configurez pas ces mécanismes, vous aurez : (1) du spam, (2) de la fatigue d’alerte, (3) un reflexe de “mute everything” (donc plus de sécurité/ops). Le point clé : grouper par labels stables (alertname, env, service) et éviter de grouper par des labels trop fins (instance) si l’incident est global.

Exemple alertmanager.yml : routage “page” vers on-call, “ticket” vers email, inhibition des alertes symptomatiques quand une alerte racine (ex. “site down”) est active. Pour les canaux, vous pouvez aussi vous inspirer d’un flux d’alerting applicatif (voir PrestaShop : module d’alerting temps réel Slack, Discord et email : https://www.expertise-prestashop.fr/2026/07/30/prestashop-module-dalerting-temps-reel-slack-discord-et-email/), mais côté Prometheus/Alertmanager, la logique de grouping/dedup est non négociable.

route:
  receiver: "default"
  group_by: ["alertname", "env", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers: ["severity=page"]
      receiver: "oncall"
    - matchers: ["severity=ticket"]
      receiver: "email"

inhibit_rules:
  - source_matchers: ["alertname=BlackboxProbeFailed", "severity=page"]
    target_matchers: ["severity=ticket"]
    equal: ["env", "service"]

receivers:
  - name: "default"
  - name: "oncall"
    slack_configs:
      - api_url_file: /run/secrets/slack_webhook
        channel: "#oncall"
        send_resolved: true
  - name: "email"
    email_configs:
      - to: "[email protected]"
        from: "[email protected]"
        smarthost: "smtp.example.com:587"
        send_resolved: true

Checklist “anti-alert storm” (simple, mais efficace) :

• group_by sur des labels stables (service/env/alertname).
• group_wait non nul (30–60s) : laisse le temps aux alertes corrélées d’arriver.
• repeat_interval suffisamment long (heures) pour éviter le spam pendant un incident long.
• inhibit_rules : si le site est down, inutile de recevoir 15 alertes secondaires “latence haute”, “taux 5xx”, etc.

Côté sécurité : évitez de laisser Prometheus/Alertmanager exposés publiquement sans auth. Les endpoints web (9090/9093) révèlent beaucoup (topology, noms d’hôtes, labels internes). Appliquez segmentation réseau, reverse proxy + auth, et des standards de durcissement conteneur (voir DISA : sécuriser les images conteneurisées selon le guide officiel : https://www.expertise-prestashop.fr/2026/07/30/disa-securiser-les-images-conteneurisees-selon-le-guide-officiel/).

Mise en production : validation, performance PromQL, rétention et sizing

Traitez la configuration Prometheus comme du code. promtool est votre garde-fou minimal : promtool check config prometheus.yml et promtool check rules rules/*.yml dans votre CI. Ajoutez des tests de règles (unit tests) pour éviter les régressions lors d’un changement de label ou de nom de métrique. C’est particulièrement important en e-commerce : un renommage côté app peut rendre silencieuses des alertes critiques (pire que du bruit).

Pour la validation opérationnelle (avant même Grafana), adoptez une routine courte :

• Vérifier les targets : onglet Status → Targets (ou API /api/v1/targets).
• Vérifier les règles : Status → Rules (ou /api/v1/rules).
• Vérifier l’ingestion : la métrique up et, côté TSDB, prometheus_tsdb_head_series (proxy de la cardinalité courante).

Sur la performance, trois leviers dominent : (1) cardinalité (labels), (2) fenêtres de requête (éviter les [30d] sur des dashboards), (3) recording rules pour pré-calculer les expressions coûteuses. Si votre Prometheus commence à swapper, le problème n’est pas “Prometheus est lent”, c’est votre design de métriques.

Astuce pratique : surveillez la croissance du nombre de séries. Même sans “outil externe”, Prometheus expose ses propres métriques ; vous pouvez grapher :

• prometheus_tsdb_head_series (séries actives)
• prometheus_tsdb_head_chunks
• prometheus_engine_query_duration_seconds (latence des requêtes PromQL)
• prometheus_rule_evaluation_duration_seconds (temps d’évaluation des règles)

Ces signaux vous disent si vous êtes en train de “payer” trop cher une métrique mal conçue (labels trop variés, buckets trop fins, métriques inutilisées).

Pour les sizing de base (CPU/RAM/IO), partez d’un VPS avec NVMe et assez de RAM pour l’index ; et ajustez selon le nombre de séries actives, la rétention, et le volume de scrapes (cf. VPS pour Docker : critères techniques et ressources recommandées : https://www.expertise-prestashop.fr/2026/07/29/vps-pour-docker-criteres-techniques-et-ressources-recommandees/). La démarche la plus fiable reste empirique : vous déployez, vous observez prometheus_tsdb_head_series, la taille du volume, et la latence de requête, puis vous corrigez d’abord les labels inutiles avant d’augmenter la machine.

Sur la rétention, évitez le “15d par défaut” sans réfléchir :

• Si votre objectif est le diagnostic incident, 7–15 jours peuvent suffire.
• Si vous voulez comparer SLO, releases, ou effets d’une optimisation (cache, index MySQL), vous voudrez souvent 30 jours ou plus… mais alors un stockage externe (remote_write) devient vite pertinent.

Enfin, acceptez la limite structurelle : Prometheus stocke localement, donc la haute dispo et le long terme passent par une stratégie (fédération, double Prometheus, remote_write + backend). Même sans aller jusqu’à Thanos/Mimir, vous pouvez déjà fiabiliser : deux instances Prometheus scrappant les mêmes targets, Alertmanager en cluster (2+), et un “blackbox” externe pour vérifier la disponibilité réelle (HTTP/TCP) depuis un autre réseau. À l’échelle d’une boutique, ça suffit souvent à passer d’un monitoring décoratif à un alerting qui déclenche des actions correctives mesurables.