Konfiguration - Symfony

3 Min. Lesezeit Aktualisiert: 11.09.2026

Auf dieser Seite Die vollständige Konfiguration
  1. Die vollständige Konfiguration
  2. Umgebungen
  3. Was das Bundle registriert
  4. Was nicht gemeldet werden sollte
  5. Benutzerkontext und Datenschutz
  6. Melden aus eigenem Code
  7. Messenger und langlebige Prozesse
  8. Den privaten Schlüssel schützen

Die vollständige Konfiguration

SchlüsselStandardBedeutung
environment%kernel.environment%Umgebungsspalte im Panel
releasenullVersion der ausgelieferten Anwendung
sample_rate1.0Anteil der gesendeten Fehlerereignisse
traces_sample_rate0.0Anteil der gesendeten Transaktionen; 0 deaktiviert die Messung
send_default_piifalsehängt IP-Adresse und User-Agent an
send_default_usertruehängt den authentifizierten Benutzer an
ignore_exceptions[]Klassen, die nie gemeldet werden
ignore_transactions['/_wdt', '/_profiler']nie gemessene Pfad-Präfixe
options{}direkt an das SDK weitergegeben

Umgebungen

Jede Umgebung sollte unter einem eindeutigen Namen berichten - production, staging, preview. Der Name ist eine Spalte im Panel und ein Filter in der Fehlerliste; ohne ihn sieht ein Produktionsausfall genauso aus wie ein Fehler, den jemand im Test ausgelöst hat. Lass die lokale Umgebung ohne Zugangsdaten: ohne Token und Schlüssel lädt die Integration und bleibt still - ein eigener Schalter ist nicht nötig.

Was das Bundle registriert

ListenerEreignisWirkung
ExceptionListenerkernel.exception (-128)meldet die Ausnahme, an der die Anfrage tatsächlich gescheitert ist
TracingListenerkernel.request / kernel.terminateeine Transaktion pro Hauptanfrage
UserListenerkernel.controllerhängt den authentifizierten Benutzer an
ConsoleErrorListenerconsole.errormeldet fehlgeschlagene Befehle, markiert mit dem Befehlsnamen

Die letzten beiden registrieren sich nur, wenn symfony/security-core und symfony/console installiert sind. Die Priorität -128 bei kernel.exception ist beabsichtigt: gemeldet wird die Ausnahme, die alle Listener der Anwendung passiert hat, und nicht eine, die ein anderer Listener gleich in eine gültige Antwort verwandelt.

Was nicht gemeldet werden sollte

4xx-Antworten sind in Symfony Ausnahmen; ohne Ausschlüsse füllt sich das Panel mit Ereignissen, die keine Störungen sind:

yaml
ray:
    ignore_exceptions:
        - Symfony\Component\HttpKernel\Exception\NotFoundHttpException
        - Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException
        - Symfony\Component\Security\Core\Exception\AccessDeniedException

ignore_transactions arbeitet mit Pfad-Präfixen und überspringt standardmäßig /_wdt und /_profiler - ohne das wäre die Hälfte der Transaktionen einer dev-Umgebung der Profiler selbst.

Benutzerkontext und Datenschutz

Nutzt die Anwendung die Security-Komponente, hängt UserListener den authentifizierten Benutzer an. send_default_user: false schaltet das ab. IP-Adresse und User-Agent sind ein eigener Schalter (send_default_pii) und gehen standardmäßig nicht hinaus - sie betreffen auch anonyme Anfragen.

Melden aus eigenem Code

Der Hub steht als Dock\Ray\State\HubInterface und als öffentlicher Service ray.hub bereit:

php
use Dock\Ray\State\HubInterface;

final class ImportService
{
    public function __construct(private HubInterface $ray)
    {
    }

    public function import(): void
    {
        try {
            $this->run();
        } catch (\Throwable $exception) {
            $this->ray->captureException($exception);

            throw $exception;
        }
    }
}

Die globalen SDK-Funktionen wirken ebenfalls - das Bundle installiert seinen Hub beim Bootstrapping des Containers als den aktuellen.

Messenger und langlebige Prozesse

Der Hub ist ein Container-Singleton, ein Worker behält seinen Client also für die ganze Laufzeit. Nachrichten, an denen der Worker selbst stirbt, werden über console.error gemeldet; ein Melden pro Nachricht braucht eigene Messenger-Middleware um captureException().

Den privaten Schlüssel schützen

Der private Schlüssel ist ein Projektgeheimnis, keine Kennung. Bewahre ihn in Umgebungsvariablen, in einem Secret-Manager oder in der Serverkonfiguration auf - niemals im Repository, in Logs, auf einem Screenshot oder in Code, der an den Browser geht. Ein Projekt kann mehrere Schlüssel haben, deshalb sollten Produktion und Staging je eigene bekommen: jeder lässt sich einzeln widerrufen, ohne die übrigen zu unterbrechen. Der Verdacht, dass ein Schlüssel abgeflossen ist, genügt, um ihn zu widerrufen und einen neuen zu erzeugen.

Weiterlesen

DockRay Newsletter

Anwendungssicherheit in Ihrem Postfach

Wichtige Schwachstellen, konkrete Empfehlungen und praktische Tipps für Ihre Anwendungen. Wählen Sie Ihre Technologien und verfolgen Sie, was für Ihr Projekt relevant ist.

  • Eine tägliche Zusammenfassung neuer Schwachstellen, auch kritischer.
  • Benachrichtigungen über wichtige Updates.
  • Praktische Tipps zur Sicherheit und Überwachung von Anwendungen.

Leer lassen, um Meldungen zu allen Technologien zu erhalten.

Kostenlos anmelden. In jeder E-Mail mit einem Klick abmelden.