Monolog Bundle 4
Problem Statement
The Monolog bundle will hit a major bump soon, and it will also include:
- compatibility with Symfony 8 (which is coming out this month)
- removal of
ravenandsentryloggers, in favor of leveraging Sentry's bundle services: https://github.com/symfony/monolog-bundle/commit/9dd37971ef73ea6d55bf0bd5b36e348ee92312b3
Solution Brainstorm
We should check if this requires any further testing and\or integration, on top of a refresh of the docs. This will probably impede #951 in our CI.
Hey! Thanks for the heads-up. I will update the docs in the next few days so that we can prevent new users from setting it up in a way that isn't going to be valid for newer versions
FYI Monolog bundle v4 has been released: https://github.com/symfony/monolog-bundle/releases/tag/v4.0.0
I've been updating our stack today (Symfony 8 with monolog-bundle 4) and I'm a bit lost with sentry. The docs still refer to hub_id and fill_extra_context, which are no longer available.
This is our old configuration working since February 2024
sentry:
dsn: '%hc.sentry.dsn.api%'
tracing:
enabled: false
options:
before_send: 'sentry.callback.before_send'
release: 'octaved-flow@%hc.release_version%'
tags:
branch: '%hc.build_info.branch%'
revision: '%hc.build_info.revision%'
register_error_listener: false
register_error_handler: false
monolog:
handlers:
sentry:
channels:
- '!javaScript'
type: sentry
level: warning
hub_id: Sentry\State\HubInterface
fill_extra_context: true
services:
Monolog\Processor\PsrLogMessageProcessor:
tags: {name: monolog.processor, handler: sentry}
sentry.callback.before_send:
class: 'Octaved\Env\SentryIo'
factory: ['@Octaved\Env\SentryIo', 'getBeforeSend']
I don't know what the upgrade path is here.
Is this correct to get the same behavior as before?
sentry:
options:
+ enable_logs: true
monolog:
handlers:
sentry:
- type: sentry
- hub_id: Sentry\State\HubInterface
- fill_extra_context: true
+ type: service
+ id: Sentry\SentryBundle\Monolog\LogsHandler
services:
+ Sentry\SentryBundle\Monolog\LogsHandler: ~
It's a bit confusing that I have to define the handler service. And with monolog already up and running, what is enable_logs actually doing here?
In any case, my changes don't work. My before_send is not called anymore and I don't get anything in sentry.
Please help 🥲
Hi @uncaught! Thanks for opening the issue.
I agree it's unfortunate to define the handler service, but unfortunately monolog dropped many 3rd party integrations.
Based on your old config, you are converting log messages to Sentry errors but your new configuration uses the new Logs feature. enable_logs is only relevant if you want to use the new Logs feature.
If you want to continue seeing errors, you have to define \Sentry\Monolog\Handler (from the base SDK) as your monolog handler. That should restore your old functionality.
That said, you should see logs showing up in Explore -> Logs with your current configuration.
Please let me know if this works for you, I will also update the docs to reflect the necessary changes for Monolog 4.
Edit: A config like the one below should work to restore your old functionality:
services:
app.sentry.handler:
class: Sentry\Monolog\Handler
arguments:
- '@Sentry\State\HubInterface'
- !php/const Monolog\Logger::WARNING
monolog:
handlers:
sentry:
type: service
id: app.sentry.handler
level: warning
Thanks a lot! I think it worked, I've accidentally crashed into our rate limit by logging 1k events because I didn't realise the class' log level would override the handler configuration. I'll tell you more tomorrow 😄
@Litarnus I can confirm now, it works great. To summarize, this is all I needed:
monolog:
handlers:
sentry:
- type: sentry
+ type: service
+ id: Sentry\Monolog\Handler
level: warning
- hub_id: Sentry\State\HubInterface
- fill_extra_context: true
services:
+ Sentry\Monolog\Handler:
+ arguments:
+ - '@Sentry\State\HubInterface'
+ - warning