Advice on logging libraries: Logfire, Loguru, or just Python's built-in logging?

Posted by Ranteck@reddit | Python | View on Reddit | 66 comments

Hey everyone,

I’m exploring different logging options for my projects (fastapi backend with langgraph) and I’d love some input.

So far I’ve looked at:

Python’s built-in logging module
Loguru
Logfire

I’m mostly interested in:

Clean and beautiful output (readability really matters)
Ease of use / developer experience
Flexibility for future scaling (e.g., larger apps, integrations)

Has anyone here done a serious comparison or has strong opinions on which one strikes the best balance?
Is there some hidden gem I should check out instead?

Thanks in advance!

[-]

Fenzik@reddit

I’ll further muddle the waters by putting in a good word for loguru. No messing around with thinking up names or keeping track of where the log statement actually fired from - it’s right there in the output by default. Just

from loguru import logger

logger.info(“whatever”)

and you see exactly where the output came from straight out of the box.

Obviously you can also customize formatting, handlers, etc, but tbh I’ve never felt the need.

[-]

Alex_1729@reddit

I use loguru well, though have a dedicated logging module always.

[-]

CSI_Tech_Dept@reddit

No messing around with thinking up logger names

That was never an issue, as the documentation say you should use something like:

log: Final = logging.getLogger(__name__)

in every file, this way you also get flexibility and ability to control logging level in section of code that you're interested.

[-]

Fenzik@reddit

Yeah true but loguru gives the exact line number and qualname of the call site which is super handy. Especially if you have a bunch of different functions or classes in the same file, __name__ has room for improvement.

[-]

supreme_blorgon@reddit

you can log the line number in the standard library logger too

[-]

splendidsplinter@reddit

Yes, this is exactly the point. All loggers have the same functionality, and all loggers can be made to behave like all the others. Which logger makes good choices a default instead of a wild goose chase through their API?

[-]

Fenzik@reddit

All these logging libraries can replicate each other’s functionality, there’s no magic here. Loguru is just very functional out of the box with no config.

[-]

ihearapplause@reddit

loguru is what `import logging` should have been imo

[-]

binaryfireball@reddit

your log statements are fucked up if you need that

[-]

Fenzik@reddit

Eh it’s not a need it’s just handy

[-]

CSI_Tech_Dept@reddit

You can log all of that including thread name, task name, and bunch of other things.

I send most of those details via structured logging to the log server, but during development adding file and line number just pollutes the screen. I never had a problem locating the culprit by the error message and module.

[-]

fibgen@reddit

Nice. The built-in logging module fails the test of doing the correct thing by default and needing more work to not use a global logger.

[-]

CSI_Tech_Dept@reddit

That's because it was written in 2002 and things change.

But the module is extremely flexible. This is recommendation how to use it today:

https://www.dash0.com/guides/logging-in-python

The biggest benefit of this module over other is that pretty much all libraries use it.

[-]

yamanahlawat@reddit

+1. I just use loguru for its simplicity.

[-]

outceptionator@reddit

Love loguru. Super easy to get going and still a lot of depth if you need it later.

[-]

sudonem@reddit

Same - I haven't tried all possible options, but Loguru was really simple to implement and that's likely what I'll always use unless I have a really specific need down the road.

[-]

Darwinmate@reddit

+1.

It also works well with the joblib mutlithreading library

[-]

MolonLabe76@reddit

Yup, loguru is really good, and stupid simple to use.

[-]

gerardwx@reddit

If you use the standard library, you'll know how it works when you use PyPI packages that use the standard library. Plus, you can easily have logging in your stand-alone scripts.

[-]

luddington@reddit

I'm just using this snippet throughout my (Lambda) projects:

import logging
import os
import sys

import colorlog

class Logger(metaclass=SingletonMeta):
    def __init__(self):
        if os.environ.get('AWS_LAMBDA_FUNCTION_NAME') is None:
            _logger = logging.getLogger()
            stdout = colorlog.StreamHandler(stream=sys.stdout)
            fmt = colorlog.ColoredFormatter(
                '%(white)s%(asctime)s%(reset)s | %(log_color)s%(levelname)s%(reset)s | %(log_color)s%(message)s%(reset)s'
            )
            stdout.setFormatter(fmt)
            _logger.addHandler(stdout)
            _logger.setLevel(logging.INFO)
            self.log = _logger
        else:
            from aws_lambda_powertools import Logger as LambdaLogger

            self.log = LambdaLogger()


logger = Logger().log

[-]

Mevrael@reddit

You can check Arkalos. It has a user friendly Log facade with JSONL logs and also uses FastAPI and has a simple UI to view logs in your browser.

If you gonna go with a custom solution, you will have to do a lot of shenanigans and extend core classes yourself so your logger would actually take control of FastAPI, etc logs as well.

[-]

Ranteck@reddit (OP)

Actually I always use fastapi ones but I want to know other opinions. In my projects always centralize the logging in a core solution

[-]

txprog@reddit

I'm a fan of structlog, different philosophy, structured logging. For example you can bind a logger to a request id, and then a problem happen you can lookup what happen for this request, not just the traceback. Same for any kind of background worker. It make production debugging much easier when correctly used.

[-]

Log2@reddit

I really like structlog, but setting it up to also work with stdlib logging is a pain. It doesn't help that a lot of the information you need is scattered through multiple documentation pages.

[-]

MaticPecovnik@reddit

What do you mean you pass the bounded logger to the function? You dont need to do that to get the benefits that you want if I am understanding you correctly. You can just use the bounded_contextvars or something like that contextual manager and it propagates the context down the stack.

[-]

THEGrp@reddit

How does struct log work with ELK or splunk?

[-]

antonagestam@reddit

Given you configure ingestion, it works excellent.

[-]

txprog@reddit

I thought the contextual manager return one that you need to use. I will reread the doc, that would be even more transparent and awesome 👌

[-]

FanZealousideal1511@reddit

>If it's from a code path, i'm passing it to to the function or class

You can also set logging up in such a way that all logging (even the loggers created via stdlib) goes via structlog. This will address the following 2 issues with your setup:

You wouldn't need to pass the logger instance. You can just create a logger anywhere and use it directly (e.g. `logger = logging.getLogger(...)`.
All the logging from 3rd-party libs will also go via structlog.

https://www.structlog.org/en/stable/standard-library.html#rendering-using-structlog-based-formatters-within-logging

[-]

ArgetDota@reddit

Just fyi, loguru supports everything you’ve described, it’s not like it’s only possible with structlog

[-]

wouldacouldashoulda@reddit

+1 on structlog. I use it everywhere, always. It’s so simple (to use) but so powerful.

[-]

senhaj_h@reddit

If you take the time to configure well logging builtin, it’s all what you need and it’s very flexible and powerful

[-]

Grouchy-Peak-605@reddit

For many projects, a staged approach is best:

Start with Loguru. Its simplicity and clean output will serve you well during initial development and prototyping

2.Migrate to Structlog + Rich when your project grows and you need to scale to structured logging. The local experience remains excellent, and the production output becomes machine-readable for centralized log analysis.

Explore Logfire when your application is more mature and you require deep observability into complex, long-running processes common in AI applications.

[-]

vish4life@reddit

Airflow uses structlog, so do I. No regrets really. Just pick one and move on.

https://github.com/apache/airflow/blob/bfbd90181a03f16f00da4e530803c69bd83ed274/airflow-core/pyproject.toml#L150

[-]

Hiker_Ryan@reddit

I used to use a 3rd party library but then they stopped security improvements and support. Can't remember which library it was but it got me thinking it was better to build a module I could use in multiple projects bases on the standard library. It maybe isn't the best visually but I am less concerned that it will become deprecated.

[-]

anx1etyhangover@reddit

I pretty much use pythons built in logging. I’ve been happy with it, but I don’t ask too much of it. It spits out what I want it to spit out and logs what I want it to log. =]

[-]

lifelite@reddit

It’s usually all anyone really needs. It can get a bit burdensome with multiprocessing, though.

[-]

singlebit@reddit

is there a logging problem with multiprocessknh?

[-]

WN_Todd@reddit

Pre optimizing logs is also a monstrous time sink. Plenty of parsers that'll make the canned logs nicer without prepaying the overhead on your app.

[-]

rooi_baard@reddit

You'll regret adding unnecessary dependencies when the built in logging is so good.

[-]

Immediate_Truck_1829@reddit

Loguru is the way to go!

[-]

sweet-tom@reddit

Structlog is again an option, although I haven't used it yet.

[-]

Delta-9-@reddit

Just as a general rule, going with what's in the standard library unless you specifically need something not offered there is always a safe choice. If other programmers join your project, they will (or should) be familiar with the standard library but they may not know the other library you picked. It's also held to the performance and security standards as the language implementation itself.

The safe choice isn't necessarily the best choice, but the bar is pretty high to pick something else, imo.

[-]

Ranteck@reddit (OP)

Great answer

[-]

Delta-9-@reddit

Thanks!

I should probably acknowledge the rare cases of 3rd party libraries that are so ubiquitous they may as well be in the standard lib, like requests. I don't know of any logging libraries that have reached that level of popularity, though I hope to see loguru get there.

[-]

xinaked@reddit

personally love loguru

[-]

nat5142@reddit

My two cents: learn the built-in logging module inside and out and if it actually has some limitations that are solved by another SDK, make the switch then.

[-]

aplarsen@reddit

This is really solid advice

[-]

fenghuangshan@reddit

just like other questions about python

you always have too many choices , it's hard to choose

so i prefer the builtin one

[-]

Pythonic-Wisdom@reddit

Builtin all the way, every day

[-]

ottawadeveloper@reddit

I'd just use default logging. You can get all of what you want with good config for the default logger and maybe a custom plugin for whatever log management tool yo want eventually

[-]

Competitive_Lie2628@reddit

Loguru, I used to use the built in bu it's so boring to have to write a new logger from scratch on every new project.

Loguru does all the setup for me.

[-]

Fun-Purple-7737@reddit

Logly

[-]

richieadler@reddit

It's evolving nicely to be a Rust-based loguru, but it's not there yet, I think.

[-]

extraordinaire78@reddit

I had created my own so that I can dynamically add extra to a few log entries.

[-]

sodennygoes@reddit

A cool one is richuru. Allows to make very nice logs using rich.
You can also leverage rich’s logging module with loguru this way:

from loguru import logger
from rich.logging import RichHandler
import sys

# Configure logging
def setup_logger(level: str = “INFO”):
    “””Set up a logger with RichHandler for better formatting and color support.”””
    logger.remove()  # Ensure no duplicated logs
    logger.add(sys.stdout, format=“{message}”)
    logger.configure(
        handlers=[{“sink”: RichHandler(), “format”: “{message}”, “level”: level}]
    )
    return logger

setup_logger()

[-]

unapologeticjerk@reddit

If you've ever used Textual for anything, this is essentially what textual-dev is/has built in as the TextualLogger class. It's nice because it also works with any third-party library stdout streams as the console logger, complete with the rich treatment.

[-]

lexplua@reddit

logury is pretty simple to use, however I just removed it from my project completely. It hides implementation details too well. I had problems when I had to do simple things like iterate over my handlers. Or shutdown logging to existing handlers if I need at some point manipulate the log file and set up logging again

[-]

eriky@reddit

I like to use the default Python logger enhanced with Rich. Rich supplies a logging handler which will format and colorize text written by Python’s logging module.

[-]

trllnd@reddit

I like python-json-logger

[-]

me_myself_ai@reddit

I've been very happy with logfire, though I haven't made use of their main feature yet (telemetry streaming to their webgui) so take that with a huge grain of salt lol. The readibility is great, and most importantly, it naturally ties into logging.py!

[-]

luigibu@reddit

Im using logfire, and is pretty cool and easy to set. Not experience in any other tool.

[-]

mighalis@reddit

Loguru made my life a lot easier. It outputs rich on the terminal and with one line connects with the logfire (also awesome)

[-]

Ranteck@reddit (OP)

you connect loguru with logfire? nice, how is it feel?

[-]

mighalis@reddit

Yeah it will create a new sink and send your logs"structured" to the cloud. https://logfire.pydantic.dev/docs/integrations/loguru/

[-]

forgotpw3@reddit

I like rich