Skip to main content

Django Database Based Automated Logging - finally solved and done in a proper way.

Project description

Django Database Based Automated Logging

Build Status

Notice: Most of this will be moved into a wiki.

What is Django-Automated-Logging (DAL)?

TL;DR: DAL is a package to automatically track changes in your project, ranging from simple logging messages, to model changes or requests done by users.

You can decide what you want to do and how. DAL allows fine-grained customization and filtering with various methods.


Django Fully Automated Logging - finally solved and done properly.

How to install? pip install django-automated-logging or poetry add django-automated-logging

What is the purpose?

The goal of DAL is to provide an easy, accessible and DRY way to log the inner working of you applications. Ultimately giving you the chance to easily see what is happening without excessive manual print/logging statements.

The application uses minimal requirements and is performant.

How does it work?

The application facilitates the built-in logging mechanic by providing a custom handler, that just needs to be added to the LOGGING configuration.

DAL uses native Django signals to know what is happening behind the scenes without injecting custom code.

Minimal Setup

You can also configure DAL to only log to a file and not to a database. You just need to enable DAL and not include the custom logging handler.

Detailed Information


  1. Easy Setup
  2. Extensible
  3. Feature-Rich
  4. Completely Automated
  5. Built-In Database Logger
  6. No custom code needs to be inserted into your codebase
  7. Can capture logging messages unrelated to the package itself
  8. Only does what it needs to do, no extra bells and whistles.


Initial Configuration is via your projects

  1. INSTALLED_APPS append: 'automated_logging'
  2. MIDDLEWARE append: 'automated_logging.middleware.AutomatedLoggingMiddleware'
  3. LOGGING section handlers add:
       'db': {
           'level': 'INFO',
           'class': 'automated_logging.handlers.DatabaseHandler',
  4. LOGGING section loggers add: (only required if database logging desired)
       'automated_logging': {
           'level': 'INFO',
           'handlers': ['db'],
           'propagate': True,
       'django': {
           'level': 'INFO',
           'handlers': ['db'],
           'propagate': True,
  5. execute: python migrate automated_logging

LOGGING configuration details are just recommendations.


Further configuration can be done via the variable AUTOMATED_LOGGING. The defaults are:

    "globals": {
        "exclude": {
            "applications": [
    "model": {
        "detailed_message": True,
        "exclude": {"applications": [], "fields": [], "models": [], "unknown": False},
        "loglevel": 20,
        "mask": [],
        "max_age": None,
        "performance": False,
        "snapshot": False,
        "user_mirror": False,
    "modules": ["request", "unspecified", "model"],
    "request": {
        "data": {
            "content_types": ["application/json"],
            "enabled": [],
            "ignore": [],
            "mask": ["password"],
            "query": False,
        "exclude": {
            "applications": [],
            "methods": ["GET"],
            "status": [200],
            "unknown": False,
        "ip": True,
        "loglevel": 20,
        "max_age": None,
    "unspecified": {
        "exclude": {"applications": [], "files": [], "unknown": False},
        "loglevel": 20,
        "max_age": None,

You can always inspect the current default configuration by doing:

from pprint import pprint
from automated_logging.settings import default
from automated_logging.helpers import namedtuple2dict


Recommendation: include the globals application defaults as those modules can be particularly verbose or be duplicates.

There are three different independent modules available request (for request logging), unspecified (for general logging messages), and models (for model changes). They can be enabled and disabled by including them in the modules configuration.

The loglevel setting indicates the severity for the logging messages sent from the module. INFO (20) or DEBUG (10) is the right call for most cases.

New in 6.x.x: Saving can be batched via the batch setting for the handler.

New in 6.x.x: Saving can be threaded by thread: True for the handler settings. This is highly experimental

New in 6.x.x: every field in exclude can be either be a glob (prefixing the string with gl:), a regex (prefixing the string with re:) or plain (prefixing the string with pl:). The default is glob.


You can explicitly exclude or include views/models, by using the new decorators.

from automated_logging.decorators import include_view, include_model, exclude_view, exclude_model

def view(request):

@include_model(operations=None, fields=None)
@exclude_model(operations=[], fields=[])
class ExampleModel:

include always takes precedence over exclude, if you use multiple include or exclude instead of overwriting they will update/extend the previous definition.

operations can be either create, modify, delete. fields is a list model specific fields to be included/excluded. methods is a list methods to be included/excluded.

Class-Based Configuration

Class-Based Configuration is done over a specific meta class LoggingIgnore. Decorators take precedence over class-based configuration, but class-based configuration takes precedence over AUTOMATED_LOGGING configuration.

class ExampleModel:
    class LoggingIgnore:
        complete = False
        fields = []
        operations = []

as described above operations and fields work the same way. complete = True means that a model is excluded no matter what.


Version 6.0.0

  • Added: batch settings to the handler
  • Added: decorators
  • Added: class-based configuration
  • Added: request and response bodies can now be saved
  • Added: regex, glob matching for settings
  • Updated: settings
  • Updated: models
  • Updated: to current django version (2.2, 3.0, 3.1)
  • Updated: DAL no longer stores internal information directly, but now has a custom _meta object injected.
  • Updated: project now uses black for formatting
  • Updated: internals were completely rewritten for greater maintainability and speed.
  • Fixed:
  • Fixed:
  • Moved: max_age is now part of the configuration.

Version 5.0.0

  • Added: maxage handler setting to automatically remove database entries after a certain amount of time.
  • Added: query string in requests can now be enabled/disabled (are now disabled by default)
  • Fixed: Value and URI could be longer than 255 characters. DAL would throw an exception. This is fixed.


Version 6.1.x

  • archive options
  • decorators greater flexibility
  • wiki -> documentation
  • make django-ipware optional via extras
  • and more!

Version 7.x.x

  • implementation of a git like versioning interface

Version 8.x.x

  • temporary world domination

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django-automated-logging-6.1.3.tar.gz (47.4 kB view hashes)

Uploaded source

Built Distribution

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page