New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change default level severity no (e.g. to match pino) #949
Comments
How are logs parsed by your external tools? Which kind of handler are you using with Loguru? I would suggest to adapt your sink or formatter so that it convert Loguru default severity to the one you're interested in. Here is an example using a global patching function: def add_pino_log_level(record):
log_level_adapter = {
"TRACE": 10,
"DEBUG": 20,
"INFO": 30,
"WARNING": 40,
"ERROR": 50,
"CRITICAL": 60,
}
pino_level = log_level_adapter.get(record["level"].name, record["level"].no)
record["extra"]["pino_level"] = pino_level
logger.configure(patcher=add_pino_log_level)
logger.add("file.log", format="[{time}][{extra[pino_level]}] {message}") |
We're outputting logs as JSON via stderr, which gets aggregated up in AWS Cloudwatch, from where we run queries like i will experiment to see if I can override the level in a patch function (your example shows adding a secondary property which would be confusing in the output). Out of interest, is it a deliberate design decision to make the levels immutable, or is there an impediment in some implementation detail of the library? It feels a little arbitrary from here on the outside and a patch/custom formatter like a slightly odd workaround! |
I would not advise to patch the Clearly differentiating Loguru's levels from those of Pino seems to me to be the best solution. How would you have done it using the standard Level severity was made immutable after discussions in #209. It's not a technical restriction. This is to maintain a coherent system. If a library expects a "DEBUG" log to be less severe than "INFO", the logs would no longer make sense if the two There is one small problem, however. If two libraries independently decide to create a custom level with the same name, then they become incompatible. A user importing both would face an error. This is something I need to fix, so perhaps the restriction on level mutation will be loosened. But I don't know what I'm going to do yet. |
We have consolidated logging across multiple services. In most (node) services, we use
pino
, which has established a precedent for logging severity -- in particular thatwarning=40
anderror=50
. This is different from loguru's default levels, which has warnings at 30 and errors at 40. This means that our standardised (external) log-processing tools, which look for logs wherelevel>40
to escalate them don't catch loguru's error-level logs.I have tried to change the default level severities with e.g.
logger.level("WARNING", no=40)
, but I getTypeError: Level 'WARNING' already exists, you can't update its severity no
. Is there an alternative approach? I suppose a workaround would be to define fully custom levels and log withlogger.log('_WARNING', '..'), but then I'd have to make sure no one accidentally uses
logger.warning`.The text was updated successfully, but these errors were encountered: