sentry/sentry-symfony bundle with Composer:
composer require sentry/sentry-symfony
Add your DSN to
###> sentry/sentry-symfony ### SENTRY_DSN="<paste-your-DSN-here>" ###< sentry/sentry-symfony ###
Quickly identify performance issues and view full end-to-end distributed trace to see the exact, poor-performing API call and surface any related errors.
See local variables in the stack for prod errors, just like in your dev environment. Explore the full source code context with frame to function data. Filter and group Symfony exceptions intuitively to eliminate noise.
Expose the important events that led to each Symfony exception: network requests, SQL queries, debug logs, poast errors. Learn in which version a bug first appeared, merge duplicates, and know if things regress in a future release.
Aggregate errors by factors like request details, user ID, and app version to see what’s new, a priority, or a trend.
Assign custom key-value tags to reproduce the error environment specific to your application, business, and users.
Find answers to key questions: Was it a code error or usage exception? In which app release did the Symfony bug occur?
You can get started for free. Pricing depends on the number of monthly events, transactions, and attachments that you send Sentry. For more details, visit our pricing page.
Sentry doesn’t impact a web site’s performance.
If you look at the configuration options for when you initialize Sentry in your code, you’ll see there’s nothing regarding minimizing its impact on your app’s performance. This is because our team of SDK engineers already developed Sentry with this in mind.
Sentry is a listener/handler for errors that asynchronously sends out the error/event to Sentry.io. This is non-blocking. The error/event only goes out if this is an error.
Global handlers have almost no impact as well, as they are native APIs provided by the browsers.