Kowal_Sentry: Installations- und Konfigurationsanleitung

Zweck des Moduls

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

• PHP-Backend-Fehlern,
• JavaScript-Fehlern im Storefront und optional im Adminbereich,
• 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 vorbereitet und sollte aus dem Verzeichnis vendor/kowal/module-sentry heraus funktionieren.

Anforderungen

• Magento Open Source / Adobe Commerce 2.4.x
• PHP 8.1+
• Zugriff auf Sentry und mindestens ein Projekt
• GitHub-Token, wenn das Repository über ein privates vcs installiert wird

Installation

Die folgenden Befehle wurden aus README.md kopiert.

composer config repositories.sentry vcs https://github.com/kowalco/sentrycomposer config --global --auth github-oauth.github.com composer require kowal/module-sentrybin/magento module:enable Kowal_Sentrybin/magento setup:upgradebin/magento cache:flush

Wichtig

• Das Composer-Paket soll ausschließlich aus vendor/kowal/module-sentry funktionieren.
• Dasselbe Modul sollte nicht gleichzeitig in app/code/Kowal/Sentry liegen.
• Nach der Installation finden Sie die Konfiguration unter:

Stores -> Configuration -> Kowal -> Sentry

Schnellstart

Minimale Konfiguration, die zum Starten des Moduls erforderlich ist:

1. Setzen Sie Enable Module = Yes.
2. Setzen Sie Environment, z. B. production oder staging.
3. Aktivieren Sie Enable Backend Monitoring und fügen Sie Backend DSN ein.
4. Wenn Sie das Frontend überwachen möchten, aktivieren Sie Enable Frontend Monitoring und fügen Sie Frontend DSN ein.
5. Speichern Sie die Konfiguration und leeren Sie den Cache, falls dies in der jeweiligen Umgebung erforderlich ist.

Woher Sie die Daten aus Sentry erhalten

DSN

Die DSN finden Sie üblicherweise hier:

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

In die Felder Backend DSN und Frontend DSN fügen Sie nur die reine DSN-URL ein, z. B.:

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

Fügen Sie nicht das gesamte Snippet ein:

Sentryinit([ '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, z. B.:

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

In diesem Beispiel:

• acme ist Organization
• shop-frontend ist Project Slug

Project Slug

Sie können ihn ablesen:

• aus der Projekt-URL im Sentry-Panel,
• oder unter Settings -> Projects -> [projekt] -> Details

Auth Token für Source Maps

Wenn Sie sentry-cli verwenden, bewahren Sie den Token am besten außerhalb von Magento auf, z. B. in einer Umgebungsvariable:

SENTRY_AUTH_TOKEN

Token-Erstellung:

• Settings -> Custom Integrations
• oder User Settings -> Personal Tokens

Verifizierung nach der Installation

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

Nach Aktivierung von Enable Test Commands:

bin/magento kowal:sentry:test:errorbin/magento kowal:sentry:test:transactionbin/magento kowal:sentry:test:checkinbin/magento kowal:sentry:test:log

Konfiguration im Magento-Panel

Pfad:

Stores -> Configuration -> Kowal -> Sentry

Nachfolgend finden Sie eine Beschreibung der einzelnen Sektionen, Möglichkeiten und Einstellungsvarianten.

Sektion General

Diese Sektion steuert die Aktivierung des Moduls, die Umgebung und die Berechnung von release.

Enable Module

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

Empfehlung:

• Yes in 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 Sie Events trennen möchten.

Empfehlung:

• ohne Leerzeichen und ohne Schrägstriche,
• verwenden Sie eine konsistente Benennung zwischen Backend, Frontend und CI/CD.

Release Strategy

Verfügbare Varianten:

• manual: release stammt aus dem Feld Release Name Override
• env: release wird aus Umgebungsvariablen abgerufen
• file: release wird aus einer Datei gelesen
• generated: release wird automatisch durch das Modul zusammengesetzt

Wann verwenden:

• manual: wenn Sie release manuell eintragen möchten, eher für Notfälle oder einfache Implementierungen
• env: ideal in CI/CD, wenn release durch das Deployment übergeben wird
• file: geeignet, wenn das Deployment den Versionsidentifikator in eine gemeinsam genutzte Datei schreibt
• generated: gut für den Einstieg, wenn Sie noch keine ausgereifte Release-Pipeline haben

Unterstützte Umgebungsvariablen:

• KOWAL_SENTRY_RELEASE
• SENTRY_RELEASE
• RELEASE_NAME
• GIT_COMMIT

Release Name Override

Wird nur bei der Strategie manual verwendet.

Beispiel:

magento-store@2.4.7-p1+20260410.1

Empfehlung:

• genau derselbe Wert sollte beim Upload der Source Maps verwendet werden.

Project Name

Hilfsname des Projekts in den Kontexten des Moduls. Dies ist nicht der Project Slug aus Sentry.

Varianten:

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

Debug Mode

• Yes: ausführlichere Diagnose-Protokollierung
• No: Produktionsmodus

Empfehlung:

• No in der Produktion,
• Yes vorübergehend, wenn Sie die Konfiguration diagnostizieren.

Enable Test Commands

• Yes: stellt Testbefehle bin/magento bereit
• No: blendet sie im normalen Betrieb aus

Empfehlung:

• Yes auf Staging oder für die Dauer von Tests,
• No in der dauerhaften Produktionskonfiguration.

Sektion Backend SDK

Betrifft das PHP SDK, das von Storefront HTTP, Admin, API, Cron und CLI verwendet wird.

Enable Backend Monitoring

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

Backend DSN

Dies ist die grundlegende 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 separate Backend- und Frontend-Projekte verwenden,
• bei kleineren Installationen kann mit einem gemeinsamen Projekt begonnen werden.

Error Sample Rate

Bereich: 0-1

Beispiele:

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

Empfehlung:

• üblicherweise 1.0 für Fehler, zumindest zu Beginn.

Trace Sample Rate

Bereich: 0-1

Beispiele:

• 0.05: niedriges Sampling, gut für Produktion mit hohem Traffic
• 0.1: sinnvoller Startpunkt
• 0.2: mehr Daten auf Kosten des Volumens

Empfehlung:

• in der Produktion üblicherweise 0.05-0.2, abhängig von Traffic und Sentry-Plan.

Profile Sample Rate

Bereich: 0-1

Varianten:

• 0: Profiling deaktiviert
• niedriger Wert, z. B. 0.01: regelmäßige Performance-Diagnose

Empfehlung:

• 0 oder sehr niedriger Wert in der Produktion.

Enable Logs

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

Wann aktivieren:

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

Enable Metrics API

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

Hinweis:

• das aktuelle sentry/sentry 4.24.x behandelt Backend Metrics als auslaufende API / no-op.

Enable Cron Monitoring

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

Die Daten finden Sie in Sentry in der Sektion:

• Crons
• Monitors

Enable CLI Monitoring

• Yes: überwacht bin/magento-Befehle
• No: kein Monitoring von CLI-Prozessen

Nützlich für:

• Importe,
• Reindexierung,
• individuelle Integrationsbefehle.

Enable Adminhtml Monitoring

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

Enable API Monitoring

• Yes: überwacht REST, GraphQL und andere Endpoints
• No: trennt den Integrationsteil vom Monitoring

Sektion 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:

• separates Frontend-Projekt
• dieselbe DSN wie Backend
• leeres Feld, damit das Modul den Fallback auf Backend DSN versucht

Empfehlung:

• zielgerichtet ein separates Frontend-Projekt, wenn Sie übersichtliche Issues, Replay und Performance wünschen.

Enable Storefront JS

• Yes: Browser SDK läuft im Storefront
• No: kein SDK im öffentlichen Shop-Bereich

Enable Admin JS

• Yes: Browser SDK läuft auch im Adminbereich
• No: JS-Monitoring ist auf das Storefront beschränkt

Empfehlung:

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

JS Trace Sample Rate

Bereich: 0-1

Beispiele:

• 0.01: sehr vorsichtig
• 0.05: guter Start für die Produktion
• 0.1: mehr Daten, größeres Volumen

JS Replay Session Sample Rate

Bereich: 0-1

Beispiele:

• 0: keine vollständigen Replays
• 0.01: sicherer Start
• 0.05: mehr Daten für UX- und Fehleranalyse

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:

• oft ein besserer Start als ein hohes Sampling aller Sitzungen.

Enable Session Replay

• Yes: aktiviert Replay
• No: keine Sitzungsaufzeichnung

Empfehlung:

• zusammen mit starker Maskierung von Checkout und Zahlung aktivieren.

Enable User Feedback Widget

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

Hinweis:

• je nach Sentry-Plan und -Konto kann die Funktion als Beta / Experimental gekennzeichnet sein.

Enable Checkout Instrumentation

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

Empfehlung:

• in der Regel lohnt es sich, diese Option aktiviert zu lassen.

Enable Ajax Instrumentation

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

Browser SDK CDN URL

Standardmäßig verweist sie auf das offizielle Sentry-Bundle.

Varianten:

• Standard-URL des Moduls
• eigener CDN-Mirror
• festgelegtes konkretes Bundle / konkrete Version

Nur ändern, wenn:

• Sie die SDK-Version pinnen,
• Sie eigene CSP-Regeln haben,
• Sie Asset-Mirroring verwenden.

Sektion Privacy / Security

Diese Sektion ist für die Minimierung des Risikos der Übertragung sensibler Daten verantwortlich.

Send Default PII

• Yes: SDK kann den Standardumfang von Benutzer- und Request-Daten senden
• No: konservativere Datenschutzpolitik

Empfehlung:

• in der Regel No.

Anonymize IP

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

Empfehlung:

• üblicherweise Yes.

Mask Customer Data

• Yes: maskiert Kundendaten
• No: geringerer Datenschutz

Empfehlung:

• praktisch immer Yes in der Produktion.

Mask Checkout Fields

• Yes: maskiert Checkout-Felder
• No: Risiko eines Datenlecks aus dem Checkout

Empfehlung:

• immer Yes.

Mask Payment Fields

• Yes: maskiert zahlungsbezogene Felder
• No: sehr riskant

Empfehlung:

• immer Yes.

Block Authorization Headers

• Yes: entfernt oder maskiert Authorization und Tokens
• No: Risiko der Übertragung von Authentifizierungsdaten

Empfehlung:

• immer Yes.

Block Cookies

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

Empfehlung:

• üblicherweise Yes.

Block POST Bodies

• Yes: entfernt POST-Bodies
• No: sendet mehr Request-Daten

Empfehlung:

• üblicherweise Yes, besonders für Checkout, Login und Formulare.

Redact Query Params

• Yes: maskiert Query-String-Parameter
• No: Query String bleibt besser lesbar, aber weniger sicher

Additional Redacted Keys

Textfeld für zusätzliche Schlüssel zur Redaktion.

Beispiele:

• token
• api_key
• customer_email
• external_customer_id

Sie können trennen mit:

• Kommas,
• Leerzeichen,
• neuen Zeilen.

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 anhängen darf.

Beispiele:

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

Empfehlung:

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

Sektion Filtering

Diese Sektion reduziert Rauschen und Ereignisvolumen.

Ignore Exceptions Regex

Eine Regex-Regel pro Zeile.

Anwendungsbeispiele:

• bekannte, unkritische 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:

• sammeln Sie zuerst Daten,
• filtern Sie danach wenig wertvolle und wiederkehrende Transaktionen heraus.

Ignore Bots

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

Empfehlung:

• Yes bei hohem SEO-Traffic.

Ignore Health Checks

• Yes: überspringt /health, /status, /ping und Ähnliches
• No: solche Requests werden an Sentry gesendet

Ignore Admin Routes

• Yes: reduziert Ereignisse aus dem Adminbereich
• No: der Adminbereich bleibt überwacht

Ignore Static Resource Errors

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

Empfehlung:

• üblicherweise Yes, wenn Sie das Projekt nach Deployments nicht mit Rauschen füllen möchten.

Sektion Context

Steuert die Menge des geschäftlichen Kontexts, der Events hinzugefügt wird.

Attach Store Context

• Yes: fügt store_id, store_code, Shop-Namen und Währung hinzu
• No: kein dieser 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-/Quote-Kontext hinzu
• No: weniger Daten für die Checkout-Diagnose

Attach Cart Totals

• Yes: fügt Warenkorb-Totals hinzu
• No: leichteres Event

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,
• transaktionale E-Mails,
• ERP-/OMS-Integrationen.

Attach Product Context

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

Attach Category Context

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

Attach Payment / Shipping Method

• Yes: fügt payment_method und shipping_method hinzu
• No: weniger Daten für den Checkout

Empfehlung:

• dies ist eine der wertvolleren Diagnoseeinstellungen.

Attach Module Version

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

Attach Magento Version

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

Attach Deployment Metadata

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

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

Sektion Source Maps / Release

Diese Sektion organisiert die für Release und Source Maps benötigten Parameter. Der eigentliche Upload sollte in CI/CD erfolgen, nicht während der Magento-Runtime.

Enable Source Map Upload

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

Hinweis:

• dies ist ein Konfigurationsflag, kein Upload-Mechanismus.

Source Map Upload Mode

Varianten:

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

Empfehlung:

• in der Produktion meistens ci.

Assets Base URL

Beispiel:

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

Dieser Wert muss dem entsprechen, was das Browser SDK im Stack Trace sieht. Andernfalls werden Source Maps nicht zugeordnet.

Release Dist

Optionales dist für release.

Beispiele:

• storefront
• admin
• pl-store

Verwenden Sie es, wenn ein Release mehrere Asset-Varianten hat.

Organization

Organisations-Slug, der von sentry-cli und API verwendet wird.

So finden Sie ihn:

• aus der URL des Sentry-Panels,
• z. B. https://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:

• aus der Projekt-URL,
• oder Settings -> Projects -> [projekt] -> Details

Release File Path

Pfad zur Datei mit dem Release-Namen bei der Strategie file.

Beispiele:

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

Sektion User Feedback

Konfiguration des Widgets für Problemmeldungen auf Browser-Seite.

Widget Theme

Varianten:

• light
• dark
• system

Empfehlung:

• üblicherweise system.

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 ein Feedback-Vorschlag erscheinen
• No: das Widget öffnet sich nicht automatisch

Empfehlung:

• vorsichtig einsetzen, um für den Nutzer nicht zu aggressiv zu wirken.

Show on checkout success

• Yes: der Feedback-Trigger kann auf der Bestellerfolgsseite erscheinen
• No: kein Trigger an dieser Stelle

Show on contact page

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

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äche Zglos problem haben möchten.

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 an eine eigene Schaltfläche im Layout oder CMS-Block anbinden möchten.

Sektion Cron Monitoring

Diese Sektion steuert Check-ins und Monitore für Magento-Crons.

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 haben.

Monitored job codes

Liste der Magento-job_code.

Sie können trennen mit:

• Kommas,
• Leerzeichen,
• neuen Zeilen.

Varianten:

• leeres Feld: alle Crons überwachen
• Liste ausgewählter job_code: 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 dies, wenn ein Cron 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 Überschreitung des Limits kann Sentry den Monitor als problematisch markieren.

Check-in slug prefix

Beispiel:

magento-

Nützlich, wenn eine Sentry-Organisation mehrere Magento-Instanzen überwacht und Sie Namenskollisionen vermeiden möchten.

Empfohlene Konfigurationsprofile

Sicherer Produktionsstart

• Enable Module = Yes
• Enable Backend Monitoring = Yes
• Enable Frontend Monitoring = Yes
• Error Sample Rate = 1
• Trace Sample Rate = 0.05 oder 0.1
• JS Trace Sample Rate = 0.01 oder 0.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öhere Trace Sample Rate, z. B. 0.2
• höhere JS Trace Sample Rate, z. B. 0.1
• vorübergehend Debug Mode = Yes
• Enable Test Commands = Yes
• vorsichtig mit Replay: Maskierung und Blockierungen weiterhin beibehalten

Minimale Variante nur Backend

• Enable Backend Monitoring = Yes
• Backend DSN ausgefüllt
• Enable Frontend Monitoring = No

Das ist ein guter erster Schritt, wenn Sie zunächst das Monitoring von Exceptions und Crons auf PHP-Seite starten möchten.

Häufigste Konfigurationsfehler

• Einfügen des gesamten Snippets Sentryinit(...) statt nur der DSN.
• Gleichzeitige Präsenz des Moduls in vendor/ und app/code/.
• Unterschiedliche release-Werte zwischen Events und Source Maps.
• Zu aggressives Replay Sampling in der Produktion.
• Deaktivierung der Maskierung von Checkout und Zahlungen.
• Belassen einer Beispiel-DSN in der aktiven Konfiguration.

Zusammenfassung

Am sichersten ist es, mit Backend-Monitoring, vorsichtigem Frontend-Monitoring und restriktiven Datenschutzeinstellungen zu beginnen. Wenn die Daten in Sentry stabil und übersichtlich werden, können Trace Sampling, Replay und der Umfang des geschäftlichen Kontexts schrittweise erhöht werden.