Django Request Logging

Common errors

• Logs are not appearing in the console/file for requests.

  cause The `django.request` logger is not properly configured in Django's `LOGGING` settings, or `propagate` is set to `False` without an attached handler.
  fix Verify that `LOGGING['loggers']['django.request']` exists, has a handler (e.g., 'console'), and its `level` is set appropriately (e.g., 'DEBUG'). Also, ensure `propagate: False` is used correctly with a handler for `django.request`.

• Logs are duplicated in the console or file.

  cause The `django.request` logger is propagating messages to a parent logger that also has a handler configured.
  fix Set `propagate: False` for the `django.request` logger in your `LOGGING` settings to prevent message duplication if a parent logger also processes these messages.

• Logs are too verbose or not verbose enough.

  cause The log level for the `django.request` logger is set too high or too low, or specific settings like `REQUEST_LOGGING_DATA_LOG_LEVEL` are not configured.
  fix Adjust `LOGGING['loggers']['django.request']['level']` to control general verbosity. Use `REQUEST_LOGGING_DATA_LOG_LEVEL` and `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL` in `settings.py` to fine-tune data and error log levels respectively.

• Logs appear without color, even in the console.

  cause Colorization is disabled by default or explicitly turned off, especially if logging to a file.
  fix Ensure `REQUEST_LOGGING_ENABLE_COLORIZE = True` (which is the default) in your `settings.py`. If logging to a file, remember that ANSI color codes might not be desired in file output.

Warnings

• gotcha Sensitive data might be logged by default. The middleware logs request and response bodies.
  Fix: Use the `@no_logging` decorator on views handling sensitive data. For example, `@no_logging()` will disable all logging for that view, while `@no_logging(log_headers=False, log_body=False)` allows partial logging.
• gotcha Incorrect Django `LOGGING` configuration can lead to missing or duplicated logs.
  Fix: Ensure a handler is defined for the `django.request` logger in your `LOGGING` dictionary. Set `propagate: False` for `django.request` to prevent logs from being processed multiple times by other handlers.
• gotcha Extensive request logging, especially to a database, can impact application performance.
  Fix: While `django-request-logging` primarily logs to `StreamHandler` (console), be mindful of log levels. Consider reducing the `level` for `django.request` in production (e.g., to `INFO` or `WARNING`) or using filters to log only critical requests to avoid excessive I/O.
• gotcha The default log levels for different HTTP status codes might be unexpected. By default, 4xx-5xx responses are logged at ERROR level, others at INFO/DEBUG.
  Fix: Adjust the `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL` and `REQUEST_LOGGING_DATA_LOG_LEVEL` settings in `settings.py` to match your desired logging verbosity for different response types. For example, `REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL = logging.WARNING`.

Install

• pip install django-request-logging Install with pip

Imports

• LoggingMiddleware

  from request_logging.middleware import LoggingMiddleware

  The primary middleware to add to your Django MIDDLEWARE settings.
• no_logging

  from request_logging.decorators import no_logging

  Decorator to disable logging for specific views, especially useful for sensitive data.

Quickstart

To quickly set up `django-request-logging`, add `request_logging.middleware.LoggingMiddleware` to your `MIDDLEWARE` list in `settings.py`. Crucially, configure your Django `LOGGING` settings to handle the `django.request` logger. This logger is where `django-request-logging` outputs its messages. Setting `propagate: False` for `django.request` prevents log messages from being handled by parent loggers and potentially duplicated. You can also use the `@no_logging` decorator on views to control logging behavior for sensitive endpoints.

import logging

# settings.py

INSTALLED_APPS = [
    # ...
    # 'request_logging', # Not strictly required, but can be added if you want to explicitly signal app presence
    # ...
]

MIDDLEWARE = [
    # ... other middleware
    'request_logging.middleware.LoggingMiddleware',
    # ... other middleware
]

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
        },
    },
    'loggers': {
        'django.request': {
            'handlers': ['console'],
            'level': 'DEBUG', # Change debug level as appropriate
            'propagate': False, # Important: prevent duplication if other loggers handle 'django'
        },
    },
    'root': {
        'handlers': ['console'],
        'level': 'WARNING',
    }
}

# Optional: Customize log levels for specific HTTP status codes
# REQUEST_LOGGING_HTTP_4XX_LOG_LEVEL = logging.WARNING
# REQUEST_LOGGING_DATA_LOG_LEVEL = logging.INFO
# REQUEST_LOGGING_ENABLE_COLORIZE = False # Disable color for file logging

# Example usage in a view to disable logging
from django.http import HttpResponse
from request_logging.decorators import no_logging

@no_logging()
def sensitive_view(request):
    return HttpResponse("This view's requests/responses are not logged.")

@no_logging(log_headers=False, log_body=False)
def partially_sensitive_view(request):
    return HttpResponse("This view logs only metadata, no headers or body.")