Notes on Loggers in Python

Roel M. Hogervorst


Categories: blog Tags: 100DaysToOffload logging python

Python loggers are very versatile but debugging what goes wrong is annoying. Here are a few things I learned or have to look up all the time. (I guess this works for any logging system, not just python, but I’ve only worked with python and the R {logger} package)



Loggers are hierarchical

You call a logger by name with logging.getlogger(name).

Loggers have hierarchical namespace, which is a fancy way to say that the ordering goes like this: if you don’t specify a logger name (, you call the root logger. If you use logger the logger above is called name.


Convention is to use the filename for the logger, since you usually order your modules in an hierarchical way. you call that logger like so:

logger = logging.getLogger(__name__)

Why does this matter? If a logger has no handler defined, it looks in the logger above.

So if you define a handler for name all the underlying loggers (name.baz, (in namespace terms) will use that one as well. Loggers default to propagate too. This leads to interesting situations:

Log records

Log records have as most important components:

But you can add extra information in log records. The dagster logging records contain a component dagster_meta, that component is a huge dictionary of all the relevant information for a dagster run.

Stopping certain messages from getting into your logs

I’m publishing this as part of 100 Days To Offload. You can join in yourself by visiting, post - 5/100 2023

Find other posts tagged #100DaysToOffload here