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.

• request: The request object (a socket.socket) that generated the logging message.

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

Log messages related to django.contrib.auth, particularly ERROR messages are generated when a PasswordResetForm is successfully submitted but the password reset email cannot be delivered due to a mail sending exception.

django.contrib.gis

Log messages related to GeoDjango at various points: during the loading of external GeoSpatial libraries (GEOS, GDAL, etc.) and when reporting errors. Each ERROR log record includes the caught exception and relevant contextual data.

django.dispatch

This logger is used in Signaler, specifically within the Signal class, to report issues when dispatching a signal to a connected receiver. The ERROR log record includes the caught exception as exc_info and adds the following extra context:

• mottagare: Namnet på mottagaren.

• err: Det undantag som inträffade när mottagaren anropades.

django.security.*

The security loggers will receive messages on any occurrence of SuspiciousOperation and other security-related errors. There is a sub-logger for each subtype of security error, including all SuspiciousOperations. The level of the log event depends on where the exception is handled. Most occurrences are logged as a warning, while any SuspiciousOperation that reaches the WSGI handler will be logged as an error. For example, when an HTTP Host header is included in a request from a client that does not match ALLOWED_HOSTS, Django will return a 400 response, and an error message will be logged to the 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.