docs · by hand · symfony from sentry

Symfony errors with the Sentry SDK you already have.

Change the DSN and the exceptions your Symfony app already reports arrive in Vinktar. Then add product events with the native PHP SDK, on the same user id, so an error sits next to what the person was doing. Checked on sentry-symfony 5.13.0 with Symfony 8.1 and PHP 8.5.

1. The DSN

SENTRY_DSN=https://abc123@o12345.ingest.sentry.io/451

SENTRY_DSN=https://vnk_pk_YOUR_KEY@in.vinktar.com/YOUR_PROJECT_ID

The key is the project's public write key and the number is the project id. The finished DSN is on the project's Connect page under Manual, and an agent gets it from get_project_keys. The recipe adds an empty SENTRY_DSN to .env and config/packages/sentry.yaml under when@prod. Without allow-contrib Composer installs the package and registers nothing.

check it worked

APP_ENV=prod php bin/console sentry:test sends one message. Within a few seconds the project's Errors page lists Message: This is a test message from the Sentry bundle.

2. What arrives, and what does not

stored

  • Uncaught exceptions and anything passed to captureException: type, message and the 50 frames nearest the crash. A Symfony request stack is longer than that; the frames above are cut, not the error.
  • captureMessage calls, as an issue of type Message.
  • Release, environment, the user id and email on the scope, tags, breadcrumbs and the request URL and method.
  • Levels fatal, error, warning and info; debug is stored as info.

accepted and dropped

Transactions, spans, profiles, sessions, cron check-ins, logs, metrics and attachments get a 200 and are discarded, so the SDK reports no failure. There is no tracing or cron product behind the DSN; keep Sentry for those if you use them.

Everything stored goes through the same pipeline as /v1/errors: the same per-error caps, error rate limit and monthly error budget, described on the migration page and in section 11 of api.md.

3. Release, environment and the user

when@prod:
    sentry:
        dsn: '%env(SENTRY_DSN)%'
        options:
            release: '%env(SENTRY_RELEASE)%'       # any env var; the Vinktar SDK below gets the same name
            environment: '%kernel.environment%'

The release and environment are the Sentry SDK's own options and arrive on every error. The user id is what joins an error to a person: without setUser an error from a signed-in request is anonymous. Use the same id you will pass to identify() below.

4. Then three product events

The DSN carries errors only. Product events come from vinktarhq/php, which is a beta: the API can still change before 0.2.0. It sends on the same write key, and the same release, environment and user id make the error and the person's events one record.

composer require vinktarhq/php:^0.2@beta

Event names and property keys are snake_case, the object then a past-tense action. Define each one as you add it, with define_event from your agent or in the project's data dictionary, so the name keeps one meaning. Under PHP-FPM what a request queues is sent when the request ends; a console command calls flush() before it returns, and the SDK README has a kernel.terminate subscriber for FrankenPHP workers.