# How Debug Logging Is Configured in the Yappuccino Django Application

> Learn how debug logging is configured in the Yappuccino Django application. Explore settings for development and production environments in the repository.

- Repository: [Ja'farbek Yusupov/yappuccino](https://github.com/jafarbekyusupov/yappuccino)
- Tags: internals
- Published: 2026-03-04

---

**The Yappuccino application configures debug logging through a centralized `LOGGING` dictionary in [`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py) that defines console and file handlers for development, while [`blogpost/production.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/production.py) overrides this with a streamlined console-only setup for production environments.**

Understanding how debug logging is configured in a Django application is essential for monitoring behavior during development and troubleshooting issues in production. In the Yappuccino project, logging behavior is explicitly defined through Python's standard `logging` module integrated with Django's configuration system. This setup separates development verbosity from production efficiency using environment-specific settings files.

## Central Logging Configuration in settings.py

The primary debug logging configuration resides in **[`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py)** beginning around line 44. This file contains a standard Python `LOGGING` dictionary that Django automatically processes when the settings module loads.

The configuration defines two distinct handlers and two named loggers, plus root logger safeguards to prevent suppression of third-party logging.

### Console and File Handlers

The configuration establishes two handlers to capture debug output:

- **Console Handler**: Uses `logging.StreamHandler` at `DEBUG` level to stream messages to stdout. This is defined around lines 44-48 in [`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py).
- **File Handler**: Uses `logging.FileHandler` at `DEBUG` level, writing all messages to a file named `debug.log`. This configuration appears around lines 55-61.

```python

# Example handler configuration from blogpost/settings.py

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'level': 'DEBUG',
        },
        'file': {
            'class': 'logging.FileHandler',
            'filename': 'debug.log',
            'level': 'DEBUG',
        },
    },
    # ... loggers configuration follows

}

```

### Logger Hierarchy

The `LOGGING` dictionary defines specific loggers for different components:

- **`django` logger**: Configured with `handlers: ['console', 'file']` and `level: INFO`. This captures Django framework messages while avoiding excessive debug noise from internal Django operations.
- **`blog` logger**: Configured with `handlers: ['console', 'file']` and `level: DEBUG`. This application-specific logger captures detailed debug output from custom business logic.

The root logger setting `disable_existing_loggers: False` ensures that loggers not explicitly defined in this configuration—such as those from third-party packages—remain functional.

## Production Logging Overrides

When the application runs in production mode, **[`blogpost/production.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/production.py)** overrides the development logging configuration. Around lines 97-107, this file redefines the `LOGGING` dictionary to use a simpler, more performant setup suitable for production environments.

The production configuration:
- Retains only the **console handler** (removes the file handler to avoid disk I/O and log file management issues)
- Sets the console level to **INFO** (suppressing DEBUG messages to reduce noise and improve performance)
- Maintains the same logger names but adjusts their effective levels through the handler configuration

```python

# Simplified production logging configuration from blogpost/production.py

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'console': {
            'class': 'logging.StreamHandler',
            'level': 'INFO',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['console'],
            'level': 'INFO',
        },
        'blog': {
            'handlers': ['console'],
            'level': 'INFO',
        },
    },
}

```

## Using the Configured Loggers in Code

To utilize the debug logging configuration in application code, developers instantiate loggers using the names defined in the settings. The standard pattern appears throughout the codebase, particularly in **[`users/views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/users/views.py)** and **[`blog/api_views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blog/api_views.py)**.

The implementation follows Python's standard logging module practices:

```python
import logging

# Instantiate the logger using the name defined in settings.py

logger = logging.getLogger('blog')

def my_view(request):
    # Debug level message - only appears in development (file and console)

    logger.debug('Entering my_view with request method: %s', request.method)
    
    # Informational message - appears in both development and production

    logger.info('Successfully processed request for user: %s', request.user)
    
    try:
        # Business logic here

        result = perform_operation()
        logger.debug('Operation result: %s', result)
    except Exception as e:
        # Error level - always logged

        logger.error('Operation failed: %s', str(e))
        raise

```

In **[`users/views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/users/views.py)** (around lines 2-5), the logger is instantiated at module level to capture authentication and user management debug information. Similarly, **[`blog/api_views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blog/api_views.py)** (around lines 13-19) uses the `blog` logger to track API request processing and database query performance.

## Summary

- **Debug logging is configured** in [`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py) using a standard Python `LOGGING` dictionary with console and file handlers both set to `DEBUG` level.
- **Two primary loggers** are defined: `django` (INFO level) for framework messages and `blog` (DEBUG level) for application-specific output.
- **Production overrides** in [`blogpost/production.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/production.py) simplify the configuration to console-only INFO-level logging, removing the file handler and suppressing debug messages.
- **Implementation** requires instantiating loggers via `logging.getLogger('blog')` and using standard methods like `logger.debug()` and `logger.info()`.

## Frequently Asked Questions

### Where is the debug logging configured in the Yappuccino application?

The debug logging is configured in **[`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py)** starting around line 44. This file contains the `LOGGING` dictionary that defines handlers, loggers, and formatting for the development environment. A separate production configuration exists in [`blogpost/production.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/production.py) that overrides these settings for deployed environments.

### What is the difference between development and production logging configurations?

In development ([`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py)), the configuration includes both a **console handler** and a **file handler** (`debug.log`), both set to `DEBUG` level to capture verbose output. In production ([`blogpost/production.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/production.py)), the configuration strips away the file handler and sets the console handler to `INFO` level, reducing log volume and eliminating disk I/O concerns while still capturing important operational messages.

### How do I use the blog logger in my views?

Import Python's `logging` module and instantiate the logger using the name defined in settings: `logger = logging.getLogger('blog')`. Place this at the module level in your view file (as seen in [`users/views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/users/views.py) and [`blog/api_views.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blog/api_views.py)). Then use methods like `logger.debug()`, `logger.info()`, or `logger.error()` throughout your view functions to capture application behavior.

### What log file does the application create during development?

During development, the application creates a file named **`debug.log`** in the project root (or the working directory from which the application is run). This is configured in [`blogpost/settings.py`](https://github.com/jafarbekyusupov/yappuccino/blob/main/blogpost/settings.py) via the `logging.FileHandler` with the filename parameter set to `'debug.log'`. This file captures all DEBUG level messages from both the `django` and `blog` loggers.