Exemplo de registro simples para arquivo para django 1.3+

As notas de lançamento dizem:

Django 1.3 adiciona suporte em nível de estrutura para o módulo de registro do Python.

Isso é bom. Eu gostaria de aproveitar isso. Infelizmente, a documentação não me entrega tudo em uma bandeja de prata na forma de um código de exemplo funcional completo que demonstra como isso é simples e valioso.

Como faço para configurar este novo recurso funky para que eu possa apimentar meu código com

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

e veja o arquivo "/tmp/application.log" preenchido com

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

Qual é a diferença entre o registro Python padrão e este 'suporte de nível de estrutura'?

django django-settings

— John Mee
fonte

Respostas:

183

Eu realmente amo tanto isso, aqui está seu exemplo de trabalho! Sério, isso é incrível!

Comece colocando isso em seu 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',
        },
    }
}

Agora, o que tudo isso significa?

Formadores que eu gosto que saiam com o mesmo estilo de ./manage.py runserver
Manipuladores - quero dois logs - um arquivo de texto de depuração e um console de informações. Isso me permite realmente cavar (se necessário) e olhar para um arquivo de texto para ver o que acontece nos bastidores.
Loggers - aqui é onde determinamos o que queremos logar. Em geral, django obtém WARN e superior - a exceção (portanto, propaga) são os back-ends, onde adoro ver as chamadas SQL, pois podem ficar malucas. Por último, é meu aplicativo onde tenho dois manipuladores e empurro tudo para ele.

Agora como faço para habilitar MYAPP para usá-lo ...

De acordo com a documentação, coloque-o no topo de seus arquivos (views.py).

import logging
log = logging.getLogger(__name__)

Então, para tirar algo, faça isso.

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

Os níveis de log são explicados aqui e para python puro aqui .

— rh0dium
fonte

eu segui os passos acima. arquivo é criado, mas nada é gravado nele. pedidos de ajuda

— Vivek S

@InternalServerError você precisa substituir MYAPP pelo nome do seu aplicativo na seção de loggers.

— Rog

Pode apostar! Substitua 'MYAPP' por ''

— rh0dium

Para esclarecimento, o que quer que você chame o logger settings.py, ou seja MYAPP, neste exemplo, também deve ser o parâmetro na chamada para logging.getLogger. Portanto, se o seu projeto contém muitos aplicativos independentes e você deseja que eles usem um registrador comum, você precisa usar em logging.getLogger('MYAPP')vez delogging.getLogger(__name__)

— rhunwicks

Isso funciona muito bem. Tive que usar 'class': 'logging.NullHandler' porque 'django.utils.log.NullHandler' não é mais válido, mas o resto funcionou para mim em 1.11

— JacquelineIO

Baseado parcialmente na configuração de registro sugerida por rh0dium e mais algumas pesquisas que eu mesmo fiz, comecei a montar um projeto Django de exemplo com bons padrões de registro - fail-nicely-django .

Saída de arquivo de log de amostra:

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.

O uso detalhado é explicado no README , mas essencialmente, você copia o módulo logger para o seu projeto Django e adiciona from .logger import LOGGINGno final do seu settings.py .

— metakermit
fonte