# Surveillance et Alertes PrestaShop (DataFirefly Monitor)
> 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…
- Page:
- Langue: fr
- Mis à jour le: 2026-10-07
- Autres langues: [en](https://www.datafirefly.com/en/documentation/dfmonitor/index.md), [es](https://www.datafirefly.com/es/documentation/dfmonitor/index.md), [de](https://www.datafirefly.com/de/documentation/dfmonitor/index.md), [it](https://www.datafirefly.com/it/documentation/dfmonitor/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfmonitor/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfmonitor/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfmonitor/index.md)
- Index:
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.