New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
custom_options with Rails.logger.error #272
Comments
I'll take a stab at this one, as I believe it's working as designed here: Lograge doesn't mess with direct calls to a logger. It functions by capturing a lot of the events that Rails uses to trigger log writes and silencing them or incorporating them into its own log output. I think the point of Lograge is sort of "one log line per request" but if you wanted to log your own messages in its format, you could imitate what it's doing here: |
@dleavitt Thanks for the response. A specific use case is an exception in the middle of the request/response cycle. Because lograge does not mess with it, the exception hits the logs immediately--before the lograge entry that marks end of request response cycle + its duration. As a result, you then need to check the lograge timestamp and subtract the duration value in order to see if the stacktrace entry falls in the request/response window and may have, in fact, been caused by that particular request. What I was looking for was the ability to "annotate" the lograge entry on the fly, as it were, so I could capture an error and have some messaging inserted into the logs as part of the request/response log entry in order to definitively connect the cause and the effect. Granted, we use json formatted logs plus a log aggregator, so having "one log line per request" be a very long log line is not as much of a concern for us as having error messaging dropped in the context as the request/response log entry. It felt like you were suggesting that a 2nd log entry be created with the same request/response info, but would you say that if we add info to the ActionController payload by overloading |
I tried @dleavitt 's suggestion. That does bring in the same "format", in that you'll get something like
but that's really missing the heart of what the original request is. There's useful information (like user_id) that I've set up via For us to use lograge/lib/lograge/log_subscribers/base.rb Lines 22 to 23 in 1729eab
rails.logger.error , we would have to execute Lograge::LogSubscribers::Base.extract_request, specifically the line data.merge!(custom_options(event)) . I don't know how to get the event variable though in order to extract the custom options.
I'm excited to see if #303 can be revived in order to offer this functionality though! Thanks for all the work the team has put into this so far. |
I am using
Rails.logger.error "some error"
in my controller's action. I can see the resulting JSON-formatted log indevelopment.log
but it completely bypassed thecustom_options
code where I add in theparams
values.Is this working as designed?
Rails 5.0.x
The text was updated successfully, but these errors were encountered: