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

> **See also**
>
> - loggning - hur man gör
> - [Django loggningsöversikt](/sv/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0.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/6.0/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/6.0/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/6.0/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.
- `request`: The request object (a [`socket.socket`](https://docs.python.org/3/library/socket.html#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](/sv/6.0/ref/contrib/auth/), particularly `ERROR`
messages are generated when a
[`PasswordResetForm`](/sv/6.0/topics/auth/default/#django.contrib.auth.forms.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](/sv/6.0/ref/contrib/gis/) 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](/sv/6.0/ref/signals/), specifically within the
[`Signal`](/sv/6.0/topics/signals/#django.dispatch.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`](/sv/6.0/ref/exceptions/#django.core.exceptions.SuspiciousOperation) and other security-related
errors. There is a sub-logger for each subtype of security error, including all
`SuspiciousOperation`s. 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`](/sv/6.0/ref/settings/#std-setting-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](/sv/6.0/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/6.0/topics/migrations/). Observera att den inte kommer att logga de frågor som körs av [`RunPython`](/sv/6.0/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/6.0/topics/http/sessions/).

- Icke-fatala fel som uppstår när man använder [`django.contrib.sessions.backends.cached_db.SessionStore`](/sv/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0/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/6.0/ref/settings/#std-setting-DEBUG) är `True`.