# Getting more clues from Python's logging module

DevFeed: [Getting more clues from Python's logging module](<https://devfeed.tech/articles/getting-more-clues-from-python-s-logging-module-19707.md>)

Original publisher: [Read original article](<https://word.bitly.com/post/69080588278>)

Author: Wordbitly

Published: 2013-12-05T16:01:54Z

Content type: tutorial

Language: en

Sources: [Bitly](<https://devfeed.tech/sources/bitly.md>)

Topics: [Python](<https://devfeed.tech/topics/python.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [Django](<https://devfeed.tech/topics/django.md>)

Tags: [applications](<https://devfeed.tech/tags/applications.md>), [bug](<https://devfeed.tech/tags/bug.md>), [developers](<https://devfeed.tech/tags/developers.md>), [development](<https://devfeed.tech/tags/development.md>), [django](<https://devfeed.tech/tags/django.md>), [exception](<https://devfeed.tech/tags/exception.md>), [logging](<https://devfeed.tech/tags/logging.md>), [python](<https://devfeed.tech/tags/python.md>), [troubleshooting](<https://devfeed.tech/tags/troubleshooting.md>), [web-applications](<https://devfeed.tech/tags/web-applications.md>)

## AI overview

The article discusses diagnosing bugs and exceptions in Python web applications, especially production issues where development debug tools are unavailable. It describes how limited logging can create a repeated cycle of adding logging, deploying it, and waiting for the error to recur, and introduces more informative logging configuration as a way to gather useful context.

## Source excerpt

During development of Python web applications, there are a lot of tools that can help provide clues about what caused a bug or exception. For example, Django's default debug error page prints out local variables at every stack frame when there's an unhandled exception. The popular django_debugtoolbar adds more information. In a similar vein there are things like Pyramid's pyramid_debugtoolbar and its predecessor WebError. But when troubleshooting production issues, those tools aren't available, for good reason: We need the useful information to be exposed to developers, not overwhelming our end users nor exposing sensitive information to malicious eyes. So, we turn to logging instead. But that provides a lot less information out of the box. So at bitly, we often found ourselves in an irritating cycle that went something like this: Sometime soon after a deploy, we notice an unusual number of exceptions being logged. (Let's say that old Python chestnut, 'NoneType' object is unsubscriptable.) So we know that we have some code that is expecting a dict or list and getting None instead. We may decide the error is not critical enough to roll back without first trying to diagnose the underlying cause, but of course we want to fix it quickly. The pressure is on. We find the traceback in our logs. It looks like: Python traceback example But where's the None? Is it response['data'] or is it one of the entry values? We have no way to see. (Tip: We can actually tell that it's not response['data']['subtotal']. Do you know why? Would you remember that while under pressure to fix a production bug?) We try, and fail, to provoke the error on our local development or staging environments. Then we add some logging code. We get a quick code review and deploy the logging code. We wait for the error to happen again. We find the log message and realize we forgot to log everything we wanted to see, or we need more contextual information. Go back 3 steps and repeat as needed. Finally we can