Registro

Ver también

Django’s logging module extends Python’s builtin logging.

La configuración de registro se configura como parte de la función general de Django django.setup(), por lo que siempre está disponible a menos que se desactive explícitamente.

Configuración de registro predeterminada de Django

Por defecto, Django utiliza el formato de configuración de registro de Python logging.config.dictConfig.

Condiciones de registro por defecto

La completa serie de condiciones de registro por defecto son:

Cuando DEBUG es True:

  • El logger django envía mensajes en la jerarquía django (excepto django.server) a nivel INFO o superior a la consola.

Cuando DEBUG es False:

  • El logger django envía mensajes en la jerarquía django (excepto django.server) con el nivel ERROR o CRITICAL al AdminEmailHandler.

Independientemente del valor de DEBUG:

  • El logger django.server envía mensajes al nivel INFO o superior a la consola.

Todos los loggers excepto django.server propagan el registro a sus padres, hasta el logger raíz django. Los manejadores console y mail_admins se adjuntan al logger raíz para proporcionar el comportamiento descrito anteriormente.

Las propias configuraciones de Python envían registros del nivel WARNING y superior a la consola.

Definición por defecto de registro

La configuración de registro predeterminada de Django hereda las configuraciones de Python. Está disponible como django.utils.log.DEFAULT_LOGGING y se define en django/utils/log.py:

{
    "version": 1,
    "disable_existing_loggers": False,
    "filters": {
        "require_debug_false": {
            "()": "django.utils.log.RequireDebugFalse",
        },
        "require_debug_true": {
            "()": "django.utils.log.RequireDebugTrue",
        },
    },
    "formatters": {
        "django.server": {
            "()": "django.utils.log.ServerFormatter",
            "format": "[{server_time}] {message}",
            "style": "{",
        }
    },
    "handlers": {
        "console": {
            "level": "INFO",
            "filters": ["require_debug_true"],
            "class": "logging.StreamHandler",
        },
        "django.server": {
            "level": "INFO",
            "class": "logging.StreamHandler",
            "formatter": "django.server",
        },
        "mail_admins": {
            "level": "ERROR",
            "filters": ["require_debug_false"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    "loggers": {
        "django": {
            "handlers": ["console", "mail_admins"],
            "level": "INFO",
        },
        "django.server": {
            "handlers": ["django.server"],
            "level": "INFO",
            "propagate": False,
        },
    },
}

Consulte configurando-registro para saber cómo complementar o reemplazar esta configuración de registro predeterminada.

Extensiones de registro de Django

Django proporciona una serie de utilidades para manejar las particularidades del registro en un entorno de servidor web.

Registradores

Django proporciona varios loggers integrados.

django

El logger padre para los mensajes en la jerarquía de loggers nombres de loggers django. Django no envía mensajes utilizando este nombre. En su lugar, utiliza uno de los loggers que se presentan a continuación.

django.request

Los mensajes de registro relacionados con el manejo de solicitudes. Las respuestas 5XX se elevan como ERROR; las respuestas 4XX se elevan como WARNING. Las solicitudes que se registran en el logger django.security no se registran en django.request.

Los mensajes a este logger tienen el siguiente contexto adicional:

  • status_code: El código de respuesta HTTP asociado con la solicitud.

  • request: La objeto de solicitud que generó el mensaje de registro.

django.server

Los mensajes de registro relacionados con el manejo de solicitudes recibidas por el servidor invocado mediante el comando runserver. Las respuestas HTTP 5XX se registran como ERROR, las respuestas 4XX se registran como WARNING y todo lo demás se registra como INFO.

Los mensajes a este logger tienen el siguiente contexto adicional:

  • status_code: El código de respuesta HTTP asociado con la solicitud.

  • La traducción de los textos es la siguiente:

django.template

Los mensajes de registro relacionados con la renderización de plantillas.

  • Las variables de contexto faltantes se registran como mensajes DEBUG.

django.db.backends

Los mensajes relacionados con la interacción del código con la base de datos. Por ejemplo, cada declaración SQL a nivel de aplicación ejecutada por una solicitud se registra al nivel DEBUG en este logger.

Los mensajes a este logger tienen el siguiente contexto adicional:

  • duration: El tiempo necesario para ejecutar la sentencia SQL.

  • sql: La sentencia SQL que se ejecutó.

  • params: Los parámetros utilizados en la llamada a SQL.

  • alias: El alias de la base de datos utilizado en la llamada a SQL.

Por razones de rendimiento, la depuración SQL solo se habilita cuando settings.DEBUG está establecido en True, independientemente del nivel de depuración o los manejadores instalados.

Esta depuración no incluye la inicialización a nivel de marco (por ejemplo, SET TIMEZONE). Activa la depuración de consultas en tu base de datos si deseas ver todas las consultas de la base de datos.

django.utils.autoreload

Los mensajes de registro relacionados con el recarga automática del código durante la ejecución del servidor de desarrollo de Django. Este logger genera un mensaje INFO al detectar una modificación en un archivo de código fuente y puede producir mensajes WARNING durante la inspección del sistema de archivos y los procesos de suscripción a eventos.

django.contrib.auth

Los mensajes de registro relacionados con django.contrib.auth, particularmente los mensajes ERROR se generan cuando un formulario de restablecimiento de contraseña (PasswordResetForm) es enviado correctamente pero el correo electrónico de restablecimiento no puede ser entregado debido a una excepción al enviar correos electrónicos.

django.contrib.gis

Los mensajes de registro relacionados con GeoDjango en varios puntos: durante la carga de bibliotecas GeoSpatial externas (GEOS, GDAL, etc.) y cuando se informan errores. Cada registro de error ERROR incluye la excepción capturada y los datos contextuales relevantes.

django.dispatch

Este logger se utiliza en Señales, específicamente dentro de la clase Signal, para informar sobre problemas cuando se envía un señal a un receptor conectado. El registro de error ERROR incluye la excepción capturada como exc_info y agrega el siguiente contexto adicional:

  • receiver: El nombre del receptor.

  • err: La excepción que ocurrió al llamar al receptor.

django.security.*

Los registradores de seguridad recibirán mensajes en cualquier ocurrencia de SuspiciousOperation y otros errores relacionados con la seguridad. Hay un sub-registrador para cada subtipo de error de seguridad, incluyendo todos los SuspiciousOperations. El nivel del evento de registro depende de dónde se maneja la excepción. La mayoría de las ocurrencias se registran como advertencias, mientras que cualquier SuspiciousOperation que llegue al manipulador WSGI se registrarán como errores. Por ejemplo, cuando un encabezado HTTP Host está incluido en una solicitud desde un cliente que no coincide con ALLOWED_HOSTS, Django devolverá una respuesta 400 y un mensaje de error se registrará en el django.security.DisallowedHost logger.

Estos eventos de registro llegarán al django logger por defecto, que envía los eventos de error a los admins cuando DEBUG=False. Las solicitudes que resultan en una respuesta 400 debido a un SuspiciousOperation no se registrarán en el django.request logger, sino solo en el django.security logger.

Para silenciar un tipo particular de SuspiciousOperation, puedes sobreescribir ese registrador específico siguiendo este ejemplo:

LOGGING = {
    # ...
    "handlers": {
        "null": {
            "class": "logging.NullHandler",
        },
    },
    "loggers": {
        "django.security.DisallowedHost": {
            "handlers": ["null"],
            "propagate": False,
        },
    },
    # ...
}

Otros loggers de seguridad django.security no basados en SuspiciousOperation son:

django.db.backends.schema

Se registran las consultas SQL que se ejecutan durante los cambios de esquema en la base de datos por el marco de migraciones. Ten en cuenta que no registrarán las consultas ejecutadas por RunPython. Los mensajes para este logger tienen params y sql en su contexto extra (pero a diferencia de django.db.backends, no duración). Los valores tienen el mismo significado que se explica en django.db.backends.

django.contrib.sessions

Los mensajes de registro relacionados con el marco de sesiones.

  • Errores no fatales que ocurren al utilizar el motor de almacenamiento SessionStore de la clase django.contrib.sessions.backends.cached_db se registran como mensajes ERROR con el correspondiente traceback.

Handlers

Django proporciona un manejador de registro adicional a los que ofrece el módulo de registro de Python <python:logging.handlers>.

class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)[fuente]

Este manejador envía un correo electrónico a los administradores del sitio ADMINS para cada mensaje de registro que recibe.

Si el registro de log contiene un atributo request, se incluirán los detalles completos de la solicitud en el correo electrónico. El asunto del correo electrónico incluirá la frase «dirección IP interna» si la dirección IP del cliente está en la configuración INTERNAL_IPS; si no, incluirá «dirección IP EXTERNA».

Si el registro de la traza del log contiene información sobre la traza del stack, esta traza del stack se incluirá en el correo electrónico.

El argumento include_html de AdminEmailHandler se utiliza para controlar si el correo electrónico con la pista de error incluye una adjunta en formato HTML que contiene todo el contenido de la página web de depuración que habría sido producida si DEBUG fuera True. Para establecer este valor en tu configuración, inclúyelo en la definición del manejador para django.utils.log.AdminEmailHandler, como se muestra a continuación:

"handlers": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "include_html": True,
    },
}

Ten en cuenta las implicaciones de seguridad del registro (seguridad implicaciones de registro) al utilizar el AdminEmailHandler.

Por establecer el argumento email_backend de AdminEmailHandler, se puede sobrescribir la backend de correo electrónico que está siendo utilizado por el manipulador, como se muestra a continuación:

"handlers": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "email_backend": "django.core.mail.backends.filebased.EmailBackend",
    },
}

Por defecto, se utilizará una instancia del backend de correo electrónico especificado en :setting:`EMAIL_BACKEND.

El argumento reporter_class de AdminEmailHandler permite proporcionar una subclase de django.views.debug.ExceptionReporter para personalizar el texto del seguimiento de trazas incluido en el cuerpo del correo electrónico. Proporciona un string con la ruta de importación al clase que deseas utilizar, como se muestra a continuación:

"handlers": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "include_html": True,
        "reporter_class": "somepackage.error_reporter.CustomErrorReporter",
    },
}
send_mail(subject, message, *args, **kwargs)[fuente]

Los textos traducidos son:

Filtros

Django proporciona algunos filtros de registro en lugar de aquellos proporcionados por el módulo de registro de Python.

class CallbackFilter(callback)[fuente]

Este filtro acepta una función de llamada (que debe aceptar un solo argumento, el registro a ser registrado), y la llama para cada registro que pase por el filtro. El manejo del registro no continuará si la función de llamada devuelve False.

Por ejemplo, para filtrar los registros UnreadablePostError (elevados cuando un usuario cancela una subida) de los correos electrónicos administrativos, crearías una función de filtro:

from django.http import UnreadablePostError


def skip_unreadable_post(record):
    if record.exc_info:
        exc_type, exc_value = record.exc_info[:2]
        if isinstance(exc_value, UnreadablePostError):
            return False
    return True

y luego la agregarías a tu configuración de registro:

LOGGING = {
    # ...
    "filters": {
        "skip_unreadable_posts": {
            "()": "django.utils.log.CallbackFilter",
            "callback": skip_unreadable_post,
        },
    },
    "handlers": {
        "mail_admins": {
            "level": "ERROR",
            "filters": ["skip_unreadable_posts"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    # ...
}
class RequireDebugFalse[fuente]

Este filtro solo pasará registros cuando settings.DEBUG es False.

Este filtro se utiliza de la siguiente manera en la configuración por defecto LOGGING para asegurarse de que el AdminEmailHandler envíe correos electrónicos de error a los administradores sólo cuando DEBUG es False:

LOGGING = {
    # ...
    "filters": {
        "require_debug_false": {
            "()": "django.utils.log.RequireDebugFalse",
        },
    },
    "handlers": {
        "mail_admins": {
            "level": "ERROR",
            "filters": ["require_debug_false"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    # ...
}
class RequireDebugTrue[fuente]

Este filtro es similar a RequireDebugFalse, excepto que se pasan registros solo cuando DEBUG es True.

« previous | up | next »