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

In Log4J, Slf4J e un paio di altri framework di registrazione in Java, hai due livelli di "sviluppo" per la registrazione:

• DEBUG
• TRACCIARE

Capisco cosa fa DEBUG, perché la spiegazione è chiara:

Il livello DEBUG designa eventi informativi dettagliati che sono più utili per il debug di un'applicazione.

Ma il livello TRACE non è molto specifico sul suo caso d'uso:

Il livello TRACE indica eventi informativi più dettagliati rispetto al DEBUG

(Fonte: log4J JavaDoc )

Questo non mi dice come o quando usare TRACE. È interessante notare che questo non è un livello di gravità definito nello standard syslog . Cercare su Google la differenza tra TRACE e DEBUG sembra solo restituire "usa DEBUG, oh, e c'è anche TRACE". Non sono riuscito a trovare un caso d'uso specifico per il livello TRACE. La migliore che ho trovato è stata questa vecchia pagina wiki che ha discusso del merito dell'esistenza del livello.

Questo, come architetto, solleva molte bandiere e domande nella mia testa. Se un giovane sviluppatore mi chiedesse di aggiungere TRACE alla mia architettura, lo bombarderei con domande:

• Quali sono alcuni esempi di informazioni che dovrebbero essere registrate con TRACE e non con DEBUG?
• Quale problema specifico posso risolvere registrando tali informazioni?
• In quegli esempi, quali sono le proprietà delle informazioni registrate che discriminano chiaramente tra la registrazione a livello di TRACE piuttosto che a livello di DEBUG?
• Perché tali informazioni devono passare attraverso l'infrastruttura di registro?
  • Quali sono i vantaggi della persistenza di tali informazioni nelle riviste dei registri piuttosto che del solo utilizzo System.out.println?
  • Perché è meglio usare il registro per questo piuttosto che un debugger?
• Quale sarebbe un esempio canonico di registrazione a livello di TRACE?
  • Quali sono i vantaggi specifici ottenuti registrando a livello di TRACE anziché DEBUG nell'esempio?
  • Perché questi guadagni sono importanti?
  • Al contrario: quali problemi ho evitato registrandolo su TRACE anziché su DEBUG?
  • In quale altro modo potrei risolvere questi problemi? Perché la registrazione a livello di TRACE è migliore di quelle di altre soluzioni?
• L'istruzione di registro a livello di TRACE deve essere lasciata nel codice di produzione? Perché?

Ma dato che è presente nella maggior parte dei principali framework, immagino che sia utile per qualcosa? Quindi ... a cosa serve TRACE e cosa lo distingue da DEBUG?

Quali sono esempi di informazioni che dovrebbero essere registrate con TRACE e non con 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 più fine. Cose come gli input e gli output letterali di ogni passaggio.

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

Quale problema specifico posso risolvere registrando tali informazioni?

È necessario eseguire il debug di qualcosa che uscite modo troppi dati per accedere al di fuori di una build specifica quando sei targeting che cosa particolare e non si preoccupano di errori o altre informazioni di registrazione (in quanto il volume di informazioni traccia li oscurare). In alcuni logger, si accenderà un determinato modulo solo per tracciare il livello.

In quegli esempi, quali sono le proprietà delle informazioni registrate che discriminano chiaramente tra la registrazione a livello di TRACE piuttosto che a livello di DEBUG?

In generale, la registrazione a livello di traccia non può essere attiva per periodi prolungati perché riduce notevolmente le prestazioni dell'applicazione e / o crea un'abbondanza di dati di registro non sostenibili a causa di vincoli del disco / larghezza di banda.

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

Perché tali informazioni devono passare attraverso l'infrastruttura di registro?

Non deve. Alcuni framework hanno un tracelogger separato.

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

Perché è meglio usare il registro per questo piuttosto che un debugger?

Perché il debugger potrebbe non essere in grado di collegarsi alla macchina problematica. Potresti non sapere abbastanza per sapere dove impostare anche i punti di interruzione o per scorrere il codice. Potrebbe non essere possibile riprodurre in modo affidabile l'errore in un debugger, quindi utilizzare i registri per rilevarlo "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 fa riferimento l'etichetta.

Nota speciale che slf4j raccomanda espressamente di non usare trace ( http://slf4j.org/faq.html#trace ):

In breve, sebbene scoraggiamo ancora l'uso del livello TRACE perché esistono alternative o perché in molti casi le richieste di registro del livello TRACE sono dispendiose, dato che le persone continuavano a chiederlo, abbiamo deciso di piegarci alla domanda popolare.

Personalmente, la mia aspettativa sarebbe che la traccia registri tutto (ad esempio, anche cose come "funzione MyFunc inserita con argomenti A, B, C al momento Y"). L'aspetto negativo di questo è che non solo è incredibilmente rumoroso, ma tende anche a causare problemi di spazio su disco; Mi aspetto che tale registrazione venga disabilitata durante le normali operazioni. Il lato positivo è che questo ti dà un livello di informazioni simile a quello che otterresti quando passi attraverso il tuo programma nei casi in cui collegare un debugger potrebbe essere meno pratico.

In generale, trovo che la traccia sia di solito più sforzo di altri approcci.

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

Detto questo, ecco come li ho visti usati:

TRACCIA: utilizzata per mostrare il flusso del programma a livello logico. Hai inserito una funzione? Un'istruzione "if" ha scelto il ramo principale o "else"? Questo è un candidato per la traccia. In altre parole, la registrazione di traccia viene generalmente utilizzata per specificare "sei qui". Ciò è utile nel contesto di altre istruzioni 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 altri eventi registrati a un livello diverso.

DEBUG: utilizzato per il dumping dello 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 fallita". Immagina che uno sviluppatore riceva un registro dal sistema di un utente molto tempo dopo che si è verificato l'errore e si chiede " perché si è verificato l'errore?" questa è una buona cosa per accedere a livello di debug. Un altro esempio potrebbe essere se un bug continua a verificarsi nella produzione ma è difficile da riprodurre, il debug registra determinate variabili o eventi nel modulo problematico per aiutare gli sviluppatori a indicare lo stato del programma quando si verifica l'errore per facilitare la risoluzione dei problemi.

Normalmente si configura 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 avvisi ed errori).

Il vantaggio di separare i livelli di registro è controllare la quantità registrata. Per un'applicazione complessa, la registrazione della traccia potrebbe potenzialmente registrare un'enorme quantità di dati, per lo più inutili per la maggior parte del tempo. È meglio solo registrare informazioni critiche (forse alcune informazioni di avvio, quindi solo errori) a meno che non si stia cercando di individuare come causare un bug. Inoltre, questo è generalmente utile solo in un ambiente di produzione in cui non sono presenti debugger e altri strumenti di sviluppo.

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

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

• DEBUG il logging deve poter essere utilizzato in produzione (ma tende a essere spento normalmente)
• TRACE la registrazione è consentita in modo tale che non sia possibile utilizzarlo in produzione (tranne che per una sessione specifica / breve)

Ecco 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)

L'ipotesi alla base è che lo farà il team operativo

• impostare sempre la produzione su informazioni a livello di registro
• la produzione potrebbe essere impostata su debug a livello di log
• la produzione non è mai impostata su traccia a livello di registro

Con questo presupposto, ecco come tu, come sviluppatore, puoi usare i livelli di registro ...

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

debugrisolve # 1. Sei tu, in qualità di sviluppatore, a fare del tuo meglio per bilanciare le informazioni di cui potresti aver bisogno in produzione senza avere troppo rumore che rallenti la macchina. Stai dicendo "è una buona idea registrarlo costantemente in produzione (se vuoi)".

Problema n. 2) con informazioni dettagliate durante lo sviluppo

tracerisolve il problema n. 2. Non hai assolutamente alcuna preoccupazione sull'impatto che avrebbe su una macchina di produzione, ma al momento hai bisogno di queste informazioni durante lo sviluppo del codice. Stai dicendo "Non prometto che sia una buona idea registrare sempre queste informazioni in produzione".

Concesso (come altri hanno già detto), queste cose sono arbitrarie; quindi assicurati che il tuo team di sviluppo (e il team operativo / di monitoraggio - perché sono anche utenti della tua registrazione) siano d'accordo su qualcosa.

Quale sarebbe un esempio canonico di registrazione a livello di TRACE?

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

1. Il programma si blocca improvvisamente: sai esattamente in quale funzione si è schiantato guardando l'ultima riga del registro

2. Alcune funzioni canaglia falliscono silenziosamente assorbendo un'eccezione

Garantiscono un livello TRACE separato piuttosto che usare DEBUG perché abilitando i registri ENTRY / EXIT per ogni metodo nella tua base di codice genererà un'enorme quantità di registri extra che è irragionevole essere sempre attivi , anche in un contesto DEBUG.