Logging while developing and afterward

While developing I sometimes need some extra insight in what is going on. Sometimes I use import pdb; pdb.set_trace() but this is more like the nuclear option and it only works while developing. For error catching I use sentry which works great if an exception is triggered. But I feel there is a middle ground between falling back into a debug shell and throwing an exception.
So how would or should I log stuff happening in my Django instance? For convenience I almost always deploy with docker and docker compose so this might be something to consider.

Also on s broader scope: What should I be logging?

Thanks for your advice!

1 Like

The Django documentation has a great section on logging if you haven’t read it before. I’d be doing it a disservice by paraphrasing anything it says as I think that it does a very good job of describing a surprisingly complex topic. A hard thing for me was getting my LOGGING setting correct, between what Django recommends as a default, what the Sentry Python SDK recommends, and what logging activity I wanted to see myself…it gets a bit hairy.

A big takeaway is that Sentry’s log handler will collect your log messages and surface them as part of your Sentry event. This is useful for providing more application context to why a particular error state may have occurred.

You can also log non-exception events in Sentry (e.g. you may want to catch an exception and do something nicer for the user, but still send that exception to Sentry). Unsure if you are aware of this. I find this very helpful when keeping track of the occurrences of certain corner cases and weird application state that my application will handle for the user (in a less-than-desired way), but that I still want to keep track of with the sort of granular trove of information I am used to receiving from Sentry.

1 Like