PS PrestaShop PrestaShop Anfänger

PrestaShop Monitoring & Alarme (DataFirefly Monitor)

Modul installieren, Cron einplanen, Alarmkanäle einrichten und jede Erkennung verstehen.

Aktualisiert Modulversion 1.1.0

DataFirefly Monitor überwacht Ihren PrestaShop-8- oder 9-Shop laufend und warnt Sie, wenn er ausfällt, abstürzt, langsam wird oder keine Zahlungen mehr annimmt. Diese Dokumentation behandelt Installation, Cron-Job, Benachrichtigungskanäle, jede Erkennung und den Umgang mit Alarmen.

Installation

  1. Öffnen Sie im Backoffice Module > Modulverwaltung, klicken Sie auf Modul hochladen und senden Sie die Datei dfmonitor-1.1.0.zip.
  2. Das Modul legt seine Tabellen und einen Reiter Erweiterte Einstellungen > Überwachung & Alarme an. Der Konfigurieren-Button des Moduls führt direkt dorthin.
  3. Bei der Installation wird die Shop-E-Mail als Empfänger verwendet und der Status Zahlungsfehler als Fehlerstatus ausgewählt. PrestaShop-Protokolle von vor der Installation werden nicht importiert.

Das Modul ist kompatibel mit PrestaShop 8.0 bis 9.x, Multishop und mehrsprachig. Es verwendet keine Composer-Abhängigkeit. Ein Update von 1.0.0 erfolgt durch Hochladen des neuen ZIP: Das Update-Skript ergänzt die neuen Spalten und trägt den Ursprung der bereits erfassten Fehler nach.

Erste Schritte

Das Dashboard zeigt eine Einrichtungsliste mit vier Schritten, bis sie abgeschlossen ist: erste Benachrichtigung erhalten, Cron-Job hinzufügen, Status für fehlgeschlagene Zahlungen prüfen, externen Heartbeat hinzufügen. Jeder Schritt führt zum passenden Einstellungsreiter.

Cron-Job

Fatal Errors und fehlgeschlagene Zahlungen werden in Echtzeit gemeldet. Alles andere (Verfügbarkeit, Antwortzeit, Zahlungen, Bestellungen, Server, Bericht) wertet ein geplanter Job aus, der alle 5 Minuten laufen sollte.

Server-Cron (empfohlen)

*/5 * * * * php /pfad/zu/prestashop/modules/dfmonitor/cron.php

Der genaue Befehl mit dem Pfad Ihres Servers steht unter Einstellungen > Geplante Prüfungen, mit einem Kopieren-Button.

Cron per URL

Erlaubt Ihr Hoster nur Web-Crons, rufen Sie die tokengeschützte URL aus demselben Reiter auf, aus dem Hosting-Panel oder über einen Dienst wie cron-job.org. Sie antwortet in JSON und funktioniert auch im Wartungsmodus. Der Button Neues Token erzeugen macht die bisherige URL ungültig.

Ohne Cron

Mit PHP-FPM startet die Ausweichoption die Prüfungen über den Besucherverkehr, wenn seit 10 Minuten kein Cron lief, nachdem die Seite gesendet wurde. Verfügbarkeitsprüfung und Heartbeat laufen in diesem Modus nicht, und ein nächtlicher Ausfall kann ohne Besuche unbemerkt bleiben.

Externer Heartbeat

Einen Totalausfall des Servers kann das Modul nicht melden. Legen Sie einen Check bei Healthchecks.io oder Better Stack an und fügen Sie dessen URL unter Heartbeat-URL ein: Sie wird bei jedem Cron-Lauf aufgerufen, und der Dienst warnt Sie, wenn die Aufrufe ausbleiben.

Benachrichtigungskanäle

Aktivieren Sie unter Einstellungen > Benachrichtigungskanäle beliebig viele Kanäle. Jeder Kanal hat einen Mindestschweregrad (Warnung und kritisch oder nur kritisch) und einen Button Speichern und Test senden, der das Formular speichert und dann eine echte Nachricht sendet. Das Ergebnis der letzten Zustellung steht unter dem Kanalnamen.

E-Mail

Geben Sie einen oder mehrere Empfänger durch Kommas getrennt ein. Die E-Mails nutzen die E-Mail-Konfiguration von PrestaShop (Erweiterte Einstellungen > E-Mail) und die Standardsprache des Shops.

Telegram

  1. Öffnen Sie in Telegram @BotFather, senden Sie /newbot und folgen Sie den Anweisungen.
  2. Fügen Sie das erhaltene Token unter Bot-Token ein.
  3. Senden Sie Ihrem Bot eine Nachricht oder fügen Sie ihn einer Gruppe hinzu und klicken Sie auf Meinen Chat erkennen: Die Chat-ID wird automatisch eingetragen.

Slack

In Slack: Apps > Incoming Webhooks > Add to Slack, Kanal wählen und die Webhook-URL kopieren, die mit https://hooks.slack.com/ beginnt.

Discord

In Discord: Servereinstellungen > Integrationen > Webhooks > Neuer Webhook, dann Webhook-URL kopieren.

Webhook

Für Zapier, Make, n8n, ein Bereitschaftstool oder Ihr eigenes Skript. Bei jedem neuen Alarm, jeder Erinnerung und jeder Behebung wird ein JSON-POST mit dem Header X-DataFirefly-Event gesendet:

{
  "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"
}

Die Werte von event sind open, repeat, resolved und test. Ist ein Signaturgeheimnis gesetzt, trägt jede Anfrage den Header X-DataFirefly-Signature: sha256=…, den HMAC SHA-256 des Rohinhalts mit diesem Geheimnis.

Alarmregeln

  • Erinnerung an einen laufenden Alarm: Abstand zwischen zwei Benachrichtigungen zum selben Problem (standardmäßig 60 Minuten).
  • Maximale Benachrichtigungen pro Stunde: standardmäßig 20, 0 für keine Begrenzung.
  • Entwarnung: Eine Nachricht wird gesendet, wenn ein gemeldetes Problem verschwindet.
  • Ruhezeiten: Im gewählten Zeitraum werden nur kritische Alarme gesendet. Eine Warnung, die am Ende des Zeitraums noch offen ist, wird beim nächsten Cron-Lauf gesendet.
  • Zusammenfassung per E-Mail: deaktiviert, täglich oder jeden Montag zur gewählten Uhrzeit. Sie umfasst Verfügbarkeit, Antwortzeit, PHP-Fehler, Bestellungen, fehlgeschlagene Zahlungen, die Alarme des Zeitraums und die häufigsten Fehler.

Pause

Der Button Pausieren in der Kopfzeile setzt Benachrichtigungen für 30 Minuten, 2, 8 oder 24 Stunden aus, etwa während eines Updates. Probleme werden weiter erkannt und erfasst; die bei Pausenende noch offenen werden gemeldet.

Was das Modul erkennt

PHP-Fehler

Das Modul erfasst Fatal Errors und Warnungen (optional auch Hinweise und Deprecations) im Shop und, wenn die Option aktiviert ist, im Backoffice. Identische Fehler werden gruppiert. Ein neuer Fatal Error löst sofort einen kritischen Alarm aus; der Alarm läuft nach 24 Stunden ohne neues Vorkommen ohne Nachricht ab. Ein Spitzenalarm wird bei mehr als 100 Fehlern und Warnungen in 15 Minuten ausgelöst (einstellbar, 0 deaktiviert). PrestaShop-Protokolle mit Schweregrad 3 und 4 werden bei jedem Cron-Lauf importiert.

Jeder Fehler erhält einen wahrscheinlichen Ursprung: Modul, Theme, Override, kompiliertes Template oder Kern. Tritt der Fehler im Kern auf, wird das erste Modul im Aufrufstapel verwendet.

Antwortzeit und Verfügbarkeit

  • Die Antwortzeit wird an echten Besuchen gemessen. Der Anteil gemessener Seiten ist von 1 bis 100 % einstellbar; jede gemessene Seite kostet einen Datenbank-Schreibvorgang.
  • Ein Alarm wird ausgelöst, wenn das 95. Perzentil über 15 Minuten die Schwelle überschreitet (standardmäßig 3000 ms), ab 20 gemessenen Seiten.
  • Ein kritischer Alarm wird ausgelöst, wenn die Serverfehlerquote (HTTP 5xx oder PHP Fatal Error) über 15 Minuten 5 % überschreitet, bei mindestens 5 Fehlern.
  • Die Startseite wird bei jedem Server-Cron-Lauf geladen; zwei Fehlschläge in Folge öffnen den kritischen Alarm „Shop nicht erreichbar“. Im Wartungsmodus ist die Prüfung ausgesetzt.

Zahlungen und Bestellungen

  • Zahlungsfehler: Bestellungen, die in der letzten Stunde in einen der gewählten Status wechselten, aufgeschlüsselt nach Zahlungsmodul. Standardschwelle: 3. Die Prüfung läuft außerdem, sobald eine Bestellung den Status ändert. Wählen Sie die Status, die Ihre Zahlungsmodule für eine Ablehnung verwenden.
  • Checkout-Conversion: Das Modul erfasst jeden Warenkorb, der den Zahlungsschritt erreicht, und vergleicht über ein 2-Stunden-Fenster, das 30 Minuten vor der Prüfung endet, den Anteil dieser Warenkörbe mit Bestellung mit dem üblichen Anteil über 28 Tage. Die Prüfung beginnt nach etwa 40 Warenkörben Historie und 8 Warenkörben im Fenster (einstellbar).
  • Bestelleinbruch: Die Bestellungen der letzten 3 Stunden (einstellbar) werden mit dem Durchschnitt desselben Zeitfensters der 4 Vorwochen verglichen. Werden weniger als 4 Bestellungen erwartet, entfällt die Prüfung. Null Bestellungen statt der üblichen Aktivität ergeben einen kritischen Alarm.
  • Empfindlichkeit: niedrig, mittel (empfohlen) oder hoch. Hoch warnt früher, erzeugt aber mehr Fehlalarme.

Im Multishop werden Zahlungen, Conversion und Bestellungen Shop für Shop ausgewertet.

Serverzustand

  • SSL-Zertifikat: alle 6 Stunden an der Shop-Domain gelesen. Warnung 14 Tage vor Ablauf (einstellbar), kritisch ab 3 Tagen.
  • Speicherplatz: Warnung unter 2048 MB frei (einstellbar), kritisch unter einem Viertel dieser Schwelle. Bei Shared Hosting mit Kontingent kann der gelesene Wert die gesamte Serverplatte sein.
  • Cron-Überwachung: Sobald ein Server-Cron einmal gelaufen ist, wird nach 30 Minuten ohne Lauf ein Alarm über Besucherverkehr oder Backoffice ausgelöst.

Alarme verwalten

Ein Problem öffnet einen einzigen Alarm, der aktualisiert wird, solange es besteht. Der Reiter Alarme zeigt den Verlauf und die gesendeten Benachrichtigungen mit dem Ergebnis jeder Zustellung.

  • Bestätigen: stoppt die Erinnerungen. Die Entwarnung wird weiterhin gesendet.
  • Schließen: schließt den Alarm. Besteht das Problem weiter, öffnet sich bei der nächsten Prüfung ein neuer Alarm.

Bestätigen aus einer Benachrichtigung

Jede Alarmbenachrichtigung enthält einen Link Bestätigen und Erinnerungen stoppen. Er öffnet eine für Handys ausgelegte Bestätigungsseite im Shop; der Alarm wird erst nach Ihrer Zustimmung bestätigt, sodass E-Mail-Scanner ihn nicht durch Öffnen des Links bestätigen können.

Seite der PHP-Fehler

Filtern Sie nach Schweregrad oder Ursprung, suchen Sie nach Meldung, Datei oder Seite. Ein aufgeklappter Fehler zeigt Seite, Controller, Daten, die vollständige Meldung und bei Warnungen den Aufrufstapel. Der Button Bericht für einen Entwickler kopieren kopiert einen Text mit PrestaShop- und PHP-Version, Datei, Ursprung, Seite, Vorkommen, Meldung und Aufrufstapel. Stummschalten zählt den Fehler weiter, alarmiert aber nie wieder.

Daten und Datenschutz

  • Seitenadressen werden ohne URL-Parameter gespeichert.
  • Der Aufrufstapel wird ohne Funktionsargumente gespeichert.
  • Serverpfad und Name des Admin-Ordners werden aus allen gespeicherten und gesendeten Texten entfernt.
  • Telegram-Tokens und Webhook-Pfade werden im Benachrichtigungsprotokoll maskiert.
  • Der Verlauf wird standardmäßig nach 30 Tagen gelöscht (einstellbar von 7 bis 365 Tagen); geschlossene Alarme bleiben 90 Tage erhalten.

Bekannte Grenzen

  • Ein Fatal Error vor dem Laden der Module wird vom Fehlerhandler nicht erfasst; Verfügbarkeitsprüfung und 5xx-Quote melden ihn.
  • Symfony-Seiten des Backoffice laufen nicht über den Hook, mit dem Backoffice-Fehler erfasst werden.
  • Die Checkout-Conversion beruht auf dem Hook displayPaymentTop. Ruft Ihr One-Page-Checkout-Modul ihn nicht auf, deaktivieren Sie diese Prüfung: Die Überwachung der Bestelleinbrüche bleibt aktiv.

Fehlerbehebung

Der E-Mail-Test schlägt fehl

Prüfen Sie die Konfiguration unter Erweiterte Einstellungen > E-Mail und senden Sie dort eine Test-E-Mail. Die genaue Fehlermeldung erscheint nach dem Test und im Reiter Alarme.

„Kein Server-Cron erkannt“ bleibt sichtbar

Nur der CLI-Cron oder die Cron-URL zählen als Server-Cron. Führen Sie den Befehl per SSH von Hand aus: Er gibt einen JSON-Bericht aus. Schlägt er fehl, klären Sie den Pfad zu PHP CLI mit Ihrem Hoster.

Der Telegram-Test meldet „chat not found“

Ein Bot kann nur in eine Unterhaltung schreiben, die ihn bereits angeschrieben hat. Senden Sie ihm eine Nachricht und klicken Sie dann auf Meinen Chat erkennen.

War diese Seite hilfreich?

Immer noch nicht weiter? Support kontaktieren