Because the datahandler's logging was written in a huge hurry at the last minute, it's going to need a rewrite:
- A custom object is used for logging instead of django's logging facility; it's already running if you
orm.setup(). - The root logger (
'') is always hardcoded to talk to a socket; sooner or later we'll need a configuration-based logging config (which again django already provides). - The custom method,
Logger.log, calls python'slogging.log, thus losing information asfuncNamewill always belog; the custom extra used instead,caller, is not reliable, as 3rd party libs don't know to use it (we had this problem with RQ). - In
dhd.serve_log,jobidandcallerhad to be taken out due to above issues with RQ. This is becauselogging.basicConfigsets a configuration for the root (ie global) logger that makes poor assumptions. - It's a datahandler logger, not a gips logger. In the long run, there is no meaningful separation between gips logging and datahandler logging, only differential configs based on various use cases.
Fixes for the client side:
- Use django's logging, including existing means to have django read the gips config. This can be used to set the logging server to talk to, etc etc.
- Modules do what they're supposed to do: Log to a named log specific to that part of the application (python's logging tutorial says to use the fully-qualified module name via:
l = logging.getLogger(__name__); l.info('message')) - Go through existing logging class and make sure it's not necessary; any additional wiring (say, saving a
jobid) should be done in the pythonic way for logging, maybe via a custom LoggerAdapter:
Fixes for the server side:
- Revise
logging.basicConfigcall so it makes no assumptions about custom logging anything. - Set up formatters or other wiring to handle logs whose names match
'gips'or'gips.datahandler', and thus pick up extra custom info for those logs.
Note that github gists don't notify when you comment, so it's best to have discussion elsewhere.