# Monitorización y Alertas PrestaShop (DataFirefly Monitor)
> DataFirefly Monitor vigila tu tienda PrestaShop 8 o 9 de forma continua y te avisa cuando se cae, falla, se ralentiza o deja de cobrar. Esta documentación cubre la instalación,…
- Página:
- Idioma: es
- Actualizado el: 2026-10-07
- Otros idiomas: [fr](https://www.datafirefly.com/documentation/dfmonitor/index.md), [en](https://www.datafirefly.com/en/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)
- Índice:
DataFirefly Monitor vigila tu tienda PrestaShop 8 o 9 de forma continua y te avisa cuando se cae, falla, se ralentiza o deja de cobrar. Esta documentación cubre la instalación, la tarea cron, los canales de notificación, cada detección y la gestión de alertas.
## Instalación
1. En el back office, abre **Módulos > Gestor de módulos**, haz clic en **Subir un módulo** y envía el archivo `dfmonitor-1.1.0.zip`.
2. El módulo crea sus tablas y una pestaña **Parámetros avanzados > Supervisión y alertas**. El botón Configurar del módulo lleva directamente a ella.
3. En la instalación, el email de la tienda se usa como destinatario y el estado _Error en el pago_ se selecciona como estado de fallo. Los registros de PrestaShop anteriores a la instalación no se importan.
El módulo es compatible con PrestaShop 8.0 a 9.x, multitienda y multiidioma. No usa dependencias de Composer. Para actualizar desde la 1.0.0 basta con subir el nuevo ZIP: el script de actualización añade las nuevas columnas y rellena el origen de los errores ya registrados.
## Primeros pasos
El panel muestra una lista de puesta en marcha en cuatro pasos mientras no esté terminada: recibir una primera notificación, añadir la tarea cron, revisar los estados de pago fallido y añadir un heartbeat externo. Cada paso lleva a la pestaña de ajustes correspondiente.
## Tarea cron
Los errores fatales y los pagos fallidos se notifican en tiempo real. El resto (disponibilidad, tiempo de respuesta, pagos, pedidos, servidor, informe) lo evalúa una tarea programada que debe ejecutarse cada 5 minutos.
### Cron del servidor (recomendado)
```
*/5 * * * * php /ruta/a/prestashop/modules/dfmonitor/cron.php
```
El comando exacto, con la ruta de tu servidor, aparece en **Ajustes > Comprobaciones programadas** con un botón Copiar.
### Cron por URL
Si tu hosting solo permite crons web, llama a la URL protegida con token que aparece en la misma pestaña, desde el panel del hosting o un servicio como cron-job.org. Responde en JSON y también funciona con la tienda en modo mantenimiento. El botón **Generar un nuevo token** invalida la URL anterior.
### Sin cron
Con PHP-FPM, la opción de respaldo sin cron lanza las comprobaciones con el tráfico de visitantes cuando ningún cron se ha ejecutado en 10 minutos, después de enviar la página. La comprobación de disponibilidad y el heartbeat no se ejecutan en este modo, y una caída de noche puede pasar desapercibida si no hay visitas.
### Heartbeat externo
El módulo no puede notificar una caída total del servidor. Crea un check en Healthchecks.io o Better Stack y pega su URL en **URL de heartbeat**: se llama en cada ejecución del cron y el servicio te avisa si deja de recibir llamadas.
## Canales de notificación
Activa tantos canales como quieras en **Ajustes > Canales de notificación**. Cada canal tiene una gravedad mínima (aviso y crítico, o solo crítico) y un botón **Guardar y enviar una prueba** que guarda el formulario y luego envía un mensaje real. El resultado del último envío aparece bajo el nombre del canal.
### Email
Introduce uno o varios destinatarios separados por comas. Los emails usan la configuración de email de PrestaShop (**Parámetros avanzados > E-mail**) y el idioma por defecto de la tienda.
### Telegram
1. En Telegram, abre **@BotFather**, envía `/newbot` y sigue las instrucciones.
2. Pega el token obtenido en **Token del bot**.
3. Envía un mensaje a tu bot, o añádelo a un grupo, y haz clic en **Detectar mi chat**: el ID del chat se rellena automáticamente.
### Slack
En Slack: **Apps > Incoming Webhooks > Add to Slack**, elige el canal y copia la URL del webhook, que empieza por `https://hooks.slack.com/`.
### Discord
En Discord: **Ajustes del servidor > Integraciones > Webhooks > Nuevo webhook** y luego **Copiar URL del webhook**.
### Webhook
Para Zapier, Make, n8n, una herramienta de guardias o tu propio script. Se envía un POST JSON en cada nueva alerta, recordatorio y resolución, con la cabecera `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"
}
```
Los valores de `event` son `open`, `repeat`, `resolved` y `test`. Si se define un secreto de firma, cada petición lleva la cabecera `X-DataFirefly-Signature: sha256=…`, HMAC SHA-256 del cuerpo en bruto con ese secreto.
## Reglas de alerta
- **Recordatorio de una alerta en curso**: tiempo entre dos notificaciones del mismo problema (60 minutos por defecto).
- **Máximo de notificaciones por hora**: 20 por defecto, 0 sin límite.
- **Mensaje de resolución**: se envía un mensaje cuando desaparece un problema notificado.
- **Horas tranquilas**: durante la franja elegida solo se envían alertas críticas. Un aviso que siga abierto al final de la franja se envía en la siguiente ejecución del cron.
- **Informe resumen por email**: desactivado, diario o cada lunes, a la hora elegida. Incluye disponibilidad, tiempo de respuesta, errores PHP, pedidos, pagos fallidos, alertas del periodo y errores más frecuentes.
### Pausa
El botón **Pausa** de la cabecera suspende las notificaciones durante 30 minutos, 2 horas, 8 horas o 24 horas, por ejemplo durante una actualización. Los problemas se siguen detectando y registrando; los que sigan abiertos al terminar la pausa se notifican.
## Qué detecta el módulo
### Errores PHP
El módulo captura errores fatales y warnings (y, opcionalmente, notices y deprecaciones) en la tienda y, si la opción está marcada, en el back office. Los errores idénticos se agrupan. Un nuevo error fatal dispara una alerta crítica inmediata; la alerta caduca sin mensaje tras 24 horas sin nuevas apariciones. Se genera una alerta de pico por encima de 100 errores y avisos en 15 minutos (ajustable, 0 para desactivar). Los registros de PrestaShop de gravedad 3 y 4 se importan en cada ejecución del cron.
Cada error recibe un **origen probable**: módulo, tema, override, plantilla compilada o núcleo. Cuando el error se produce en el núcleo, se toma el primer módulo encontrado en la pila de llamadas.
### Tiempo de respuesta y disponibilidad
- El tiempo de respuesta se mide en visitas reales a la tienda. El **porcentaje de páginas medidas** se ajusta de 1 a 100 %; cada página medida cuesta una escritura en base de datos.
- Se genera una alerta cuando el percentil 95 en 15 minutos supera el umbral (3000 ms por defecto), a partir de 20 páginas medidas.
- Se genera una alerta crítica cuando la tasa de errores de servidor (HTTP 5xx o error fatal PHP) supera el 5 % en 15 minutos, con al menos 5 errores.
- La página de inicio se carga en cada ejecución del cron del servidor; dos fallos seguidos abren la alerta crítica «Tienda inaccesible». La comprobación se suspende en modo mantenimiento.
### Pagos y pedidos
- **Pagos fallidos**: pedidos que pasaron a uno de los estados seleccionados en la última hora, con el desglose por módulo de pago. Umbral por defecto: 3. La comprobación también se lanza en cuanto un pedido cambia de estado. Marca los estados que usan tus módulos de pago para un rechazo.
- **Conversión en el pago**: el módulo registra cada carrito que llega al paso de pago y compara, en una ventana de 2 horas que termina 30 minutos antes de la comprobación, la parte de esos carritos convertidos en pedidos con la parte habitual en 28 días. La comprobación empieza tras unos 40 carritos de historial y 8 carritos en la ventana (ajustable).
- **Caída de pedidos**: los pedidos de las últimas 3 horas (ajustable) se comparan con la media de la misma franja en las 4 semanas anteriores. Se omite cuando se esperan menos de 4 pedidos. Cero pedidos en lugar de la actividad habitual genera una alerta crítica.
- **Sensibilidad**: baja, media (recomendada) o alta. La alta avisa antes pero genera más falsas alarmas.
En multitienda, pagos, conversión y pedidos se evalúan tienda por tienda.
### Salud del servidor
- **Certificado SSL**: se lee cada 6 horas en el dominio de la tienda. Aviso 14 días antes de caducar (ajustable), crítico a 3 días.
- **Espacio en disco**: aviso por debajo de 2048 MB libres (ajustable), crítico por debajo de una cuarta parte de ese umbral. En hosting compartido con cuota, el valor leído puede ser el del disco completo del servidor.
- **Vigilancia del cron**: cuando un cron del servidor ya se ha ejecutado, se genera una alerta desde el tráfico de visitantes o el back office tras 30 minutos sin ejecución.
## Gestionar las alertas
Un problema abre una sola alerta, que se actualiza mientras dura. La pestaña **Alertas** muestra el historial y las notificaciones enviadas, con el resultado de cada envío.
- **Confirmar**: detiene los recordatorios. El mensaje de resolución se sigue enviando.
- **Cerrar**: cierra la alerta. Si el problema persiste, se abre una nueva alerta en la siguiente comprobación.
### Confirmar desde una notificación
Cada notificación de alerta contiene un enlace **Confirmar y detener recordatorios**. Abre una página de confirmación en la tienda, adaptada al móvil; la alerta solo se confirma tras validar, lo que impide que los antivirus de correo la confirmen al abrir el enlace.
## Página de errores PHP
Filtra por gravedad u origen, busca un mensaje, un archivo o una página. Un error desplegado muestra la página, el controlador, las fechas, el mensaje completo y, para los warnings, la pila de llamadas. El botón **Copiar el informe para un desarrollador** copia un texto con las versiones de PrestaShop y PHP, el archivo, el origen, la página, las apariciones, el mensaje y la pila de llamadas. **Silenciar** sigue contando el error sin volver a alertar.
## Datos y privacidad
- Las direcciones de página se guardan sin parámetros de URL.
- La pila de llamadas se guarda sin los argumentos de las funciones.
- La ruta del servidor y el nombre de la carpeta de administración se eliminan de todos los textos guardados y enviados.
- Los tokens de Telegram y las rutas de webhook se ocultan en el registro de notificaciones.
- El historial se purga a los 30 días por defecto (ajustable de 7 a 365 días); las alertas cerradas se conservan 90 días.
## Límites conocidos
- Un error fatal producido antes de cargar los módulos no lo captura el gestor de errores; la comprobación de disponibilidad y la tasa de 5xx lo señalan.
- Las páginas Symfony del back office no pasan por el hook usado para capturar errores en el back office.
- La conversión en el pago depende del hook `displayPaymentTop`. Si tu módulo de checkout en una página no lo llama, desactiva esta comprobación: la caída de pedidos sigue vigilada.
## Solución de problemas
### La prueba de email falla
Revisa la configuración en **Parámetros avanzados > E-mail** y envía un email de prueba desde esa página. El mensaje de error exacto aparece tras la prueba y en la pestaña Alertas.
### Sigue apareciendo «No se ha detectado ningún cron del servidor»
Solo el cron CLI o la URL cron cuentan como cron del servidor. Ejecuta el comando a mano por SSH: muestra un informe JSON. Si falla, revisa la ruta de PHP CLI con tu hosting.
### La prueba de Telegram devuelve «chat not found»
Un bot solo puede escribir a una conversación que ya le ha hablado. Envíale un mensaje y haz clic en Detectar mi chat.