Regole e consigli per la registrazione?

Come estensione della regola di registrazione in cui l'applicazione proviene dall'espressione del log, è possibile che si desideri aggiungere flag di registrazione a livello di modulo. Invece di registrare tutto, sempre, questo ti permette di indirizzare selettivamente sezioni della tua applicazione. C'è un sovraccarico in questo, ed è necessario creare una funzione che consente di abilitare / disabilitare tale registrazione. Idealmente, si sarebbe in grado di abilitare / disabilitare al volo mentre l'applicazione è in esecuzione.

Sono abituato a vedere un livello sotto il debug che io definisco "Trace", ma non è necessariamente un termine universale. Le tracce di registrazione del livello "Trace" possono essere conservate per quanto possibile, inclusi l'ingresso / uscita del modulo, i timestamp con entrata / uscita e i punti bonus per l'acquisizione dei valori passati. Ovviamente, questo genera un sacco di dati e non è qualcosa che si accende su volente o nolente. Ma ha dei vantaggi rispetto al debug quando non puoi collegarti al processo o non hai un core dump dell'applicazione errante.

Mi piace vedere i riferimenti di file / modulo e le marche temporali con le mie informazioni di registro. Può essere utile quando si cerca di rintracciare le condizioni di gara tra le discussioni e di coordinare le attività di più aree dell'applicazione. Per essere onesti, conosco gente che pensa che questi dettagli ingombrino il file di registro. Aggiungere il timestamp è qualcosa da discutere con il team. (Mi scuso se log4j lo fa già.)

Se la registrazione non viene gestita dal proprio thread / processo, è una cosa da considerare. Invece di fare in modo che il thread dell'applicazione attenda che la registrazione venga elaborata, il messaggio di log viene trasmesso al gestore log e il thread dell'applicazione procede in modo allegro. In alternativa, creare un meccanismo di buffer per gestire i messaggi di registro è un altro modo per accelerare la reattività dell'applicazione.

Avere controlli sulla dimensione e sulla cronologia dei file di registro è un'altra caratteristica da considerare. Non vuoi che l'app elimini tutto lo spazio su disco sul sistema host, né vuoi necessariamente conservare tutti i file di registro per l'eternità.

Una cosa da tenere a mente è controllare il livello di registrazione prima di eseguire qualsiasi tipo di operazione di stringa per la registrazione. Cioè, non andare a tutto il lavoro di impostare un formattatore di date o concatenare un gruppo di stringhe per creare il messaggio di log se non si sta andando davvero a registrarlo. È solo uno spreco di lavoro che rallenta l'applicazione.

FYI, il progetto Apache Commons ha un ToStringBuilder classe che semplifica la creazione dei tuoi metodi toString() .

Non trovo nulla di discutibile in ciò che hai aggiunto qui Nick. È così che lo faccio da un po 'di tempo. Il post che hai fornito è molto dettagliato e probabilmente può essere usato come una sorta di tutorial per la registrazione. Comunque, voglio aggiungere una cosa qui, che è: In molti posti, ho visto chaps usare la registrazione condizionale, per es. :

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Penso che questo tipo di traccia condizionale o di debug non sia il modo migliore per andare.

Oltre a registrare la classe / metodo che ha generato l'errore, sarebbe utile anche registrare i parametri passati in quel metodo. Sapere dove è stato sollevato un errore non è molto utile se si verifica solo 1 volta su 1000; devi anche sapere quali dati hanno causato l'errore.

Ho anche trovato utile avere una variabile che definisce il livello predefinito di registrazione per un'applicazione. In questo modo puoi avere il codice DEBUG e INFO insieme al codice WARNING e ERROR. Quando si esegue in modalità di produzione, l'impostazione predefinita non genera informazioni DEBUG, ma quando si verifica un errore è possibile aggiornare un flag e iniziare a scrivere i messaggi DEBUG anche nel registro.

La registrazione è per lo più una preoccupazione trasversale. Java da solo non è abbastanza espressivo per renderti in grado di separare la registrazione dalle logiche di business attuali. Ciò significa che non è possibile, ad esempio, prendere solo un metodo e inserirlo in un altro progetto, ma è necessario rimuovere e modificare tutte le registrazioni prima di farlo. E questa è solo la punta dell'iceberg.

Per evitare questo ed altri problemi quando si mischiano log e logiche di business "reali" dovresti considerare l'uso della programmazione orientata all'aspetto. Per Java il framework più utilizzato sarebbe AspectJ. C'è questo video di youtube dai talk di google tech che spiega AspectJ ei suoi usi al di là del logging piuttosto bene. Troverai molti esempi per la registrazione di te stesso qui anche su stackexchange .

Una cosa che suggerirei sarebbe quella di avere un mezzo per avere più contesti di logging associati ad un particolare file di log, e fare in modo che qualsiasi cosa scritta in qualsiasi contesto di logging venga registrata a meno che non sia esplicitamente chiede al contesto di registrazione di scartarne il contenuto. Tale progetto consentirà di acquisire registri piuttosto dettagliati durante un'operazione e di scartarli se l'operazione ha esito positivo, ma averli disponibili se l'operazione non riesce. In assenza di tale funzione di registrazione, avere buoni registri disponibili quando qualcosa non funziona può richiedere che un'applicazione impieghi molto tempo a registrare dati inutili nel 99,99% dei casi in cui tutto funziona.