Log-Management und Monitoring in Magento 2: von exception.log zu echtem Alerting

1. Warum exception.log allein kein Monitoring ist: die Lücke zwischen Logging und Alerting

Viele Magento-Teams verwechseln Logging mit Monitoring, weil beide auf denselben Rohdaten aufsetzen. Log-Management und Monitoring sind aber zwei verschiedene Disziplinen: Logging schreibt Ereignisse in eine Datei, Monitoring bewertet diese Ereignisse aktiv und löst bei Bedarf eine Reaktion aus. Eine exception.log, die im Container unter var/log unbemerkt auf mehrere Gigabyte anwächst, ist streng genommen nur ein Archiv. Niemand liest sie proaktiv, bevor ein Kunde sich über einen fehlgeschlagenen Checkout beschwert. Genau diese Lücke zwischen dem reinen Wegschreiben von Fehlern und dem tatsächlichen Erkennen eines Problems in Echtzeit ist der Ausgangspunkt für jedes ernstzunehmende Log-Management-Konzept.

Der Unterschied zeigt sich am deutlichsten in der Reaktionszeit. Ohne Monitoring erfährt ein Team von einem defekten Zahlungsmodul häufig erst durch einen Support-Ticket oder einen Umsatzeinbruch, der Stunden später im Reporting auffällt. Mit funktionierendem Monitoring löst derselbe Fehler innerhalb von Sekunden eine Slack-Nachricht oder einen PagerDuty-Incident aus, weil ein Handler den Log-Eintrag klassifiziert und die Schwelle für eine kritische Meldung überschritten wurde. Diese Verschiebung von reaktivem Debugging zu proaktivem Alerting ist der eigentliche Wertbeitrag eines durchdachten Log-Management-Setups, nicht die bloße Existenz von Logdateien.

Wer bereits Monolog-Channels und -Handler in Magento kennt, muss diese Grundlagen an dieser Stelle nicht wiederholen, sondern die nächste Schicht bauen: strukturierte, maschinenlesbare Logs, eine zentrale Aggregation über alle Container hinweg, definierte Alerting-Regeln und einen Betriebsprozess, der auf einen Alarm auch tatsächlich reagiert. Genau diese operative Schicht steht im Zentrum der folgenden Abschnitte.

2. Strukturiertes Logging: ein JSON-Formatter für maschinenlesbare Magento-Logs

Klassische Magento-Logzeilen sind für Menschen lesbar, aber für Maschinen mühsam zu parsen. Ein Log-Aggregator wie Grafana Loki oder Elasticsearch muss Freitext-Zeilen mit regulären Ausdrücken zerlegen, was bei jeder Formatänderung bricht. Log-Management auf Produktionsniveau setzt deshalb auf strukturiertes JSON-Logging: jede Zeile ist ein vollständiges, in sich geschlossenes JSON-Objekt mit festen Feldern wie timestamp, level, channel, message, trace_id und einem frei erweiterbaren context-Objekt. Dieses Format lässt sich ohne Parsing-Heuristik direkt indizieren, filtern und aggregieren.

Monolog bringt mit Monolog\Formatter\JsonFormatter bereits eine Basisimplementierung mit, die für den Magento-Betrieb aber meist zu generisch ist. Ein eigener Formatter reichert jeden Eintrag um Felder an, die für Monitoring relevant sind: die aktuelle Store-View, die Magento-Version, den Hostnamen des Containers und, sofern vorhanden, eine Trace-ID aus dem laufenden Request. Diese Anreicherung passiert einmalig im Formatter und muss nicht in jedem einzelnen Log-Aufruf im Code wiederholt werden, was die Konsistenz über alle Module hinweg sicherstellt.

Der folgende Formatter zeigt eine PHP-8.4-Implementierung mit readonly-Eigenschaften für die statischen Metadaten, die sich pro Prozess nicht ändern:

declare(strict_types=1);

namespace Mironsoft\LogMonitoring\Logger\Formatter;

use Monolog\Formatter\NormalizerFormatter;
use Monolog\LogRecord;

/**
 * Structured JSON formatter enriching every log record with
 * static process metadata and the active trace identifier.
 */
final class StructuredJsonFormatter extends NormalizerFormatter
{
    public function __construct(
        private readonly string $hostname,
        private readonly string $magentoVersion,
        private readonly string $environment,
    ) {
        parent::__construct(self::SIMPLE_DATE);
    }

    /**
     * Formats a single log record as a single-line JSON document.
     *
     * @param LogRecord $record The record produced by the Monolog logger
     * @return string One JSON object terminated by a newline
     */
    public function format(LogRecord $record): string
    {
        $payload = [
            'timestamp' => $record->datetime->format(self::SIMPLE_DATE),
            'level' => $record->level->getName(),
            'channel' => $record->channel,
            'message' => $record->message,
            'context' => $this->normalize($record->context),
            'extra' => $this->normalize($record->extra),
            'trace_id' => $record->extra['trace_id'] ?? null,
            'host' => $this->hostname,
            'magento_version' => $this->magentoVersion,
            'environment' => $this->environment,
        ];

        return json_encode($payload, JSON_UNESCAPED_SLASHES) . "\n";
    }
}

Der entscheidende Vorteil eines solchen Formatters zeigt sich erst im Zusammenspiel mit der Aggregation: Felder wie environment oder trace_id werden zu durchsuchbaren Labels, nicht zu Textfragmenten, die erst per Regex extrahiert werden müssen. Das reduziert die Query-Zeit in Loki oder Elasticsearch erheblich und macht Alerting-Regeln, die auf einzelnen Feldern basieren, überhaupt erst praktikabel.

3. Ein Custom Monolog Handler für kritische Fehler: Push-Benachrichtigung an Slack oder PagerDuty

Strukturierte Logs allein lösen das Alerting-Problem nicht, solange niemand sie in Echtzeit beobachtet. Der nächste Baustein im Log-Management und Monitoring-Stack ist ein Custom Monolog Handler, der kritische Log-Einträge aktiv an einen externen Kanal weiterleitet, statt sie nur zu schreiben. Der Handler filtert nach Log-Level (typischerweise ab CRITICAL oder ERROR mit zusätzlicher Kontextprüfung) und sendet einen HTTP-POST an einen Slack-Webhook oder die PagerDuty Events API v2.

Wichtig ist, dass dieser Handler den Request-Zyklus nicht blockiert. Ein synchroner HTTP-Call in einem PHP-FPM-Worker, der auf eine langsame Slack-API wartet, verlangsamt jede Checkout-Anfrage, die zufällig einen kritischen Fehler produziert. In der Praxis setzt man deshalb entweder auf einen kurzen Timeout mit Fire-and-Forget-Semantik oder auf einen asynchronen Versand über eine Magento-Queue (async.operations.all), die den eigentlichen Push in einem separaten Consumer-Prozess ausführt. Für die meisten Magento-Setups reicht ein kurzer Timeout von ein bis zwei Sekunden aus, kombiniert mit einem try/catch, das einen fehlgeschlagenen Push selbst nur intern loggt statt einen weiteren Alert-Sturm auszulösen.

declare(strict_types=1);

namespace Mironsoft\LogMonitoring\Logger\Handler;

use Monolog\Handler\AbstractProcessingHandler;
use Monolog\Level;
use Monolog\LogRecord;

/**
 * Custom Monolog handler pushing critical Magento log records
 * to a Slack incoming webhook or the PagerDuty Events API v2.
 */
final class CriticalAlertHandler extends AbstractProcessingHandler
{
    public function __construct(
        private readonly string $webhookUrl,
        private readonly string $serviceKey,
        private readonly string $alertProvider = 'slack',
        Level $level = Level::Critical,
    ) {
        parent::__construct($level, true);
    }

    /**
     * Sends a single log record to the configured alerting provider.
     *
     * @param LogRecord $record The record already filtered by minimum level
     * @return void
     */
    protected function write(LogRecord $record): void
    {
        $payload = $this->alertProvider === 'pagerduty'
            ? $this->buildPagerDutyPayload($record)
            : $this->buildSlackPayload($record);

        $context = stream_context_create([
            'http' => [
                'method' => 'POST',
                'header' => "Content-Type: application/json\r\n",
                'content' => json_encode($payload),
                'timeout' => 2.0,
                'ignore_errors' => true,
            ],
        ]);

        try {
            @file_get_contents($this->webhookUrl, false, $context);
        } catch (\Throwable) {
            // Alert delivery failure must never break the request cycle
            // and must never trigger another alert (avoids alert loops).
        }
    }

    /**
     * @param LogRecord $record The log record to convert
     * @return array<string, mixed> Slack-compatible message payload
     */
    private function buildSlackPayload(LogRecord $record): array
    {
        return [
            'text' => sprintf(
                ':rotating_light: *%s* on `%s`: %s',
                $record->level->getName(),
                $record->channel,
                $record->message
            ),
        ];
    }

    /**
     * @param LogRecord $record The log record to convert
     * @return array<string, mixed> PagerDuty Events API v2 payload
     */
    private function buildPagerDutyPayload(LogRecord $record): array
    {
        return [
            'routing_key' => $this->serviceKey,
            'event_action' => 'trigger',
            'payload' => [
                'summary' => $record->message,
                'source' => $record->channel,
                'severity' => 'critical',
            ],
        ];
    }
}

Über di.xml wird dieser Handler an einen spezifischen Logger-Channel gebunden, statt ihn global für jeden Log-Aufruf zu aktivieren. So bleibt das Alerting auf Kanäle beschränkt, die tatsächlich betriebsrelevante Ereignisse tragen, etwa Zahlungsabwicklung oder Bestandsabgleich, während Debug-Ausgaben aus Entwicklermodulen keinen Push auslösen.

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <!-- Handler instance configured with alerting endpoint and provider -->
    <type name="Mironsoft\LogMonitoring\Logger\Handler\CriticalAlertHandler">
        <arguments>
            <argument name="webhookUrl" xsi:type="string">https://hooks.slack.com/services/REPLACE/WITH/TOKEN</argument>
            <argument name="serviceKey" xsi:type="string">REPLACE_WITH_PAGERDUTY_ROUTING_KEY</argument>
            <argument name="alertProvider" xsi:type="string">slack</argument>
        </arguments>
    </type>

    <!-- Dedicated logger channel for payment processing -->
    <type name="Mironsoft\LogMonitoring\Logger\PaymentLogger">
        <arguments>
            <argument name="name" xsi:type="string">payment</argument>
            <argument name="handlers" xsi:type="array">
                <item name="alert" xsi:type="object">Mironsoft\LogMonitoring\Logger\Handler\CriticalAlertHandler</item>
                <item name="system" xsi:type="object">Magento\Framework\Logger\Handler\System</item>
            </argument>
        </arguments>
    </type>
</config>

4. Zentrale Log-Aggregation: Log-Shipping von Magento-Containern zu Grafana Loki oder dem ELK-Stack

Ein Custom Handler löst das Problem für einzelne kritische Ereignisse, ersetzt aber keine zentrale Sicht auf alle Logs über alle Container hinweg. Sobald ein Magento-Setup aus mehreren Web-Containern, Cron-Containern und Consumer-Prozessen besteht, verteilen sich Logdateien über verschiedene Hosts und Volumes. Log-Management auf Betriebsniveau bedeutet deshalb, alle Logquellen an einen zentralen Aggregator zu schicken, statt sich mit bin/log exception.log von Container zu Container zu hangeln.

Zwei Architekturen dominieren die Praxis: Der ELK-Stack (Elasticsearch, Logstash, Kibana) mit Filebeat als leichtgewichtigem Log-Shipper, oder Grafana Loki mit Promtail beziehungsweise dem Filebeat-Loki-Output. Loki indiziert im Gegensatz zu Elasticsearch nur die Labels, nicht den vollständigen Log-Inhalt, was Speicherverbrauch und Betriebskosten deutlich reduziert, aber bei komplexen Volltextsuchen langsamer ist als Elasticsearch. Für die meisten Magento-Betreiber, die primär nach channel, level und trace_id filtern, ist Loki die kosteneffizientere Wahl, während Teams mit hohem Bedarf an Freitextsuche in Fehlermeldungen eher zu Elasticsearch tendieren.

Die folgende Filebeat-Konfiguration liest die strukturierten JSON-Logs aus var/log und leitet sie an einen Loki-Endpunkt weiter. Da die Logs bereits im JSON-Format vorliegen, entfällt jede Grok-Pattern-Definition, die bei Freitext-Logs sonst nötig wäre.

# filebeat.yml: ships structured Magento JSON logs to Grafana Loki
filebeat.inputs:
  - type: filestream
    id: magento-json-logs
    paths:
      - /var/www/html/var/log/*.log
    parsers:
      - ndjson:
          target: ""
          add_error_key: true
          message_key: message

processors:
  - add_fields:
      target: ""
      fields:
        service: magento
        stack: production

output.loki:
  url: "http://loki:3100/loki/api/v1/push"
  batch_wait: 1s
  batch_size: 1024
  labels:
    keys: ["level", "channel", "environment", "host"]

Wer stattdessen den ELK-Stack betreibt, ersetzt lediglich den output-Block gegen Logstash oder direkt Elasticsearch, während Input und Processor-Konfiguration identisch bleiben, weil beide Systeme dieselben strukturierten JSON-Zeilen konsumieren. Genau diese Entkopplung von Formatierung im Application-Code und Transport im Log-Shipper ist der Grund, warum der JSON-Formatter aus Abschnitt zwei die eigentliche Grundlage für jedes zentrale Log-Management ist.

5. Alerting-Regeln definieren: Schwellenwerte, ratenbasierte Alerts und Vermeidung von Alert-Fatigue

Ein zentraler Log-Aggregator allein erzeugt noch kein Monitoring, solange niemand definiert, wann ein Muster in den Logs tatsächlich einen Alarm rechtfertigt. Naive Alerting-Regeln, die bei jedem einzelnen ERROR-Eintrag einen Slack-Push auslösen, führen innerhalb weniger Tage zu Alert-Fatigue: Teams beginnen, Benachrichtigungen zu ignorieren, weil die meisten davon keine tatsächliche Handlung erfordern. Gutes Monitoring unterscheidet deshalb zwischen Einzelereignissen, die informativ sind, und Mustern, die eine Reaktion verlangen.

Ratenbasierte Alerts sind hier der wichtigste Hebel: Statt bei jedem fehlgeschlagenen Zahlungsversuch zu alarmieren, definiert man eine Regel wie "mehr als 20 fehlgeschlagene Zahlungen pro Minute über alle Store-Views hinweg", was in Grafana als Alert-Rule auf Basis einer Loki-Query oder in Elasticsearch als Watcher formuliert wird. Diese Schwellenwerte müssen an das tatsächliche Grundrauschen des Shops angepasst werden: Ein Shop mit hohem Traffic hat eine andere Baseline an vereinzelten Zahlungsfehlern als ein kleiner B2B-Shop, bei dem bereits ein einzelner Fehler auffällig ist.

Zusätzlich zur reinen Rate sollten Alerting-Regeln nach Schweregrad gestaffelt werden: ein WARNING-Alert landet in einem Team-Channel zur Kenntnisnahme, ein CRITICAL-Alert mit anhaltender Fehlerrate löst einen PagerDuty-Incident mit Eskalation aus. Deduplizierung ist ebenfalls entscheidend: Derselbe zugrunde liegende Fehler, der hundertmal pro Minute auftritt, soll einen einzigen aktiven Incident erzeugen, nicht hundert einzelne Benachrichtigungen. PagerDuty und die meisten modernen Alerting-Systeme gruppieren Ereignisse automatisch über einen dedup_key, sofern der Custom Handler diesen konsistent aus Fehlertyp und Channel ableitet.

6. Log-Rotation und Retention im Produktionsbetrieb: Speicherkosten und Compliance-Anforderungen

Zentrale Aggregation löst nicht automatisch das Problem wachsender lokaler Logdateien in den Containern selbst. Ohne Rotation füllt eine aktive exception.log in einem stark frequentierten Shop das Container-Volume innerhalb weniger Wochen, was im schlimmsten Fall zu einem vollen Dateisystem und ausfallendem Checkout führt. Log-Management auf Produktionsniveau umfasst deshalb immer eine klare Rotations- und Retentionsstrategie, unabhängig davon, ob die Logs zusätzlich zentral aggregiert werden.

Für den Magento-Container ist logrotate der Standardansatz: Logdateien werden ab einer definierten Größe oder in festen Zeitintervallen rotiert, komprimiert und nach einer definierten Anzahl von Generationen gelöscht. Wichtig ist die copytruncate-Option, weil Magento und PHP-FPM Dateihandles auf die Logdatei offen halten, solange der Prozess läuft, und ein einfaches Verschieben der Datei ohne Signal an den Prozess dazu führt, dass neue Log-Einträge ins Leere geschrieben werden.

# /etc/logrotate.d/magento: rotate Magento log files in production
/var/www/html/var/log/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
    dateext
    dateformat -%Y%m%d
    size 500M
}

/var/www/html/var/log/exception.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

Retention ist nicht nur eine Frage der Speicherkosten, sondern zunehmend auch eine Compliance-Frage. Logs, die personenbezogene Daten enthalten, etwa E-Mail-Adressen in Bestellfehlern, unterliegen der DSGVO und dürfen nicht unbegrenzt aufbewahrt werden. Eine sinnvolle Praxis ist eine gestaffelte Retention: Rohlogs lokal für 14 bis 30 Tage, aggregierte und anonymisierte Metriken in Grafana Loki für 90 Tage, kritische Sicherheitsereignisse gegebenenfalls länger in einem separaten, zugriffsbeschränkten Speicher. Diese Staffelung reduziert sowohl Speicherkosten als auch das Risiko, personenbezogene Daten länger als nötig vorzuhalten.

7. Korrelation von Logs mit Application Performance Monitoring: Trace-IDs über Request-Grenzen hinweg

Ein einzelner Log-Eintrag zeigt, dass ein Fehler passiert ist, aber selten, warum. Um einen fehlgeschlagenen Checkout vollständig nachzuvollziehen, muss man den zugehörigen HTTP-Request, den ausgelösten Datenbank-Query, den externen API-Call an einen Payment-Provider und den resultierenden Log-Eintrag als zusammenhängende Kette sehen können. Genau das leistet die Korrelation von Log-Management und Monitoring mit Application Performance Monitoring über eine gemeinsame Trace-ID.

Praktisch bedeutet das: Ein Frontend-Controller oder ein früher Plugin-Punkt generiert zu Beginn jedes Requests eine eindeutige trace_id (oder übernimmt eine bereits vom Load Balancer gesetzte, etwa über den traceparent-Header nach W3C Trace Context), die anschließend über den gesamten Request-Lebenszyklus mitgeführt wird. Der JSON-Formatter aus Abschnitt zwei schreibt diese Trace-ID in jeden Log-Eintrag, während APM-Tools wie New Relic, Datadog APM oder ein selbst betriebener OpenTelemetry-Collector dieselbe ID in ihre Spans übernehmen.

Der eigentliche operative Gewinn entsteht, sobald man in Grafana ein Dashboard hat, das aus einem APM-Trace direkt zur zugehörigen Loki-Log-Zeile verlinkt, und umgekehrt aus einem Alert in Slack direkt zum vollständigen Trace springt. Diese bidirektionale Verlinkung verkürzt die Fehleranalyse von einem manuellen Abgleich mehrerer Systeme auf wenige Klicks. Ohne konsequente Trace-ID-Propagation über Queue-Consumer, Cron-Jobs und asynchrone API-Calls hinweg reißt diese Kette jedoch schnell ab, weshalb die Trace-ID explizit in Message-Queue-Payloads und Cron-Kontext mitgegeben werden muss, nicht nur im HTTP-Request-Header.

8. Betriebsprozess rund um Alerts: On-Call-Rotation, Eskalationsstufen, Runbooks

Technisches Alerting ohne organisatorischen Prozess dahinter verpufft. Ein PagerDuty-Incident, der niemanden erreicht, weil keine On-Call-Rotation definiert ist, unterscheidet sich in der Wirkung kaum von einem Alert, der nie ausgelöst wurde. Eine funktionierende On-Call-Rotation weist zu jedem Zeitpunkt eine klar verantwortliche Person zu, die Alerts der ersten Stufe innerhalb einer definierten Reaktionszeit bestätigt, typischerweise fünf bis fünfzehn Minuten für kritische Produktionsfehler.

Eskalationsstufen fangen den Fall ab, dass die primäre On-Call-Person nicht reagiert: Nach Ablauf der Reaktionszeit eskaliert PagerDuty automatisch an eine zweite Person oder ein Team-Lead-Level, danach gegebenenfalls an das gesamte Entwicklungsteam. Diese Eskalationslogik gehört fest in die Konfiguration des Alerting-Tools, nicht in informelle Absprachen, weil informelle Prozesse unter Stress und außerhalb der Kernarbeitszeit erfahrungsgemäß versagen.

Runbooks schließen die Lücke zwischen "ein Alert ist eingegangen" und "das Problem ist gelöst". Ein Runbook zu einem spezifischen Alert, etwa "Zahlungsfehlerrate über Schwellenwert", beschreibt konkrete erste Schritte: welches Dashboard zu öffnen ist, welche Log-Query in Grafana Loki den Fehler eingrenzt, welche externen Statusseiten (etwa des Payment-Providers) zu prüfen sind, und wann ein Rollback des letzten Deployments die richtige Reaktion ist. Ohne Runbook verbringt selbst ein erfahrener Entwickler die ersten kritischen Minuten eines Incidents mit Orientierung statt mit Behebung, was bei nächtlichen Alerts besonders schwer wiegt.

9. Dashboards für den Alltag: welche Kennzahlen aus Magento-Logs operativ relevant sind

Neben reaktivem Alerting braucht ein Team ein Dashboard, das den Gesundheitszustand des Shops auf einen Blick zeigt, ohne dass erst ein Alarm ausgelöst werden muss. Für Log-Management und Monitoring in Magento sind dabei wenige Kennzahlen wirklich operativ relevant, viele andere sind nur Rauschen. Die Fehlerrate pro Minute, aufgeschlüsselt nach Log-Channel, zeigt Trendveränderungen, bevor sie zu einem ausgewachsenen Incident werden.

Ebenso wichtig ist die Verteilung von Log-Levels über Zeit: Ein plötzlicher Anstieg von WARNING-Einträgen kündigt oft ein CRITICAL-Problem an, bevor Kunden es überhaupt bemerken, etwa wenn ein externer Payment-Endpunkt zunehmend langsamer antwortet, bevor er komplett ausfällt. Ein Dashboard, das diese Vorwarnsignale sichtbar macht, verschiebt Monitoring von reiner Fehlererkennung zu echter Prävention.

Für Grafana-Dashboards auf Basis von Loki-Queries hat sich eine feste Struktur bewährt: oben eine Zeitreihe der Gesamtfehlerrate, darunter eine Aufschlüsselung nach Channel und Store-View, gefolgt von einer Tabelle der zehn häufigsten Fehlermeldungen der letzten Stunde und einem Panel mit der aktuellen Anzahl offener PagerDuty-Incidents. Diese Struktur gibt jedem Teammitglied, unabhängig vom aktiven On-Call-Status, in unter einer Minute ein verlässliches Bild vom aktuellen Systemzustand.

Die folgende Tabelle vergleicht die gängigsten Ziele für zentrales Log-Management hinsichtlich Aufwand, Durchsuchbarkeit, Kosten und Alerting-Fähigkeit.

10. Zusammenfassung

Log-Management und Monitoring in Magento 2 beginnt dort, wo einfaches Logging aufhört: bei der aktiven Bewertung und Weiterleitung kritischer Ereignisse. Ein strukturierter JSON-Formatter macht Logs maschinenlesbar, ein Custom Monolog Handler schickt kritische Fehler direkt an Slack oder PagerDuty, und eine zentrale Aggregation in Grafana Loki oder dem ELK-Stack macht alle Container-Logs an einem Ort durchsuchbar. Alerting-Regeln mit sinnvollen Schwellenwerten verhindern Alert-Fatigue, während Log-Rotation und Retention Speicherkosten und Compliance-Anforderungen im Griff halten.

Der letzte, oft unterschätzte Baustein ist die Verbindung von Monitoring mit einem funktionierenden Betriebsprozess: Trace-IDs verbinden Logs mit APM-Traces, eine klare On-Call-Rotation mit Eskalationsstufen stellt sicher, dass jemand reagiert, und Runbooks verkürzen die Zeit von Alarm zu Lösung. Ein Dashboard mit wenigen, wirklich relevanten Kennzahlen rundet das Setup ab und macht den Systemzustand für das gesamte Team jederzeit sichtbar, nicht nur im Ernstfall.

11. FAQ: Log-Management und Monitoring in Magento 2