Magento-Suche-Performance-Monitoring mit dem Elasticsearch Slow Log

1. Warum langsame Magento-Suchanfragen oft unbemerkt bleiben

Magento zeigt in seiner eigenen Anwendungsebene in der Regel keine detaillierte Aufschlüsselung, wie lange eine einzelne Suchanfrage im Cluster tatsächlich gebraucht hat, sondern nur die Gesamtantwortzeit der Storefront-Seite, in der Netzwerklatenz, PHP-Verarbeitung und Rendering ebenfalls enthalten sind. Eine einzelne langsame Aggregation in der Layered Navigation geht in dieser Gesamtzeit unter, solange sie nicht isoliert gemessen wird.

Ohne gezieltes Monitoring fällt eine schleichende Verschlechterung meist erst auf, wenn Nutzer sich über träge Suchergebnisse beschweren oder Conversion-Metriken sinken, zu einem Zeitpunkt, an dem bereits reale Umsatzeinbußen entstanden sind. Der Slow Log verschiebt diesen Erkennungszeitpunkt deutlich nach vorn, weil er jede Anfrage oberhalb eines Schwellenwerts sofort und automatisch protokolliert.

2. Slow Log Grundlagen: Query-Phase gegenüber Fetch-Phase

Der Search Slow Log unterscheidet zwischen zwei Phasen einer Suchanfrage: der Query-Phase, in der jeder Shard die eigentliche Suche ausführt und Treffer-IDs samt Scores ermittelt, und der Fetch-Phase, in der die tatsächlichen Dokumentinhalte für die finalen Top-Treffer geladen werden. Beide Phasen werden getrennt geloggt, weil sie unterschiedliche Ursachen für Langsamkeit haben können, etwa eine teure Aggregation in der Query-Phase gegenüber großen _source-Dokumenten in der Fetch-Phase.

Zusätzlich zum Search Slow Log existiert ein eigener Indexing Slow Log, der langsame Schreiboperationen protokolliert und für Magento besonders während eines vollständigen Reindex relevant ist, wenn große Mengen an Produktdokumenten in kurzer Zeit indexiert werden. Beide Slow Logs werden unabhängig voneinander konfiguriert und landen standardmäßig in getrennten Log-Dateien.

3. Schwellenwert-Konfiguration pro Index

Die Schwellenwerte werden als dynamische Index-Settings gesetzt und lassen sich damit pro Magento-Katalogindex individuell konfigurieren, ohne den Cluster neu zu starten. Vier Stufen stehen zur Verfügung, warn, info, debug und trace, wobei jede Stufe unabhängig für Query- und Fetch-Phase mit einer eigenen Zeitschwelle konfiguriert wird und Anfragen, die eine höhere Stufe überschreiten, automatisch auch in den niedrigeren Stufen protokolliert werden.

Für produktive Magento-Cluster hat sich eine gestaffelte Konfiguration bewährt, bei der warn auf einen Wert gesetzt wird, der wirklich kritische Anfragen markiert, während debug deutlich niedriger liegt, um auch beginnende Verschlechterungen sichtbar zu machen. Ein zu niedriger Schwellenwert auf hoher Log-Stufe erzeugt allerdings schnell eine unhandliche Log-Menge, die das eigentliche Problem eher verdeckt als aufdeckt.

PUT /catalogsearch_fulltext_de/_settings
{
  "index.search.slowlog.threshold.query.warn": "3s",
  "index.search.slowlog.threshold.query.info": "1s",
  "index.search.slowlog.threshold.query.debug": "500ms",
  "index.search.slowlog.threshold.query.trace": "200ms",
  "index.search.slowlog.threshold.fetch.warn": "2s",
  "index.search.slowlog.threshold.fetch.info": "800ms",
  "index.search.slowlog.level": "info",
  "index.indexing.slowlog.threshold.index.warn": "10s",
  "index.indexing.slowlog.threshold.index.info": "5s",
  "index.indexing.slowlog.source": "1000"
}

4. Konfiguration im Kontext mehrerer Magento-Indizes pro Store View

Magento legt für jede Store View mit eigener Sprache oder eigenem Preiskontext einen separaten Katalogindex an, sodass ein Shop mit fünf Store Views auch fünf unabhängige Indizes im Cluster besitzt, jeder mit eigenen Slow-Log-Einstellungen. Eine Konfiguration ausschließlich für einen einzelnen Index reicht deshalb nicht aus, wenn tatsächlich alle Store Views überwacht werden sollen.

Praktikabel ist ein Index-Template, das die Slow-Log-Schwellenwerte automatisch auf jeden neu angelegten Katalogindex anwendet, sodass auch nach einem vollständigen Reindex mit neu erzeugten Indexnamen die Überwachung ohne manuellen Zusatzschritt lückenlos weiterläuft. Ohne ein solches Template müssten Schwellenwerte nach jedem Reindex erneut manuell gesetzt werden, was in der Praxis schnell vergessen wird.

PUT /_index_template/magento_catalog_slowlog
{
  "index_patterns": ["catalogsearch_fulltext_*", "magento2_product_*"],
  "template": {
    "settings": {
      "index.search.slowlog.threshold.query.warn": "3s",
      "index.search.slowlog.threshold.query.debug": "500ms",
      "index.search.slowlog.level": "info"
    }
  }
}

5. Das Slow-Log-Format lesen und interpretieren

Ein typischer Slow-Log-Eintrag enthält die verstrichene Zeit, den betroffenen Index und Shard, die Anzahl der Treffer, die vollständige Query-DSL sowie optional Stack-Statistiken, sofern slowlog.source aktiviert ist. Die enthaltene Query-DSL ist der wichtigste Bestandteil, weil sie exakt die Struktur zeigt, die zur Langsamkeit geführt hat, etwa eine tiefe Verschachtelung von Aggregationen oder eine Wildcard-Query auf einem nicht optimierten Feld.

Für Magento-Suchanfragen lässt sich die geloggte Query anhand charakteristischer Aggregationsnamen und Filterfelder relativ zuverlässig der ursprünglichen Anfrage zuordnen, etwa einer Attribut-Facette in der Layered Navigation, deren Feldname direkt dem Magento-Attributcode entspricht. Diese Zuordnung ist der entscheidende Schritt, um von einem abstrakten Zeitwert im Log zu einer konkreten, im Magento-Code nachvollziehbaren Ursache zu kommen.

[2026-08-08T09:14:22,481][WARN ][index.search.slowlog.query] [node-1]
[catalogsearch_fulltext_de][3] took[3.4s], took_millis[3412],
total_hits[184302], types[], stats[], search_type[QUERY_THEN_FETCH],
total_shards[5], source[{"query":{"bool":{"filter":[{"terms":
{"category_ids":["24","31","57"]}}]}},"aggs":{"farbe_bucket":
{"terms":{"field":"farbe","size":500}}}}], id[]

6. Workflow: Von Slow-Log-Eintrag zur konkreten Query-Optimierung

Der systematische Ablauf beginnt mit dem täglichen oder wöchentlichen Sichten der warn- und info-Einträge, sortiert nach Häufigkeit desselben Query-Musters statt nach einzelnen Vorkommen, weil ein wiederkehrendes Muster mit hoher Frequenz meist einen größeren Gesamteinfluss auf die Nutzererfahrung hat als ein einmaliger Ausreißer. Aus der geloggten Query-DSL wird dann isoliert, welcher Teil, Filter, Aggregation oder Sortierung, den größten Zeitanteil verursacht.

Im nächsten Schritt wird die isolierte Query-Komponente mit der Profiler-API einzeln getestet, um die Vermutung aus dem Slow-Log-Eintrag zu bestätigen, bevor eine Änderung am Magento-Code oder an der Index-Konfiguration vorgenommen wird. Nach der Optimierung wird dieselbe Anfrage erneut ausgeführt und mit dem ursprünglichen Zeitwert verglichen, um den tatsächlichen Effekt zu belegen, statt sich auf ein gefühltes Ergebnis zu verlassen.

7. Häufige Ursachen langsamer Magento-Suchanfragen

In der Praxis dominieren drei Ursachen: eine zu große Anzahl gleichzeitiger Terms-Aggregationen in der Layered Navigation, bei der jedes zusätzliche Filterattribut eine weitere Aggregation erzeugt, Wildcard- oder Prefix-Queries auf Textfeldern ohne passenden Analyzer, die eine vollständige Term-Durchsuchung erzwingen, sowie tiefe Pagination über from und size, die bei großen Trefferzahlen exponentiell teurer wird, weil jeder Shard alle Treffer bis zum angeforderten Offset sortieren muss.

Ein weiterer, spezifisch für Magento relevanter Fall ist eine ungewollt hohe size bei Terms-Aggregationen für Attribute mit vielen unterschiedlichen Werten, etwa eine Farb- oder Größenfacette mit mehreren Hundert möglichen Werten, bei der eine zu großzügig konfigurierte Aggregationsgröße unnötig viel Speicher und Rechenzeit pro Shard bindet.

8. Konkrete Optimierungsschritte nach einem Slow-Log-Fund

Für zu viele Facetten in der Layered Navigation hilft eine Begrenzung der gleichzeitig aggregierten Attribute auf die tatsächlich in der jeweiligen Kategorie relevanten, statt pauschal alle konfigurierten Filterattribute in jeder Anfrage zu aggregieren. Für Wildcard-Queries ist meist ein dedizierter ngram- oder edge_ngram-Analyzer die bessere Lösung, weil er die teure Laufzeit-Suche durch eine zur Indexzeit vorbereitete Struktur ersetzt.

Bei tiefer Pagination liefert search_after in Kombination mit einem stabilen Sortierkriterium eine deutlich günstigere Alternative zu großen from-Werten, ist für die klassische seitenweise Magento-Storefront-Navigation aber nur bedingt einsetzbar und eignet sich vor allem für Exportfunktionen oder interne Batch-Verarbeitung großer Ergebnismengen. Für Filter-Kontexte ohne Relevanz-Scoring, etwa reine Kategoriefilter, sollte grundsätzlich filter statt must verwendet werden, damit Elasticsearch das Ergebnis cachen kann.

9. Slow Log in ein umfassendes Monitoring integrieren

Rohe Log-Dateien auf dem Server sind für den täglichen Betrieb wenig praktikabel, weshalb sich ein Log-Shipping in einen eigenen, dedizierten Auswertungsindex im selben oder einem separaten Cluster empfiehlt, verbunden mit einem Dashboard, das die häufigsten Query-Muster nach Gesamtzeitanteil aggregiert darstellt. Auf dieser Grundlage lassen sich auch automatisierte Alerts konfigurieren, die bei einer plötzlichen Häufung von Slow-Log-Einträgen eine Benachrichtigung auslösen.

Wichtig ist, Slow-Log-Auswertung nicht isoliert zu betreiben, sondern mit Magento-seitigen Metriken wie Reindex-Dauer, Seitenladezeit und Fehlerraten zu korrelieren, weil ein Anstieg langsamer Suchanfragen häufig zeitlich mit einem laufenden Reindex, einem Deployment oder einer Änderung an der Layered Navigation zusammenfällt und diese Korrelation die eigentliche Ursache oft schneller findet als die isolierte Betrachtung des Slow Logs allein.

10. Zusammenfassung

11. FAQ: Slow Log Monitoring