Make logging level of the django app configurable #2078
Conversation
ATM we do not have a single DEBUG level log statement, but I hope that logging would be enriched. Adding such control would also allow to make log less talkative if so desired by setting it to WARNING level. But also would simplify addition and use of new log statements
yarikoptic
added
DX
These are not needed here, as they are already part of the setting definition (that is, `settings.DANDI_LOG_LEVEL` always exists and has the correct default value if it is not set explicitly).
The [`logging` module docs](https://docs.python.org/3/library/logging.html#logging.Logger.setLevel) explain that `setLevel()` can handle the string representations of the logging levels. This allows the setting value to be directly tied to what is passed in, and `setLevel()` also does a "validation" on the value and will refuse to process levels that don't exist.
dandiapi/api/apps.py
Outdated
| @@ -50,13 +50,15 @@ def ready(self): | |||
| import dandiapi.api.checks # noqa: F401, RUF100 | |||
| import dandiapi.api.signals # noqa: F401 | |||
|
|
|||
| logging.getLogger(__name__).setLevel(settings.DANDI_LOG_LEVEL) | |||
There was a problem hiding this comment.
This was originally logging.getLogger(__name__.split('.')[0]), but looking through the codebase and at the logging docs, it seems logging.getLogger(__name__) is a standard practice. Was there a reason you had it the other way? (If necessary, we can revert 6addfac, which makes the change.)
There was a problem hiding this comment.
Actually, this does not have the desired effect (of changing the logging level for all loggers). Instead, we need to omit the __name__ argument so as to affect the root logger. See b07bfe1.
This needs to be `logging.INFO` so that Sentry can propery construct breadcrumbs within its error reports.
dandiapi/api/apps.py
Outdated
| @@ -50,13 +50,15 @@ def ready(self): | |||
| import dandiapi.api.checks # noqa: F401, RUF100 | |||
| import dandiapi.api.signals # noqa: F401 | |||
|
|
|||
| logging.getLogger(__name__).setLevel(settings.DANDI_LOG_LEVEL) | |||
There was a problem hiding this comment.
Actually, this does not have the desired effect (of changing the logging level for all loggers). Instead, we need to omit the __name__ argument so as to affect the root logger. See b07bfe1.
dandiapi/api/apps.py
Outdated
| @@ -50,6 +50,8 @@ def ready(self): | |||
| import dandiapi.api.checks # noqa: F401, RUF100 | |||
| import dandiapi.api.signals # noqa: F401 | |||
|
|
|||
| logging.getLogger().setLevel(settings.DANDI_LOG_LEVEL) | |||
There was a problem hiding this comment.
Thanks @waxlamp for catching the initial limitation! but I do not think we should go this wild, what about affecting only dandi ? i.e. smth like
| logging.getLogger().setLevel(settings.DANDI_LOG_LEVEL) | |
| logging.getLogger(__name__.split('.', 1)[0]).setLevel(settings.DANDI_LOG_LEVEL) |
? otherwise, if to debug our code we turn to DEBUG level globally -- could lead to excessive amount of noise from all kinds of libraries we use. WDYT?
There was a problem hiding this comment.
Ah I see what you were going for now. I've added this back (along with explanatory comment) in dc3549d.
ATM we do not have a single DEBUG level log statement, but I hope that logging would be enriched. Adding such control would also allow to make log less talkative if so desired by setting it to WARNING level. But also would simplify addition and use of new log statements. E.g. I would right away add it into dandi-cli docker-compose setup so to help in the future troubleshooting issues like