Loggning

Se även

• loggning - hur man gör

• Django loggningsöversikt

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.

Djangos standardkonfiguration för loggning

Som standard använder Django Pythons logging.config.dictConfig-format.

Standardvillkor för loggning

Den fullständiga uppsättningen standardvillkor för loggning är:

Nä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.

Standard loggningsdefinition

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:

{
    "version": 1,
    "disable_existing_loggers": False,
    "filters": {
        "require_debug_false": {
            "()": "django.utils.log.RequireDebugFalse",
        },
        "require_debug_true": {
            "()": "django.utils.log.RequireDebugTrue",
        },
    },
    "formatters": {
        "django.server": {
            "()": "django.utils.log.ServerFormatter",
            "format": "[{server_time}] {message}",
            "style": "{",
        }
    },
    "handlers": {
        "console": {
            "level": "INFO",
            "filters": ["require_debug_true"],
            "class": "logging.StreamHandler",
        },
        "django.server": {
            "level": "INFO",
            "class": "logging.StreamHandler",
            "formatter": "django.server",
        },
        "mail_admins": {
            "level": "ERROR",
            "filters": ["require_debug_false"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    "loggers": {
        "django": {
            "handlers": ["console", "mail_admins"],
            "level": "INFO",
        },
        "django.server": {
            "handlers": ["django.server"],
            "level": "INFO",
            "propagate": False,
        },
    },
}

Se Konfigurera loggning om hur du kompletterar eller ersätter denna standardkonfiguration för loggning.

Django loggningstillägg

Django tillhandahåller ett antal verktyg för att hantera de särskilda krav som ställs på loggning i en webbservermiljö.

Loggers

Django tillhandahåller flera inbyggda loggrar.

django

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äran

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:

• status_code: Den HTTP-svarskod som är kopplad till begäran.

• begäran: Det request-objekt som genererade logningsmeddelandet.

django.server

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:

• status_code: Den HTTP-svarskod som är kopplad till begäran.

• begäran: Det request-objekt (en socket.socket) som genererade logningsmeddelandet.

django.mall

Loggar meddelanden relaterade till rendering av mallar.

• Saknade kontextvariabler loggas som DEBUG-meddelanden.

django.db.backends

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:

• duration: 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.autoreload

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.auth

New in Django 4.2.16.

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.gis

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.dispatch

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.*

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 = {
    # ...
    "handlers": {
        "null": {
            "class": "logging.NullHandler",
        },
    },
    "loggers": {
        "django.security.DisallowedHost": {
            "handlers": ["null"],
            "propagate": False,
        },
    },
    # ...
}

Andra django.security loggrar som inte är baserade på SuspiciousOperation är:

• django.security.csrf: För CSRF-fel.

django.db.backends.schema

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.sessions

Loggar meddelanden relaterade till session framework.

• Icke-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.

Handläggare

Django tillhandahåller en logghantering utöver de som tillhandahålls av Pythons loggmodul.

class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)[source]

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.

Argumentet 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": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "include_html": True,
    },
}

Var 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": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "email_backend": "django.core.mail.backends.filebased.EmailBackend",
    },
}

Som 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": {
    "mail_admins": {
        "level": "ERROR",
        "class": "django.utils.log.AdminEmailHandler",
        "include_html": True,
        "reporter_class": "somepackage.error_reporter.CustomErrorReporter",
    },
}

send_mail(subject, message, *args, **kwargs)[source]

Skickar e-postmeddelanden till adminanvändare. För att anpassa detta beteende kan du underordna klassen AdminEmailHandler och åsidosätta denna metod.

Filter

Django tillhandahåller några loggfilter utöver de som tillhandahålls av Pythons loggmodul.

class CallbackFilter(callback)[source]

Detta 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.

Om 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


def skip_unreadable_post(record):
    if record.exc_info:
        exc_type, exc_value = record.exc_info[:2]
        if isinstance(exc_value, UnreadablePostError):
            return False
    return True

och lägg sedan till den i din loggningskonfiguration:

LOGGING = {
    # ...
    "filters": {
        "skip_unreadable_posts": {
            "()": "django.utils.log.CallbackFilter",
            "callback": skip_unreadable_post,
        },
    },
    "handlers": {
        "mail_admins": {
            "level": "ERROR",
            "filters": ["skip_unreadable_posts"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    # ...
}

class RequireDebugFalse[source]

Detta filter kommer endast att skicka vidare poster när settings.DEBUG är False.

Detta 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 = {
    # ...
    "filters": {
        "require_debug_false": {
            "()": "django.utils.log.RequireDebugFalse",
        },
    },
    "handlers": {
        "mail_admins": {
            "level": "ERROR",
            "filters": ["require_debug_false"],
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    # ...
}

class RequireDebugTrue[source]

Detta filter liknar RequireDebugFalse, förutom att poster endast skickas när DEBUG är True.