Suppongo che tu stia utilizzando un tipo di utility di registrazione di terze parti che supporta più livelli di registrazione che possono essere modificati senza dover ricompilare il codice sorgente (come Log4J o SLF4J). Se non lo sei, fai un favore a te stesso e implementalo ... ieri.
Un buon schema di registrazione dovrebbe consentire di diagnosticare la causa principale di qualsiasi problema senza ricompilare il codice . Ovviamente, il solo logging dello stack trace non ti darà molto contesto. D'altra parte, la registrazione di ogni passaggio logico uccide le prestazioni delle applicazioni e consuma un sacco di spazio su disco. Il trucco è di impostare i registri predefiniti sulla quantità minima di dettagli, ma concediti la possibilità di aumentare il livello di registrazione in caso di problemi.
Per l'elaborazione normale, la quantità minima di registrazione necessaria è probabilmente la migliore per accedere al livello INFO. Pensa a questo come un sommario in un libro: non ti racconterà la storia, di per sé, ma ti darà un'idea su dove cercare e trovare quello che vuoi. Registrare i passaggi, i servizi o le classi di processo di alto livello con messaggi informativi generici come "Avvio processo di convalida" o "Recupero dati query", ma utilizzare questo livello di messaggio con parsimonia (o non del tutto) nei servizi di livello inferiore, classi o funzioni per evitare confusione.
Uso i messaggi DEBUG più come i breadcrumb. Se il livello INFO ha fatto il suo lavoro, allora dovrei avere una buona idea di quale processo si sia interrotto. Da lì, dovrei essere in grado di attivare il livello DEBUG e capire quale classe ha avuto l'azione incriminata. Per garantire ciò, mi assicuro di registrare un messaggio di livello DEBUG su ogni voce e punto di uscita per ogni metodo in ogni classe . In ingresso, registro il nome del metodo, i nomi dei parametri formali e i valori passati per ciascuno di questi parametri. All'uscita, registro nuovamente il nome del metodo e fornisco il nome e il valore di ogni variabile restituita o dichiaro che il metodo non restituisce nulla.
Se sono necessari ulteriori dettagli, è possibile attivare il livello TRACE per la classe che causa l'errore. La registrazione del livello di traccia dovrebbe consentire di seguire ogni passaggio logico della classe, quasi come se si passasse attraverso il codice utilizzando un debugger. Tieni presente che nella maggior parte delle applicazioni live non avrai il lusso di usare un debugger, quindi il livello di TRACE è spesso il più vicino possibile a quel livello di feedback. Naturalmente, questo è anche il livello di registrazione più noioso e, nella mia esperienza, il più spesso trascurato. Nella registrazione TRACE, provare almeno a includere i punti critici critici nel metodo (tutti i percorsi nelle istruzioni condizionali, i puntatori nei loop, ecc.) Per consentire all'utente di seguire il percorso che l'applicazione ha intrapreso verso la sua scomparsa.
Tornando all'esempio, una classe DTO è ciò che considererei un codice piuttosto basso. Probabilmente non hai bisogno di alcuna registrazione a livello di INFO qui, ma DEBUG sui punti di entrata / uscita dovrebbe essere aggiunto insieme al log di TRACE per qualsiasi processo di elaborazione delle chiavi o eventi decisionali nel DTO. Quindi, assicurati di impostare il livello di registrazione sul DTO su INFO in modo che questi eventi non vengano registrati normalmente.
Un paio di altri suggerimenti:
- Registrazione predefinita al livello INFO
- Assicurati di utilizzare un appender scorrevole per registrare l'output in più file anziché in un file enorme.
- Output, al minimo, TIMESTAMP, CLASS, THREAD, LINE NUMBER gli appendici del log
- Quando si aggiungono i messaggi DEBUG che registrano i valori delle variabili, tenere presente che il metodo to_string () di molte classi non viene sovrascritto in modo da non ottenere risultati utili. Prova a utilizzare il metodo statico ReflectionToStringBuilder.toString (Oggetto dell'oggetto).