Magento-Monitoring vom Cron bis zur Kasse
XICTRAQ prüft Warenkorb, Kasse, Schnittstellen und Cron-Läufe Ihres Magento-Shops und meldet, wenn ein eingebundenes Fremdskript seinen Inhalt ändert. Was der cookielose Tracker in Magento von selbst erfasst und was nicht, steht weiter unten.
Diese Magento-Pfade zuerst prüfen
- Uptime-MonitoringWarenkorb, nicht aus dem Seitencache
/checkout/cart/ - Uptime-MonitoringAnmeldeseite für Kunden
/customer/account/login/ - Uptime-MonitoringKatalogsuche mit Suchbegriff
/catalogsearch/result/?q=test - Browser-MonitoringVom Produkt über den Warenkorb zur Kasse
/checkout/ - API-MonitoringREST-API ohne Token, mit JSON-Prüfung
/rest/V1/directory/currency - API-MonitoringGraphQL-Abfrage storeConfig per POST
/graphql
Warum die Startseite allein wenig über Ihren Shop sagt
Magento liefert viele Seiten aus dem Seitencache aus. Warenkorb und Kasse gehören laut Herstellerdokumentation nicht dazu: Sie werden bei jedem Aufruf neu erzeugt. Eine Startseite aus dem Cache kann deshalb noch antworten, während der Warenkorb schon einen Fehler zeigt.
Dazu kommt der Cron. Über bin/magento cron:run laufen unter anderem Indexierung, Katalogpreisregeln, Währungskurse, Newsletter und – bei eingeschaltetem asynchronem Versand – die Bestellbestätigungen. Steht er still, bleibt der Shop erreichbar – und eine reine Erreichbarkeitsprüfung sieht davon nichts.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten für Warenkorb, Login und Suche, Browser-Checks für den Weg zur Kasse, API-Checks für REST und GraphQL, einen Heartbeat für den Cron und die Skript-Integrität für extern eingebundene Skripte.
Den Wartungsmodus von Magento (bin/magento maintenance:enable) wertet XICTRAQ als Ausfall: Die Standardseite antwortet mit HTTP 503 und enthält keinen der Wartungstexte, an denen der Prüfknoten eine geplante Wartung erkennt. Legen Sie für Deployments ein Wartungsfenster an – darin bleiben Ausfall- und Unterseitenalarme stumm.
Wo es in Magento-Shops hakt – und welches Modul es bemerkt
Wartungsmodus bleibt nach dem Deployment an
Bricht ein Deployment ab, bleibt die Datei var/.maintenance.flag liegen und der Shop zeigt weiter die Wartungsseite. Das Uptime-Monitoring wertet diese Antwort als Ausfall und alarmiert, wenn kein Wartungsfenster läuft.
Cron läuft nicht mehr
Nach einem Serverumzug, einem PHP-Wechsel oder einem gelöschten Crontab-Eintrag läuft bin/magento cron:run nicht mehr. Ein Heartbeat-Ping nach dem Aufruf fällt dann aus, und XICTRAQ meldet einen verpassten Heartbeat; ein Aufruf der /fail-Adresse löst einen Fehleralarm aus.
Kasse bricht nach einem Update ab
Ein Update von Erweiterung oder Theme verändert den Checkout, und die Versand- oder Zahlungsauswahl lädt nicht mehr. Ein dafür eingerichteter Browser-Check legt einen Artikel in den Warenkorb, öffnet die Kasse und prüft, ob die erwarteten Elemente sichtbar werden, ohne die Bestellung abzuschicken. Schlägt ein Schritt fehl, speichert er einen Screenshot der Stelle.
Warenkorb fällt aus, die Startseite nicht
Die Startseite kann aus dem Seitencache weiter antworten, während Warenkorb oder Kundenkonto einen Fehler liefern, etwa nach einem Datenbankproblem oder einer defekten Erweiterung. Überwachte Unterseiten prüft XICTRAQ bei jedem Uptime-Lauf mit; fällt eine aus, kommt ein eigener Alarm mit dem betroffenen Pfad.
Fremdskript ändert seinen Inhalt
Web-Skimming, oft Magecart genannt, zielt auf Zahlungsdaten im Checkout. Die Skript-Integrität speichert den SHA-256-Hash extern eingebundener Skripte und meldet, wenn sich einer ändert oder nicht mehr erreichbar ist; ein Live-Scan der Warenkorbseite meldet zusätzlich neue fremde Formularziele. Das ist ein Hinweis, kein abschließender Sicherheitsbeweis.
REST- oder GraphQL-Schnittstelle liefert Fehler
Warenwirtschaft, Marktplatzanbindung oder ein Headless-Frontend hängen an der Magento-API. Ein API-Check ruft den Endpunkt auf und prüft Statuscode, Antwortzeit und Inhalte per JSON-Pfad oder JSON-Schema; weicht die Antwort zweimal in Folge ab, folgt ein Alarm.
Woran XICTRAQ Magento erkennt
Magento wird an zwei Stellen erkannt: im Live-Scan und im Tracker. Daraus folgt, welche Angaben in Technikübersicht, CRA-Cockpit und Auswertung erscheinen.
- Der Live-Scan erkennt Magento an Adressen mit /static/version im Quelltext. Diese Versionskennung setzt Magento bei aktivierter Signierung statischer Dateien, die der Standardeinstellung entspricht.
- Die laufende Technikerkennung der Prüfknoten führt Magento nicht. Findet sie nichts, bleibt ein Magento-Befund aus dem Live-Scan aber stehen.
- Der Tracker erkennt Magento-Seiten an Skriptblöcken vom Typ text/x-magento-init, an der Seitenklasse catalog-product-view der Produktseite oder an der Klasse product-info-main zusammen mit RequireJS und liest dann Produkt, Warenkorb-Klick und Bestellabschluss aus dem Markup.
- Im CRA-Komponenten-Cockpit erscheint Magento ohne Versionsnummer und damit als nicht bewertbar. Einen Abgleich mit Sicherheitshinweisen des Herstellers gibt es für Magento nicht.
- Hyvä-Themes und Headless-Frontends wie PWA Studio weichen vom Luma-Markup ab. Dort greifen die Selektoren des Trackers nicht verlässlich; Produkt-, Warenkorb- und Kaufereignisse übergeben Sie dann über die JavaScript-API.
Was der Tracker in Magento erfasst
Der cookielose Tracker liest im Standard-Theme Luma Produkt, Warenkorb-Klick und Bestellabschluss direkt aus dem Markup. Einen Betrag zeigt die Luma-Erfolgsseite nicht an, deshalb meldet der Tracker den Kauf dort mit Betrag 0. Ein Betrag über dataLayer oder JavaScript-API kommt nur mit Einschränkungen in der Auswertung an.
Erfasst der Tracker von selbst
- Seitenaufrufe mit Herkunft und UTM-Parametern, dazu Web Vitals wie LCP und CLS
- Produktaufrufe mit Produkt-ID, Name und Endpreis, ergänzt um SKU und Kategorie aus der Brotkrumennavigation, soweit im Markup vorhanden
- Klicks auf „In den Warenkorb“ (#product-addtocart-button und .tocart) als Warenkorb-Ereignis
- Checkout-Beginn auf Pfaden mit „checkout“ – dazu zählt bereits die Warenkorbseite /checkout/cart/
- Bestellabschluss auf der Erfolgsseite (.checkout-success), bei angemeldeten Kunden mit Bestellnummer
- Bildansichten in der Produktgalerie des Luma-Themes: Klicks auf ein Bild und Bildwechsel über die Vorschaubilder, jeweils mit Bildadresse und Alternativtext, im Verlauf der Sitzung als „Bild angesehen“ und „Galerie gewechselt“
- JavaScript-Fehler aus echten Besuchen mit Meldung, Datei und Zeile
Nicht automatisch erfasst
- Ein verlässlicher Umsatzbetrag: Luma zeigt auf der Erfolgsseite keinen, und der Tracker meldet den Kauf dort mit Betrag 0 – auch wenn ein Betrag über dataLayer oder JavaScript-API hinzukommt
- Bestellnummer bei Gastbestellungen: Luma gibt sie dort ohne das Element aus, das der Tracker liest
- Angemeldete Kunden: Einen Magento-eigenen Weg, sie zu erkennen, hat der Tracker nicht
- Mengenänderungen und entfernte Artikel auf der Warenkorbseite: Die Luma-Zeilen passen nicht zu den Selektoren des Trackers
- Ob ein Artikel wirklich im Warenkorb gelandet ist: Gezählt wird der Klick auf den Button
- Erstattungen und Gutschriften: Sie entstehen im Magento-Backend, nicht im Browser des Kunden
Fehlende Werte übergeben Sie über die JavaScript-API, sobald der Tracker geladen ist: xictraq.revenue(betrag, "EUR", bestellnummer, { tax, shipping }) auf der Erfolgsseite, xictraq.identify(kundenId, { name }) für angemeldete Kunden und xictraq.cart("remove", { id, name, price, quantity }) für entfernte Artikel. Kundendaten gehören in Magento nicht in eine Seite aus dem Seitencache, ermitteln Sie die Kundenkennung für identify deshalb erst im Browser. Auf der Luma-Erfolgsseite meldet die automatische Erkennung zusätzlich einen Kauf mit Betrag 0: Bei gleicher Bestellnummer zählt nur eine der beiden Meldungen, und gehen beide in derselben Sekunde ein, ist nicht vorhersagbar, welche; ohne Bestellnummer, etwa bei Gastbestellungen, zählen beide. Prüfen Sie nach dem Einbau in der Auswertung, ob Betrag und Anzahl der Bestellungen stimmen.
Die passenden Module für Magento
Häufige Fragen
Wertet XICTRAQ den Magento-Wartungsmodus als Ausfall?
Ja. Die Standard-Wartungsseite von Magento antwortet mit HTTP 503 und nennt keinen der Wartungstexte, an denen XICTRAQ eine geplante Wartung erkennt. Legen Sie für Deployments ein einmaliges oder ein wöchentlich wiederkehrendes Wartungsfenster an, dann bleiben Ausfall- und Unterseitenalarme in diesem Zeitraum stumm.
Wie überwache ich den Magento-Cron?
Legen Sie in XICTRAQ einen Heartbeat mit dem Zeitplan Ihres Crontab-Eintrags an und rufen Sie dessen Ping-Adresse nach bin/magento cron:run auf. Bleibt der Ping aus, meldet XICTRAQ einen verpassten Heartbeat; über die Adressen /start und /fail melden Sie zusätzlich Beginn und Fehlschlag eines Laufs. Der Ping belegt, dass cron:run gelaufen ist, nicht, dass jeder einzelne Magento-Job erfolgreich war.
Erkennt XICTRAQ einen Magecart-Angriff?
Teilweise. Die Skript-Integrität meldet, wenn sich ein extern eingebundenes Skript ändert, und ein Live-Scan einer Warenkorb- oder Checkout-Seite meldet neue fremde Formularziele. Ein neu hinzugekommenes Skript meldet sie nicht, und Code direkt im Seitenquelltext, Dateien, die Ihr Shop selbst unter /static/ ausliefert, sowie Skripte, die erst im Browser nachgeladen werden, deckt sie nicht ab. Die Prüfung ist ein Hinweis, kein abschließender Sicherheitsbeweis.
Prüft XICTRAQ meine Magento-Version auf Sicherheitslücken?
Nein. Der Live-Scan erkennt Magento, liest aber keine Versionsnummer aus, und für Magento gibt es keinen Abgleich mit Sicherheitshinweisen. Der Security-Scan prüft allgemeine Punkte wie Sicherheits-Header, TLS und offen liegende Dateien wie .git/config, .env oder SQL-Dumps. Für den Fall, dass das Web-Verzeichnis auf den Projektordner statt auf pub zeigt, fragt er zusätzlich var/log/system.log, var/log/exception.log und die Composer-Zugänge in auth.json ab und meldet eine Datei erst, wenn ihr Inhalt dazu passt. Die Sicherheitsupdates des Herstellers einzuspielen bleibt Aufgabe Ihres Teams oder Ihrer Agentur.
Warum zeigt die Auswertung bei Magento-Bestellungen keinen Umsatz?
Die Erfolgsseite des Standard-Themes Luma zeigt nur die Bestellnummer, keinen Betrag, deshalb meldet der Tracker den Kauf dort mit Betrag 0. Einen Betrag liefern ein purchase-Ereignis mit ecommerce.value im dataLayer oder ein Aufruf von xictraq.revenue() auf der Erfolgsseite, die Meldung mit Betrag 0 bleibt aber bestehen. Bei gleicher Bestellnummer zählt nur eine der beiden, und welche das ist, lässt sich nicht verlässlich vorhersagen; ohne Bestellnummer zählen beide. Prüfen Sie deshalb nach dem Einbau, ob Betrag und Anzahl der Bestellungen in der Auswertung stimmen.
Funktioniert das auch mit Hyvä oder einem Headless-Frontend?
Uptime-, API- und Heartbeat-Checks arbeiten unabhängig vom Frontend, Browser-Checks prüfen die Selektoren, die Sie selbst hinterlegen. Der Tracker ist auf das Luma-Markup ausgerichtet; bei Hyvä oder PWA Studio greifen seine Selektoren nicht verlässlich. Dort übergeben Sie Produkt-, Warenkorb- und Kaufereignisse über xictraq.product(), xictraq.cart() und xictraq.revenue(). Die Auswertung zählt je Sitzung und Seite höchstens einen Produktaufruf pro Minute, neben einem automatisch erkannten Aufruf gilt also nur der zuerst eingegangene.