Not a trivial example of the Logger library in python?

Question

Python

I would like to study the code that implements the logger library in python. Not in one file by a simple example. And it is included in several application modules, with a logger conf setting to handle various errors (for example, running out of disk space). You need to see how people with experience use it. I repeat, trivial examples are not of interest. Any project on github will do just fine.

Answer 1

A few years ago I (apparently like you) came to believe in logging. It's not for nothing that there are such wild and deep settings: there are formatters, handlers, and some kind of filters. And I thought: cool programmers use all this, and I beg in the back of the market.
And since then I began to configure all conceivable and inconceivable logging settings. All the errors I had were in the corresponding error files. Also, there was a log with debug information. All this was grouped by files. The debug was formatted with one formatter, the erroneous log was formatted with another formatter, more detailed. And all this grew, blossomed and smelled.
Reality was cruel. All these formatters turned out to be a waste - it became more difficult to hack logs. Separate files with debugs and errors turned out to be abuse - after all, it's easier to grep at the log level ( | grep ERROR). In a pile of log files - the devil will break his leg. And in general, the logs almost always turned out to be unnecessary - errors fly to Sentry, and statistics are collected by other mechanisms (prometheus). And the rotation and archiving of logs was done by devops.
And here are the good practices that I took out:
1. Take loguru, which literally does not need settings:

from loguru import logger
...
# Где-то настроил sink-файл (либо будет только stdout)
...
logger.debug("hello")

2. Sometimes it is convenient to keep logs in JSON format. There is no need to invent cunning greps, everything is perfectly filtered using jq
3. Errors should not be logged, but sent to Sentry. It is desirable if Sentry is configured for webhooks in some slack / discord, so that you see the error the second it occurs. There must be order in Sentry.
4. Log statistics should not be built. To do this, there are much more convenient and faster tools from conventional databases to prometheus + grafana
5. A bunch of log files - in the furnace. One file
6. Log rotation should preferably be external
7. Use ELK
8. Use tests and debugger
To summarize: there are too many hopes and expectations placed on the logs. Logs are a by-product that VERY RARELY helps to investigate unexpected behavior, and in a very awkward way. Most often, not enough necessary information and a lot of unnecessary information are surrounded by logs. And at the time of the accident, there are not enough logs, because after all, it is an accident - it cannot be foreseen. Instead of logging, in most cases it is more convenient to use other tools. Also, I advise you to read this https://sobolevn.me/2020/03/do-not-log