Design logging
Opened this issue · 0 comments
Important starting point: there are at least three separate usage scenarios:
golem_api.default_logger.DefaultLogger
is used- Some other logger is used
- Logging is totally ignored (-> no
logger
is configured etc)
We want to every scenario to be "supported" in a convenient way. E.g. we'd like to avoid a situation when writing a 5-line code requires additional 2 lines just to silence some default logs we don't care about etc.
Also, there's a distinction:
A. Logs in the low-level API
B. Logs in the mid-level API in the general part (-> #12) (my current take is that there should be no default logging in this section)
C. Logs in the mid-level API in the golem-specific part
D. Logs in the high-level API (if we have any high-level API at all)
There are few three separate topics here:
W. Do we accept logger.debug()
lines buried deep in low-level code? We probably should. But also we don't want them to show on the screen unless developer explicitly asks for them,
X. Is there any other logging logic than debug logs mentioned in W
and event-based logging? If no, are our events granular enough?
Y. Improvements in golem_api.default_logger.DefaultLogger
- better log file, screen logs
Z. Optional high-level detail logs - e.g. every request. This is now implemented in yapapi
and is useful.
I think we should start with defining requirements, e.g.:
- By default, all logs are silent
- Without much effort developer can get "usually useful" screen logs
- Without much effort developer can get very detailed log file
- Decide on W and X