Hai ragione nel rispondere a questa domanda, "quali sono le tue esigenze", ma questa è la mia opinione.
Assicurati che qualsiasi evento avviato da un utente sia riconducibile all'utente. Ogni evento registrato dovrebbe indicare chi sta eseguendo l'evento, o almeno contiene un ID transazione che può essere ricondotto all'utente che crea la transazione. Ciò ti consentirà di soddisfare i requisiti di non rifiuto in cui un utente non sarebbe in grado di negare la creazione della transazione.
Non consiglierei di creare un nuovo file di registro per ogni sessione. Un approccio migliore sarebbe creare nuovi file di registro una volta raggiunta una certa dimensione (ad esempio 10 MB). Oppure, è sufficiente creare un nuovo file di registro ogni giorno o settimana (a seconda della dimensione dei file). Se vengono registrati molti eventi, un database può essere migliore in quanto può gestire grandi volumi di dati più facilmente e sarà possibile interrogare i risultati secondo necessità.
Per le librerie, ce ne sono molte là fuori per Java EE. Log 4J va bene. Ho anche usato il Commons Logging di Apache, ma preferisco la combinazione di SLF4J e Logback personalmente: sono facili da usare e si integrano bene con altri framework di registrazione.
Potresti anche voler guardare ad Aspect Oriented Programming per creare gli eventi di logging comuni che appariranno in molti modi. In particolare, AOP può aiutare a creare la registrazione di debug per il metodo enter / exit / throw. Ho fatto AOP con Spring e posso dirlo è molto utile per mantenere pulito il codice.
Parlando di livelli di registrazione, sarà molto utile fare buon uso di ogni livello come appropriato e creare un modo sicuro per modificare il livello in fase di esecuzione se si verificano problemi.
Registra solo gli errori che potrebbero essere utili per l'accesso. Tautologico, forse, ma la registrazione può spesso sfuggire di mano. Avere troppi record da esaminare significa che non sarai in grado di identificare valori anomali o problemi reali. La registrazione troppo piccola significa che potresti perdere un problema (se non lo hai registrato, non è mai successo), quindi, usa bene i livelli di registrazione anche per questi motivi. Potrebbe non esserci motivo per registrare un errore di convalida dell'utente (ad esempio, creando una nuova password inferiore al numero consentito di chacters), ma gli errori di sistema devono sempre essere registrati (ad esempio, impossibile contattare il database).
Allo stesso modo, informa l'utente solo di ciò che è necessario sapere. Avranno bisogno di sapere se la password che hanno inserito non è riuscita a convalidare e perché, ma non hanno bisogno di sapere se il database è inattivo (hanno solo bisogno di sapere che il sito sta riscontrando problemi e cosa possono fare nel frattempo - cioè, chiama un numero di supporto). La chattiness per l'utente deve essere ridotta al minimo in quanto le notifiche di errori costanti che non possono essere risolte personalmente potrebbero rappresentare un'esperienza utente scadente.
Ti suggerisco di dare un'occhiata a Logging Cheat Sheet di OWASP per ulteriori informazioni sulla registrazione delle best practice.