---
title: "Loggning"
version: 5.2
locale: sv
source: https://docs.djangoproject.com/sv/5.2/ref/logging/
canonical: https://djangodocs.dev/sv/5.2/ref/logging/
---
# Loggning

> **See also**
>
> - loggning - hur man gör
> - [Django loggningsöversikt](/sv/5.2/topics/logging/#logging-explanation)

Djangos loggningsmodul utökar Pythons inbyggda [`logging`](https://docs.python.org/3/library/logging.html#module-logging).

Loggning konfigureras som en del av den allmänna Django [`django.setup()`](/sv/5.2/ref/applications/#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](https://docs.python.org/3/library/logging.config.html#logging-config-dictschema).

### Standardvillkor för loggning

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

När [`DEBUG`](/sv/5.2/ref/settings/#std-setting-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`](/sv/5.2/ref/settings/#std-setting-DEBUG) är `False`:

- Loggern `django` skickar meddelanden i `django` hierarkin (utom `django.server`) med `ERROR` eller `CRITICAL` nivå till [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler).

Oberoende av värdet på [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG):

- Loggern [django.server](#django-server-logger) skickar meddelanden på nivån `INFO` eller högre till konsolen.

Alla loggrar utom [django.server](#django-server-logger) 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](https://github.com/django/django/blob/stable/5.2.x/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](/sv/5.2/topics/logging/#configuring-logging) 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](/sv/5.2/howto/logging/#naming-loggers-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`](/sv/5.2/ref/django-admin/#django-admin-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`](https://docs.python.org/3/library/socket.html#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](/sv/5.2/ref/contrib/auth/), särskilt `ERROR`-meddelanden genereras när en [`PasswordResetForm`](/sv/5.2/topics/auth/default/#django.contrib.auth.forms.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](/sv/5.2/ref/contrib/gis/) 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](/sv/5.2/ref/signals/), specifikt inom [`Signal`](/sv/5.2/topics/signals/#django.dispatch.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`](/sv/5.2/ref/exceptions/#django.core.exceptions.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`](/sv/5.2/ref/settings/#std-setting-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](/sv/5.2/howto/csrf/#csrf-rejected-requests).

#### `django.db.backends.schema`

Loggar de SQL-frågor som körs under schemaändringar i databasen av [migrations framework](/sv/5.2/topics/migrations/). Observera att den inte kommer att logga de frågor som körs av [`RunPython`](/sv/5.2/ref/migration-operations/#django.db.migrations.operations.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-db-logger).

#### `django.contrib.sessions`

Loggar meddelanden relaterade till [session framework](/sv/5.2/topics/http/sessions/).

- Icke-fatala fel som uppstår när man använder [`django.contrib.sessions.backends.cached_db.SessionStore`](/sv/5.2/topics/http/sessions/#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`](https://docs.python.org/3/library/logging.handlers.html#module-logging.handlers).

#### `class AdminEmailHandler(include_html=False, email_backend=None, reporter_class=None)`

Denna hanterare skickar ett e-postmeddelande till webbplatsen [`ADMINS`](/sv/5.2/ref/settings/#std-setting-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`](/sv/5.2/ref/settings/#std-setting-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`](/sv/5.2/ref/settings/#std-setting-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](/sv/5.2/topics/logging/#logging-security-implications) 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`](/sv/5.2/ref/settings/#std-setting-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)`

Skickar e-postmeddelanden till adminanvändare. För att anpassa detta beteende kan du underordna klassen [`AdminEmailHandler`](#django.utils.log.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)`

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`](/sv/5.2/ref/exceptions/#django.http.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`

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`](/sv/5.2/ref/settings/#std-setting-LOGGING) för att säkerställa att [`AdminEmailHandler`](#django.utils.log.AdminEmailHandler) endast skickar felmeddelanden till administratörer när [`DEBUG`](/sv/5.2/ref/settings/#std-setting-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`

Detta filter liknar [`RequireDebugFalse`](#django.utils.log.RequireDebugFalse), förutom att poster endast skickas när [`DEBUG`](/sv/5.2/ref/settings/#std-setting-DEBUG) är `True`.
