# Documentazione Django 6.0.7

# Come configurare ed utilizzare i log

Vedi anche

- riferimento del sistema di logging di Django

- Panoramica del logging di Django

Django offre una configurazione predefinita di logging funzionante che può essere prontamente estesa.

## Esegui una chiamata di base al sistema di log

Per inviare un messaggio di log dal tuo codice, inserisci una chiamata di logging.

Non utilizzare le chiamate al sistema di log all’interno di `settings.py`.

Il modo in cui il logging di Django è configurato come parte della funzione `setup()` significa che le chiamate di logging poste in `settings.py` potrebbero non funzionare come ci si aspetta, perchè il logging non sarà pronto a quel punto. Per esplorare il logging, usa una funzione di view come suggerito nell’esempio qui sotto.

First, import the Python logging library, and then obtain a logger instance with `logging.getLogger()`. Provide the `getLogger()` method with a name to identify it and the records it emits. A good option is to use `__name__` (see Usa lo spazio dei nomi del logger below for more on this) which will provide the name of the current Python module as a dotted path:

    import logging

    logger = logging.getLogger(__name__)

E” una buona convenzione eseguire questa dichiarazione a livello di modulo.

E quindi in una funzione, per esempio in una vista, invia un record al sistema di logging:

    def some_view(request):
        ...
        if some_risky_state:
            logger.warning("Platform is running at risk")

When this code is executed, a `LogRecord` containing that message will be sent to the logger. If you’re using Django’s default logging configuration, the message will appear in the console.

Il livello `WARNING` usato nell’esempio qui sopra è uno dei molti livelli di severità del logging: `DEBUG`, `INFO`, `WARNING`, `ERROR`, `CRITICAL`. Così, un altro esempio potrebbe essere:

    logger.critical("Payment system is not responding")

Importante

I record con un livello più basso di `WARNING` non appariranno in console di default. Cambiare questo comportamento richiede configurazioni aggiuntive.

## Personalizza la configurazione del sistema di log

Anche se la configurazione di logging di Django funziona da sè, puoi controllare esattamente come i tuoi log sono inviati a varie destinazioni - ai file di log, servizi esterni, email e così via - con qualche configurazione aggiuntiva.

Puoi configurare:

- la mappatura del logger, per determinare quale record deve essere inviato a quale gestore

- i gestori, per determinare cosa devono fare con i log che ricevono

- i filtri, per fornire un controllo addizionale sul trasferimento dei record e eventualmente per effettuare delle modifiche al volo

- formattatori, per convertire oggetti `LogRecord` a stringa o altre forme per il consumo da parte degli umani o di un altro sistema.

Ci sono diversi modi di configurare il logging. In Django, l’impostazione `LOGGING` viene usata più comunemente. L’impostazione usa il formato dictConfig ed estende la configurazione di logging di default.

Vedi Configuring logging per una spiegazione di come le tue impostazioni personalizzate vengono fuse con le impostazioni predefinite di Django.

Vedi la `documentazione del logging di Python` per avere dettagli su altri modi di configurare il logging. Per amor di semplicità, questa documentazione considererà solamente la configurazione tramite l’impostazione `LOGGING`.

### Configurazione di base del sistema di log

Quando si configurano i log, ha senso fare

#### Creare un dizionario di `LOGGING`

Nel tuo `settings.py`:

    LOGGING = {
        "version": 1,  # the dictConfig format version
        "disable_existing_loggers": False,  # retain the default loggers
    }

Ha quasi sempre senso trattenere ed estendere la configurazione di logging predefinita impostando `disable_existing_loggers` a `False`.

#### Configura un gestore

Questo esempio configura un singolo handler chiamato `file`, che usa il `FileHandler` di Python per salvare i log con livello `DEBUG` e superiore sul file `general.log` (nella radice del progetto):

    LOGGING = {
        # ...
        "handlers": {
            "file": {
                "class": "logging.FileHandler",
                "filename": "general.log",
            },
        },
    }

Different handler classes take different configuration options. For more information on available handler classes, see the `AdminEmailHandler` provided by Django and the various `handler classes` provided by Python.

I livelli di log possono essere anche configurati sul gestore (di default, accettano log di tutti i livelli). Usando l’esempio precedente, aggiungendo:

    {
        "class": "logging.FileHandler",
        "filename": "general.log",
        "level": "DEBUG",
    }

definirebbe una configurazione di gestione che accetta solo record di livello `DEBUG` e superiore.

#### Configura la mappatura del sistema di log

Per inviare record a questo handler, configurare una mappatura del logger per usarlo ad esempio:

    LOGGING = {
        # ...
        "loggers": {
            "": {
                "level": "DEBUG",
                "handlers": ["file"],
            },
        },
    }

Il nome del mapping determina quali record di log elaborerà. Questa configurazione (`''`) è senza nome. Questo significa che elaborerà record da tutti i logger (vedi Usa lo spazio dei nomi del logger qua sotto per sapere come usare il nome di mapping per determinare i logger per i quali processerà i record).

Questo inoltrerà i messaggi di livello `DEBUG` e superiore all’handler chiamato `file`.

Nota che un logger può inoltrare messaggi a più gestori, così la relazione tra logger e gestori è molti-a-molti.

Se esegui:

    logger.debug("Attempting to connect to API")

nel tuo codice, troverai quel messaggio nel file `general.log` nella radice del progetto.

#### Configurare un formatter

By default, the final log output contains the message part of each `LogRecord` object. Use a formatter if you want to include additional data. First name and define your formatters - this example defines formatters named `verbose` and `simple`:

    LOGGING = {
        # ...
        "formatters": {
            "verbose": {
                "format": "{name} {levelname} {asctime} {module} {process:d} {thread:d} {message}",
                "style": "{",
            },
            "simple": {
                "format": "{levelname} {message}",
                "style": "{",
            },
        },
    }

La keyword `style` ti permette di specificare `{` per `str.format()` o `$` per la formattazione `string.Template; quello predefinito è ``$``.

Vedi LogRecord attributes per gli attributi di `LogRecord` che puoi includere.

Per applicare un formattatore ad un gestore, aggiungi una voce `formatter` al dizionario del gestore, che faccia riferimento al formattatore per nome, per esempio:

    "handlers": {
        "file": {
            "class": "logging.FileHandler",
            "filename": "general.log",
            "formatter": "verbose",
        },
    }

#### Usa lo spazio dei nomi del logger

La configurazione di logging senza nome `''` cattura log da ogni applicazione Python. Una configurazione di logging con nome catturerà log solo dai logger con nomi che combaciano.

The namespace of a logger instance is defined using `getLogger()`. For example in `views.py` of `my_app`:

    logger = logging.getLogger(__name__)

creerà un logger nel namespace `my_app.views` namespace. `__name__` ti permette di organizzare i messaggi di log in accordo con la loro provenienza nelle applicazioni del tuo progetto in modo automatico. Assicura anche che non ci siano collisioni sui nomi.

Un mapping di logger chiamato `my_app.views` catturerà record da questo logger:

    LOGGING = {
        # ...
        "loggers": {
            "my_app.views": {...},
        },
    }

Un mapping di logger chiamato `my_app` sarà più permissivo, catturando record dai logger che si trovino ovunque nel namespace `my_app` (incluso `my_app.views`, `my_app.utils` e così via):

    LOGGING = {
        # ...
        "loggers": {
            "my_app": {...},
        },
    }

Puoi anche definire esplicitamente i namespacing del logger:

    logger = logging.getLogger("project.payment")

e impostare le mappature del logger di conseguenza.

##### Utilizzo di gerarchie di logger e propagazione

La nomenclatura dei logger è gerarchica. `my_app` è genitore di `my_app.views`, che è genitore di `my_app.views.private`. Finchè non specificato altrimenti, i mapping dei logger propagheranno i record che elaborano ai loro genitori - un record da un logger nel namespace `my_app.views.private` sarà gestito da entrambi i mapping di `my_app` e `my_app.views`.

Per gestire questo comportamento, imposta la chiave di propagazione sulle mappature che definisci:

    LOGGING = {
        # ...
        "loggers": {
            "my_app": {
                # ...
            },
            "my_app.views": {
                # ...
            },
            "my_app.views.private": {
                # ...
                "propagate": False,
            },
        },
    }

`propagate` è di dafault a `True`. In questo esempio, i log da `my_app.views.private` non saranno gestiti dal genitore, ma i log da `my_app.views` lo saranno.

### Configura logging reattivi

Il logging è soprattutto utile quando contiene più informazioni possibili ma non le informazioni di cui non hai bisogno - e di quanto hai bisogno dipende da quel che stai facendo. Quando stai facendo debug, hai bisogno di un livello di informazioni che sarebbe eccessivo ed inutile se fossi in produzione.

Puoi configurare il loggin per fornirti il livello di dettaglio di cui necessiti, quando ne hai bisogno. Piuttosto che cambiare manualmente la configurazione per fare questo, un modo migliore è applicare la configurazione automaticamente a seconda dell’environment.

Per esempio, potresti impostare una variabile d’ambiente appropriata `DJANGO_LOG_LEVEL` nei tuoi ambienti di sviluppo e staging ed usarla nel mapping del logger, quindi:

    "level": os.getenv("DJANGO_LOG_LEVEL", "WARNING")

- così che, fintanto che l’ambiente non specifica un livello di log più basso, questa configurazione girerà solo i record di severità `WARNING` e superiore al proprio gestore.

Altre opzioni nella configurazione (come le opzioni del gestore `level` o `formatter`) possono essere gestite in modo simile.