Shopware 6 ohne Observability: Warum die meisten Shops Blindflug machen

Ihr Shopware-Shop läuft. Bestellungen kommen rein, der Umsatz stimmt, niemand schreit. Aber wenn Sie heute jemand fragt: „Funktioniert Ihr Checkout gerade so schnell wie letzte Woche?" - können Sie das verlässlich beantworten? In den meisten Shops, die wir uns ansehen, ist die ehrliche Antwort: nein. Und genau das ist das Problem.

Wenn ein Kunde anruft und sagt „die Seite lädt ewig", öffnet jemand den Browser, klickt selbst drauf und sagt „bei mir geht's". Das ist Raten statt Monitoring, und es kostet Sie Geld, ohne dass Sie es merken.

Das „Es läuft doch"-Syndrom

Wie tief dieses Problem sitzt, sieht man erst, wenn man hinschaut. Stellvertretendes Beispiel aus einem unserer Projekte: ein Shopware-6-Shop mit knapp 30.000 Produkten, einem selbstgebauten B2B-Modul und einer Anbindung an ein externes Warenwirtschaftssystem. Der Kunde war zufrieden - der Shop lief. Dachten alle Beteiligten.

Bis wir beim Einrichten eines vernünftigen Monitorings drei Dinge innerhalb der ersten 24 Stunden fanden. Vermutlich existieren ähnliche Probleme in Ihrem Shop genauso - nur kennt sie aktuell niemand:

1. Der Product-Export in die Wawi brach jede Nacht um 02:17 ab. Der Cronjob lief in einen Timeout, rollte still zurück und versuchte es beim nächsten Durchlauf erneut. Kein Log-Eintrag oberhalb von DEBUG-Level. Seit sechs Wochen - während Produktdaten leise veralteten.

2. Die Checkout-Conversion war an Wochentagen zwischen 10:00 und 10:30 um 40 % niedriger. Ursache: Ein Redis-Snapshot, der den Session-Handler für exakt diese halbe Stunde in die Knie zwang. Hochgerechnet auf einen Monat: ein fünfstelliger Umsatzverlust, den niemand auf dem Schirm hatte.

3. Der Elasticsearch-Index war seit dem letzten Shopware-Minor-Update verwaist. Die Suche funktionierte trotzdem - sie fiel lautlos auf MySQL FULLTEXT zurück. Niemand hatte den Performance-Unterschied bemerkt, weil „die Suche ja Ergebnisse liefert". Die Frage ist nur: Wie viele Kunden haben die schlechteren Treffer einfach weggeklickt?

Drei kritische Probleme, kein einziger Alarm, sechs Monate Betrieb - in einem Shop, dessen Betreiber dachten, alles sei unter Kontrolle.

Was „Monitoring" in den meisten Shops wirklich heißt

Wenn wir in Gesprächen fragen, was an Monitoring läuft, klingt die Antwort fast immer wie eine dieser drei. Schauen Sie ehrlich, welche zu Ihrem Shop passt:

• „Wir haben das Shopware-Health-Check-Plugin."

• „Unser Hoster macht das."

• „Wir kriegen eine Mail, wenn der Shop down ist."

Wenn Sie sich hier wiedererkennen: Das ist ungefähr so, als würden Sie Ihr Auto warten, indem Sie nur gucken, ob die Motorlampe leuchtet. Der Shopware-Health-Check sagt Ihnen, ob PHP läuft und die Datenbank antwortet. Er sagt Ihnen nicht, ob Ihr Checkout funktioniert, ob Drittanbieter-APIs antworten oder ob Ihre Cache-Hit-Rate gerade von 92 % auf 34 % gefallen ist.

Ein typisches Shop-Setup, in das auch Ihr System wahrscheinlich grob passt: Shopware 6 mit MySQL, Redis und Elasticsearch dahinter - und keine dieser Komponenten hat richtiges Monitoring. Jede kann teilweise ausfallen, ohne dass Ihr Shop komplett „down" geht. Genau das macht es so gefährlich: Ihr Shop stirbt nicht dramatisch - er degradiert. Und degradierte Shops kosten Umsatz, ohne dass jemand es mitbekommt.

Die drei Ebenen, die Sie als Shop-Betreiber brauchen

Damit aus „der Shop fühlt sich okay an" eine belastbare Aussage wird, brauchen Sie Transparenz auf drei Ebenen. Keine davon ist Selbstzweck - jede beantwortet eine konkrete Frage, die Sie sonst Geld kostet.

Ebene 1: Infrastruktur. CPU, RAM, Disk-I/O, Netzwerk-Durchsatz. Das macht Ihr Hoster meistens - aber nur auf Server-Ebene, nicht pro Dienst. Wenn Redis einen Memory-Spike hat, während MySQL gleichzeitig schläft, sehen Sie auf der Hoster-Übersicht nur „Server OK". Die Frage, die diese Ebene beantworten muss: Hat Ihre Plattform überhaupt die Ressourcen, um die heutige Last zu tragen?

Ebene 2: Applikation. Transaction Traces für Ihren Checkout, Cache-Hit-Rates pro Storefront-Route, Queue-Durchsatz, Scheduled Tasks. Shopwares Scheduled-Task-System ist ein schwarzes Loch: Tasks können mit Status queued festhängen, ohne dass irgendwas loggt - und Sie merken es erst, wenn Bestellungen nicht mehr ans ERP gehen. Die Frage hier: Macht Ihr Shopware intern noch das, was es soll - oder hakt es leise an Stellen, die niemand sieht?

Ebene 3: Business. Checkout-Funnel, API-Latenzen zu Drittsystemen (Wawi, Payment, Versand), Produktdaten-Konsistenz. Wenn die DHL-API plötzlich 4 statt 0,2 Sekunden braucht, wollen Sie das wissen, bevor Ihre Kunden die Versandkosten nicht berechnet kriegen - nicht erst, wenn die Support-Tickets reinrasseln. Die Frage, die Ihnen direkt Geld bringt:Verdient Ihr Shop heute genauso zuverlässig wie gestern?

Ein pragmatischer Stack, mit dem Sie anfangen können

Sie brauchen keine sechsstellige Tooling-Investition, um aus dem Blindflug rauszukommen. Mit drei Komponenten decken Sie die wichtigsten Lücken ab - und können sie schrittweise aufbauen, statt alles auf einmal:

• Prometheus + Grafana für Metriken. Der Shopware-eigene Metrik-Endpunkt liefert Ihnen einen guten Einstieg, ergänzt mit eigenen Exportern für Queue-Tiefe und Checkout-Funnel. Dashboards, die Sie selbst lesen können, sind mehr wert als ein SaaS-Tool, dessen Login niemand im Team kennt.

• OpenTelemetry für Traces. In Symfony/Shopware per Bundle relativ schmerzfrei einzubinden. Damit sehen Sie, an welcher Stelle im Request-Lifecycle die Zeit verloren geht - und müssen nicht mehr raten, ob „der Checkout lahm" am Plugin, am Payment-Provider oder an der Datenbank liegt.

• Uptime Kuma oder Blackbox Exporter für synthetische Checks. „Kann ich ein Produkt in den Warenkorb legen?" als HTTP-Sequenz, alle 60 Sekunden. So merken Sie es als Erste, wenn Ihr Checkout bricht - nicht Ihre Kunden.

Metriken und Traces zeigen, wie sich Ihr Shop verhält. Wer in der Administration wann was geändert hat, beantwortet unser Plugin Audit Trail (Protokollierung): Es protokolliert die Aktionen, die Sie auswählen, und sein Prüfbefehl lässt sich als Cron-Job in Ihr Monitoring einbinden.

Wichtiger als das Tool ist die Entscheidung, Observability von Anfang an ins Projektbudget zu nehmen statt als Add-on, das „irgendwann nach dem Go-Live" kommt. In der Praxis kommt es nämlich nie, solange niemand bei Ihnen dafür Budget reserviert.

Fazit

Wenn Ihr Shop im Monat 50.000 € Umsatz macht und Sie kein Monitoring haben, das Ihnen sagt, ob der Checkout funktioniert, dann verlieren Sie jeden Tag Geld, ohne es zu bemerken.

Fangen Sie mit den drei Business-Metriken an, die Sie direkt Geld kosten - Checkout-Rate, Payment-API-Response, Search-Fallback. Bauen Sie dafür Alerts. Alles Weitere kommt danach. Was sich an Conversion oder Umsatz konkret bewegt, lässt sich seriös erst nach den ersten Wochen Monitoring sagen - Kataloggröße, Traffic und Plugin-Setup sind bei jedem Shop anders. Genau deshalb messen wir, statt zu versprechen.