Come sapere quando ci sono troppi messaggi di registrazione?

Question

Ho trovato una libreria molto buona per l'analisi dei file CUE. Ma quando ho iniziato a leggere il suo codice sorgente, mi sono reso conto che è quasi illeggibile:

public void setParent(final CueSheet parent) { 
    FileData.logger.entering(FileData.class.getCanonicalName(), "setParent(CueSheet)", parent); 
    this.parent = parent; 
    FileData.logger.exiting(FileData.class.getCanonicalName(), "setParent(CueSheet)"); 
} 

ogni metodo ha logger.entering() e logger.exiting) messaggi (. Non è troppo?

C'è un'altra libreria java per l'analisi dei tag audio. Aveva anche 15 messaggi di registro per ogni file letto. E 'stato fastidioso quindi ho commentato ogni chiamata al logger. E la libreria è diventata due volte più veloce, perché hanno utilizzato un sacco di concatenazione di stringhe per i messaggi di registro.

Quindi la domanda è: devo davvero registrare tutto, anche se non è un'applicazione enterprise di grandi dimensioni? Perché queste librerie ovviamente non hanno bisogno di alcuna registrazione, tranne che per i messaggi di errore. E la mia esperienza mostra che i logger sono strumenti terribili per il debug. Perché dovrei usarlo?

Answer 1

Come sapere quando è troppo il logging? Quando si sa che le informazioni registrate non sono importanti a lungo termine, essendo per le azioni di debug o correzione dei bug, o l'applicazione non si occupa di informazioni troppo importanti.

A volte è necessario registrare quasi tutto. Le prestazioni o la piena possibilità di analisi sono la parte più importante di un'applicazione? Dipende davvero.

Ho lavorato in passato con una certa integrazione con molti diversi servizi web, come 10 in una stessa app. Abbiamo registrato tutte le richieste e le risposte xml. È un sovraccarico? A lungo termine, io non la penso così perché abbiamo lavorato con molte operazioni con carte di credito e ogni processo dovrebbe essere eseguito con il server registrato. Come sapere cosa è successo a quando c'è stato un errore?

Non si crederebbe a quello che ho visto in alcune delle risposte xml. Ho persino ricevuto un xml senza tag di chiusura, da una grande compagnia di aeroplani. I "registri eccessivi" erano una cattiva pratica? Dillo ai tuoi clienti quando devi dimostrare che l'errore proviene dall'altro fornitore.

Answer 2

Idealmente, si utilizza un logger che consente i livelli di registrazione; log4j ha fatal/error/warn/debug/info, per esempio. In questo modo, se si imposta il livello su "Mostra solo errori", non si perde la velocità dei messaggi del log di costruzione del software che non erano necessari.

Detto questo, è solo troppa registrazione fino a quando non si ha bisogno di qualcosa che sarebbe stato registrato. Sembra che la maggior parte del logging che ti rallenta dovrebbe essere a livello di "traccia"; ti sta mostrando ciò che un profiler avrebbe.

Answer 3

Dipende, è questo codice per un'applicazione o una libreria? Per un'applicazione, i programmi di registrazione sono utili una volta che il codice è in produzione. Non dovrebbe essere usato per il debug, ma per aiutarti a replicare un bug. Quando un utente ti dice che la tua applicazione si è bloccata, vuoi sempre le informazioni di registrazione massime.

Sono d'accordo che rende il codice meno leggibile. Rende anche l'applicazione più lenta!

È un gioco completamente diverso per una biblioteca. Dovresti avere una registrazione coerente con un livello adeguato. La libreria DOVREBBE informare il team di sviluppo quando si verifica un errore.

Answer 4

La registrazione dovrebbe fornire informazioni che una traccia dello stack non è in grado di rintracciare un problema. Questo di solito significa che l'informazione è una sorta di traccia storica di ciò che il programma ha fatto, a differenza di quale stato è al momento del fallimento.

Troppi dati storici verranno ignorati. Se è possibile dedurre che è stato chiamato un metodo senza dover effettivamente registrare la sua voce e uscire, è possibile rimuovere tali voci di registrazione in sicurezza.

Un altro segno negativo è se i file di registro iniziano a consumare un'enorme quantità di spazio su disco. Non stai sacrificando solo lo spazio, probabilmente stai rallentando troppo l'app.

Answer 5

Per rispondere alla domanda, perché dovrei utilizzare i logger?

Avete mai incontrato un software in cui l'unico errore indicato presentato all'utente finale è Fatal error occured. Non sarebbe bello scoprire cosa l'ha causato?

La registrazione è uno strumento che può davvero aiutare a restringere questo tipo di problemi sul campo. Ricorda che i sistemi degli utenti finali non hanno un buon IDE per il debug e gli utenti finali di solito non sono abbastanza informati per eseguire questi strumenti. Tuttavia, gli utenti finali, nella maggior parte dei casi, sono in grado di copiare i file di configurazione del registro (scritti da noi, programmatori intelligenti) in posizione predefinita e recuperare i file di registro e inviarli via e-mail (suole scadenti per dover analizzare i megabyte dell'output del registro) quando incontrano problemi.

Detto questo, la registrazione dovrebbe essere altamente configurabile e in condizioni normali produrre un output minimo. Inoltre, le guardie dovrebbero proteggere la registrazione di livello più fine dal consumare troppe risorse.

Penso che nell'esempio che è stato fornito tutto il logging avrebbe dovuto essere eseguito a livello TRACE. Inoltre, poiché in realtà non può succedere nulla di brutto tra il punto di ingresso e l'uscita della funzione, probabilmente è logico disporre di un'unica istruzione di registro.

Answer 6

maggior parte delle librerie di registrazione incorporano un mezzo per confermare che la registrazione è attivata prima di elaborare un'istruzione:

Ad esempio:

public void foo(ComplicatedObject bar) { 
    Logger.getInstance(Foo.class).trace("Entering foo(" + bar + ")"); 
} 

Potrebbe essere molto costoso a seconda dell'efficienza del bar.toString() metodo. Tuttavia, se si avvolgono invece che in un controllo per il livello di registrazione prima di fare la concatenazione di stringhe:

static { 
    Logger log = Logger.getInstance(Foo.class); 

public void foo(ComplicatedObject bar) { 
    if (log.isTraceEnabled()) { 
     log.trace("Entering foo(" + bar + ")"); 
    } 
} 

Poi la concatenazione di stringhe si verifica solo se almeno un appender per la classe è impostato su Trace. Qualsiasi messaggio di registro complicato dovrebbe fare questo per evitare la creazione di stringhe non necessarie.

Answer 7

Nel corso degli anni ho oscillato avanti e indietro tra promuovendo la registrazione di tutto ai livelli appropriati (traccia, informazioni, ecc ...) e pensando che qualsiasi è una completa perdita di tempo. In realtà dipende da cosa sarà utile rintracciare o richiedere (la registrazione può essere un modo economico per mantenere una pista di controllo).

Personalmente, tendo a registrare l'entrata/uscita a un componente oa un livello di servizio e quindi registrare i punti significativi nell'elaborazione, ad esempio una decisione di business logic o una chiamata su un altro servizio/componente. Ovviamente gli errori vengono sempre registrati, ma solo una volta e nel luogo in cui sono stati gestiti (il messaggio di traccia e eccezione dovrebbe contenere informazioni sufficienti per diagnosticare il problema) e qualsiasi interfaccia di servizio/componente dovrebbe sempre gestire errori (anche se è solo convertendolo in un altro più appropriato per il chiamante).

Il problema con la registrazione di file nella remota possibilità che qualcosa vada storto è che si finisce con troppe informazioni che è impossibile identificare il problema, specialmente se è in esecuzione sotto un server quando si finisce con un sacco di intrecci voci di registro. Ovviamente è possibile aggirare il problema incorporando un ID di richiesta nella voce e utilizzando alcuni software per filtrarlo. Ovviamente hai anche il caso in cui la tua applicazione è distribuita e/o cluster e hai più log.

Al giorno d'oggi non scriverò mai il codice di entrata/uscita delle entrate, il codice è solo di intralcio ed è molto più facile usare qualcosa come aspectj se è davvero necessario. L'uso di aspectj garantisce inoltre di essere coerente (è possibile modificare il formato del registro in un unico posto piuttosto che dover cambiare ogni operazione) e preciso (nel caso in cui alcuni refactoring aggiungano un nuovo parametro e lo sviluppatore dimentichi di aggiungerlo al logging).

Una cosa che ho pensato di fare o in cerca di vedere se qualcuno ha già è un registratore che conterrà le voci in memoria, allora, se si verifica un errore sono scritte, se l'operazione ha esito positivo le voci sono solo scartate. Se qualcuno ne conosce uno (idealmente per log4j) per favore fammelo sapere, in alternativa ho qualche idea su come implementarlo se qualcuno è interessato a farne uno.

Answer 8

Questo livello di registrazione è canonicamente scorretto: in effetti, ho visto il codice exactly like this nel Daily WTF alcuni giorni fa.

Ma la registrazione è in generale una cosa molto buona.