Repository navigation
feat(logs): Add Monolog channel to compiled log attributes - #2029
Conversation
|
Hi @melkamar! Can you tell us why you need the channel name in the log attributes? Adding it to every log message would increase the number of bytes per message, so we are a bit reluctant to add it without proper reason |
|
@Litarnus sure, the reason is that I may want to filter for messages sent to a certain channel. For example, if some troubleshooting issues related to async processing, I may want to narrow my search to the In our application, we use dozens of different channels. I may want to drill down to a specific one. That's what we currently do in Elastic/Kibana and it's very useful. Having the same in Sentry, along with all the other app data, would be great. I do understand the reluctance of adding data. I also understand that this is truly pointless for use cases where someone uses a single channel (e.g. |
|
Thanks for the explanation, I can see that it makes a lot of sense to have that option in your setup.
Yes, I think that would be best. I'm happy to review the PR if you change it to opt-in |
|
@Litarnus Thanks, I have pushed an update that makes this opt-in |
The channel is a relevant piece of metadata of a log entry. This change adds an option to include the channel in the recorded attributes, but remains backwards compatible and will not overwrite existing extra or context fields named 'channel'.
# Conflicts: # tests/Monolog/LogsHandlerTest.php
stayallive
left a comment
stayallive
left a comment
There was a problem hiding this comment.
Thanks, sorry this took a bit 😄
…ibutes() Add the channel attribute after the existing array_merge instead of as an extra argument, so the baselined mixed-argument issues still match. Context and extra still take precedence over the channel.
3 participants
Description
Adds
channelname to the log metadata.The channel is a relevant piece of metadata of a log entry. This change includes the channel in the recorded attributes, but remains backwards compatible and will not overwrite existing extra or context fields named 'channel'.
I considered making this an opt-in configuration of the Handler in the constructor, but since this is backwards compatible, I figured that's not necessary.