Kowal_Sentry: Installations- und Konfigurationsanleitung

Zweck des Moduls

Kowal_Sentryintegriert Magento 2 mit Sentry und ermöglicht das Monitoring von:

• PHP-Backend-Fehlern,
• JavaScript-Fehlern im Storefront und optional im Admin-Panel,
• HTTP-, CLI- und Cron-Transaktionen,
• Checkout-Breadcrumbs,
• Session Replay,
• User Feedback,
• Release-Tracking und Vorbereitung für Source Maps.

Das Modul wurde als Composer-Paket entwickelt und sollte aus dem Verzeichnisvendor/kowal/module-sentry.

Anforderungen

• Magento Open Source / Adobe Commerce 2.4.x
• PHP 8.1+
• Zugriff auf Sentry und mindestens ein Projekt
• E-Mail-Adresse des Kunden und Lizenz-Token für das Kowal Composer-Repository

Installation

Die folgenden Befehle wurden ausREADME.md.

Die Zugangsdaten zum Composer-Repository (E-Mail-Adresse des Kunden und Lizenz-Token) erhalten Sie nach dem Kauf per E-Mail. Sie sind außerdem nach dem Login im Kundenbereich unter kowal.storeverfügbar. Ersetzen Sie TWOJ_EMAIL_KLIENTA durch die E-Mail-Adresse Ihres Kontos und TWOJ_TOKEN durch den erhaltenen Token. Führen Sie die Befehle im Magento-Stammverzeichnis aus.

composer config repositories.kowal composer https://repo.kowal.store
composer config http-basic.repo.kowal.store "TWOJ_EMAIL_KLIENTA" "TWOJ_TOKEN"
composer require kowal/module-sentry
bin/magento module:enable Kowal_Sentry
bin/magento setup:upgrade
bin/magento cache:flush

Wichtig

• Das Composer-Paket darf nur ausvendor/kowal/module-sentry.
• Dasselbe Modul darf nicht gleichzeitig unterapp/code/Kowal/Sentry.
• Nach der Installation finden Sie die Konfiguration unter:

Stores -> Configuration -> Kowal -> Sentry

Schnellstart

Minimale Konfiguration zum Starten des Moduls:

1. Legen SieEnable Module = Yes.
2. Legen SieEnvironmentfest, z. B.productionoderstaging.
3. Aktivieren SieEnable Backend Monitoringund fügen SieBackend DSN.
4. Wenn Sie das Frontend überwachen möchten, aktivieren SieEnable Frontend Monitoringund fügen SieFrontend DSN.
5. Speichern Sie die Konfiguration und leeren Sie bei Bedarf den Cache der jeweiligen Umgebung.

Wo Sie die Daten aus Sentry finden

DSN

Die DSN finden Sie normalerweise hier:

Settings -> Projects -> [projekt] -> Client Keys (DSN)

In die FelderBackend DSNundFrontend DSN fügen Sie ausschließlich die DSN-URL ein, zum Beispiel:

https://examplePublicKey@o0000000000000000.ingest.de.sentry.io/0000000000000000

Fügen Sie nicht das vollständige Snippet ein:

\Sentry\init([
    'dsn' => 'https://examplePublicKey@o0000000000000000.ingest.de.sentry.io/0000000000000000',
]);

Organization

Den Organisations-Slug können Sie am einfachsten aus der URL des Sentry-Panels ablesen, zum Beispiel:

https://sentry.io/settings/acme/projects/shop-frontend/

In diesem Beispiel gilt:

• acmeistOrganization
• shop-frontendistProject Slug

Project Slug

Sie finden ihn:

• in der Projekt-URL im Sentry-Panel,
• oder unterSettings -> Projects -> [projekt] -> Details

Auth-Token für Source Maps

Wenn Siesentry-cliverwenden, sollte der Token außerhalb von Magento gespeichert werden, beispielsweise in der Umgebungsvariable:

SENTRY_AUTH_TOKEN

Token erstellen:

• Settings -> Custom Integrations
• oderUser Settings -> Personal Tokens

Überprüfung nach der Installation

Nach der Grundkonfiguration können Sie prüfen, ob das Modul aktiv ist und das SDK funktioniert. Die folgenden Smoke-Test-Befehle wurden ausREADME.md.

Nach der Aktivierung vonEnable Test Commands:

bin/magento kowal:sentry:test:error
bin/magento kowal:sentry:test:transaction
bin/magento kowal:sentry:test:checkin
bin/magento kowal:sentry:test:log

Konfiguration im Magento-Panel

Pfad:

Stores -> Configuration -> Kowal -> Sentry

Nachfolgend finden Sie eine Beschreibung der einzelnen Bereiche, Optionen und Einstellungsvarianten.

Bereich General

Dieser Bereich steuert die Aktivierung des Moduls, die Umgebung und die Berechnung vonrelease.

Enable Module

• Yes: aktiviert das Modul global.
• No: Backend und Frontend werden nicht initialisiert, selbst wenn andere Optionen aktiviert sind.

Empfehlung:

• Yesin der Umgebung, aus der Sie Daten an Sentry senden möchten.

Environment

Beispiele:

• production
• staging
• development

Varianten:

• ein gemeinsamer Name für die gesamte Instanz,
• unterschiedliche Werte pro Website/Store View, wenn Ereignisse getrennt werden sollen.

Empfehlung:

• ohne Leerzeichen und Schrägstriche,
• verwenden Sie eine einheitliche Benennung für Backend, Frontend und CI/CD.

Release Strategy

Verfügbare Varianten:

• manual: Release stammt aus dem FeldRelease Name Override
• env: Release wird aus Umgebungsvariablen übernommen
• file: Release wird aus einer Datei gelesen
• generated: Release wird automatisch vom Modul zusammengesetzt

Wann verwenden:

• manual: bei manueller Release-Eingabe, eher als Ausweichlösung oder bei einfachen Implementierungen
• env: ideal für CI/CD, wenn das Deployment den Release übergibt
• file: wenn das Deployment die Versionskennung in eine gemeinsam genutzte Datei schreibt
• generated: für den Einstieg, wenn noch keine ausgereifte Release-Pipeline vorhanden ist

Unterstützte Umgebungsvariablen:

• KOWAL_SENTRY_RELEASE
• SENTRY_RELEASE
• RELEASE_NAME
• GIT_COMMIT

Release Name Override

Wird nur bei der Strategiemanual.

Beispiel:

magento-store@2.4.7-p1+20260410.1

Empfehlung:

• Beim Upload der Source Maps sollte exakt derselbe Wert verwendet werden.

Project Name

Hilfsname des Projekts in den Modulkontexten. Dies ist nicht derProject Slugaus Sentry.

Varianten:

• Name der Shop-Instanz,
• Name der Shop-Gruppe,
• Name des internen Projekts.

Debug Mode

• Yes: ausführlichere Diagnoseprotokollierung
• No: Produktionsmodus

Empfehlung:

• Noin der Produktionsumgebung,
• Yesvorübergehend zur Diagnose der Konfiguration.

Enable Test Commands

• Yes: stellt Testbefehle bereitbin/magento
• No: blendet sie im Normalbetrieb aus

Empfehlung:

• Yesauf Staging oder während Tests,
• Noin der dauerhaften Produktivkonfiguration.

Abschnitt Backend SDK

Betrifft das PHP-SDK für Storefront-HTTP, Administration, API, Cron und CLI.

Enable Backend Monitoring

• Yes: aktiviert das Backend-Monitoring
• No: das Backend sendet keine Fehler und Traces an Sentry

Backend DSN

Dies ist die primäre DSN für das PHP SDK.

Varianten:

• separates Sentry-Projekt nur für das Backend
• dasselbe Projekt für Backend und Frontend

Empfehlung:

• Bei ausgereifteren Implementierungen sollten getrennte Projekte für Backend und Frontend verwendet werden,
• bei kleineren Installationen kann zunächst ein gemeinsames Projekt verwendet werden.

Error Sample Rate

Bereich:0-1

Beispiele:

• 1: alle Fehler senden
• 0.5: ungefähr die Hälfte senden
• 0.25: ungefähr 25 % senden

Empfehlung:

• normalerweise1.0für Fehler, zumindest zu Beginn.

Trace Sample Rate

Bereich:0-1

Beispiele:

• 0.05: niedriges Sampling, geeignet für Produktionsumgebungen mit hohem Traffic
• 0.1: sinnvoller Ausgangspunkt
• 0.2: mehr Daten bei höherem Volumen

Empfehlung:

• in der Produktionsumgebung normalerweise0.05-0.2, abhängig von Traffic und Sentry-Tarif.

Profile Sample Rate

Bereich:0-1

Varianten:

• 0: Profiling deaktiviert
• niedriger Wert, beispielsweise0.01: regelmäßige Performance-Diagnose

Empfehlung:

• 0oder ein sehr niedriger Wert in der Produktionsumgebung.

Enable Logs

• Yes: sendet Structured Logs
• No: keine Logs in Sentry

Wann aktivieren:

• wenn Sie Logs mit Traces und Fehlern korrelieren möchten.

Enable Metrics API

• Yes: aktiviert die Modulfassade für Metriken
• No: modulbezogene Metriken sind nicht aktiv

Hinweis:

• Das aktuellesentry/sentry 4.24.xbehandelt Backend Metrics als auslaufende API beziehungsweise alsno-op.

Enable Cron Monitoring

• Yes: sendet Check-ins und Cron-Transaktionen
• No: Cron-Jobs werden nicht durch Sentry überwacht

Die Daten finden Sie in Sentry in den Bereichen:

• Crons
• Monitors

Enable CLI Monitoring

• Yes: überwacht Befehlebin/magento
• No: keine Überwachung von CLI-Prozessen

Hilfreich für:

• Importe,
• Neuindexierung,
• individuelle Integrationsbefehle.

Enable Adminhtml Monitoring

• Yes: überwacht Requests des Admin-Panels
• No: beschränkt das Backend auf Storefront, API, Cron und CLI

Enable API Monitoring

• Yes: überwacht REST, GraphQL und andere Endpoints
• No: schließt den Integrationsbereich vom Monitoring aus

Bereich Frontend SDK

Betrifft das Browser SDK, das im Storefront und optional im Admin-Panel geladen wird.

Enable Frontend Monitoring

• Yes: lädt das Browser SDK
• No: das Frontend sendet keine Daten an Sentry

Frontend DSN

Varianten:

• ein eigenes Frontend-Projekt
• dieselbe DSN wie im Backend
• ein leeres Feld, damit das Modul einen Fallback versucht aufBackend DSN

Empfehlung:

• langfristig ein eigenes Frontend-Projekt für übersichtliche Issues, Replay und Performance.

Enable Storefront JS

• Yes: Browser SDK ist im Storefront aktiv
• No: kein SDK im öffentlichen Bereich des Shops

Enable Admin JS

• Yes: Browser SDK ist auch im Admin-Panel aktiv
• No: JS-Monitoring ist auf den Storefront beschränkt

Empfehlung:

• nur aktivieren, wenn Sie tatsächlich JS-Probleme im Admin-Bereich diagnostizieren.

JS Trace Sample Rate

Bereich:0-1

Beispiele:

• 0.01: sehr vorsichtig
• 0.05: guter Ausgangspunkt für die Produktionsumgebung
• 0.1: mehr Daten und höheres Volumen

JS Replay Session Sample Rate

Bereich:0-1

Beispiele:

• 0: keine vollständigen Replays
• 0.01: sicherer Ausgangspunkt
• 0.05: mehr Daten für die Analyse von UX und Fehlern

JS Replay On Error Sample Rate

Bereich:0-1

Beispiele:

• 1: Replay nach jedem Fehler in der Sitzung
• 0.5: Replay nach einem Teil der Fehler

Empfehlung:

• häufig ein besserer Ausgangspunkt als ein hohes Sampling sämtlicher Sitzungen.

Enable Session Replay

• Yes: aktiviert Replay
• No: keine Sitzungsaufzeichnung

Empfehlung:

• nur zusammen mit einer umfassenden Maskierung von Checkout- und Zahlungsdaten aktivieren.

Enable User Feedback Widget

• Yes: das Feedback-Widget ist verfügbar
• No: das Widget wird nicht geladen

Hinweis:

• abhängig vom Sentry-Tarif und -Konto kann die Funktion als Beta oder Experimental gekennzeichnet sein.

Enable Checkout Instrumentation

• Yes: fügt Checkout-Breadcrumbs und -Tags hinzu
• No: kein zusätzlicher Checkout-Kontext

Empfehlung:

• normalerweise sollte diese Option aktiviert bleiben.

Enable Ajax Instrumentation

• Yes: Breadcrumbs für AJAX / fetch / XHR
• No: weniger Kontext für Frontend-Probleme

Browser SDK CDN URL

Verweist standardmäßig auf das offizielle Sentry-Bundle.

Varianten:

• Standard-URL des Moduls
• eigener CDN-Mirror
• festgelegtes Bundle oder eine bestimmte Version

Nur ändern, wenn:

• Sie die SDK-Version festschreiben,
• Sie eigene CSP-Regeln verwenden,
• Sie Assets spiegeln.

Bereich Privacy / Security

Dieser Bereich dient dazu, das Risiko der Übertragung vertraulicher Daten zu minimieren.

Send Default PII

• Yes: das SDK kann den standardmäßigen Satz an Benutzer- und Request-Daten senden
• No: restriktivere Datenschutzrichtlinie

Empfehlung:

• normalerweiseNo.

Anonymize IP

• Yes: vollständige IP-Adresse nicht übertragen
• No: Standardverhalten beibehalten

Empfehlung:

• normalerweiseYes.

Mask Customer Data

• Yes: maskiert Kundendaten
• No: geringerer Datenschutz

Empfehlung:

• in der Produktionsumgebung praktisch immerYes.

Mask Checkout Fields

• Yes: maskiert Checkout-Felder
• No: Risiko eines Datenlecks im Checkout

Empfehlung:

• immerYes.

Mask Payment Fields

• Yes: maskiert zahlungsbezogene Felder
• No: sehr riskant

Empfehlung:

• immerYes.

Block Authorization Headers

• Yes: entfernt oder maskiertAuthorizationund Tokens
• No: Risiko der Übertragung von Authentifizierungsdaten

Empfehlung:

• immerYes.

Block Cookies

• Yes: entfernt Cookies aus den Ereignisdaten
• No: höheres Risiko eines Lecks von Sitzungsdaten

Empfehlung:

• normalerweiseYes.

Block POST Bodies

• Yes: entfernt die Bodies vonPOST
• No: sendet mehr Request-Daten

Empfehlung:

• normalerweiseYes, besonders bei Checkout, Anmeldung und Formularen.

Redact Query Params

• Yes: maskiert Query-String-Parameter
• No: der Query String bleibt besser lesbar, ist jedoch weniger sicher

Additional Redacted Keys

Textfeld für zusätzliche zu schwärzende Schlüssel.

Beispiele:

• token
• api_key
• customer_email
• external_customer_id

Sie können die Werte trennen durch:

• Kommas,
• Leerzeichen,
• Zeilenumbrüche.

Replay Mask Selectors

CSS-Selektoren, deren Inhalt in Replay maskiert werden soll.

Beispiele:

• .customer-email
• .field[name*="password"]
• .payment-method

Replay Block Selectors

CSS-Selektoren, die in Replay vollständig blockiert werden sollen.

Beispiele:

• .checkout-container
• .payment-method iframe
• .opc-wrapper

Allowed Domains for Replay Network Details

Liste der Domains, für die Replay Details zu Netzwerk-Requests hinzufügen darf.

Beispiele:

• store.example.com
• api.example.com
• trusted-partner.example

Empfehlung:

• tragen Sie nur eigene und vertrauenswürdige Domains ein.

Bereich Filtering

Dieser Bereich reduziert Rauschen und Ereignisvolumen.

Ignore Exceptions Regex

Eine Regex-Regel pro Zeile.

Anwendungsbeispiele:

• bekannte, harmlose technische Fehler,
• Exceptions aus externen Integrationen, die bereits anderweitig behandelt werden.

Ignore URLs Regex

Eine Regex-Regel pro Zeile.

Beispiele:

• Health-Check-Endpoints,
• Test-Webhooks,
• technische Ressourcen.

Ignore Transactions

Ein Transaktionsname pro Zeile.

Empfehlung:

• zunächst Daten sammeln,
• anschließend wenig wertvolle und wiederkehrende Transaktionen herausfiltern.

Ignore Bots

• Yes: schließt Bot- und Crawler-Traffic aus
• No: überwacht auch automatisierten Traffic

Empfehlung:

• Yesbei hohem SEO-Traffic.

Ignore Health Checks

• Yes: überspringt/health,/status,/pingund ähnliche Requests
• No: solche Requests werden an Sentry übertragen

Ignore Admin Routes

• Yes: reduziert Ereignisse aus dem Admin-Bereich
• No: der Admin-Bereich bleibt überwacht

Ignore Static Resource Errors

• Yes: filtert einen Teil der Asset-Fehler.jsund.css
• No: alle Fehler dieses Typs bleiben sichtbar

Empfehlung:

• normalerweiseYes, wenn Sie das Projekt nach Deployments nicht mit Störmeldungen füllen möchten.

Abschnitt Context

Steuert den Umfang des Geschäftskontexts in Events.

Attach Store Context

• Yes: fügtstore_id,store_code, Shopname und Währung hinzu
• No: kein entsprechender Kontext

Empfehlung:

• Yes, insbesondere bei Multistore.

Attach Website Context

• Yes: fügt Website-Daten hinzu
• No: keine Identifikation auf dieser Ebene

Attach Customer Context

• Yes: fügt anonymisierten Kundenkontext hinzu
• No: keine Daten zum Kundenstatus

Attach Quote Context

• Yes: fügt Warenkorb- oder Quote-Kontext hinzu
• No: weniger Daten für die Checkout-Diagnose

Attach Cart Totals

• Yes: fügt Warenkorbsummen hinzu
• No: schlankeres Ereignis

Empfehlung:

• nur aktivieren, wenn diese Daten tatsächlich bei der Analyse helfen.

Attach Order Context

• Yes: fügt Bestellkontext hinzu
• No: keine Daten zum Order Flow

Besonders nützlich für:

• Invoice,
• Shipment,
• Transaktions-E-Mails,
• ERP- oder OMS-Integrationen.

Attach Product Context

• Yes: fügt grundlegenden Produktkontext hinzu
• No: kein entsprechender Kontext

Attach Category Context

• Yes: fügt grundlegenden Kategoriekontext hinzu
• No: kein entsprechender Kontext

Attach Payment / Shipping Method

• Yes: fügtpayment_methodundshipping_method
• No: weniger Checkout-Daten

Empfehlung:

• ist eine besonders hilfreiche Diagnoseeinstellung.

Attach Module Version

• Yes: fügt die Version hinzu vonKowal_Sentry
• No: ohne diese Information in Events

Attach Magento Version

• Yes: fügt die Magento-Version hinzu
• No: kein Plattformkontext

Attach Deployment Metadata

• Yes: fügt zusätzliche Deployment-Daten hinzu, sofern verfügbar
• No: keine entsprechenden Metadaten

Nützlich, wenn Sie ein Problem schnell mit einem Rollout oder einem bestimmten Build verknüpfen möchten.

Bereich Source Maps / Release

Dieser Bereich verwaltet die für Release und Source Maps benötigten Parameter. Der Upload selbst sollte in CI/CD und nicht während der Magento-Laufzeit erfolgen.

Enable Source Map Upload

• Yes: bestätigt, dass Source Maps organisatorisch verwendet werden
• No: das Modul setzt keine Source Maps in der Konfiguration voraus

Hinweis:

• Dies ist ein Konfigurationsschalter und kein Upload-Mechanismus.

Source Map Upload Mode

Varianten:

• manual: manuelle Befehlesentry-cli
• ci: Upload in der CI/CD-Pipeline
• deploy_hook: Upload im Deployment-Hook

Empfehlung:

• im Produktivbetrieb meistensci.

Assets Base URL

Beispiel:

https://store.example.com/static/frontend

Dieser Wert muss dem entsprechen, was das Browser SDK im Stacktrace sieht. Andernfalls können die Source Maps nicht zugeordnet werden.

Release Dist

Optionalesdistfür das Release.

Beispiele:

• storefront
• admin
• pl-store

Verwenden Sie dies, wenn ein Release mehrere Asset-Varianten besitzt.

Organization

Organisations-Slug, der vonsentry-cliund API verwendet wird.

So finden Sie ihn:

• in der URL des Sentry-Panels,
• zum Beispielhttps://sentry.io/settings/acme/projects/shop-frontend/->acme

Project Slug

Projekt-Slug, der vom Release- und Source-Maps-Workflow verwendet wird.

So finden Sie ihn:

• in der Projekt-URL,
• oderSettings -> Projects -> [projekt] -> Details

Release File Path

Pfad zur Datei mit dem Release-Namen bei der Strategiefile.

Beispiele:

• /var/www/shared/release.txt
• pub/media/deploy/release-id.txt

Bereich User Feedback

Konfiguration des Widgets zur Meldung von Problemen im Browser.

Widget Theme

Varianten:

• light
• dark
• system

Empfehlung:

• normalerweisesystem.

Widget Language

Beispiele:

• pl-PL
• en-US

Empfehlung:

• bei Multistore an die Locale der Store View anpassen.

Auto-open after selected errors

• Yes: nach ausgewählten Frontend-Fehlern kann eine Aufforderung zum Feedback angezeigt werden
• No: das Widget wird nicht automatisch geöffnet

Empfehlung:

• vorsichtig verwenden, um Nutzer nicht zu stark zu beeinträchtigen.

Show on checkout success

• Yes: der Feedback-Trigger kann auf der Bestellbestätigungsseite erscheinen
• No: kein Trigger an dieser Stelle

Show on contact page

• Yes: Trigger oder Widget auf der Kontaktseite
• No: keine Anzeige auf der Kontaktseite

Show in footer

• Yes: dauerhaft sichtbarer Trigger im Footer oder als festes Seitenelement
• No: kein dauerhafter Trigger

Dies ist die einfachste Option, wenn Sie eine SchaltflächeZglos problem.

Custom Trigger Selector

CSS-Selektor eines vorhandenen Elements, das Feedback öffnet.

Beispiele:

• #report-issue
• .js-sentry-feedback

Verwenden Sie dieses Feld, wenn Sie das Widget mit einer eigenen Schaltfläche im Layout oder CMS-Block verknüpfen möchten.

Bereich Cron Monitoring

Dieser Bereich steuert Check-ins und Monitore für Magento-Cron-Jobs.

Enable auto-registration of configured cron jobs

• Yes: der erste Check-in kann einen Monitor in Sentry erstellen oder aktualisieren
• No: das Modul sendet Check-ins ohne automatische Monitorkonfiguration

Empfehlung:

• Yes, wenn Sie ein kontrolliertes Deployment und bewusst definierte Jobs verwenden.

Monitored job codes

Liste der Magento-job_code-Werte.

Sie können die Werte trennen durch:

• Kommas,
• Leerzeichen,
• Zeilenumbrüche.

Varianten:

• leeres Feld: alle Cron-Jobs überwachen
• Liste ausgewählterjob_code-Werte: nur kritische Aufgaben überwachen

Beispiele:

• sales_clean_quotes
• catalog_product_alert
• indexer_reindex_all_invalid

Timeout threshold per job

Eine Regel pro Zeile:

job_code:minutes

Beispiel:

catalog_product_alert:10

Verwenden Sie diese Einstellung, wenn ein Cron-Job unregelmäßig ausgeführt wird und Sie Fehlalarme reduzieren möchten.

Max runtime per job

Eine Regel pro Zeile:

job_code:minutes

Beispiel:

indexer_reindex_all_invalid:30

Nach Überschreiten des Grenzwerts kann Sentry den Monitor als problematisch markieren.

Check-in slug prefix

Beispiel:

magento-

Nützlich, wenn eine Sentry-Organisation mehrere Magento-Instanzen überwacht und Namenskollisionen vermieden werden sollen.

Empfohlene Konfigurationsprofile

Sicherer Einstieg in der Produktionsumgebung

• Enable Module = Yes
• Enable Backend Monitoring = Yes
• Enable Frontend Monitoring = Yes
• Error Sample Rate = 1
• Trace Sample Rate = 0.05oder0.1
• JS Trace Sample Rate = 0.01oder0.05
• Enable Session Replay = Yes
• JS Replay Session Sample Rate = 0.01
• JS Replay On Error Sample Rate = 1
• Send Default PII = No
• Anonymize IP = Yes
• Mask Customer Data = Yes
• Mask Checkout Fields = Yes
• Mask Payment Fields = Yes
• Block Authorization Headers = Yes
• Block Cookies = Yes
• Block POST Bodies = Yes
• Redact Query Params = Yes
• Ignore Bots = Yes
• Ignore Health Checks = Yes

Diagnoseprofil für Staging

• höhereTrace Sample Ratefest, z. B.0.2
• höhereJS Trace Sample Ratefest, z. B.0.1
• vorübergehendDebug Mode = Yes
• Enable Test Commands = Yes
• Replay vorsichtig verwenden: Maskierung und Blockierungen weiterhin beibehalten

Minimale Variante nur für das Backend

• Enable Backend Monitoring = Yes
• Backend DSNausgefüllt
• Enable Frontend Monitoring = No

Dies ist ein guter erster Schritt, wenn Sie zunächst das Monitoring von Exceptions und Cron-Jobs auf der PHP-Seite aktivieren möchten.

Häufigste Konfigurationsfehler

• Einfügen des vollständigen Snippets\Sentry\init(...)anstelle der DSN.
• Gleichzeitiges Vorhandensein des Moduls untervendor/undapp/code/.
• Unterschiedlicherelease-Werte zwischen Ereignissen und Source Maps.
• Zu aggressives Replay-Sampling in der Produktionsumgebung.
• Deaktivierung der Maskierung von Checkout- und Zahlungsdaten.
• Beispiel-DSN in der aktiven Konfiguration belassen.

Zusammenfassung

Am sichersten ist es, mit Backend-Monitoring, vorsichtigem Frontend-Monitoring und strengen Datenschutzeinstellungen zu beginnen. Sobald die Daten in Sentry stabil und übersichtlich sind, können Trace Sampling, Replay und der Umfang des Geschäftskontexts schrittweise erhöht werden.