Ejemplo simple de registro a archivo para django 1.3+

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'?

django django-settings John Mee
fuente

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?

Formadores Me gusta que tenga el mismo estilo que ./manage.py runserver
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ó.
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í .

rh0dium
fuente

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

Vivek S

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

Rog

¡Apuesta! Reemplazar 'MYAPP' con ''

rh0dium

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

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

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 .

metakermit
fuente