PS PrestaShop PrestaShop Débutant

Surveillance et Alertes PrestaShop (DataFirefly Monitor)

Installer le module, programmer le cron, configurer les canaux d'alerte et comprendre chaque détection.

Mis à jour Version du module 1.1.0

DataFirefly Monitor surveille votre boutique PrestaShop 8 ou 9 en continu et vous prévient quand elle tombe, plante, ralentit ou cesse d’encaisser. Cette documentation couvre l’installation, la tâche cron, les canaux de notification, chaque détection et la gestion des alertes.

Installation

  1. Dans le back-office, ouvrez Modules > Gestionnaire de modules, cliquez sur Installer un module et envoyez le fichier dfmonitor-1.1.0.zip.
  2. Le module crée ses tables et un onglet Paramètres avancés > Supervision & alertes. Le bouton Configurer du module y mène directement.
  3. À l’installation, l’email de la boutique est utilisé comme destinataire et le statut Erreur de paiement est sélectionné comme statut d’échec. Les journaux PrestaShop antérieurs à l’installation ne sont pas importés.

Le module est compatible PrestaShop 8.0 à 9.x, multiboutique et multilingue. Il n’utilise aucune dépendance Composer. Une mise à jour depuis la 1.0.0 se fait en envoyant le nouveau ZIP : le script de mise à jour ajoute les nouvelles colonnes et renseigne l’origine des erreurs déjà enregistrées.

Premiers pas

Le tableau de bord affiche une liste de mise en route en quatre étapes tant qu’elle n’est pas terminée : recevoir une première notification, ajouter la tâche cron, vérifier les statuts de paiement échoué, ajouter un heartbeat externe. Chaque étape mène au bon onglet des réglages.

Tâche cron

Les erreurs fatales et les paiements échoués sont signalés en temps réel. Le reste (disponibilité, temps de réponse, paiements, commandes, serveur, rapport) est évalué par une tâche planifiée qui doit tourner toutes les 5 minutes.

Cron serveur (recommandé)

*/5 * * * * php /chemin/vers/prestashop/modules/dfmonitor/cron.php

La commande exacte, avec le chemin de votre serveur, est affichée dans Réglages > Vérifications planifiées avec un bouton Copier.

Cron par URL

Si votre hébergeur ne permet que des crons web, appelez l’URL protégée par jeton affichée dans le même onglet, depuis le panneau d’hébergement ou un service comme cron-job.org. Elle répond en JSON et fonctionne aussi quand la boutique est en mode maintenance. Le bouton Générer un nouveau jeton invalide l’ancienne URL.

Sans cron

Avec PHP-FPM, l’option Repli sans cron lance les vérifications depuis le trafic des visiteurs quand aucun cron n’a tourné depuis 10 minutes, après l’envoi de la page. Le test de disponibilité et le heartbeat ne tournent pas dans ce mode, et une panne la nuit peut passer inaperçue faute de visites.

Heartbeat externe

Le module ne peut pas signaler une panne totale du serveur. Créez un check sur Healthchecks.io ou Better Stack et collez son URL dans URL de heartbeat : elle est appelée à chaque passage du cron, et le service vous prévient s’il ne reçoit plus d’appel.

Canaux de notification

Activez autant de canaux que vous voulez dans Réglages > Canaux de notification. Chaque canal a une gravité minimum (avertissement et critique, ou critique seulement) et un bouton Enregistrer et envoyer un test qui enregistre le formulaire puis envoie un vrai message. L’état du dernier envoi est affiché sous le nom du canal.

Email

Saisissez un ou plusieurs destinataires séparés par des virgules. Les emails utilisent la configuration email de PrestaShop (Paramètres avancés > E-mail) et la langue par défaut de la boutique.

Telegram

  1. Dans Telegram, ouvrez @BotFather, envoyez /newbot et suivez les instructions.
  2. Collez le jeton obtenu dans Jeton du bot.
  3. Envoyez un message à votre bot, ou ajoutez-le à un groupe, puis cliquez sur Détecter mon chat : l’ID du chat est rempli automatiquement.

Slack

Dans Slack : Apps > Incoming Webhooks > Add to Slack, choisissez le canal et copiez l’URL du webhook, qui commence par https://hooks.slack.com/.

Discord

Dans Discord : Paramètres du serveur > Intégrations > Webhooks > Nouveau webhook, puis Copier l’URL du webhook.

Webhook

Pour Zapier, Make, n8n, un outil d’astreinte ou votre propre script. Un POST JSON est envoyé à chaque nouvelle alerte, rappel et résolution, avec l’en-tête X-DataFirefly-Event :

{
  "event": "open",
  "alert": {
    "id": 42, "key": "payment:1", "type": "payment", "severity": "critical",
    "title": "...", "message": "...", "occurrences": 3,
    "first_at": "2026-10-07 16:35:00", "last_at": "2026-10-07 16:45:00",
    "ack_url": "https://..."
  },
  "shop": { "name": "...", "url": "https://..." },
  "sent_at": "2026-10-07T16:45:01+02:00"
}

Les valeurs de event sont open, repeat, resolved et test. Si un secret de signature est renseigné, chaque requête porte l’en-tête X-DataFirefly-Signature: sha256=…, HMAC SHA-256 du corps brut avec ce secret.

Règles d’alerte

  • Rappel pour une alerte en cours : délai entre deux notifications d’un même problème (60 minutes par défaut).
  • Nombre maximum de notifications par heure : 20 par défaut, 0 pour aucune limite.
  • Message de résolution : un message est envoyé quand un problème notifié disparaît.
  • Heures calmes : pendant la plage choisie, seules les alertes critiques partent. Un avertissement encore ouvert à la fin de la plage est envoyé au passage suivant du cron.
  • Rapport récapitulatif : désactivé, quotidien ou chaque lundi, à l’heure choisie. Il reprend disponibilité, temps de réponse, erreurs PHP, commandes, paiements échoués, alertes de la période et erreurs les plus fréquentes.

Pause

Le bouton Pause de l’en-tête suspend les notifications pendant 30 minutes, 2 heures, 8 heures ou 24 heures, par exemple pendant une mise à jour. Les problèmes restent détectés et enregistrés ; ceux encore ouverts à la fin de la pause sont notifiés.

Ce que le module détecte

Erreurs PHP

Le module capture les erreurs fatales et les warnings (et, au choix, les notices et dépréciations) en front et, si l’option est cochée, en back-office. Les erreurs identiques sont regroupées. Une nouvelle erreur fatale déclenche une alerte critique immédiate ; l’alerte expire sans message après 24 heures sans nouvelle occurrence. Une alerte de pic est levée au-delà de 100 erreurs et avertissements en 15 minutes (réglable, 0 pour désactiver). Les journaux PrestaShop de gravité 3 et 4 sont importés à chaque passage du cron.

Chaque erreur reçoit une origine probable : module, thème, override, template compilé ou cœur. Quand l’erreur est levée dans le cœur, le premier module trouvé dans la pile d’appels est retenu.

Temps de réponse et disponibilité

  • Le temps de réponse est mesuré sur les vraies visites de la boutique. La part des pages mesurées se règle de 1 à 100 % ; chaque page mesurée coûte une écriture en base.
  • Une alerte est levée quand le 95e centile sur 15 minutes dépasse le seuil (3000 ms par défaut), à partir de 20 pages mesurées.
  • Une alerte critique est levée quand le taux d’erreurs serveur (HTTP 5xx ou fatale PHP) dépasse 5 % sur 15 minutes, avec au moins 5 erreurs.
  • La page d’accueil est chargée à chaque passage du cron serveur ; deux échecs consécutifs ouvrent l’alerte critique « Boutique injoignable ». Le test est suspendu en mode maintenance.

Paiements et commandes

  • Paiements échoués : commandes passées dans un des statuts sélectionnés sur la dernière heure, avec le détail par module de paiement. Seuil par défaut : 3. Le contrôle est aussi lancé dès qu’une commande change de statut. Cochez les statuts que vos modules de paiement utilisent pour un refus.
  • Conversion au paiement : le module enregistre chaque panier qui atteint l’étape de paiement, puis compare, sur une fenêtre de 2 heures se terminant 30 minutes avant la vérification, la part de ces paniers devenus commandes avec la part habituelle sur 28 jours. Le contrôle démarre après environ 40 paniers d’historique et 8 paniers dans la fenêtre (réglable).
  • Chute des commandes : les commandes des 3 dernières heures (réglable) sont comparées à la moyenne du même créneau sur les 4 semaines précédentes. Le contrôle est ignoré quand moins de 4 commandes sont attendues. Zéro commande au lieu d’une activité habituelle donne une alerte critique.
  • Sensibilité : basse, moyenne (recommandée) ou haute. Une sensibilité haute alerte plus tôt mais produit plus de fausses alertes.

En multiboutique, paiements, conversion et commandes sont évalués boutique par boutique.

Santé du serveur

  • Certificat SSL : lu toutes les 6 heures sur le domaine de la boutique. Avertissement à 14 jours de l’expiration (réglable), critique à 3 jours.
  • Espace disque : avertissement sous 2048 Mo libres (réglable), critique sous le quart de ce seuil. Sur un hébergement mutualisé avec quota, la valeur lue peut être celle du disque entier du serveur.
  • Surveillance du cron : quand un cron serveur a déjà tourné, une alerte est levée depuis le trafic visiteurs ou le back-office après 30 minutes sans passage.

Gérer les alertes

Un problème ouvre une seule alerte, mise à jour tant qu’il dure. L’onglet Alertes liste l’historique et les notifications envoyées, avec le résultat de chaque envoi.

  • Acquitter : arrête les rappels. Le message de résolution est toujours envoyé.
  • Fermer : clôt l’alerte. Si le problème est toujours là, une nouvelle alerte s’ouvre au contrôle suivant.

Acquitter depuis une notification

Chaque notification d’alerte contient un lien Acquitter et arrêter les rappels. Il ouvre une page de confirmation sur la boutique, adaptée au téléphone ; l’alerte est acquittée seulement après validation, ce qui empêche les antivirus de messagerie d’acquitter en ouvrant le lien.

Page des erreurs PHP

Filtrez par gravité ou par origine, recherchez un message, un fichier ou une page. Une erreur dépliée montre la page, le contrôleur, les dates, le message complet et, pour les warnings, la pile d’appels. Le bouton Copier le rapport pour un développeur copie un texte avec la version de PrestaShop et de PHP, le fichier, l’origine, la page, les occurrences, le message et la pile d’appels. Mettre en sourdine garde le comptage sans plus jamais alerter.

Données et confidentialité

  • Les adresses de page sont enregistrées sans paramètres d’URL.
  • La pile d’appels est enregistrée sans les arguments des fonctions.
  • Le chemin du serveur et le nom du dossier d’administration sont retirés de tous les textes enregistrés et envoyés.
  • Les jetons Telegram et les chemins de webhook sont masqués dans le journal des notifications.
  • L’historique est purgé après 30 jours par défaut (réglable de 7 à 365 jours) ; les alertes closes sont conservées 90 jours.

Limites connues

  • Une erreur fatale levée avant le chargement des modules n’est pas capturée par le gestionnaire d’erreurs ; le test de disponibilité et le taux de 5xx la signalent.
  • Les pages Symfony du back-office ne passent pas par le hook utilisé pour capturer les erreurs en back-office.
  • La conversion au paiement repose sur le hook displayPaymentTop. Si votre module de commande en une page ne l’appelle pas, désactivez ce contrôle : la chute des commandes reste surveillée.

Dépannage

Le test email échoue

Vérifiez la configuration dans Paramètres avancés > E-mail et envoyez un email de test depuis cette page. Le message d’erreur exact est affiché après le test et dans l’onglet Alertes.

« Aucun cron serveur détecté » reste affiché

Seul le cron CLI ou l’URL cron comptent comme cron serveur. Lancez la commande à la main en SSH : elle affiche un rapport JSON. Si elle échoue, vérifiez le chemin vers PHP CLI chez votre hébergeur.

Le test Telegram renvoie « chat not found »

Le bot ne peut écrire qu’à une conversation qui lui a déjà parlé. Envoyez-lui un message, puis cliquez sur Détecter mon chat.

Cette page vous a-t-elle été utile ?

Toujours bloqué ? Contactez le support