Magento mit New Relic überwachen: APM richtig einrichten

1. Warum New Relic für Magento mehr zeigt als Server-Metriken

Klassisches Server-Monitoring beantwortet die Frage, ob CPU und RAM ausgelastet sind, aber nicht, warum ein Kunde beim Checkout drei Sekunden auf eine Antwort wartet. New Relic setzt genau hier an: Es instrumentiert den PHP-Prozess selbst und zeichnet auf, welche Methode wie lange braucht, welche Datenbankabfrage eine Transaktion dominiert und welcher externe Aufruf, etwa an einen Zahlungsdienstleister, die Antwortzeit in die Höhe treibt. Für einen Magento Shop mit vielen Modulen, Plugins und externen Integrationen ist das der Unterschied zwischen Raten und Wissen.

In der Praxis zeigt sich der Wert von New Relic besonders bei Performance-Regressionen nach einem Release. Ein neues Plugin verlangsamt eine Observer-Kette, aber der Server-Load bleibt unauffällig, weil die zusätzliche Last sich über viele kleine Anfragen verteilt. Ohne Transaktions-Tracing bleibt dieses Problem tagelang unentdeckt, bis Kunden sich beschweren. Mit New Relic erscheint die verlangsamte Methode sofort in der Transaction Trace, mit genauer Zeitangabe und Aufrufhierarchie, sodass das verantwortliche Modul in Minuten statt Tagen identifiziert wird.

Der dritte Grund, warum sich New Relic für Magento lohnt, ist die Verbindung von Infrastruktur und Anwendungsebene in einer einzigen Oberfläche. Statt zwischen Server-Dashboard, Datenbank-Monitor und Applikationslogs zu wechseln, zeigt eine einzige Transaktion, wie viel Zeit in PHP, wie viel in MySQL, wie viel in Redis und wie viel in externen HTTP-Aufrufen verbracht wurde. Diese End-to-End-Sicht ist die Grundlage für jede ernsthafte Observability-Strategie in einem Magento Shop.

2. PHP-Agent installieren und mit Magento verbinden

Der New Relic PHP-Agent wird als natives Paket installiert, nicht als Composer-Abhängigkeit, weil er als PHP-Extension in den Interpreter geladen wird. Auf Debian-basierten Systemen erfolgt die Installation über das offizielle APT-Repository, danach folgt die Konfiguration über newrelic.ini. Der Lizenzschlüssel und der Applikationsname werden dort hinterlegt, wobei sich für Magento eine klare Namenskonvention lohnt, etwa Magento-Production und Magento-Staging, damit Daten aus verschiedenen Umgebungen nicht vermischt werden.

Nach der Installation muss PHP-FPM neu gestartet werden, damit der Agent geladen wird. Ein häufiger Fehler ist, den Agent nur für die CLI zu aktivieren, aber nicht für den FPM-Pool, oder umgekehrt, weil Magento Cron-Jobs über CLI läuft, während Webanfragen über FPM bedient werden. Beide Kontexte brauchen eine eigene Agent-Konfiguration, sonst fehlen entweder die Web-Transaktionen oder die Hintergrundjobs in New Relic.

# Add the New Relic APT repository and install the PHP agent
echo "deb http://apt.newrelic.com/debian/ newrelic non-free" \
  | sudo tee /etc/apt/sources.list.d/newrelic.list
wget -O- https://download.newrelic.com/548C16BF.gpg | sudo apt-key add -
sudo apt-get update
sudo apt-get install newrelic-php5

# Configure the agent for the Magento production application
sudo newrelic-install install
sudo sed -i 's/newrelic.appname = ".*"/newrelic.appname = "Magento-Production"/' \
  /etc/php/8.3/mods-available/newrelic.ini

# Restart both contexts that run Magento code
sudo systemctl restart php8.3-fpm
sudo phpenmod newrelic
sudo systemctl restart cron

3. Transaktionen verstehen: Web-Transaktionen und Hintergrundjobs

New Relic unterscheidet grundlegend zwischen Web-Transaktionen, die durch eine HTTP-Anfrage ausgelöst werden, und Hintergrundtransaktionen, die etwa durch Cron-Jobs oder Message-Queue-Consumer entstehen. Für Magento ist diese Trennung entscheidend, weil ein Shop mit langsamem Indexer im Web-Frontend völlig unauffällig bleiben kann, während im Hintergrund ein Reindex-Vorgang Minuten statt Sekunden braucht. Ohne die Unterscheidung landen beide Arten von Last in derselben Übersicht und verzerren die Wahrnehmung des tatsächlichen Anwendungsverhaltens.

In der Transaktionsübersicht von New Relic lassen sich Web-Transaktionen nach Controller-Aktion gruppieren, was für Magento bedeutet, dass jede Route wie catalog/product/view oder checkout/cart/add als eigene Zeile mit Durchschnittszeit, Durchsatz und Fehlerquote erscheint. Diese Granularität erlaubt es, gezielt die zehn langsamsten Aktionen zu identifizieren, statt sich auf eine einzige aggregierte Antwortzeit zu verlassen, die reale Ausreißer verschleiert.

4. Custom Instrumentation für eigene Module

Der Standard-Agent instrumentiert automatisch bekannte Frameworks und Datenbanktreiber, aber eigene Magento Module, insbesondere komplexe Service-Klassen, bleiben ohne zusätzliche Konfiguration unsichtbar. Die New Relic PHP-API erlaubt es, benutzerdefinierte Segmente in eine Transaktion einzufügen, sodass etwa ein aufwendiger Preisberechnungsservice oder ein externer API-Aufruf als eigener, benannter Block in der Transaction Trace erscheint.

Ein bewährtes Muster ist, die Instrumentierung über einen Plugin auf zentrale Service-Klassen zu legen, statt jede Methode manuell zu annotieren. So bleibt die Kernlogik unverändert, während New Relic automatisch Zeit und Aufrufanzahl für jede Instanz der Klasse erfasst. Für Magento eignet sich das besonders bei Preisregeln, Rabattlogik und Versandkostenberechnung, weil diese Bereiche oft die größten Individualisierungen enthalten und entsprechend anfällig für Performance-Regressionen sind.

<?php
declare(strict_types=1);

namespace Mironsoft\Observability\Plugin;

/**
 * Wraps expensive service calls in a named New Relic custom segment
 * so slow pricing calculations show up as their own block in traces.
 */
class NewRelicSegmentPlugin
{
    /**
     * Measures the wrapped method as a custom New Relic transaction segment.
     *
     * @param object   $subject The instrumented service instance.
     * @param callable $proceed The original method call.
     * @param mixed    ...$args Original method arguments.
     * @return mixed The original method return value.
     */
    public function aroundCalculate(object $subject, callable $proceed, ...$args): mixed
    {
        if (!\extension_loaded('newrelic')) {
            return $proceed(...$args);
        }

        \newrelic_start_segment('PriceCalculation/' . \get_class($subject));
        try {
            return $proceed(...$args);
        } finally {
            \newrelic_end_segment();
        }
    }
}

5. Checkout und Zahlungsanbindung gezielt überwachen

Der Checkout ist der Bereich, in dem jede Millisekunde Ladezeit sich direkt auf die Konversionsrate auswirkt, und gleichzeitig der Bereich mit den meisten externen Abhängigkeiten. Zahlungsanbieter, Steuerdienste und Betrugsprüfungen laufen oft synchron innerhalb der Checkout-Transaktion. New Relic zeigt in der Transaction Trace exakt, wie lange der externe HTTP-Aufruf an den Zahlungsanbieter dauert, getrennt von der eigenen Verarbeitungszeit.

Besonders wertvoll ist die Kombination aus Fehlerrate und Latenz pro externem Dienst. Wenn ein Zahlungsanbieter zeitweise langsam antwortet, ohne komplett auszufallen, bleibt das in klassischen Uptime-Checks unsichtbar, verursacht aber messbare Umsatzverluste durch Kaufabbrüche. New Relic macht solche partiellen Degradationen sichtbar, bevor sie zu einem vollständigen Ausfall eskalieren, und erlaubt damit proaktives statt reaktives Handeln im Checkout-Bereich.

6. Indexer, Cron und Message Queues im Blick behalten

Magentos Indexer, Cron-Jobs und Message-Queue-Consumer laufen außerhalb des typischen Web-Request-Zyklus, sind aber genauso anfällig für Performance-Probleme wie der Checkout. Ein hängender Consumer für die Bestellexport-Queue bleibt ohne Monitoring oft tagelang unbemerkt, während sich Nachrichten in der Warteschlange stauen. New Relic erfasst Hintergrundtransaktionen genauso wie Web-Transaktionen, sofern der Agent im CLI-Kontext korrekt konfiguriert ist.

Für Cron-Jobs lohnt sich eine explizite Benennung der Transaktion über newrelic_name_transaction(), damit jeder Job unter seinem eigenen Namen erscheint, statt unter dem generischen cron.php. Ohne diese Benennung verschwimmen alle Cron-Aufgaben in einer einzigen Sammelmetrik, und ein einzelner langsamer Job, etwa die Bereinigung alter Sitzungsdaten, lässt sich nicht mehr isoliert betrachten.

<?php
declare(strict_types=1);

namespace Mironsoft\Observability\Cron;

/**
 * Names the current New Relic transaction after the concrete cron job
 * so background tasks appear individually instead of under cron.php.
 */
class NamedCronJob
{
    /**
     * Runs the scheduled task under a distinct New Relic transaction name.
     *
     * @return void
     */
    public function execute(): void
    {
        if (\extension_loaded('newrelic')) {
            \newrelic_name_transaction('Cron/OrderExportQueue');
        }

        // Actual export logic goes here
    }
}

7. Alerts und NRQL-Abfragen sinnvoll konfigurieren

Rohdaten allein verhindern keinen Ausfall, wenn niemand sie rechtzeitig ansieht. New Relic Alerts basieren auf NRQL, einer SQL-ähnlichen Abfragesprache, die es erlaubt, präzise Bedingungen zu formulieren, etwa eine Fehlerquote über zwei Prozent in der Checkout-Transaktion über fünf Minuten hinweg. Solche zielgerichteten Alerts sind deutlich aussagekräftiger als ein pauschaler CPU-Schwellwert, weil sie direkt an geschäftskritische Abläufe gekoppelt sind.

Ein bewährtes Muster ist die Staffelung von Alert-Schwellen: eine Warnung bei moderater Verschlechterung, ein kritischer Alarm bei deutlicher Überschreitung. Für einen Magento Shop bedeutet das etwa, bei einer durchschnittlichen Checkout-Antwortzeit über 800 Millisekunden eine Warnung auszulösen und erst bei über zwei Sekunden das On-Call-Team zu alarmieren. Diese Staffelung verhindert Alarmmüdigkeit, ohne echte Vorfälle zu verpassen.

{
  "nrql": {
    "query": "SELECT percentage(count(*), WHERE error IS true) FROM Transaction WHERE appName = 'Magento-Production' AND name LIKE '%checkout/cart%' SINCE 5 minutes ago"
  },
  "terms": [
    { "duration": 5, "operator": "above", "priority": "critical", "threshold": 2 },
    { "duration": 5, "operator": "above", "priority": "warning", "threshold": 1 }
  ],
  "type": "NRQL"
}

8. Sampling, Kosten und Datenschutz im Griff behalten

Vollständiges Tracing jeder einzelnen Transaktion erzeugt bei einem stark frequentierten Magento Shop erhebliche Datenmengen, die sich direkt auf die Kosten der New Relic Lizenz auswirken. Sampling reduziert die Anzahl vollständig erfasster Traces, während aggregierte Metriken weiterhin aus allen Transaktionen berechnet werden. Diese Balance zwischen Detailtiefe und Datenvolumen muss bewusst konfiguriert werden, statt der Standardeinstellung blind zu vertrauen.

Datenschutzrechtlich ist wichtig, dass Transaktionsnamen und Custom-Attribute keine personenbezogenen Daten enthalten, etwa Kundennamen oder E-Mail-Adressen in URL-Parametern. New Relic bietet die Möglichkeit, sensible Parameter über eine Ignorierliste von der Erfassung auszuschließen, was bei jeder Magento Installation vor dem produktiven Einsatz geprüft werden sollte, insbesondere im Hinblick auf die DSGVO-Konformität von Checkout- und Kundendaten.

9. New Relic im Vergleich zu anderen Monitoring-Ansätzen

New Relic ist nicht die einzige Option für Magento Observability, und die Wahl hängt von Budget, Teamgröße und gewünschter Kontrolle über die eigene Infrastruktur ab. Die folgende Übersicht ordnet die gängigen Ansätze nach ihrem typischen Einsatzzweck ein.

In der Praxis ergänzen sich diese Ansätze oft, statt sich gegenseitig auszuschließen. Viele Magento Betreiber nutzen New Relic für das laufende Monitoring und greifen bei tiefergehenden Performance-Analysen einzelner Requests zusätzlich auf ein Profiling-Werkzeug zurück. Entscheidend ist, dass mindestens ein Werkzeug Transaktionen über Systemgrenzen hinweg nachvollziehbar macht, statt sich auf isolierte Server-Metriken zu verlassen.

10. Zusammenfassung

New Relic verwandelt Magento Monitoring von reinem Server-Watching in echte Transaktionsbeobachtung. Der PHP-Agent erfasst automatisch Web-Transaktionen und Hintergrundjobs, während Custom Instrumentation eigene Module und Service-Klassen sichtbar macht, die sonst als schwarze Blackbox in der Transaction Trace verschwinden würden. Besonders im Checkout, wo externe Zahlungsanbieter die Antwortzeit beeinflussen, liefert New Relic die Daten, um Ursache und Wirkung sauber zu trennen.

Der größte Hebel liegt darin, Alerts direkt an geschäftskritische Transaktionen zu koppeln, statt an generische Infrastruktur-Schwellwerte. Eine gestaffelte Alert-Konfiguration mit NRQL, kombiniert mit bewusstem Sampling gegen ausufernde Kosten, macht New Relic zu einem nachhaltigen Bestandteil der Betriebsstrategie für jeden produktiven Magento Shop.

11. FAQ: Magento mit New Relic überwachen