Djangos loggningsmodul utökar Pythons inbyggda logging.
Loggning konfigureras som en del av den allmänna Django django.setup()-funktionen, så den är alltid tillgänglig om den inte uttryckligen inaktiveras.
Som standard använder Django Pythons logging.config.dictConfig-format.
\nDen fullständiga uppsättningen standardvillkor för loggning är:
\nNär DEBUG är True:
Loggern django skickar meddelanden i hierarkin django (utom django.server) på nivån INFO eller högre till konsolen.
När DEBUG är False:
Loggern django skickar meddelanden i django hierarkin (utom django.server) med ERROR eller CRITICAL nivå till AdminEmailHandler.
Oberoende av värdet på DEBUG:
Loggern django.server skickar meddelanden på nivån INFO eller högre till konsolen.
Alla loggrar utom django.server sprider loggning till sina föräldrar, upp till roten django logger. Hanterarna console och mail_admins är kopplade till rotloggern för att ge det beteende som beskrivs ovan.
Pythons egna standardinställningar skickar poster av nivån WARNING och högre till konsolen.
Djangos standardkonfiguration för loggning ärver Pythons standardvärden. Den är tillgänglig som django.utils.log.DEFAULT_LOGGING och definieras i django/utils/log.py:
{\n "version": 1,\n "disable_existing_loggers": False,\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n "require_debug_true": {\n "()": "django.utils.log.RequireDebugTrue",\n },\n },\n "formatters": {\n "django.server": {\n "()": "django.utils.log.ServerFormatter",\n "format": "[{server_time}] {message}",\n "style": "{",\n }\n },\n "handlers": {\n "console": {\n "level": "INFO",\n "filters": ["require_debug_true"],\n "class": "logging.StreamHandler",\n },\n "django.server": {\n "level": "INFO",\n "class": "logging.StreamHandler",\n "formatter": "django.server",\n },\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n "loggers": {\n "django": {\n "handlers": ["console", "mail_admins"],\n "level": "INFO",\n },\n "django.server": {\n "handlers": ["django.server"],\n "level": "INFO",\n "propagate": False,\n },\n },\n}\nSe Konfigurera loggning om hur du kompletterar eller ersätter denna standardkonfiguration för loggning.
\nDjango tillhandahåller ett antal verktyg för att hantera de särskilda krav som ställs på loggning i en webbservermiljö.
\nDjango tillhandahåller flera inbyggda loggrar.
\ndjangoLink to this heading#Den överordnade loggern för meddelanden i django named logger hierarchy. Django postar inte meddelanden med detta namn. Istället använder den en av loggrarna nedan.
django.begäranLink to this heading#Loggmeddelanden relaterade till hanteringen av förfrågningar. 5XX-svar tas upp som ERROR-meddelanden; 4XX-svar tas upp som WARNING-meddelanden. Förfrågningar som loggas till loggern django.security loggas inte till django.request.
Meddelanden till denna logger har följande extra sammanhang:
\nstatus_code: Den HTTP-svarskod som är kopplad till begäran.
begäran: Det request-objekt som genererade logningsmeddelandet.
django.serverLink to this heading#Loggar meddelanden relaterade till hanteringen av förfrågningar som tas emot av den server som anropas med kommandot runserver. HTTP 5XX-svar loggas som ERROR-meddelanden, 4XX-svar loggas som WARNING-meddelanden och allt annat loggas som INFO.
Meddelanden till denna logger har följande extra sammanhang:
\nstatus_code: Den HTTP-svarskod som är kopplad till begäran.
begäran: Det request-objekt (en socket.socket) som genererade logningsmeddelandet.
django.mallLink to this heading#Loggar meddelanden relaterade till rendering av mallar.
\nSaknade kontextvariabler loggas som DEBUG-meddelanden.
django.db.backendsLink to this heading#Meddelanden som rör kodens interaktion med databasen. Till exempel: loggas varje SQL-sats på applikationsnivå som körs av en begäran på nivån DEBUG till denna logger.
Meddelanden till denna logger har följande extra sammanhang:
\nduration: Den tid det tar att utföra SQL-satsen.
sql: Den SQL-sats som kördes.
params: De parametrar som användes i SQL-anropet.
alias: Aliaset för den databas som används i SQL-anropet.
Av prestandaskäl aktiveras SQL-loggning endast när settings.DEBUG är inställd på True, oavsett vilken loggningsnivå eller hanterare som är installerad.
Denna loggning omfattar inte initialisering på ramnivå (t.ex. SET TIMEZONE). Slå på frågeloggning i din databas om du vill visa alla databasfrågor.
django.utils.autoreloadLink to this heading#Loggar meddelanden relaterade till automatisk kodomladdning under körning av Django-utvecklingsservern. Denna logger genererar ett INFO-meddelande när den upptäcker en ändring i en källkodsfil och kan producera VARNING-meddelanden under filsysteminspektion och händelseprenumerationsprocesser.
django.contrib.authLink to this heading#Loggmeddelanden relaterade till django.contrib.auth, särskilt ERROR-meddelanden genereras när en PasswordResetForm skickas in men e-postmeddelandet om lösenordsåterställning inte kan levereras på grund av ett undantag för e-postsändning.
django.contrib.gisLink to this heading#Loggmeddelanden relaterade till GeoDjango vid olika tidpunkter: under inläsning av externa geospatiala bibliotek (GEOS, GDAL, etc.) och vid felrapportering. Varje ERROR-loggpost innehåller undantaget och relevanta kontextuella data.
django.dispatchLink to this heading#Denna logger används i Signaler, specifikt inom Signal-klassen, för att rapportera problem när en signal skickas till en ansluten mottagare. Loggposten ERROR innehåller det fångade undantaget som exc_info och lägger till följande extra sammanhang:
mottagare: Namnet på mottagaren.
err: Det undantag som inträffade när mottagaren anropades.
django.security.*Link to this heading#Säkerhetsloggarna kommer att ta emot meddelanden om alla förekomster av SuspiciousOperation och andra säkerhetsrelaterade fel. Det finns en underlogger för varje undertyp av säkerhetsfel, inklusive alla SuspiciousOperation. Logghändelsens nivå beror på var undantaget hanteras. De flesta förekomster loggas som en varning, medan alla SuspiciousOperation som når WSGI-hanteraren loggas som ett fel. Till exempel:, när en HTTP Host header ingår i en begäran från en klient som inte matchar ALLOWED_HOSTS, kommer Django att returnera ett 400-svar, och ett felmeddelande kommer att loggas till django.security.DisallowedHost logger.
Dessa logghändelser kommer att nå django logger som standard, som skickar felhändelser till administratörer när DEBUG=False. Förfrågningar som resulterar i ett 400-svar på grund av en SuspiciousOperation kommer inte att loggas till django.request-loggern, utan endast till django.security-loggern.
För att tysta en viss typ av SuspiciousOperation kan du åsidosätta den specifika loggern enligt följande exempel:
LOGGING = {\n # ...\n "handlers": {\n "null": {\n "class": "logging.NullHandler",\n },\n },\n "loggers": {\n "django.security.DisallowedHost": {\n "handlers": ["null"],\n "propagate": False,\n },\n },\n # ...\n}\nAndra django.security loggrar som inte är baserade på SuspiciousOperation är:
django.security.csrf: För CSRF-fel.
django.db.backends.schemaLink to this heading#Loggar de SQL-frågor som körs under schemaändringar i databasen av migrations framework. Observera att den inte kommer att logga de frågor som körs av RunPython. Meddelanden till den här loggern har params och sql i sitt extra sammanhang (men till skillnad från django.db.backends, inte varaktighet). Värdena har samma betydelse som förklaras i django.db.backends.
django.contrib.sessionsLink to this heading#Loggar meddelanden relaterade till session framework.
\nIcke-fatala fel som uppstår när man använder django.contrib.sessions.backends.cached_db.SessionStore-motorn loggas som ERROR-meddelanden med motsvarande traceback.
Django tillhandahåller en logghantering utöver de som tillhandahålls av Pythons loggmodul.
Denna hanterare skickar ett e-postmeddelande till webbplatsen ADMINS för varje loggmeddelande den tar emot.
Om loggposten innehåller attributet request kommer alla detaljer om begäran att inkluderas i e-postmeddelandet. Ämnet i e-postmeddelandet kommer att innehålla frasen ”internal IP” om klientens IP-adress finns i inställningen INTERNAL_IPS; om så inte är fallet kommer det att innehålla ”EXTERNAL IP”.
Om loggposten innehåller stackspårningsinformation kommer denna stackspårning att inkluderas i e-postmeddelandet.
\nArgumentet include_html i AdminEmailHandler används för att kontrollera om spårningsmailet innehåller en HTML-bilaga som innehåller hela innehållet på debug-webbsidan som skulle ha producerats om DEBUG var True. För att ställa in detta värde i din konfiguration, inkludera det i hanterardefinitionen för django.utils.log.AdminEmailHandler, så här:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n },\n}\nVar medveten om säkerhetskonsekvenserna av loggning när du använder AdminEmailHandler.
Genom att ställa in argumentet email_backend i AdminEmailHandler kan email backend <topic-email-backends>` som används av hanteraren åsidosättas, så här:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "email_backend": "django.core.mail.backends.filebased.EmailBackend",\n },\n}\nSom standard kommer en instans av den e-postbackend som anges i EMAIL_BACKEND att användas.
Argumentet reporter_class i AdminEmailHandler gör det möjligt att tillhandahålla en django.views.debug.ExceptionReporter underklass för att anpassa spårningstexten som skickas i e-postens kropp. Du anger en strängimportväg till den klass du vill använda, så här:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n "reporter_class": "somepackage.error_reporter.CustomErrorReporter",\n },\n}\nSkickar e-postmeddelanden till adminanvändare. För att anpassa detta beteende kan du underordna klassen AdminEmailHandler och åsidosätta denna metod.
Django tillhandahåller några loggfilter utöver de som tillhandahålls av Pythons loggmodul.
\nDetta filter accepterar en callback-funktion (som bör acceptera ett enda argument, den post som ska loggas) och anropar den för varje post som passerar genom filtret. Hanteringen av den posten kommer inte att fortsätta om återkallandet returnerar False.
\nOm du till exempel vill filtrera bort UnreadablePostError (som uppstår när en användare avbryter en uppladdning) från admin-e-postmeddelandena, skapar du en filterfunktion:
from django.http import UnreadablePostError\n\n\ndef skip_unreadable_post(record):\n if record.exc_info:\n exc_type, exc_value = record.exc_info[:2]\n if isinstance(exc_value, UnreadablePostError):\n return False\n return True\noch lägg sedan till den i din loggningskonfiguration:
\nLOGGING = {\n # ...\n "filters": {\n "skip_unreadable_posts": {\n "()": "django.utils.log.CallbackFilter",\n "callback": skip_unreadable_post,\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["skip_unreadable_posts"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\nDetta filter kommer endast att skicka vidare poster när settings.DEBUG är False.
\nDetta filter används på följande sätt i standardkonfigurationen LOGGING för att säkerställa att AdminEmailHandler endast skickar felmeddelanden till administratörer när DEBUG är False:
LOGGING = {\n # ...\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\nDetta filter liknar RequireDebugFalse, förutom att poster endast skickas när DEBUG är True.