Django offre una configurazione predefinita di logging funzionante che può essere prontamente estesa.
\nPer inviare un messaggio di log dal tuo codice, inserisci una chiamata di logging.
\n\nPrima, importa la libreria di logging di Python e poi ottieni una istanza di logger con logging.getLogger(). Fornisci il metodo getLogger() con un nome che lo identifica ed i record che emette. Una buona opzione è usare __name__ (vedi Usa lo spazio dei nomi del logger qui sotto per saperne di più) che offrirà il nome del modulo Python corrente come percorso puntato:
import logging\n\nlogger = logging.getLogger(__name__)\nE” una buona convenzione eseguire questa dichiarazione a livello di modulo.
\nE quindi in una funzione, per esempio in una vista, invia un record al sistema di logging:
\ndef some_view(request):\n ...\n if some_risky_state:\n logger.warning("Platform is running at risk")\nQuando questo codice viene eseguito, verrà inviato al logger un LogRecord contenente quel messaggio. Se stai usando la configurazione di logging predefinita di Django, il messaggio apparirà sulla 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")\nAnche 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.
\nPuoi configurare:
\nla 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.
\nVedi 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.
Quando si configurano i log, ha senso fare
\nLOGGINGLink to this heading#Nel tuo settings.py:
LOGGING = {\n "version": 1, # the dictConfig format version\n "disable_existing_loggers": False, # retain the default loggers\n}\nHa quasi sempre senso trattenere ed estendere la configurazione di logging predefinita impostando disable_existing_loggers a False.
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 = {\n # ...\n "handlers": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n },\n },\n}\nDifferenti classi handler accettano differenti opzioni di configurazione. Per avere più informazioni sulle classi handler disponibili, vedi AdminEmailHandler, fornita da Django e le varie various classi handler fornite da Python.
I livelli di log possono essere anche configurati sul gestore (di default, accettano log di tutti i livelli). Usando l’esempio precedente, aggiungendo:
\n{\n "class": "logging.FileHandler",\n "filename": "general.log",\n "level": "DEBUG",\n}\ndefinirebbe una configurazione di gestione che accetta solo record di livello DEBUG e superiore.
Per inviare record a questo handler, configurare una mappatura del logger per usarlo ad esempio:
\nLOGGING = {\n # ...\n "loggers": {\n "": {\n "level": "DEBUG",\n "handlers": ["file"],\n },\n },\n}\nIl 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.
\nSe esegui:
\nlogger.debug("Attempting to connect to API")\nnel tuo codice, troverai quel messaggio nel file general.log nella radice del progetto.
Di default, l’output finale del log contiene la parte di messaggio di ogni record di log. Usa un formattatore se vuoi includere dati aggiuntivi. Prima di tutto nomina e definisci i tuoi formattatori - questo esempio definisce formattatori di nome verbose e``simple``:
LOGGING = {\n # ...\n "formatters": {\n "verbose": {\n "format": "{name} {levelname} {asctime} {module} {process:d} {thread:d} {message}",\n "style": "{",\n },\n "simple": {\n "format": "{levelname} {message}",\n "style": "{",\n },\n },\n}\nLa 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": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n "formatter": "verbose",\n },\n}\nLa 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.
Il namespace di una istanza di un logger è definita usando getLogger(). Per esempio in views.py di my_app:
logger = logging.getLogger(__name__)\ncreerà 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 = {\n # ...\n "loggers": {\n "my_app.views": {...},\n },\n}\nUn 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 = {\n # ...\n "loggers": {\n "my_app": {...},\n },\n}\nPuoi anche definire esplicitamente i namespacing del logger:
\nlogger = logging.getLogger("project.payment")\ne impostare le mappature del logger di conseguenza.
\nLa 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:
\nLOGGING = {\n # ...\n "loggers": {\n "my_app": {\n # ...\n },\n "my_app.views": {\n # ...\n },\n "my_app.views.private": {\n # ...\n "propagate": False,\n },\n },\n}\npropagate è 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.
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.
\nPuoi 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.
\nPer 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")\n- 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.