# What Logging Framework Is Used in MobileAudit and How Celery Worker Errors Are Tracked

> Discover how MobileAudit uses the Python logging library and tracks Celery worker errors through explicit exception handling and persistent task state.

- Repository: [Mónica Pastor/mobileaudit](https://github.com/mpast/mobileaudit)
- Tags: internals
- Published: 2026-03-07

---

**MobileAudit uses the standard Python `logging` library for all application and Celery worker logs, tracking errors through explicit exception handling in task modules and persistent task state via Celery’s result backend.**

The MobileAudit open-source project (mpast/mobileaudit) implements a comprehensive logging strategy using Python's built-in capabilities to monitor both the Django web application and asynchronous Celery workers. By combining structured logging configuration with Celery's native error persistence mechanisms, the application maintains full visibility into mobile security scanning operations.

## Python Logging Framework Configuration

MobileAudit configures the standard **Python `logging`** library through Django's `LOGGING` dictionary in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py) (lines 194-207). The setup creates a dedicated logger named **`app`** using `logging.getLogger('app')`, which serves as the primary channel for all application diagnostics.

The configuration defines a `standard` formatter outputting `[%(levelname)s] %(asctime)-15s - %(message)s`, and attaches two handlers to the `django` logger entry: a `FileHandler` writing to `logs/debug.log` and a `StreamHandler` for console output. Both handlers propagate messages from the `app` logger, ensuring that Celery worker output and Django application logs follow identical formatting and destination rules.

## How Celery Worker Errors Are Tracked

Error tracking in MobileAudit's Celery implementation operates through two complementary mechanisms that capture both real-time exceptions and persistent failure states.

### Explicit Error Logging in Task Modules

The task implementation in [`app/worker/tasks.py`](https://github.com/mpast/mobileaudit/blob/main/app/worker/tasks.py) (lines 20-26) wraps result-retrieval logic in defensive `try/except` blocks. When accessing a task's `info` or `result` attributes triggers an exception, the code immediately logs the error using the configured `app` logger:

```python

# app/worker/tasks.py

import logging

logger = logging.getLogger('app')  # Obtains the configured app logger

def scan_state(request, id):
    try:
        data = job.info or job.result
    except Exception as exc:
        logger.error(exc)  # Logs full traceback to debug.log and console

```

This approach ensures that worker-side failures generate immediate log entries with complete stack traces, written to both the file handler (`logs/debug.log`) and the console handler according to the settings defined in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py).

### Task State Persistence via Result Backend

MobileAudit leverages Celery’s built-in result backend to maintain durable records of task execution status and failure details. The configuration in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py) (lines 186-193) specifies the backend storage:

```python

# app/config/settings.py

CELERY_BROKER_URL = env('CELERY_BROKER_URL', 'amqp://guest:guest@rabbitmq:5672')
CELERY_RESULT_BACKEND = env('CELERY_RESULT_BACKEND', 
                            'db+sqlite:///rabbitmq/results.sqlite')

```

Within [`app/worker/tasks.py`](https://github.com/mpast/mobileaudit/blob/main/app/worker/tasks.py) (lines 12-14), tasks update their progress using `current_task.update_state(...)`, storing metadata that includes execution status. When a client polls scan status through the `scan_state` view, the application uses `AsyncResult` to query the backend. If a task fails, the result backend retains the exception details, which the view layer can access and log using the same `logger.error()` pattern, creating a redundant record of the failure across both the logging infrastructure and the Celery result store.

## Summary

- MobileAudit uses the **standard Python `logging`** library, configured in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py), with a dedicated `app` logger that writes to `logs/debug.log` and the console.
- Celery worker errors are captured immediately via **`logger.error(exc)`** in [`app/worker/tasks.py`](https://github.com/mpast/mobileaudit/blob/main/app/worker/tasks.py) when task result access raises exceptions.
- The **Celery result backend** (configured as `db+sqlite:///rabbitmq/results.sqlite` by default) persists task states and failure metadata, enabling asynchronous error retrieval through `AsyncResult`.
- Error tracking spans both real-time log files and durable backend storage, ensuring no worker failures are lost during mobile security scanning operations.

## Frequently Asked Questions

### What logging framework does MobileAudit use?

MobileAudit uses Python’s standard **`logging`** module, not a third-party framework like Loguru or structlog. The application creates a logger named `app` via `logging.getLogger('app')` and configures it through Django’s `LOGGING` dictionary in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py).

### How are Celery task errors logged in MobileAudit?

Celery task errors are logged through explicit exception handling in [`app/worker/tasks.py`](https://github.com/mpast/mobileaudit/blob/main/app/worker/tasks.py). When the `scan_state` view or task logic encounters an exception while accessing `job.info` or `job.result`, the code catches the exception and calls `logger.error(exc)`, writing the traceback to the configured `logs/debug.log` file and console output.

### Where is the Celery result backend configured?

The result backend is configured in [`app/config/settings.py`](https://github.com/mpast/mobileaudit/blob/main/app/config/settings.py) (lines 186-193) via the `CELERY_RESULT_BACKEND` setting. By default, MobileAudit uses `db+sqlite:///rabbitmq/results.sqlite`, though this can be overridden via environment variables to use RabbitMQ, Redis, or another supported backend.

### How does MobileAudit persist task failure information?

MobileAudit persists task failures in two ways: first, through immediate log entries written to `logs/debug.log` via Python’s logging handlers; second, through Celery’s result backend, which stores task states and exception metadata when `current_task.update_state()` is called. The `scan_state` view retrieves this persisted state using `AsyncResult` to display or log historical error conditions.