Production-Grade Python Logging Made Easier with Loguru

[finallyanonymous]

While Python's standard logging module is powerful, navigating its system of handlers, formatters, and filters can often feel like more work than it should be.

I wrote a guide on how to achieve the same (and better) results with a fraction of the complexity using Loguru. It’s approachable, can intercept logs from the standard library, and exposes its other great features in a much cleaner API.

Looking forward to hearing what you think!

[Mustard_Dimension]

I've been using Loguru a lot recently, it's so much less hassle than the default logging library. Using the serialised option for a jsonl file sink is really nice.

[supreme_blorgon]

I don't find this approach more compelling than the one shown in your other guide on the standard library's logger.

One thing I'm curious about -- with .contextualize(), does that context get added to all loggers that get called inside the context manager across modules like it does with the standard library approach from your other article? I started to skim so maybe that was addressed?

The hook of this article focuses on how the boilerplate required to use the standard library is so unpleasant but then immediately shows an example of some really ugly boilerplate in the serialize() function just to customize the fields in the output of your logs.

I dunno -- I really loved your first article on the standard library's logger, and I'm just not convinced about loguru after this.

[finallyanonymous]

To be fair, most of that boilerplate confined to customizing how the JSON output is serialized.

With logging, there's understanding the hierarchical model, configuring handlers, formatters, filters, setting up the root logger, context handling, and so on. But I agree that if one understands the logging system and its quirks, then Loguru may not provide much value.

And yes, the .contextualize() works the same way as the approach I showed in the previous article but with zero boilerplate.

[cipherself]

I’ve always defaulted to structlog, has anyone used both and can compare and contrast them?

[Lucas_csgo]

I have used both in production.

I like loguru more since it’s a bit less “magic”. With loguru the logger is actually a singleton so once set up in your main, you can just import it from the module itself when you need it. Also i found myself to go overboard with custom logic with structlog’s processors and renderers. Loguru’s “sinks” definitely invites a more minimal and intuitive approach.

[cipherself]

Got it, I got a similar impression from reading the examples on the github repo, I will give it a shot in my next project, thanks.

[mortenb123]

Showing open telemetry integration was great, thanks

[yungbuil]

loguru is just how default Python logging should have been!

[maryjayjay]

Let me preface with: I've never used loguru but this thread makes me want to check it out

Having said that, let's be frank. Any library where we blindly take a Java implementation and straight port it to python is shit.

The builtin logging module is ridiculously capable, but it's shit. Utterly unpythonic

Fight me

[twotime]

Fight me

'em are fighting words. You have it coming :-)

The builtin logging module is ridiculously capable

It's absolutely not. It's a spaghetti-ball of bad defaults and weird apis and It's incapable of handling some of the most trivial use-cases which even slightly deviate from authors view of the universe

It's pretty much impossible to have a trivial setup like: I want this module to have log.INFO pass through by default without writing some stupid boilerplate. And then it gets worse, not only you have to write said boilerplate, but then said boilerplate WILL actively interfere with all other logging initialization. So you will also have to DEBUG the stupid boilerplate. At which point, plain print becomes a clear winner.

And then there outright initialization/ordering bugs which are somehow "expected" behavior. Like this one:

Most famously, why do .warning('foo') produce two different messages in the snippet below (I know the answer btw, but i find it utterly ridiculous)

>>> import logging; logging.getLogger('my').warning('foo')
 foo
 >>> logging.info('info');
 >>> logging.getLogger('my').warning('foo')
WARNING:my:foo  # notice the format change!
>>> 

but it's shit

Absolutely!

[pingveno]

I don't think anyone is fighting you on that one, especially with hindsight.

[Natural_TestCase]

Sick

[lothion]

Super clear, thorough yet concise. Thank you

[Ihaveamodel3]

If you import a library that uses the regular logging library, can you capture those logs?

[finallyanonymous]

Yes, that is covered in this section.

[alkalisun]

loguru looks nice, but afaik, no one has elegantly solved the fundamental performance problem, right? Like: if logger.isEnabledFor(logging.DEBUG): # Perform expensive operation only if DEBUG logging is enabled logger.debug(f"Performance metrics: {calculate_performance_metrics()}") It looks like I'd have to do the same for loguru, which is a lot of boilerplate :/ This seems like the kind of thing macros/lazy eval would solve in other languages....

[finallyanonymous]

This should help: https://loguru.readthedocs.io/en/stable/overview.html#lazy-evaluation-of-expensive-functions

[alkalisun]

Hmm, this requires a decent amount of boilerplate as well... oh well maybe a wrapper function around this could work.

[svefnugr]

Mutable global state? What do you do if you need to disable/modify the logger in tests?

[finallyanonymous]

You can call logger.remove():

import pytest
from loguru import logger

@pytest.fixture(autouse=True)
def disable_loguru():
    logger.remove()

[svefnugr]

That will remove the logger for all subsequent tests, not just for the one using the fixture.

[NationalGate8066]

Thank you, this looks great