Uh oh!
There was an error while loading. Please reload this page.
New feature to allow adding extra information to log - #90
Open
Edouard-chin wants to merge 1 commit into
Open
Conversation
Edouard-chin added a commit
to Edouard-chin/rails
that referenced
this pull request
Oct 25, 2023
- ### Context
The Tagged Logging functionality has been a source of a few
issues over the years, especially when combined with the
broadcasting feature.
Initializating a Tagged Logger wasn't very intuitive:
```ruby
logger = Logger.new(STDOUT)
tagged_logger = ActiveSupport::TaggedLogging.new(logger)
# Would expect the `tagged_logger` to be an instance of `AS::TaggedLogging`
# but it's a clone of the `logger`.
tagged_logger.formatter = ->(_, _, _, message) do
{ message: message }
end
# Modifies the formatter to output JSON formatted logs.
# This breaks tagged logging.
```
I believe the main reason of those issues is because tagged logging
is implemented at the wrong level.
### Solution
I made a proposal on the Ruby logger upstream in ruby/logger#90 to help
solve this but it hasn't been reviewed yet. So I thought about adding
it here for now.
The TL;DR is to decouple formatting and adding extra information to
logs (which is what tagged logging does).
### Deprecation
Since TaggedLogging will no longer access the formatter, there is a
few things I'd like to deprecate (such as setting a default
formatter https://github.com/rails/rails/blob/d68e43922bc11829c52ad9f736ad5549fc97631b/activesupport/lib/active_support/tagged_logging.rb#L124)
but doing so in this PR would increase the size of the diff
significantly and would maybe distract for PR reviews.
Another thing that I believe should be deprecated is
`ActiveSupport::TaggedLogging.new`. Adding tagging
functionality to a logger should be done using
a more ruby approach such as `logger.extend(AS::TaggedLogging)`.
Fixrails#49757Fixrails#49745Fixrails#46084Fixrails#44668
I made a propose on the Ruby logger upstream in ruby/logger#90,
but it hasn't been reviewed it.Edouard-chin added a commit
to Edouard-chin/rails
that referenced
this pull request
Jan 17, 2024
- ### Context
The Tagged Logging functionality has been a source of a few
issues over the years, especially when combined with the
broadcasting feature.
Initializating a Tagged Logger wasn't very intuitive:
```ruby
logger = Logger.new(STDOUT)
tagged_logger = ActiveSupport::TaggedLogging.new(logger)
# Would expect the `tagged_logger` to be an instance of `AS::TaggedLogging`
# but it's a clone of the `logger`.
tagged_logger.formatter = ->(_, _, _, message) do
{ message: message }
end
# Modifies the formatter to output JSON formatted logs.
# This breaks tagged logging.
```
I believe the main reason of those issues is because tagged logging
is implemented at the wrong level.
### Solution
I made a proposal on the Ruby logger upstream in ruby/logger#90 to help
solve this but it hasn't been reviewed yet. So I thought about adding
it here for now.
The TL;DR is to decouple formatting and adding extra information to
logs (which is what tagged logging does).
### Deprecation
Since TaggedLogging will no longer access the formatter, there is a
few things I'd like to deprecate (such as setting a default
formatter https://github.com/rails/rails/blob/d68e43922bc11829c52ad9f736ad5549fc97631b/activesupport/lib/active_support/tagged_logging.rb#L124)
but doing so in this PR would increase the size of the diff
significantly and would maybe distract for PR reviews.
Another thing that I believe should be deprecated is
`ActiveSupport::TaggedLogging.new`. Adding tagging
functionality to a logger should be done using
a more ruby approach such as `logger.extend(AS::TaggedLogging)`.
Fixrails#49757Fixrails#49745Fixrails#46084Fixrails#44668
I made a propose on the Ruby logger upstream in ruby/logger#90,
but it hasn't been reviewed it.Edouard-chin added a commit
to Edouard-chin/rails
that referenced
this pull request
Oct 28, 2024
- ### Context
The Tagged Logging functionality has been a source of a few
issues over the years, especially when combined with the
broadcasting feature.
Initializating a Tagged Logger wasn't very intuitive:
```ruby
logger = Logger.new(STDOUT)
tagged_logger = ActiveSupport::TaggedLogging.new(logger)
# Would expect the `tagged_logger` to be an instance of `AS::TaggedLogging`
# but it's a clone of the `logger`.
tagged_logger.formatter = ->(_, _, _, message) do
{ message: message }
end
# Modifies the formatter to output JSON formatted logs.
# This breaks tagged logging.
```
I believe the main reason of those issues is because tagged logging
is implemented at the wrong level.
### Solution
I made a proposal on the Ruby logger upstream in ruby/logger#90 to help
solve this but it hasn't been reviewed yet. So I thought about adding
it here for now.
The TL;DR is to decouple formatting and adding extra information to
logs (which is what tagged logging does).
### Deprecation
Since TaggedLogging will no longer access the formatter, there is a
few things I'd like to deprecate (such as setting a default
formatter https://github.com/rails/rails/blob/d68e43922bc11829c52ad9f736ad5549fc97631b/activesupport/lib/active_support/tagged_logging.rb#L124)
but doing so in this PR would increase the size of the diff
significantly and would maybe distract for PR reviews.
Another thing that I believe should be deprecated is
`ActiveSupport::TaggedLogging.new`. Adding tagging
functionality to a logger should be done using
a more ruby approach such as `logger.extend(AS::TaggedLogging)`.
Fixrails#49757Fixrails#49745Fixrails#46084Fixrails#44668
I made a propose on the Ruby logger upstream in ruby/logger#90,
but it hasn't been reviewed it.Edouard-chin added a commit
to Edouard-chin/rails
that referenced
this pull request
Oct 28, 2024
- ### Context
The Tagged Logging functionality has been a source of a few
issues over the years, especially when combined with the
broadcasting feature.
Initializating a Tagged Logger wasn't very intuitive:
```ruby
logger = Logger.new(STDOUT)
tagged_logger = ActiveSupport::TaggedLogging.new(logger)
# Would expect the `tagged_logger` to be an instance of `AS::TaggedLogging`
# but it's a clone of the `logger`.
tagged_logger.formatter = ->(_, _, _, message) do
{ message: message }
end
# Modifies the formatter to output JSON formatted logs.
# This breaks tagged logging.
```
I believe the main reason of those issues is because tagged logging
is implemented at the wrong level.
### Solution
I made a proposal on the Ruby logger upstream in ruby/logger#90 to help
solve this but it hasn't been reviewed yet. So I thought about adding
it here for now.
The TL;DR is to decouple formatting and adding extra information to
logs (which is what tagged logging does).
### Deprecation
Since TaggedLogging will no longer access the formatter, there is a
few things I'd like to deprecate (such as setting a default
formatter https://github.com/rails/rails/blob/d68e43922bc11829c52ad9f736ad5549fc97631b/activesupport/lib/active_support/tagged_logging.rb#L124)
but doing so in this PR would increase the size of the diff
significantly and would maybe distract for PR reviews.
Another thing that I believe should be deprecated is
`ActiveSupport::TaggedLogging.new`. Adding tagging
functionality to a logger should be done using
a more ruby approach such as `logger.extend(AS::TaggedLogging)`.
Fixrails#49757Fixrails#49745Fixrails#46084Fixrails#44668
I made a propose on the Ruby logger upstream in ruby/logger#90,
but it hasn't been reviewed it.nobu
reviewed
Feb 14, 2025
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
- ### Context It's quite common to add extra info to each log messages to make debugging easier. For instance, adding a request ID to trace the request more easily if an exception occurs. Or add user information for various needs. Right now, the easiest way to implement this is to create a custom formatter. ### Problem I believe formatting the log and adding extra information are two distincts features that should be handled with different objects. Moreover, because libraries or frameworks usually provide this feature, it makes things hard for them to not conflict with each others. As well as conflicting with the potential formatter set by an application. It ends up in a cascade of monkeypatch and doesn't allow much flexibility for the end user. ### Solution I'd like to introduce the concept of a log processor who's interface is similar to the formatter but its responsibility is to only add extra info to the message. More importantly, a logger can have multiple processors, each defining the logic within their scope. This should allow for a lot more flexibility (applications can now easily re-order processors, remove or add them on the fly, change their formatter afterward without breaking libraries functionalities). It will also make things easier for libraries and provide a cleaner way to hook into the logger. This change is fully backward compatible.
Edouard-chinforce-pushed
the
ec-logger-processor
branch
from
February 17, 2025 22:21
47c70c0 to
b2b0759CompareEdouard-chin
commented
Feb 17, 2025
MemberAuthor
Thanks for having a look! |
nobu
reviewed
Jul 18, 2025
Comment on lines
+733
to
735
| message = process_message(format_severity(severity), Time.now, progname, message) | ||
| @logdev.write( | ||
| format_message(format_severity(severity), Time.now, progname, message)) |
Member
There was a problem hiding this comment.
Shouldn't we use the same time?
Suggested change
| message=process_message(format_severity(severity),Time.now,progname,message) | |
| @logdev.write( | |
| format_message(format_severity(severity),Time.now,progname,message)) | |
| now=Time.now | |
| message=process_message(format_severity(severity),now,progname,message) | |
| @logdev.write( | |
| format_message(format_severity(severity),now,progname,message)) |
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello, thank you for maintaining this library ❤️ ! I'm opening this PR to propose a new feature:
Context
It's quite common to add extra info to each log messages to make debugging easier. For instance, adding a request ID to trace the request more easily if an exception occurs. Or add user information for various needs.
Right now, the easiest way to implement this is to create a custom formatter.
Problem
I believe formatting the log and adding extra information are two distincts features that should be handled with different objects. Moreover, because libraries or frameworks usually provide this feature, it makes things hard for them to not conflict with each others. As well as conflicting with the potential formatter set by an application. It ends up in a cascade of monkeypatch and doesn't allow much flexibility for the end user.
Solution
I'd like to introduce the concept of a log processor who's interface is similar to the formatter but its responsibility is to only add extra info to the message. More importantly, a logger can have multiple processors, each defining the logic within their scope.
This should allow for a lot more flexibility (applications can now easily re-order processors, remove or add them on the fly, change their formatter afterward without breaking libraries functionalities).
It will also make things easier for libraries and provide a cleaner way to hook into the logger.
This change is fully backward compatible.