Ejemplo simple de registro a archivo para django 1.3+


96

Las notas de la versión dicen:

Django 1.3 agrega soporte a nivel de marco para el módulo de registro de Python.

Eso es bueno. Me gustaría aprovechar eso. Desafortunadamente, la documentación no me lo entrega todo en bandeja de plata en forma de código de ejemplo de trabajo completo que demuestra lo simple y valioso que es esto.

¿Cómo configuro esta nueva característica funky para que pueda condimentar mi código con

logging.debug('really awesome stuff dude: %s' % somevar)

y ver que el archivo "/tmp/application.log" se llena con

18:31:59 Apr 21 2011 awesome stuff dude: foobar
18:32:00 Apr 21 2011 awesome stuff dude: foobar
18:32:01 Apr 21 2011 awesome stuff dude: foobar

¿Cuál es la diferencia entre el registro de Python predeterminado y este 'soporte a nivel de marco'?

Respuestas:


183

¡Realmente amo tanto esto aquí está su ejemplo de trabajo! ¡En serio, esto es increíble!

Empiece por poner esto en su settings.py

LOGGING = {
    'version': 1,
    'disable_existing_loggers': True,
    'formatters': {
        'standard': {
            'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
            'datefmt' : "%d/%b/%Y %H:%M:%S"
        },
    },
    'handlers': {
        'null': {
            'level':'DEBUG',
            'class':'django.utils.log.NullHandler',
        },
        'logfile': {
            'level':'DEBUG',
            'class':'logging.handlers.RotatingFileHandler',
            'filename': SITE_ROOT + "/logfile",
            'maxBytes': 50000,
            'backupCount': 2,
            'formatter': 'standard',
        },
        'console':{
            'level':'INFO',
            'class':'logging.StreamHandler',
            'formatter': 'standard'
        },
    },
    'loggers': {
        'django': {
            'handlers':['console'],
            'propagate': True,
            'level':'WARN',
        },
        'django.db.backends': {
            'handlers': ['console'],
            'level': 'DEBUG',
            'propagate': False,
        },
        'MYAPP': {
            'handlers': ['console', 'logfile'],
            'level': 'DEBUG',
        },
    }
}

Ahora bien, ¿qué significa todo esto?

  1. Formadores Me gusta que tenga el mismo estilo que ./manage.py runserver
  2. Controladores: quiero dos registros: un archivo de texto de depuración y una consola de información. Esto me permite profundizar realmente (si es necesario) y mirar un archivo de texto para ver qué sucede bajo el capó.
  3. Loggers: aquí es donde determinamos lo que queremos registrar. En general, django obtiene WARN y superior: la excepción (por lo tanto, propagar) son los backends donde me encanta ver las llamadas SQL ya que pueden volverse locas. La última es mi aplicación donde tengo dos controladores y empujo todo hacia ella.

Ahora, ¿cómo habilito MYAPP para usarlo ...

Según la documentación, coloque esto en la parte superior de sus archivos (views.py).

import logging
log = logging.getLogger(__name__)

Luego, para sacar algo, haz esto.

log.debug("Hey there it works!!")
log.info("Hey there it works!!")
log.warn("Hey there it works!!")
log.error("Hey there it works!!")

Los niveles de registro se explican aquí y para Python puro aquí .


7
Seguí los pasos anteriores. Se crea el archivo pero no se escribe nada en él. súplica ayuda
Vivek S

12
@InternalServerError necesita reemplazar MYAPP con el nombre de su aplicación en la sección de registradores.
Rog

9
¡Apuesta! Reemplazar 'MYAPP' con ''
rh0dium

10
Para aclarar, lo que sea que llame al registrador settings.py, es decir, MYAPPen este ejemplo, también debe ser el parámetro en la llamada a logging.getLogger. Por lo tanto, si su proyecto contiene muchas aplicaciones autónomas y desea que utilicen un registrador común que debe usar en logging.getLogger('MYAPP')lugar delogging.getLogger(__name__)
rhunwicks

3
Esto funciona muy bien. Tuve que usar 'class': 'logging.NullHandler' porque 'django.utils.log.NullHandler' ya no es válido, pero el resto funcionó para mí en 1.11
JacquelineIO

4

Basado parcialmente en la configuración de registro sugerida por rh0dium y algunas investigaciones más que hice yo mismo, comencé a ensamblar un proyecto de Django de ejemplo con buenos valores predeterminados de registro: fail-nicely-django .

Salida de archivo de registro de muestra:

2016-04-05 22:12:32,984 [Thread-1    ] [INFO ] [djangoproject.logger]  This is a manually logged INFO string.
2016-04-05 22:12:32,984 [Thread-1    ] [DEBUG] [djangoproject.logger]  This is a manually logged DEBUG string.
2016-04-05 22:12:32,984 [Thread-1    ] [ERROR] [django.request      ]  Internal Server Error: /
Traceback (most recent call last):
  File "/Users/kermit/.virtualenvs/fail-nicely-django/lib/python3.5/site-packages/django/core/handlers/base.py", line 149, in get_response
    response = self.process_exception_by_middleware(e, request)
  File "/Users/kermit/.virtualenvs/fail-nicely-django/lib/python3.5/site-packages/django/core/handlers/base.py", line 147, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/kermit/projekti/git/fail-nicely-django/djangoproject/brokenapp/views.py", line 12, in brokenview
    raise Exception('This is an exception raised in a view.')
Exception: This is an exception raised in a view.

El uso detallado se explica en el README , pero esencialmente, copia el módulo del registrador a su proyecto Django y lo agrega from .logger import LOGGINGal final de su settings.py .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.