Esempio di semplice registro su file per django 1.3+


96

Le note di rilascio dicono:

Django 1.3 aggiunge il supporto a livello di framework per il modulo di registrazione di Python.

Bello. Mi piacerebbe approfittarne. Sfortunatamente la documentazione non mi consegna tutto su un piatto d'argento sotto forma di codice di esempio funzionante completo che dimostra quanto sia semplice e prezioso.

Come faccio a impostare questa nuova funky funzionalità in modo tale da poter arricchire il mio codice

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

e guarda il file "/tmp/application.log" riempito 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

Qual è la differenza tra la registrazione predefinita di Python e questo "supporto a livello di framework"?

Risposte:


183

Mi piace davvero così tanto, ecco il tuo esempio funzionante! Seriamente questo è fantastico!

Inizia inserendo questo nel tuo file 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',
        },
    }
}

Ora cosa significa tutto questo?

  1. Formattatori Mi piace che abbiano lo stesso stile di ./manage.py runserver
  2. Gestori: voglio due log: un file di testo di debug e una console delle informazioni. Questo mi permette di scavare davvero (se necessario) e guardare un file di testo per vedere cosa succede sotto il cofano.
  3. Logger - Qui è dove fissiamo ciò che vogliamo registrare. In generale django ottiene WARN e soprattutto - l'eccezione (quindi propagazione) sono i backend in cui mi piace vedere le chiamate SQL poiché possono impazzire .. L'ultima è la mia app dove ho due gestori e spingo tutto ad esso.

Ora come abilito MYAPP per usarlo ...

Secondo la documentazione, mettilo all'inizio dei tuoi file (views.py) ..

import logging
log = logging.getLogger(__name__)

Quindi per ottenere qualcosa fallo.

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

I livelli di log sono spiegati qui e per Python puro qui .


7
ho seguito i passaggi precedenti. viene creato il file ma non viene scritto nulla. prego aiuto
Vivek S

12
@InternalServerError devi sostituire MYAPP con il nome della tua app nella sezione logger.
Rog

9
Scommetti! Sostituisci 'MYAPP' con ''
rh0dium

10
Per chiarimenti, qualunque cosa tu chiami logger settings.py, cioè MYAPPin questo esempio, deve essere anche il parametro nella chiamata a logging.getLogger. Pertanto, se il tuo progetto contiene molte app autonome e desideri che utilizzino un logger comune che devi utilizzare al logging.getLogger('MYAPP')posto dilogging.getLogger(__name__)
rhunwicks

3
Funziona alla grande. Ho dovuto usare "class": "logging.NullHandler" perché "django.utils.log.NullHandler" non è più valido, ma il resto ha funzionato per me in 1.11
JacquelineIO

4

Basandomi in parte sulla configurazione di registrazione suggerita da rh0dium e su alcune ulteriori ricerche che ho fatto io stesso, ho iniziato ad assemblare un progetto Django di esempio con dei bei valori predefiniti di registrazione - fail-piace-django .

Output del file di registro di esempio:

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.

L'utilizzo dettagliato è spiegato nel README , ma essenzialmente copi il modulo logger nel tuo progetto Django e lo aggiungi from .logger import LOGGINGin fondo al tuo settings.py .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.