2011-03-25 932 views
84

Parece que no puedo encontrar la manera de configurar un registrador "predeterminado" para mi instalación en Django. Me gustaría utilizar la nueva configuración LOGGING de Django 1.3 en settings.py.Django Setup Default Logging

He mirado el Django Logging Doc's example, pero me parece que solo configuran los controladores que harán el registro para los registradores en particular. En el caso de su ejemplo, configuraron el controlador para los registradores llamados 'django', 'django.request' y 'myproject.custom'.

Todo lo que quiero hacer es configurar un predeterminado logging.handlers.RotatingFileHandler que manejará todos los registradores de manera predeterminada. es decir, si hago un nuevo módulo en algún lugar de mi proyecto y se denota por algo como: my_app_name.my_new_module, debería poder hacer esto y hacer que todo el registro vaya a los registros del archivo rotativo.

# In file './my_app_name/my_new_module.py' 
import logging 
logger = logging.getLogger('my_app_name.my_new_module') 
logger.debug('Hello logs!') # <-- This should get logged to my RotatingFileHandler that I setup in `settings.py`! 

Respuesta

132

lo descubrió ...

se establece el registrador de 'coger todos' refiriéndose a ella con la cadena vacía: ''.

Como ejemplo, en la siguiente configuración tengo todos los eventos de registro guardados en logs/mylog.log, con la excepción de django.request eventos de registro que se guardarán en logs/django_request.log. Debido a que 'propagate' se establece en False para mi registrador django.request, el evento de registro nunca alcanzará el registrador 'atrapar todo'.

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': True, 
    'formatters': { 
     'standard': { 
      'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s' 
     }, 
    }, 
    'handlers': { 
     'default': { 
      'level':'DEBUG', 
      'class':'logging.handlers.RotatingFileHandler', 
      'filename': 'logs/mylog.log', 
      'maxBytes': 1024*1024*5, # 5 MB 
      'backupCount': 5, 
      'formatter':'standard', 
     }, 
     'request_handler': { 
      'level':'DEBUG', 
      'class':'logging.handlers.RotatingFileHandler', 
      'filename': 'logs/django_request.log', 
      'maxBytes': 1024*1024*5, # 5 MB 
      'backupCount': 5, 
      'formatter':'standard', 
     }, 
    }, 
    'loggers': { 
     '': { 
      'handlers': ['default'], 
      'level': 'DEBUG', 
      'propagate': True 
     }, 
     'django.request': { 
      'handlers': ['request_handler'], 
      'level': 'DEBUG', 
      'propagate': False 
     }, 
    } 
} 
+2

Chris, la documentación de Django en esto no son confusas. Gracias por esto. –

+4

Corrección pequeña: el comentario implica que el registro de sql se vería afectado por el registrador django.request. Para redirigir el registro sql, debe definir un registrador para 'django.db'. El registrador django.request maneja las respuestas http 5xx y 4xx. – rych

+0

@rych Gracias a su corrección, ¡me salvó un poco de tiempo! – 18bytes

17

Como usted ha dicho en your answer, Chris, una opción para definir un registrador por defecto es el uso de la cadena vacía como clave.

Sin embargo, creo que la forma prevista es definir un registrador especial bajo la clave root del diccionario de configuración de registro. He encontrado esto en el Python documentation:

raíz - esta será la configuración del registrador de la raíz. El procesamiento de la configuración será como el de cualquier registrador, excepto que la configuración propagate no será aplicable.

Aquí está la configuración de su respuesta cambiado para utilizar la clave root:

LOGGING = { 
    'version': 1, 
    'disable_existing_loggers': True, 
    'formatters': { 
     'standard': { 
      'format': '%(asctime)s [%(levelname)s] %(name)s: %(message)s' 
     }, 
    }, 
    'handlers': { 
     'default': { 
      'level':'DEBUG', 
      'class':'logging.handlers.RotatingFileHandler', 
      'filename': 'logs/mylog.log', 
      'maxBytes': 1024*1024*5, # 5 MB 
      'backupCount': 5, 
      'formatter':'standard', 
     }, 
     'request_handler': { 
      'level':'DEBUG', 
      'class':'logging.handlers.RotatingFileHandler', 
      'filename': 'logs/django_request.log', 
      'maxBytes': 1024*1024*5, # 5 MB 
      'backupCount': 5, 
      'formatter':'standard', 
     }, 
    }, 
    'root': { 
     'handlers': ['default'], 
     'level': 'DEBUG' 
    }, 
    'loggers': { 
     'django.request': { 
      'handlers': ['request_handler'], 
      'level': 'DEBUG', 
      'propagate': False 
     }, 
    } 
} 

Para ser justos, no puedo ver ninguna diferencia de comportamiento entre las dos configuraciones. Parece que la definición de un registrador con una clave de cadena vacía modificará el registrador de raíz, ya que logging.getLogger('') devolverá el registrador de raíz.

La única razón por la que prefiero 'root' sobre '' es que es explícita sobre la modificación del registrador de raíz. En caso de que tenga curiosidad, 'root' reemplaza '' si define ambos, simplemente porque la entrada raíz se procesó al final.

+0

Sí, eso es, ¡perdón por la falta de corrección! Si bien usar '' en lugar de 'root' es algo lógico, aún me parece un poco inconsistente mover la entrada 'root' a la raíz del dict en el proceso de una transición sin problemas de la lógica 2.6 fileConfig a 2.7 dictConfig one. –

0
import logging 
logger = logging.getLogger(__name__) 

después añadir:

logging.basicConfig(
    level = logging.DEBUG, 
    format = '%(name)s %(levelname)s %(message)s', 
) 

podemos cambiar el formato a:

format = '"%(levelname)s:%(name)s:%(message)s" ', 

o

format = '%(name)s %(asctime)s %(levelname)s %(message)s',