Configuración elegante de inicio de sesión de Python en Django

Question

Todavía tengo que encontrar la manera de configurar el registro de Python con Django con el que estoy satisfecho. Mis requisitos son bastante simples:

• diferentes manejadores de registro para diferentes eventos - es decir, quiero ser capaz de acceder a diferentes archivos
• fácil acceso a los madereros en mis módulos. El módulo debería poder encontrar su registrador con poco esfuerzo.
• Debe ser fácilmente aplicable a los módulos de línea de comandos. Partes del sistema son procesos independientes de línea de comando o daemon. El registro debe ser fácilmente utilizable con estos módulos.

Mi configuración actual es usar un archivo logging.conf y el registro de configuración en cada módulo desde el que inicio sesión. No se siente bien.

¿Tiene una configuración de registro que le guste? Por favor, detallarlo: cómo configurar la configuración (¿usa logging.conf o configurarla en el código), dónde/cuándo inicia los registradores y cómo puede acceder a ellos en sus módulos, etc.

Answer 1

La mejor manera que he encontrado hasta ahora es inicializar la configuración de inicio de sesión en settings.py - en ninguna otra parte. Puede usar un archivo de configuración o hacerlo mediante programación paso a paso; solo depende de sus requisitos. La clave es que normalmente agrego los manejadores que quiero al registrador de raíz, usando niveles y algunas veces registrando. Filtros para obtener los eventos que quiero en los archivos apropiados, consola, syslogs, etc. Por supuesto, puede agregar manejadores a cualquier otro registrador también, pero no hay una necesidad común de esto en mi experiencia.

En cada módulo, que definen un registrador usando

logger = logging.getLogger(__name__) 

y el uso que para el registro de eventos en el módulo (y, si quiero diferenciar aún más) utilizo un registrador que es un hijo del registrador creado encima.

Si mi aplicación va a ser potencialmente utilizados en un sitio que no configurar el registro en settings.py, que definen un NullHandler algún lugar de la siguiente manera:

#someutils.py 

class NullHandler(logging.Handler): 
    def emit(self, record): 
     pass 

null_handler = NullHandler() 

y asegurarse de que una instancia del mismo es agregado a todos los registradores creados en los módulos en mis aplicaciones que usan el registro. (Nota: NullHandler ya está en el paquete de registro para Python 3.1, y estará en Python 2.7.) Por lo tanto:

logger = logging.getLogger(__name__) 
logger.addHandler(someutils.null_handler) 

Esto se hace para asegurar que sus módulos desempeñan muy bien en un sitio que no configurar el registro en settings.py, y que no obtiene ningún molesto mensaje "No se encontraron controladores para el registrador XYZ" (que son advertencias sobre el registro potencialmente mal configurado).

Hacerlo de esta manera cumple con los requisitos establecidos:

• Puede configurar diferentes manejadores de registro para diferentes eventos, como se hace actualmente.
• Fácil acceso a los registradores en sus módulos - use getLogger(__name__).
• Fácilmente aplicable a los módulos de línea de comandos: también importan settings.py.

Actualización: Nota que a partir de la versión 1.3, Django incorpora ahora support for logging.

Answer 2

Actualmente estoy usando un sistema de registro, que creé yo mismo. Utiliza el formato CSV para el registro.

django-csvlog

Este proyecto aún no tiene la documentación completa, pero estoy trabajando en ello.

Answer 3

Inicializamos el registro en el nivel superior urls.py utilizando un archivo logging.ini.

La ubicación de logging.ini se proporciona en settings.py, pero eso es todo.

Cada módulo se hace

logger = logging.getLogger(__name__) 

Para distinguir las pruebas, desarrollo e instancias de producción, que tienen diferentes archivos logging.ini. En su mayor parte, tenemos un "registro de la consola" que va a stderr solo con errores. Tenemos un "registro de aplicación" que utiliza un archivo de registro continuo que va a un directorio de registros.

Answer 4

Sé que ya se trata de una respuesta resuelta, pero según django> = 1.3 hay una nueva configuración de registro.

Pasar de viejo a nuevo no es automático, así que pensé que lo escribiría aquí.

Y, por supuesto, salida the django doc para algunos más.

Ésta es la conf básico, creado por defecto con v1.3 django-admin createproject - kilometraje podría cambiar con las últimas versiones de Django:

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': False, 
    'handlers': { 
     'mail_admins': { 
      'level': 'ERROR', 
      'class': 'django.utils.log.AdminEmailHandler', 
     } 
    }, 
    'loggers': { 
     'django.request': { 
      'handlers': ['mail_admins'], 
      'level': 'ERROR', 
      'propagate': True, 
     } 
    } 
} 

Esta estructura se basa en el estándar Python logging dictConfig, que dicta el siguiente bloques:

• formatters - el valor correspondiente será un diccionario en el que cada tecla es un identificador formateador y cada valor es un diccionario que describe cómo configurar la instancia correspondiente del formateador.
• filters - el valor correspondiente será un dict en el cual cada clave es una identificación de filtro y cada valor es un dict que describe cómo configurar la instancia de filtro correspondiente.

• handlers - el valor correspondiente será un dict en el que cada clave es una identificación de controlador y cada valor es un dict que describe cómo configurar la instancia de controlador correspondiente. Cada controlador tiene las siguientes claves:

  • class (obligatorio). Este es el nombre completo de la clase de controlador.
  • level (opcional). El nivel del controlador.
  • formatter (opcional). La id del formateador para este controlador.
  • filters (opcional). Una lista de identificadores de los filtros para este controlador.

por lo general lo hago por lo menos esto:

• añadir un archivo .log
• configurar mis aplicaciones escribir en este registro

que se traduce en:

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': False, 
    'formatters': { 
     'verbose': { 
      'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s' 
     }, 
     'simple': { 
      'format': '%(levelname)s %(message)s' 
     }, 
    }, 
    'filters': { 
     'require_debug_false': { 
      '()': 'django.utils.log.RequireDebugFalse' 
     } 
    }, 
    'handlers': { 
     'null': { 
      'level':'DEBUG', 
      'class':'django.utils.log.NullHandler', 
     }, 
     'console':{ 
      'level': 'DEBUG', 
      'class': 'logging.StreamHandler', 
      'formatter': 'simple' 
     }, 
     # I always add this handler to facilitate separating loggings 
     'log_file':{ 
      'level': 'DEBUG', 
      'class': 'logging.handlers.RotatingFileHandler', 
      'filename': os.path.join(VAR_ROOT, 'logs/django.log'), 
      'maxBytes': '16777216', # 16megabytes 
      'formatter': 'verbose' 
     }, 
     'mail_admins': { 
      'level': 'ERROR', 
      'filters': ['require_debug_false'], 
      'class': 'django.utils.log.AdminEmailHandler', 
      'include_html': True, 
     } 
    }, 
    'loggers': { 
     'django.request': { 
      'handlers': ['mail_admins'], 
      'level': 'ERROR', 
      'propagate': True, 
     }, 
     'apps': { # I keep all my of apps under 'apps' folder, but you can also add them one by one, and this depends on how your virtualenv/paths are set 
      'handlers': ['log_file'], 
      'level': 'INFO', 
      'propagate': True, 
     }, 
    }, 
    # you can also shortcut 'loggers' and just configure logging for EVERYTHING at once 
    'root': { 
     'handlers': ['console', 'mail_admins'], 
     'level': 'INFO' 
    }, 
} 

edición

Ver request exceptions are now always logged y Ticket #16288:

He actualizado el conf muestra anterior para incluir explícitamente el filtro correcto para mail_admins de manera que, por defecto, los correos electrónicos no se envían cuando depuración es verdadera.

Usted debe agregar un filtro:

'filters': { 
    'require_debug_false': { 
     '()': 'django.utils.log.RequireDebugFalse' 
    } 
}, 

y aplicarlo al controlador de mail_admins:

'mail_admins': { 
     'level': 'ERROR', 
     'filters': ['require_debug_false'], 
     'class': 'django.utils.log.AdminEmailHandler', 
     'include_html': True, 
    } 

lo contrario, el django.core.handers.base.handle_uncaught_exception no pasa errores al registrador 'django.request' si los ajustes .DEBUG es verdadero.

Si no se hace esto en Django 1.5 podrás obtener una DeprecationWarning

: No tiene filtros definidos en el manejador de registro de los '' mail_admins: Adición implícita de depuración de falso único filtro

pero las cosas seguirán funcionando correctamente tanto en django 1.4 como en django 1.5.

** ** final de edición

Eso conf está fuertemente inspirado en el conf muestra en el documento de Django, pero la adición de la parte del archivo de registro.

A menudo también haga lo siguiente:

LOG_LEVEL = 'DEBUG' if DEBUG else 'INFO' 

... 
    'level': LOG_LEVEL 
... 

Luego, en mi código Python siempre añadir un NullHandler en caso de que no conf registro se define en absoluto. Esto evita advertencias para ningún controlador especificado. Especialmente útil en las librerías que no necesariamente se llama sólo en Django (ref)

import logging 
# Get an instance of a logger 
logger = logging.getLogger(__name__) 
class NullHandler(logging.Handler): #exists in python 3.1 
    def emit(self, record): 
     pass 
nullhandler = logger.addHandler(NullHandler()) 

# here you can also add some local logger should you want: to stdout with streamhandler, or to a local file... 

[...]

logger.warning('etc.etc.') 

Espero que esto ayude!