Przykład prostego logowania do pliku dla django 1.3+

96

Uwagi do wydania mówią:

Django 1.3 dodaje obsługę na poziomie frameworka dla modułu logowania Pythona.

To miłe. Chciałbym to wykorzystać. Niestety dokumentacja nie przekazuje mi tego wszystkiego na srebrnej tacy w postaci pełnego działającego kodu przykładowego, który pokazuje, jak proste i wartościowe jest to.

Jak skonfigurować tę nową, fajną funkcję, tak aby można było doprawić mój kod

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

i zobacz, jak wypełnia się plik „/tmp/application.log”

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

Jaka jest różnica między domyślnym rejestrowaniem w Pythonie a tą „obsługą na poziomie struktury”?

django django-settings John Mee
źródło

Odpowiedzi:

183

Naprawdę bardzo mi się to podoba, oto Twój przykład pracy! Poważnie, to jest niesamowite!

Zacznij od umieszczenia tego w swoim 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',
        },
    }
}

Co to wszystko oznacza?

  1. Formatery Lubię, gdy wychodzi w tym samym stylu co ./manage.py runningerver
  2. Programy obsługi - chcę mieć dwa dzienniki - plik tekstowy debugowania i konsolę informacyjną. To pozwala mi naprawdę zagłębić się (w razie potrzeby) i spojrzeć na plik tekstowy, aby zobaczyć, co dzieje się pod maską.
  3. Rejestratory - tutaj ustalamy, co chcemy zarejestrować. Ogólnie django dostaje WARN i wyższe - wyjątkiem (stąd propagacja) są backendy, w których uwielbiam widzieć wywołania SQL, ponieważ mogą oszaleć. Ostatnia jest moja aplikacja, w której mam dwa programy obsługi i wysyłam do niej wszystko.

Jak teraz włączyć MYAPP, aby go używać ...

Zgodnie z dokumentacją umieść to na początku swoich plików (views.py) ..

import logging
log = logging.getLogger(__name__)

Następnie, aby coś wydobyć, zrób to.

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

Poziomy dzienników są wyjaśnione tutaj, a dla czystego Pythona tutaj .

rh0dium
źródło
7
Wykonałem powyższe kroki. plik jest tworzony, ale nic nie jest do niego zapisywane. prośby o pomoc
Vivek S
12
@InternalServerError musisz zamienić MYAPP na nazwę swojej aplikacji w sekcji rejestratorów.
Rog
9
Pewnie! Zamień „MYAPP” na „”
rh0dium
10
Dla wyjaśnienia, cokolwiek wywołujesz rejestratora settings.py, tj. MYAPPW tym przykładzie, również musi być parametrem w wywołaniu logging.getLogger. Dlatego też, jeśli projekt zawiera wiele samodzielne aplikacje i chcesz je używać wspólnego rejestratora należy użyć logging.getLogger('MYAPP')zamiastlogging.getLogger(__name__)
rhunwicks
3
To działa świetnie. Musiałem użyć „class”: „logging.NullHandler”, ponieważ „django.utils.log.NullHandler” nie jest już poprawne, ale reszta działała dla mnie w 1.11
JacquelineIO
4

Opierając się częściowo na konfiguracji logowania sugerowanej przez rh0dium i kilku innych badaniach, które przeprowadziłem samodzielnie, zacząłem montować przykładowy projekt Django z ładnymi domyślnymi ustawieniami logowania - fail-nicely-django .

Przykładowe dane wyjściowe pliku dziennika:

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.

Szczegółowe użycie jest wyjaśnione w pliku README , ale zasadniczo kopiujesz moduł rejestratora do projektu Django i dodajesz from .logger import LOGGINGna dole swojego settings.py .

metakermit
źródło