Welcome, guest | Sign In | My Account | Store | Cart

Notice! PyPM is being replaced with the ActiveState Platform, which enhances PyPM’s build and deploy capabilities. Create your free Platform account to download ActivePython or customize Python with the packages you require and get automatic updates.

pypm install django-logdb

How to install django-logdb

  1. Download and install ActivePython
  2. Open Command Prompt
  3. Type pypm install django-logdb
 Python 2.7Python 3.2Python 3.3
Windows (32-bit)
1.1 Available View build log
1.0 Available View build log
Windows (64-bit)
1.1 Available View build log
1.0 Available View build log
Mac OS X (10.5+)
1.1 Available View build log
1.0 Available View build log
Linux (32-bit)
1.1 Available View build log
1.0 Available View build log
Linux (64-bit)
1.1 Available View build log
1.0 Available View build log
Lastest release
version 1.1 on Jan 5th, 2011


Django-logdb enables you to log entries to a database, aggregate and act on them with certain rules, and gives you more insight in what's going on.

Django-logdb requires Django 1.1 and higher.


Django-logdb has a custom logging handler that writes log entries to the database. It therefore integrates nicely with your existing logging configuration and you can decide what log entries are written to the database.

The Django admin site is extended with a graphical view of recent log entries to provide more insight in what is going on. The log messages are grouped by log level or "type of log entry".

To minimize database access, aggregation is done via a Django command that you can call periodically (as a cronjob).


The easiest way to install the package is via setuptools:

System Message: WARNING/2 (<string>, line 28)

Literal block expected; none found.

easy_install django-logdb

Once installed, update your Django settings.py and add djangologdb to your INSTALLED_APPS:

System Message: WARNING/2 (<string>, line 33)

Literal block expected; none found.

INSTALLED_APPS = ( 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', ... 'djangologdb', )

In your Django urls.py, include the djangologdb.urls before the admin:

System Message: WARNING/2 (<string>, line 44)

Literal block expected; none found.

urlpatterns = patterns('', ... (r'^admin/djangologdb/', include('djangologdb.urls')), ... (r'^admin/', include(admin.site.urls)), )

Optionally, if you want to log exceptions, add the middleware:

System Message: WARNING/2 (<string>, line 53)

Literal block expected; none found.

MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', ... 'djangologdb.middleware.LoggingMiddleware', )

Run python manage.py syncdb to create the database tables.

Setup logging

Now, for the actual logging part, you should use the database logging handler. There are two ways to do this: Using only Python code, or, by using a configuration file. Both methods are explained below.

To add this handler via Python to, for example, your root logger, you can add the following to your Django settings.py:

System Message: WARNING/2 (<string>, line 73)

Literal block expected; none found.

import logging from djangologdb.handler import DjangoDatabaseHandler, add_handler

logging.basicConfig(level=logging.DEBUG) logger = logging.getLogger()

# A bug in Django causes the settings to load twice. Using # this handler instead of logging.addHandler works around that. add_handler(logger, DjangoDatabaseHandler())

To use this handler via a logging configuration file, simply import the handlers module from djangologdb in your Django settings.py before loading the configuration from a file:

System Message: WARNING/2 (<string>, line 87)

Literal block expected; none found.

from djangologdb import handlers logging.config.fileConfig(...)

Then in your logging configuration file, you can add it from the handlers namespace and add it to any logger you want:


System Message: ERROR/3 (<string>, line 94)

Inconsistent literal block quoting.


[logger_root] level=NOTSET handlers=djangologdb

[handler_djangologdb] class=handlers.DjangoDatabaseHandler args=()


You can set the following settings in your Django settings.py file:

LOGDB_HISTORY_DAYS The number of days to show in the various graphs.


System Message: WARNING/2 (<string>, line 114)

Literal block expected; none found.


LOGDB_INTERVAL The timedelta between each datapoint in the various graphs.


System Message: WARNING/2 (<string>, line 121)

Literal block expected; none found.

LOGDB_INTERVAL = datetime.timedelta(1) # 1 day

LOGDB_RULES Define rules to create a new log entry when certain conditions are true.


System Message: WARNING/2 (<string>, line 128)

Literal block expected; none found.

LOGDB_RULES = [{ # If 3 logs with level WARNING or higher occur in 5 minutes or # less, create a new log with level CRITICAL. 'conditions': { 'min_level': logging.WARNING, 'qualname': '', 'min_times_seen': 3, 'within_time': datetime.timedelta(0, 5 * 60), }, 'actions': { 'level': logging.CRITICAL, } }]

LOGDB_LEVEL_COLORS Set colors to use in the graph for level based datasets.


System Message: WARNING/2 (<string>, line 148)

Literal block expected; none found.

LOGDB_LEVEL_COLORS = { logging.DEBUG: '#c2c7d1', logging.INFO: '#aad2e9', logging.WARNING: '#b9a6d7', logging.ERROR: '#deb7c1', logging.CRITICAL: '#e9a8ab', }

LOGDB_MEDIA_ROOT Set the absolute path to the directory of django-logdb media.


System Message: WARNING/2 (<string>, line 162)

Literal block expected; none found.

LOGDB_MEDIA_ROOT = os.path.join(djangologdb.__path__[0], 'media')

LOGDB_MEDIA_URL Set the URL that handles the media served from LOGDB_MEDIA_ROOT. Make sure to add a trailing slash at the end. If settings.DEBUG=True, the media will be served by Django.


System Message: WARNING/2 (<string>, line 171)

Literal block expected; none found.

LOGDB_MEDIA_URL = '/admin/djangologdb/media/'


aggregate_logs Aggregates log entries and triggers any action with matching rules.

Usage: python django-admin.py aggregate_logs

Options: -s, --skip-actions Do not use the rules to create new logs. --cleanup=CLEANUP Specifies the number of days to keep log entries and deletes the rest.


The graph doesn't show in the Django admin. If you don't have settings.DEBUG=True, the media will not be served by Django. You should copy the media directory to your own media directory and set LOGDB_MEDIA_ROOT and LOGDB_MEDIA_URL accordingly.


System Message: WARNING/2 (<string>, line 197)

Literal block expected; none found.

LOGDB_MEDIA_ROOT = '/myproject/media/djanglogdb/' LOGDB_MEDIA_URL = '/media/djanglogdb/'

Instead of copying, you can also use Apache's Alias directive to serve the static files, as you probably also did for Django's own media files. It is explained here: http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/#serving-media-files This boils down to adding the following line to your VirtualHost entry:

System Message: WARNING/2 (<string>, line 205)

Literal block expected; none found.

Alias <your LOGDB_MEDIA_URL setting> <path to django-logdb media dir>


System Message: WARNING/2 (<string>, line 209)

Literal block expected; none found.

Alias /admin/djangologdb/media/ /myproject/eggs/django_logdb-0.9.5-py2.6.egg/djangologdb/media/

The Django admin pages for django-logdb load very slow. If you have a lot of datapoints in the graph, it executes a lot of queries. This can take some time. You should decrease the time period or increase the interval. By default, the last 30 days with an interval of 1 day is used, resulting in 30 datapoints. See the settings LOGDB_HISTORY_DAYS and LOGDB_INTERVAL.

Why is there 1 query executed for each datapoint? Django does not (yet) allow to group by certain date information. Even though a timestamp is stored in the database, there is no way to tell the Django ORM to group by day, by hour, etc. The solution I used was to filter/limit the results needed to construct 1 datapoint.

When I run my tests, I see ERROR:djangologdb.middleware [...] When you run, for example, the testproject, the configuration is set so that any error is also displayed on sys.stderr. As you you'll see, the tests all succeed but the exceptions that are tested are just displayed in the console. This is not an error!

You can disable this behaviour by disabling logging to the console for your test configuration (ie. remove the handler).

Why are the templates extending a local version of the Django base templates? This is done for optimal flexibility regarding custom templates. Skins like Grappelli override a lot of templates and sometimes you want to be able to change and use the base template in django-logdb and change some specifics in the django-logdb template itself without copying all the base template stuff.

Test project

The testproject is a sample installation of django-logdb. It provides a settings file for Django 1.1 and Django 1.2, just to run it.

In the directory below the testproject, create a virtual environment:

$ virtualenv .
$ source bin/activate

Install Django and run the internal server using one of the setting files for your Django version.

$ bin/python bin/pip install django $ bin/python bin/django-admin.py runserver --settings=testproject.settings_django_1_1


To the various people that helped making this project better and better:

  • Maciek Szczesniak (vvarp)
  • Victor van den Elzen

Thanks to David Cramer for his work on django-db-log (http://github.com/dcramer/django-db-log/) on which this package was based.


  • Changed jQuery to use noConflict to be more compatible with other frameworks.
  • Added setting files for Django 1.1 and Django 1.2.
  • Added short howto on getting the testproject up and running.
  • Fixed an issue with applications that add log entries to the tables before

System Message: WARNING/2 (<string>, line 280)

Bullet list ends without a blank line; unexpected unindent.

the unit tests are run, which caused unit tests for django-logdb to fail.

  • Fixed a problem with django-logdb test suite being used in a project with

System Message: WARNING/2 (<string>, line 285)

Bullet list ends without a blank line; unexpected unindent.

an existing logging configuration. - Updated testproject to Django 1.2. - Added the license (MIT) file (sorry Jacob).

  • Added templates for LogEntry in manifest file.
  • Fixed a problem that occurred when something other then a string was passed as

System Message: WARNING/2 (<string>, line 293)

Bullet list ends without a blank line; unexpected unindent.

a message.

  • Use int64-friendly field for storing thread ID (vvarp).
  • Fixed a problem with invalid characters passed as logging argument.
  • Aggregation of logs is now done in a transaction.
  • Changed templates to allow for easier customization.
  • Fixed an error in tests.py that occured with Python 2.5.
  • Added 2 new settings: INTERVAL and HISTORY_DAYS with the defaults as before.
  • Moved JS code from extrastyle to extrahead block in templates.
  • Updated README to include examples to serve the media.
  • Fixed a problem with saving objects or instances as log record arguments

System Message: WARNING/2 (<string>, line 313)

Bullet list ends without a blank line; unexpected unindent.

(picklefield). - Fixed a problem with unicode characters in the arguments. - Replaced library picklefield with JSONField and TupleField.

  • Removed Django as a requirement (although it's still required) to prevent

System Message: WARNING/2 (<string>, line 320)

Bullet list ends without a blank line; unexpected unindent.

conflicts with djangorecipe.

  • Fixed manifest to include changes.
  • Added template for LogEntry view.
  • Renamed templates to Django's default. You can still override them.
  • Initial release on PyPI.

Subscribe to package updates

Last updated Jan 5th, 2011

Download Stats

Last month:20

What does the lock icon mean?

Builds marked with a lock icon are only available via PyPM to users with a current ActivePython Business Edition subscription.

Need custom builds or support?

ActivePython Enterprise Edition guarantees priority access to technical support, indemnification, expert consulting and quality-assured language builds.

Plan on re-distributing ActivePython?

Get re-distribution rights and eliminate legal risks with ActivePython OEM Edition.