Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes

Table des matières :

1. Ce qu’une surveillance PrestaShop doit réellement couvrir (et ce que le core ne remonte pas)
2. Architecture praticable : métriques, logs et traces (Prometheus/Grafana, Netdata, OpenTelemetry)
3. Tableau de bord : panels “golden signals” + indicateurs e-commerce spécifiques PrestaShop
4. Seuils et alertes : percentiles, SLO, burn rate (au lieu de “CPU > 80%”)
5. Réduction des fausses alertes : débruitage, corrélation, déduplication, et limites assumées
6. Exemple d’implémentation (Prometheus/Grafana/Alertmanager) + checklist de mise en prod

Ce qu’une surveillance PrestaShop doit réellement couvrir (et ce que le core ne remonte pas)

Sur PrestaShop (8.1 à 9.1) avec PHP 8.2/8.3 en production, “surveiller” ne veut pas dire “vérifier que le front répond en 200”. Le core n’expose ni métriques applicatives natives, ni SLO, ni signaux exploitables sans instrumentation. Vous avez des logs (souvent incomplets), quelques compteurs côté serveur si vous les activez, et beaucoup d’angles morts : lenteurs checkout liées à un module, timeouts API transporteur, saturation MySQL, ou invalidations cache qui explosent le TTFB.

Même quand PrestaShop “remonte quelque chose”, ça reste insuffisant pour de l’exploitation :

• Back-office > Paramètres avancés > Logs : utile pour repérer des erreurs fonctionnelles, mais pas pour quantifier la latence, ni attribuer un incident à une route, un module ou une dépendance externe.
• Mode debug / logs Symfony (selon version) : très utile en staging, mais à manier en production (risque de bruit, coût I/O, et risques de fuite de données si mal configuré).
• Logs PHP/Nginx : indispensables, mais sans corrélation (requestid/traceid), ils deviennent vite “un océan de lignes” difficile à relier à un incident métier (ex. panier → paiement).

La cible technique, c’est une visibilité multi-couches : système (CPU, RAM, I/O, file descriptors), reverse-proxy / LB (HAProxy/Nginx), PHP-FPM/OPcache, base de données, cache (Redis/Memcached/Varnish), puis application (erreurs, latences par route, étapes du tunnel). Sans ça, vous ne faites pas du monitoring, vous faites du “ping”. Pour recadrer les fondamentaux performance (TTFB, cache, DB), croisez avec les articles existants sur le TTFB PrestaShop et le cache côté serveur (Varnish/Redis/OPcache).

Enfin, une surveillance PrestaShop utile est orientée incidents et non “métriques décoratives”. L’objectif est d’attraper tôt ce qui casse le business (tunnel de commande, recherche, paiement) et ce qui annonce une panne (saturation I/O, pool PHP-FPM à court de workers, threads MySQL en attente). Sur un site e-commerce, un incident “soft” (p95 du checkout à +2 s) est souvent plus coûteux qu’une erreur franche : la conversion se dégrade avant l’alerte “500”.

Un repère simple pour cadrer votre périmètre : si vous ne pouvez pas répondre rapidement à ces 5 questions, votre surveillance est encore “trop ping” :

1. Quelle page/étape est lente (catégorie, recherche, panier, livraison, paiement, confirmation) ?
2. Est-ce une latence “interne” (PHP/DB/caches) ou externe (API paiement/transport/ERP) ?
3. Est-ce global (toutes les routes) ou localisé (seulement /order, seulement /module/*) ?
4. Le problème est-il corrélé à une release (module, thème, override) ou à un événement infra (CPU steal, iowait, failover) ?
5. Qu’est-ce qui est actionnable en 5–15 minutes (mitigation) en attendant le correctif ?

Architecture praticable : métriques, logs et traces (Prometheus/Grafana, Netdata, OpenTelemetry)

Le standard de fait côté métriques reste Prometheus + Grafana + Alertmanager. Prometheus le définit de façon directe : “Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud.” (Documentation officielle : Prometheus). L’intérêt : un modèle de données time-series robuste, PromQL, et une intégration mature avec les exporters (nodeexporter, mysqldexporter, php-fpm exporter, redis_exporter, nginx exporter…). Pour monter Grafana proprement sur une VM Ubuntu, vous avez déjà un guide : Grafana sur Ubuntu : installation APT et configuration initiale.

Pour un déploiement plus “plug-and-play” (ou en complément), Netdata donne une vue temps réel très fine et des alertes prêtes à l’emploi (CPU steal, iowait, backlog). C’est particulièrement utile quand vous suspectez un problème d’hébergement (noisy neighbor, throttling, quota I/O) ou un dimensionnement bancal. Référence interne : Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web. Pensez aussi à votre socle : un mutualisé “opaque” ou un VPS sous-dimensionné rend la surveillance inutile (pas d’accès exporter, pas de tuning). Voir : Hébergement e-commerce : mutualisé, VPS, cloud ou SaaS comparés.

La troisième jambe, souvent négligée sur PrestaShop, ce sont les traces (APM) pour isoler les N+1, hooks lents, appels externes et verrouillages DB. OpenTelemetry pose le cadre : “OpenTelemetry is a collection of tools, APIs, and SDKs.” (OpenTelemetry). En pratique : vous instrumentez PHP (auto-instrumentation si possible, sinon spans manuels) et vous corrélez trace_id avec les logs Nginx/PHP. Sans traces, vous finissez par “tuner” à l’aveugle (et souvent à dégrader la perf ailleurs).

Pour que cette architecture reste “praticable” (et pas un projet observabilité de 6 mois), visez un flux simple, puis itérez :

• Métriques : Prometheus scrape les exporters (OS, Nginx, PHP-FPM, MySQL, Redis). Vous créez 10–20 alertes maximum au début.
• Logs : centralisez au moins Nginx + PHP + MySQL (même sans full-text search au départ). L’objectif initial est de retrouver vite une erreur associée à une alerte.
• Traces : démarrez par les routes critiques (checkout, paiement, webservices) et un sampling faible (1–5%), puis montez ponctuellement en incident.

Petit scénario concret (très fréquent en France/UE avec PSP et transporteurs) : pendant une campagne, la latence du checkout augmente sans 5xx. Les métriques vous montrent “latence p95 /order en hausse”, les traces révèlent “appel externe paiement +1,8 s”, et les logs confirment des timeouts intermittents côté upstream. Sans traces, vous risquez de surdimensionner PHP-FPM/MySQL alors que le goulot est un SLA tiers.

Tableau de bord : panels “golden signals” + indicateurs e-commerce spécifiques PrestaShop

Un dashboard qui sert en prod commence par les 4 golden signals. La formulation est connue dans le livre Google SRE : “The four golden signals are latency, traffic, errors, and saturation.” (Beyer et al., Site Reliability Engineering, O’Reilly, 2016). Traduction opérationnelle : latence (p50/p95/p99), trafic (RPS, hits checkout), erreurs (5xx, exceptions), saturation (CPU, mémoire, I/O, pool PHP-FPM, connexions DB). C’est votre “vue cockpit” en incident.

Pour éviter un tableau de bord “joli mais inutilisable”, un bon test est : en 60 secondes, pouvez-vous dire si l’incident est (a) applicatif, (b) base de données, (c) cache, (d) dépendance externe, (e) infra/hébergement ?

Voici une trame de panels utile (et assez universelle) pour du monitoring PrestaShop :

Signal	Panel concret	Pourquoi c’est actionnable
Latence	p95/p99 par route (au moins checkout + recherche)	Vous identifiez où ça ralentit, pas juste “ça ralentit”
Trafic	RPS global + RPS checkout + taux bots (si dispo)	Distinguer charge légitime vs scrapers/attaques
Erreurs	Taux 5xx, 499/504 (si Nginx), erreurs PHP fatales	Prioriser l’impact client et la gravité
Saturation	CPU iowait/steal, saturation PHP-FPM, threads MySQL, hit ratio cache	Prouver la cause infra vs app

Ensuite, vous ajoutez des panneaux PrestaShop orientés composants :

• PHP-FPM : pm.max_children vs active/idle, queue length, slowlog hits, RSS par process, taux de recycle. Un “502 sporadique” est souvent un pool saturé, pas un bug. Ajoutez aussi un panel “workers actifs / max” + “requêtes en file” : c’est souvent le meilleur prédicteur de 502/504.
• MySQL/MariaDB : threads running, InnoDB buffer pool hit rate, temps moyen des requêtes, locks, Created_tmp_disk_tables, réplication si vous l’avez. Pour l’hygiène DB (table bloat, nettoyage, routines), voir Base de données PrestaShop : routine de maintenance et nettoyage automatisé. Un bon ajout “incident-ready” : top requêtes lentes (via slow query log) et locks InnoDB (quand elles sont accessibles via exporter).
• Cache / CDN / Varnish : hit ratio, bypass reasons, X-Cache, invalidations, taux de purge. Si vous utilisez Varnish, les régressions de cache se voient immédiatement sur le TTFB et la charge PHP. Référence : PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache. Ajoutez un panel “bypass” (cookies, headers, URLs) : c’est souvent là qu’un module “casse le cache” sans que personne ne le voie.
• Réseau / upstream (souvent oublié) : temps de réponse upstream (Nginx ↔ PHP-FPM), taux de timeouts, erreurs DNS si vous faites beaucoup d’appels externes (paiement, transport, ERP).

Enfin, ajoutez des KPI “métier technique” spécifiques au commerce : taux d’aboutissement checkout, latence par étape (panier → livraison → paiement), taux d’échecs paiement par prestataire, erreurs webservice (ERP, transporteur), et recherche interne (latence + zero-results). L’intérêt est pragmatique : un module de paiement qui répond en 3–4 s ne générera pas forcément de 5xx, mais fera chuter la conversion. Si vous avez basculé la recherche sur un moteur externe, instrumentez ce SLA (ex. Meilisearch/Elastic). Voir : Recherche interne PrestaShop : intégrer Meilisearch pour booster la conversion.

Point “GEO” utile (sans surcharger) : si votre boutique vend majoritairement en France/Belgique/Suisse, surveillez la latence côté edge (CDN/POP) et non seulement côté serveur. Une infra hébergée à Paris/Gravelines/Strasbourg avec un CDN peut masquer des problèmes “dernier kilomètre” sur mobile. Même un simple indicateur de TTFB par pays (si vous l’avez via CDN/analytics) aide à trier “incident global” vs “incident régional/opérateur”.

Seuils et alertes : percentiles, SLO, burn rate (au lieu de “CPU > 80%”)

Les seuils statiques “CPU > 80%” déclenchent des alertes inutiles (pics courts) et ratent les vrais problèmes (latence qui grimpe alors que CPU reste modéré). Sur PrestaShop, les alertes efficaces sont orientées symptômes : p95 de latence sur /order et /order-confirmation, taux de 5xx sur /module/* (modules fragiles), augmentation brutale des timeouts upstream (Nginx ↔ PHP-FPM), et dérive du TTFB.

Privilégiez les percentiles et des fenêtres temporelles adaptées. Exemple : alerter sur p95 > 900ms pendant 10 minutes sur les pages du tunnel, plutôt que sur une moyenne (qui masque les queues). De même, sur les erreurs, alertez sur un taux (5xx / total) plutôt que sur un compteur brut. Cela évite les fausses alertes lors de pics légitimes de trafic (soldes) et maintient la sensibilité quand le trafic est faible.

Une méthode simple pour définir des seuils “réalistes” sans débats infinis :

1. Mesurez 7 à 14 jours de baseline (hors incident majeur).
2. Prenez la p95 actuelle des routes critiques.
3. Fixez un SLO “d’amélioration” (ex. -10 à -20% sur 1 à 2 mois) ou un SLO “de stabilité” (ne pas dégrader).
4. Définissez l’alerte à +X% au-dessus de la baseline p95 (et non un chiffre arbitraire), puis ajustez.

Exemple de SLO “technique métier” (à adapter, car chaque boutique/modules diffèrent) :

• Checkout : 99,9% des requêtes /order et /order-confirmation sans 5xx et sous une latence cible (définie sur baseline).
• Paiement : taux d’échec (hors refus bancaires) < 0,2–0,5% sur une fenêtre glissante (si vous distinguez les codes d’erreur).
• Recherche : p95 de latence et taux de “zero-results” (souvent révélateur de synonymes/typos manquants ou d’index cassé).

Pour aller plus loin (et réduire les débats), passez en logique SLO / burn rate : vous définissez un objectif (ex. 99,9% de requêtes checkout < 1,5 s et sans 5xx), puis vous alertez sur la vitesse à laquelle vous “brûlez” le budget d’erreur. C’est le pattern recommandé en SRE pour éviter l’alerte permanente. En e-commerce, c’est aussi un langage commun avec CTO/produit : “on est en train de cramer 30% du budget de la journée en 20 minutes”. Ce modèle devient encore plus pertinent quand vous avez plusieurs environnements (staging/prod) et des campagnes marketing qui créent des charges non linéaires.

Pour une lecture complémentaire (et une source stable liée à la citation SRE ci-dessus), la section Google SRE en ligne sur le monitoring est une bonne référence : Google SRE — Monitoring distributed systems

Réduction des fausses alertes : débruitage, corrélation, déduplication, et limites assumées

Les fausses alertes viennent rarement d’un “mauvais outil”. Elles viennent d’alertes non-actionnables, sans contexte, et déclenchées par des métriques non corrélées au service. Première règle : une alerte doit déclencher une action claire (runbook, escalade, mitigation). Si l’alerte “Load average” n’entraîne rien, vous la supprimez ou vous la rétrogradez en simple annotation.

Techniquement, appliquez des mécanismes de débruitage :

• Hystérésis (seuil haut pour déclencher, seuil bas pour récupérer) sur les alertes de saturation.
• For/délai de confirmation (ex. for: 10m) pour filtrer les micro-coupures réseau.
• Multi-signal : alerter seulement si latence ET saturation pool PHP-FPM (ou latence ET erreurs). Une latence seule peut être un trafic “normal” ; la combinaison rend le diagnostic plus probable.
• Heures de maintenance / déploiement : si vous déployez souvent (modules/thème), ajoutez une annotation “release” dans Grafana (ou un label), sinon vous perdrez du temps à corréler “alerte” et “mise en prod”.

Ensuite, travaillez la corrélation et la déduplication. Alertmanager le résume clairement : “Alertmanager handles alerts sent by client applications such as the Prometheus server.” (Alertmanager docs). Concrètement : regroupez par service, instance, severity, routez vers les bons canaux, et imposez une politique de “one page per incident”. C’est là que vous tuez 80% des fausses alertes “en cascade” (Nginx 502 + PHP-FPM down + probe down = un seul incident, pas trois pages).

Un levier souvent sous-estimé sur PrestaShop : standardiser les labels (service, env, route, shop_id si multi-boutique) dès le départ. Sans conventions, vous aurez des dashboards impossibles à filtrer et des alertes impossibles à dédupliquer.

Dernier point : acceptez les limites. Un monitoring PrestaShop “parfait” sans instrumentation applicative est une fiction. Si vous ne mesurez pas les temps des hooks, les appels externes, et les erreurs applicatives avec un identifiant de corrélation, vous aurez soit trop d’alertes (bruit), soit pas assez (angle mort). Les outils APM (traces) sont souvent la différence entre “on redémarre PHP-FPM et on prie” et “on isole un module qui fait des requêtes non indexées sur ps_cart”.

Enfin, côté conformité (contexte France/UE), gardez en tête que certains logs peuvent contenir des données personnelles (IP, identifiants, emails en erreurs applicatives). Même si ce n’est pas “du marketing”, ça reste un sujet d’exploitation : minimisez ce qui est loggé, contrôlez les accès, et définissez une rétention. Pour l’analyse des requêtes et indexes, gardez sous la main : Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN.

Exemple d’implémentation (Prometheus/Grafana/Alertmanager) + checklist de mise en prod

Exemple minimal d’alertes orientées PrestaShop (à adapter selon vos labels et votre stack). Hypothèses : Nginx expose des métriques (ou vous parsez les logs), vous avez des métriques de latence par route (via OpenTelemetry Collector → Prometheus, ou via un exporter applicatif), et vous collectez PHP-FPM/MySQL.

# alert.rules.yml (format Prometheus)
groups:
  - name: prestashop
    rules:
      - alert: PrestashopCheckoutHighLatencyP95
        expr: >
          histogram_quantile(
            0.95,
            sum(rate(http_request_duration_seconds_bucket{route=~"/order|/order-confirmation"}[5m])) by (le)
          ) > 0.9
        for: 10m
        labels:
          severity: page
          service: prestashop
        annotations:
          summary: "Checkout p95 > 900ms (10m)"
          runbook: "Vérifier pool PHP-FPM, hit ratio cache, locks MySQL, appels externes paiement"

      - alert: PrestashopHttp5xxRate
        expr: >
          (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))) > 0.01
        for: 5m
        labels:
          severity: page
          service: prestashop
        annotations:
          summary: "Taux de 5xx > 1% (5m)"
          runbook: "Identifier route/module, vérifier logs PHP/Nginx, rollback si release récente"

      - alert: MysqlThreadsRunningHigh
        expr: mysql_global_status_threads_running > 80
        for: 10m
        labels:
          severity: ticket
          service: mysql
        annotations:
          summary: "Threads MySQL running élevés"
          runbook: "Vérifier slow queries, locks InnoDB, saturation CPU/I/O, taille buffer pool"

En dashboard Grafana, évitez l’anti-pattern “un écran par composant”. Faites plutôt : (1) cockpit golden signals, (2) drilldown latence checkout + erreurs, (3) drilldown saturation PHP-FPM/DB/cache. Et quand vous préparez des périodes à risque (soldes), formalisez vos runbooks et tests de charge : l’article PrestaShop performance : monitoring, tests de charge et runbooks soldes est exactement sur ce sujet.

Checklist prod (prérequis + risques) :

1. Accès et sécurité : exporters et endpoints métriques doivent être restreints (IP allowlist, auth mTLS si possible). Ne sortez jamais des métriques contenant PII. Pour le durcissement global, voir Sécurité PrestaShop : mises à jour, SSL et durcissement .htaccess.
2. Cardinalité & coût Prometheus : surveillez la cardinalité (labels trop “uniques” = explosion mémoire/CPU). Typiquement, évitez de labelliser avec des IDs utilisateurs, des querystrings complètes ou des IDs de panier.
3. Coût de l’observabilité : activer des logs verbeux ou du tracing à 100% peut coûter cher (CPU, I/O, stockage). Commencez par un sampling (ex. 1–5%) et augmentez en incident.
4. Qualité des alertes : démarrez avec peu d’alertes, mais solides : checkout (latence + 5xx), PHP-FPM saturé, DB saturée/locks, cache en chute de hit ratio. Si vous ne savez pas “quoi faire” quand ça sonne, l’alerte est à revoir.
5. Boucle d’amélioration : chaque alerte déclenchée doit être revue (post-mortem court) pour ajuster seuil, fenêtre, ou enrichir le contexte. Une alerte qui réveille sans action est un bug de monitoring, pas un “problème d’équipe”.