Configure Symfony Logs Without Surprise Volume

Unofficial preview — not affiliated with Sentry. Treat the examples as a reviewable prototype and verify them against your application and current SDK version.

Start with a minimum log level#

Configure the Symfony Logs handler at warning for the first production test. The handler checks the record level before capturing it.

# config/packages/monolog.yaml
monolog:
  handlers:
    sentry_logs:
      type: service
      id: Sentry\SentryBundle\Monolog\LogsHandler

# config/packages/sentry.yaml
services:
  Sentry\SentryBundle\Monolog\LogsHandler:
    arguments:
      - !php/const Monolog\Logger::WARNING
 
sentry:
  options:
    enable_logs: true

Lower the threshold only after reviewing which additional messages will be sent.

Exclude expected HTTP exceptions from error events#

Use ignore_exceptions when an exception represents expected control flow in your application. A common example is a route miss that becomes a NotFoundHttpException.

# config/packages/sentry.yaml
sentry:
  options:
    ignore_exceptions:
      - Symfony\Component\HttpKernel\Exception\NotFoundHttpException

Do not copy a broad exclusion list without reviewing it. An authentication or authorization exception may indicate a real problem in one application and expected behavior in another.

Filter structured logs before sending#

Use before_send_log to drop or modify structured logs after the SDK creates them and before it sends them. Returning null discards a log.

# config/packages/sentry.yaml
sentry:
  options:
    enable_logs: true
    before_send_log: "sentry.callback.before_send_log"
 
services:
  sentry.callback.before_send_log:
    class: 'App\Service\SentryLogFilter'
    factory: ['@App\Service\SentryLogFilter', "getBeforeSendLog"]

The callback implementation must reflect your application's attributes and noise patterns. The official guide includes a callback that drops all info logs; use that example as the syntax reference rather than inventing production rules.

Treat flushing as a latency trade-off#

Symfony flushes the Sentry Logs handler when a request or command finishes. Set log_flush_threshold only when a single request or command can produce a high volume of logs.

Sentry warns that every partial flush sends a network request and can add latency. Do not copy a threshold without measuring request duration and log volume in your application.

Verify before widening the rollout#

Generate one expected exception and one unexpected exception.
Confirm only the intended error event reaches Sentry.
Emit one record below and one record above the Monolog threshold.
Confirm only the intended structured log reaches the Logs interface.
Inspect searchable attributes for sensitive or high-cardinality values.
Exercise a representative request or worker cycle.
Compare the resulting log volume before adding channels or lowering the level.

Sentry's current pricing includes a Logs allowance and charges paid plans for additional Logs volume. Verify the current allowance and overage price on the official pricing page before production rollout.