[22.05] Disable translogger middleware by default #14467
Merged
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.
Setting to draft for discussion, I have partially talked myself out of this
gunicorn/uvicorn have built in transaction (access) logging which makes the translogger middleware somewhat redundant. Also, because translogger sets up its own console logger, these messages are only written to stdout and thus only captured by methods that capture stdout (that means gunicorn with
--error-logfile
, but not custom Python logging setups like settinglog_destination
or thelogging
dict as in #14457). In the latter case, the access log is lost.This change makes it so both ways of execution (default logging, custom/rotation logging) will produce the same log output in a single log file, via the standard Python logging mechanisms.
It is worth noting that translogger and uvicorn access log messages will be different:
I couldn't see a way to set a formatter just for the
gunicorn.access
logger to override the format so it is just the bare "access log" style message but still have it logged to the same handler, since formatters are specified per-handler, not per-logger. This is not a big deal IMO. Also, the uvicorn access logger is missing the remote address, referer, and user-agent fields, and that is not currently fixable as per encode/uvicorn#527. I also don't know if it logs the remote IP or the proxy IP. This is a bigger deal and could be a motivation to keep translogger. That said, uvicorn logging is probably faster.The motivation for access logs in the application logs are so that you can more easily correlate them with application log messages that may be relevant to that request. Having them in a separate file is not particularly useful IMO. Having a separate access log file is also essentially a duplication of the proxy's access log files.
If you want to disable the access log entries, you can do so with a custom logging config (as described in the Galaxy logging config docs) but replacing the
gunicorn.access
logger like so:Alternatively, to log to a separate file, set up a handler (and in this example, a formatter, if you like):
Alternatively, to get translogger statements into non-captured logs we can initialize it with
setup_console_handler=False
. Then it appears in the default log format like so:TL;DR we can have log rotation with Python's builtin logging facilities or we can have translogger but not both.
It might be possible with some hacking to translogger to get it to log to the "console" handler in the Galaxy logging config rather than its own.
How to test the changes?
(Select all options that apply)
License