Logging und Debugging in Symfony

Effektives Logging und Debugging sind entscheidend für die Entwicklung und Wartung von Symfony-Anwendungen. Symfony bietet leistungsstarke Werkzeuge wie Monolog für das Logging und den Symfony Profiler sowie die Debug Toolbar für das Debugging.

In diesem Artikel werden wir die folgenden Themen ausführlich behandeln:

1. Konfiguration von Monolog für das Logging
2. Verständnis der Log-Level
3. Verwendung des Symfony Profilers und der Debug Toolbar
4. Fehlerbehandlung und Ausnahme-Management
5. Debugging-Techniken

1. Konfiguration von Monolog für das Logging

1.1 Einführung in Monolog

Monolog ist eine weit verbreitete PHP-Bibliothek zum Logging, die von Symfony standardmäßig verwendet wird. Es ermöglicht das Protokollieren von Ereignissen und Nachrichten in verschiedene Ziele, sogenannte Handler, wie Dateien, Datenbanken oder externe Dienste.

1.2 Standardkonfiguration in Symfony

Nach der Installation eines neuen Symfony-Projekts ist Monolog bereits vorinstalliert und vorkonfiguriert.

Standardkonfiguration in config/packages/monolog.yaml:

monolog:
    handlers:
        main:
            type: fingers_crossed
            action_level: error
            handler: nested
        nested:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug

1.3 Anpassen der Monolog-Konfiguration

Beispiel: Hinzufügen eines RotatingFileHandler

Der RotatingFileHandler erstellt für jeden Tag eine neue Logdatei.

Konfiguration:

# config/packages/monolog.yaml
monolog:
    handlers:
        main:
            type: fingers_crossed
            action_level: error
            handler: rotating_file
            excluded_http_codes: [404]
        rotating_file:
            type: rotating_file
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            max_files: 30
            level: info

Erläuterung:

• type: rotating_file: Verwendet den RotatingFileHandler.
• max_files: 30: Hält Logs der letzten 30 Tage.
• excluded_http_codes: [404]: Schließt 404-Fehler aus den Logs aus.

1.4 Verwendung von Umgebungsvariablen in der Konfiguration

Sie können Umgebungsvariablen verwenden, um die Konfiguration zu dynamisieren.

# config/packages/prod/monolog.yaml
monolog:
    handlers:
        main:
            type: stream
            path: "%env(LOG_PATH)%"
            level: "%env(LOG_LEVEL)%"

2. Verständnis der Log-Level

2.1 Überblick über die Log-Level

Monolog unterstützt die Log-Level, die in RFC 5424 definiert sind:

• DEBUG (100): Detaillierte Debugging-Informationen.
• INFO (200): Allgemeine Informationen über den normalen Betrieb.
• NOTICE (250): Wichtige normale Ereignisse.
• WARNING (300): Warnungen über ungewöhnliche Situationen.
• ERROR (400): Fehler, die die Ausführung nicht stoppen.
• CRITICAL (500): Kritische Bedingungen, z. B. Komponenten nicht verfügbar.
• ALERT (550): Sofortige Maßnahmen erforderlich.
• EMERGENCY (600): System nicht nutzbar.

2.2 Verwendung der Log-Level im Code

Beispiel:

// src/Controller/ExampleController.php

namespace App\Controller;

use Psr\Log\LoggerInterface;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ExampleController extends AbstractController
{
    #[Route('/example', name: 'example')]
    public function index(LoggerInterface $logger): Response
    {
        $logger->debug('Dies ist eine DEBUG-Nachricht.');
        $logger->info('Dies ist eine INFO-Nachricht.');
        $logger->warning('Dies ist eine WARNING-Nachricht.');
        $logger->error('Dies ist eine ERROR-Nachricht.');

        return new Response('Logging-Beispiele wurden ausgeführt.');
    }
}

2.3 Entscheidung, wann welcher Log-Level verwendet wird

• DEBUG: Für detaillierte Informationen während der Entwicklung.
• INFO: Für allgemeine Informationen über den Ablauf der Anwendung.
• WARNING: Für potenzielle Probleme, die Aufmerksamkeit erfordern.
• ERROR: Für Fehler, die behandelt werden, aber die Ausführung beeinträchtigen.
• CRITICAL/ALERT/EMERGENCY: Für schwerwiegende Fehler, die sofortige Maßnahmen erfordern.

3. Verwendung des Symfony Profilers und der Debug Toolbar

3.1 Was ist der Symfony Profiler?

Der Symfony Profiler ist ein Werkzeug, das detaillierte Informationen über jede Anfrage sammelt und präsentiert. Er hilft Entwicklern, Leistungsprobleme zu identifizieren, Datenbankenabfragen zu analysieren und vieles mehr.

3.2 Aktivieren des Profilers

Der Profiler ist standardmäßig in der Entwicklungsumgebung aktiviert.

Konfiguration:

# config/packages/web_profiler.yaml
web_profiler:
    toolbar: true
    intercept_redirects: false

3.3 Verwendung der Debug Toolbar

Die Debug Toolbar erscheint am unteren Rand jeder Seite in der Entwicklungsumgebung und bietet schnelle Informationen:

• Zeitauslastung: Gesamtzeit der Anfrage.
• Speicherauslastung: Verwendeter Arbeitsspeicher.
• Logs: Anzahl und Level der Logs.
• Datenbank: Anzahl der ausgeführten SQL-Abfragen.
• Routen: Aktuelle Route und Controller.
• HTTP-Status: HTTP-Antwortcode.

3.4 Zugriff auf den Profiler

Klicken Sie auf die Debug Toolbar, um den Profiler zu öffnen, oder besuchen Sie /_profiler.

3.5 Analyse von Datenbankabfragen

Im Profiler können Sie unter dem Tab "Doctrine" alle ausgeführten SQL-Abfragen einsehen, ihre Ausführungszeit und potenzielle Probleme wie N+1-Abfragen identifizieren.

3.6 Überprüfung von Logs

Unter dem Tab "Logs" können Sie alle protokollierten Nachrichten sehen, gefiltert nach Level.

4. Fehlerbehandlung und Ausnahme-Management

4.1 Umgang mit Ausnahmen

Symfony bietet einen strukturierten Ansatz für die Behandlung von Ausnahmen.

Beispiel:

// src/Controller/ExceptionController.php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ExceptionController extends AbstractController
{
    #[Route('/exception', name: 'exception')]
    public function index(): Response
    {
        throw new \Exception('Dies ist eine Test-Ausnahme.');
    }
}

4.2 Anzeigen von Fehlermeldungen

• Entwicklungsumgebung: Zeigt detaillierte Fehlerseiten mit Stack-Traces.
• Produktionsumgebung: Zeigt generische Fehlerseiten ohne sensible Informationen.

4.3 Anpassen von Fehlerseiten

Erstellen Sie Templates in templates/bundles/TwigBundle/Exception/:

• error404.html.twig: Für 404-Fehler.
• error500.html.twig: Für 500-Fehler.
• error.html.twig: Standardfehlerseite.

4.4 Ausnahme-Listener

Sie können eigene Listener erstellen, um auf Ausnahmen zu reagieren.

Beispiel:

// src/EventListener/ExceptionListener.php

namespace App\EventListener;

use Psr\Log\LoggerInterface;
use Symfony\Component\HttpKernel\Event\ExceptionEvent;

class ExceptionListener
{
    private LoggerInterface $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;
    }

    public function onKernelException(ExceptionEvent $event)
    {
        $exception = $event->getThrowable();
        $this->logger->error('Eine Ausnahme ist aufgetreten: ' . $exception->getMessage());
    }
}

Registrierung des Listeners:

# config/services.yaml

services:
    App\EventListener\ExceptionListener:
        tags:
            - { name: kernel.event_listener, event: kernel.exception }

5. Debugging-Techniken

5.1 Verwenden von dump() und dd()

• dump($variable): Gibt die Struktur und den Inhalt einer Variablen aus.
• dd($variable): Dump and Die – gibt die Variable aus und stoppt die Ausführung.

Beispiel:

public function index()
{
    $data = ['name' => 'Symfony', 'version' => 5];
    dump($data);
    // ...
}

5.2 Verwendung von Xdebug

Xdebug ist eine PHP-Erweiterung, die erweiterte Debugging-Funktionen bereitstellt.

Installation:

• Installieren Sie Xdebug entsprechend Ihrer PHP-Version.
• Konfigurieren Sie Ihre php.ini:

[Xdebug]
zend_extension="path/to/xdebug.so"
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_port=9003
xdebug.client_host=127.0.0.1

• Konfigurieren Sie Ihren IDE/Editor (z. B. PHPStorm, Visual Studio Code) für Xdebug.

5.3 Breakpoints setzen und Schritt-für-Schritt-Debugging

• Setzen Sie Breakpoints in Ihrem Code.
• Starten Sie eine Debugging-Session.
• Verwenden Sie Ihre IDE, um den Code zu durchlaufen, Variablen zu inspizieren und den Ablauf zu verstehen.

5.4 Profiling mit Xdebug und Blackfire

Blackfire ist ein Profiler, der tiefgehende Einblicke in die Performance Ihrer Anwendung bietet.

Verwendung von Blackfire:

• Registrieren Sie sich bei Blackfire.io.
• Installieren Sie das Blackfire Probe auf Ihrem Server.
• Installieren Sie das Blackfire CLI Tool.
• Führen Sie Profiling-Analysen durch:

blackfire run php bin/console

5.5 Verwendung von LoggerInterface für Debugging

Sie können den Logger auch für Debugging-Zwecke verwenden.

Beispiel:

public function index(LoggerInterface $logger)
{
    $logger->debug('Aktueller Benutzer: ' . $this->getUser()->getUsername());
    // ...
}

Zusammenfassung

• Monolog-Konfiguration: Passen Sie Ihre Logging-Strategie an, um relevante Informationen zu erfassen.
• Log-Level verstehen: Nutzen Sie die passenden Log-Level, um die Dringlichkeit von Nachrichten zu kennzeichnen.
• Symfony Profiler und Debug Toolbar: Nutzen Sie diese Werkzeuge, um Performance-Probleme zu identifizieren und detaillierte Informationen über Anfragen zu erhalten.
• Fehlerbehandlung: Implementieren Sie eine robuste Fehlerbehandlung und passen Sie Fehlerseiten an.
• Debugging-Techniken: Verwenden Sie Tools wie dump(), Xdebug und Blackfire, um Ihren Code effektiv zu debuggen.

Weiterführende Ressourcen

How to Customize Error Pages

The Debug Component

How to Optimize your Development Environment for Debugging