You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Developing an application, I was given a task to change the logger formatter, so the logs are correctly consumed by our observability stack. It's also a requirement that production logs and development logs go through the same formatter, with minimal change.
To do that, I created a formatter class, registered it and changed my application formatter. Something along the lines of:
...but that didn't change the log formatting for rack requests on development/testing, which was very confusing at first... Eventually I found out that it was due to how development logging is setup here, where the constructor is hardcodding the formatter on all logs tagged as rack entries. See:
Should we then discard the default dev/test logger whenever a custom formatter is configured? The default dev/test logger is there for convenience, the common use case is that you want a human-friendly logger so that you can look at your dev/test logs. Personally, if I need a custom logger I just add it as an additional logger, rather than changing the defaults. We can of course make it respect a custom formatter and use it as a trigger to skip the default logger. I'm just trying to make sure that this would be the expected behavior in most cases.
Developing an application, I was given a task to change the logger formatter, so the logs are correctly consumed by our observability stack. It's also a requirement that production logs and development logs go through the same formatter, with minimal change.
To do that, I created a formatter class, registered it and changed my application formatter. Something along the lines of:
...but that didn't change the log formatting for rack requests on development/testing, which was very confusing at first... Eventually I found out that it was due to how development logging is setup here, where the constructor is hardcodding the formatter on all logs tagged as rack entries. See:
It's a bit annoying, but for now I've worked around this issue by setting a custom logger_constructor as follows:
The text was updated successfully, but these errors were encountered: