Il nostro approccio e' diverso dal tuo in questo: i servizi in genere non loggano le cose che vanno bene, a meno che non siano significativi per il business. Tanto meno loggano tutti i dati in ingresso e uscita.
Tanto per fare un esempio, non logghiamo: - utente Tizio si e' autenticato - Tizio ha chiesto la pagina SubmitPaper - Tizio ha riempito i campi di SubmitPaper - salvato su db i dati di SubmitPaper - risposto a Tizio "tutto bene". Logghiamo solo "Tizio ha salvato il suo paper xy" Se pero' succede qualche cosa di inaspettato (exception) o previsto ma sbagliato (network failure, etc.) logghiamo tutti i dati utili possibili per capire cosa e' successo. make sense? Uberto On Fri, 9 Nov 2018 at 08:28, Matteo Vaccari [email protected] [it-torino-java-jug] <[email protected]> wrote: > > > Io per il logging ho una regoletta molto semplice che dice: > > 1. logga tutto quello che il tuo servizio riceve come input, e quello > che rispondiamo > 2. quando vai a interrogare un servizio esterno, logga quello che gli > abbiamo mandato e quello che ci ha risposto > 3. logga tutte le eccezioni inaspettate, ma solo al livello piu' > esterno del call stack > 4. non loggare nient'altro > > Magari ci possono essere occasionali eccezioni alla regola 4, e le regole > 1 e 2 devono evitare di loggare dati sensibili, ma con questo sistema sei > in grado di fare sia analisi dei guasti, sia di osservare che cosa fa il > tuo sistema in generale. > > Domanda per Uberto: ma se tu passi il monitor che riceve gli eventi giu > giu giu fino agli oggetti di dominio, non ti da fastidio aggiungere un > parametro extra a tutti i costruttori? Od ho sbagliato io a capire? > > Il giorno ven 9 nov 2018 alle ore 08:50 Simone Bordet > [email protected] [it-torino-java-jug] < > [email protected]> ha scritto: > >> >> >> Ciao, >> >> >> >> On Thu, Nov 8, 2018 at 11:53 PM Uberto Barbini [email protected] >> [it-torino-java-jug] <[email protected]> wrote: >> > in questo modo i log entrano a far parte del dominio, specifiche e >> tutto il resto. Inoltre non c'e' piu' il concetto di debug/info/warn/trace >> ecc. o un evento e' significativo e lo notifichi oppure no. >> >> Ma secondo me il problema è definire "significativo". >> Quello che è importante per qualcuno non lo è per qualcun altro. >> >> Io sono sempre stato un fan del tagged logging: niente livelli >> (debug/info/warn) ma solo tags. >> A quel punto come dici tu il logging diventa una feature e cosa devi >> loggare dal punto di vista del business lo chiedi al cliente, mentre >> lo sviluppatore fa il logging degli internals dell'implementazione. >> >> Da Java 9 si è arrivati a questo per il logging interno della JVM, ma >> niente da fare ancora per il logging applicativo e i vari SLF4J, >> Log4J2 e LogBack che sono ancorati al modello di 20-30 anni fa. >> >> >> >> > Kirk Pepperdine mi ha fatto notare una volta come uno dovrebbe loggare >> il meno possibile quando va tutto bene e il piu' possible quando succede >> qualche cosa di sbagliato. >> >> Anche qui definire "sbagliato" è difficile. >> >> -- >> Simone Bordet >> --- >> Finally, no matter how good the architecture and design are, >> to deliver bug-free software with optimal performance and reliability, >> the implementation technique must be flawless. Victoria Livschitz >> > >
