Perché esiste il livello TRACE e quando dovrei usarlo piuttosto che DEBUG?

What are example of information that should be logged with TRACE and not with DEBUG?

Se ho un algoritmo che passa attraverso una serie di passaggi, il livello di traccia stamperà le informazioni su ciascuno di questi passaggi al livello migliore. Cose come gli input e gli output letterali di ogni passo.

In generale, la traccia includerà tutto il debug (proprio come il debug include tutti gli avvisi e gli errori).

What specific problem do I solve by logging that information?

Devi eseguire il debug di qualcosa che restituisca modo troppi dati da registrare all'esterno di una build specifica quando stai mirando a quella particolare cosa e non ti preoccupi degli errori o altre informazioni di registrazione (poiché il volume delle informazioni di tracciatura le oscurerà). In alcuni logger, trasformerai un determinato modulo solo fino al livello di tracciamento.

In those examples, what are the properties of the logged information that clearly discriminate between logging at the TRACE level rather than the DEBUG level?

In generale, la registrazione del livello di tracciamento non può essere attivata per periodi prolungati poiché peggiora notevolmente le prestazioni dell'applicazione e / o crea un'abbondanza di dati di registro che è insostenibile a causa dei limiti del disco / larghezza di banda.

La registrazione del livello di debug di solito può essere attiva per un periodo più lungo senza rendere l'app inutilizzabile.

Why does that information must go through the log infrastructure?

Non è necessario. Alcuni framework hanno un tracelogger separato.

Di solito finisce nei log poiché i logger e i normali logger hanno esigenze simili per quanto riguarda la scrittura su disco / rete, la gestione degli errori, la rotazione dei log, ecc.

Why is it better to use log for this rather than a debugger?

Perché il debugger potrebbe non essere in grado di collegarsi al computer con problemi. Potresti non sapere abbastanza da sapere dove persino impostare i punti di interruzione, o per passare attraverso il codice. Potresti non essere in grado di riprodurre in modo affidabile l'errore in un debugger, quindi usa i log per catturarlo "se succede".

Ma sono solo nomi. Come qualsiasi altra etichetta, sono solo nomi che le persone mettono sulle cose e di solito significano cose diverse per persone diverse. E l'etichetta stessa è meno importante dei bit carnosi a cui si riferisce l'etichetta.

Prendete nota speciale che slf4j raccomanda espressamente contro l'uso di trace ( link ):

In short, although we still discourage the use of the TRACE level because alternatives exist or because in many cases log requests of level TRACE are wasteful, given that people kept asking for it, we decided to bow to popular demand.

Personalmente, la mia aspettativa sarebbe che trace memorizzasse tutto (ad esempio, anche cose come "funzione inserita MyFunc con argomenti A, B, C alla volta Y"). Il lato negativo di questo è che non solo è incredibilmente rumoroso, ma tende anche a causare problemi di spazio su disco; Mi aspetterei che tale registrazione sia disabilitata durante le normali operazioni. Il vantaggio è che questo ti dà un livello di informazioni simile a quello che otterresti quando passi attraverso il tuo programma nei casi in cui il collegamento di un debugger può essere meno pratico.

In genere, trovo che la traccia di solito è più impegnativa di altri approcci.

I livelli di debug in generale sono completamente arbitrari e possono variare tra lingue, biblioteche e aziende.

Detto questo, ecco come li ho visti usati:

TRACE: utilizzato per mostrare il flusso del programma a livello logico. Inserito una funzione? Un'istruzione "se" ha scelto il ramo principale o "altro"? Quello è un candidato per la traccia. In altre parole, la traccia di tracciamento viene generalmente utilizzata per specificare "sei qui". Questo è utile nel contesto di altre dichiarazioni di registrazione che potrebbero registrare un errore o altre informazioni. La registrazione della traccia può aiutare a individuare la posizione, nel codice, dell'errore o di altro evento registrato a un livello diverso.

DEBUG: utilizzato per il dumping di stato variabile, codici di errore specifici, ecc. Ad esempio: un servizio Web potrebbe restituire il codice di errore 809214, che potrebbe essere registrato mentre l'applicazione comunica all'utente "comunicazione non riuscita". Immagina uno sviluppatore che riceve un log dal sistema di un utente molto tempo dopo che si è verificato l'errore e chiedendosi " perché si è verificato l'errore?" questa è una buona cosa per accedere al livello di debug. Un altro esempio potrebbe essere se un bug continua a verificarsi in produzione ma è difficile da riprodurre, esegui il debug nel registro di alcune variabili o eventi nel modulo problematico per aiutare gli sviluppatori a comunicare lo stato del programma quando si verifica l'errore per aiutare a risolvere i problemi.

Normalmente si configurerebbe l'applicazione per accedere a un determinato livello (o superiore). Ad esempio, la traccia è spesso il livello più basso: la registrazione a quel livello registra tutto. Il livello di debug ometterebbe la traccia ma includerebbe livelli elevati (ad esempio avvertimenti ed errori).

Il vantaggio di separare i livelli di log è controllare l'importo registrato. Per un'applicazione complessa, la registrazione di traccia potrebbe potenzialmente registrare un'enorme quantità di dati, in gran parte inutile il più delle volte. È meglio solo registrare le informazioni critiche (forse alcune informazioni di avvio, quindi solo errori) a meno che non si stia cercando di capire come causare un bug. Inoltre, questo è generalmente utile solo in un ambiente di produzione: i debugger e altri strumenti di sviluppo non sono presenti.

Non ci sono limiti reali su questo, nessuna regola che dice che devi loggarti in un certo modo. Solo ampie convenzioni che alcune librerie o applicazioni potrebbero seguire o meno.

Penso che l'eccellente risposta di Telastyn possa essere riassunta nella mia breve regola empirica:

• La registrazione di DEBUG deve essere utilizzabile in produzione (ma tende a essere sempre disattivata normalmente)
• La registrazione di TRACE può essere tale che non è possibile utilizzarla in produzione (tranne che per una sessione specifica / breve)

Qui 'la mia regola empirica

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

Il presupposto di questo è che il team ops sarà

• ha sempre la produzione impostata su informazioni a livello log
• potrebbe avere la produzione impostata su debug a livello log
• non ha mai impostato la produzione su traccia a livello log

strong di questa ipotesi, ecco come tu, come sviluppatore, puoi utilizzare i livelli di registro ...

Problema n. 1) che non rallenta eccessivamente le prestazioni di produzione

debug risolve # 1. Sei tu, in qualità di sviluppatore, a fare del tuo meglio per bilanciare le informazioni di cui potresti avere bisogno durante la produzione senza avere troppi rumori, rallentando la macchina. Stai dicendo "è una buona idea registrarlo costantemente in produzione (se vuoi)."

Problema n. 2) con informazioni dettagliate durante lo sviluppo

trace risolve il problema # 2. Non hai assolutamente alcuna preoccupazione sull'impatto che avrebbe su una macchina di produzione, ma al momento hai bisogno di queste informazioni mentre sviluppi il codice. Stai dicendo "Non faccio promesse che sia una buona idea registrare sempre queste informazioni in produzione."

Premesso (come altri hanno detto), queste cose sono arbitrarie; quindi assicurati che il tuo team di sviluppo (e ops / team di monitoraggio, perché sono anche utenti del tuo log) concordino su qualcosa.

What would be a canonical example of logging at the TRACE level?

ENTRY / EXIT registra da un metodo. Questi log aiutano a tracciare il flusso del programma e tendono ad essere molto utili quando:

1. Il programma si interrompe bruscamente: sai esattamente in quale funzione si è bloccato esaminando l'ultima riga del registro

2. Alcune funzioni canaglia falliscono silenziosamente assorbendo un'eccezione

Garantiscono un livello TRACE separato piuttosto che l'uso di DEBUG perché abilitare i registri ENTRY / EXIT per ogni metodo nel tuo codice base genererà un'enorme quantità di log aggiuntivi che sono irragionevoli per essere sempre , anche in un contesto DEBUG.

Usa TRACE quando hai bisogno di dettagli più dettagliati di quelli che DEBUG può fornire, molto probabilmente quando stai risolvendo un problema particolarmente difficile.

Se è il tuo codice, dovresti scriverlo in modo tale che non avrai mai bisogno di uno di questi livelli di log. Un modo per farlo è praticare TDD. La scrittura del codice in piccole unità ben coperte dai test unitari riduce notevolmente la necessità di registrazione e debug, fatta eccezione per la registrazione che si verifica come parte della normale funzione dell'applicazione. È improbabile che questo tipo di registrazione avvenga a livello TRACE o DEBUG.

Utilizza sempre il livello di registrazione che fornisce il livello di dettaglio più piccolo che sia sufficiente. Questo riduce il più possibile la quantità di dati di registrazione che devi setacciare. Detto questo, non ci sono regole rigide per il livello di registrazione da utilizzare in un dato scenario. Usa quello che ti è più utile.