New feature to allow adding extra information to log#90
Uh oh!
There was an error while loading. Please reload this page.
Conversation
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
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 47c70c0 to b2b0759Compare
Author
Edouard-chin commented Feb 17, 2025
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
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.