Configure the LogsHandler Service

All following definitions got to sentry.yaml file in your config/packages folder.
Define a LogsHandler service with the minimum log level you want to capture:

services:
  Sentry\SentryBundle\Monolog\LogsHandler:
    arguments:
      - !php/const Monolog\Logger::WARNING

Add the Handler to Monolog

Add the handler to the monolog configuration:

monolog:
  handlers:
    sentry:
      type: service
      id: Sentry\SentryBundle\Monolog\LogsHandler

Configure the Logger in Sentry

Add the main logger service to the SentryBundle configuration:

sentry:
  logger: monolog.logger

Enable Logging

Finally, enable logging in the SentryBundle configuration:

sentry:
  logging:
    enable_logs: true

Result

Now, when an exception is captured by the SentryBundle, it will also be logged to the configured logger. For example:

Sent event [eaaf669ea6834546a20beb6ae0c5773f] to sentry.example.com [project:12]. Result: "success" (status: 200).

The Sentry documentation on Monolog integration is almost complete.

However, it misses the part where the logger service must be configured in the SentryBundle configuration.
Without it, the logger defaults to a `NullLogger`, and nothing gets logged.

Hope it helps.

So since version 5.1 symfony will log deprecations to a dedicated log channel when it exists and ships with this monolog config:

monolog:
    channels:
        - deprecation # Deprecations are logged in the dedicated "deprecation" channel when it exists

This is added already in the recipe and ships when installing symfony.

Ok, but the handler for this deprecation channel is not configured, so you have to do this yourself.
How? Add this to your monolog config:

...
when@dev:
   monolog:
       handlers:
           main:
	       type: stream
	       path: "%kernel.logs_dir%/%kernel.environment%.log"
	       level: debug
	       channels: ["!event", "!deprecation"]
	   deprecation:
	       type: rotating_file
	       path: "%kernel.logs_dir%/%kernel.environment%.deprecations.log"
	       max_files: 2
	       channels: [deprecation]
	   console:
	       type: console
	       process_psr_3_messages: false
               channels: ["!event", "!doctrine", "!console", "!deprecation"]
...

What is happening here?
We declare a new handler for deprecations named deprecation when in dev environment.
This handler listens to the deprecation channel.
We declare it as a rotating file since the assumption is we dont need to keep this log entries for longer.
The other handlers will ignore the deprecation channel by adding a !deprecation to the channel directive.

The deprecation channel was already created and so all deprecations are now not in the main log file but in a dedicated deprecation log file.

For production we dont need to edit configuration since the log level here is info and therefore deprecations will not be considered anyway.