Capito :-)
> > intendevo comunque che non abbiamo log.debug "sto per fare questo" / > "finito di fare questo" sparsi per il codice. > Sono d'accordo, l'unica eccezione e' che se sto per chiamare un altro servizio, faccio "sto per chiamare X con messaggio Y / X mi ha risposto con il messaggio Y > > Uberto > > > Uberto > > > On Fri, 9 Nov 2018, 11:27 Matteo Vaccari [email protected] > [it-torino-java-jug] <[email protected] wrote: > >> >> >> Come minimo pero' ce l'avrai un access log? Capisco che loggare tutti i >> dati in ingresso e in uscita è discutibile, ma almeno sapere se ti abbiamo >> dato un 200 o un 400... :) >> >> Il giorno ven 9 nov 2018 alle ore 11:52 Uberto Barbini >> [email protected] [it-torino-java-jug] < >> [email protected]> ha scritto: >> >>> >>> >>> 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] >>> <[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 >>>>> >>>> >
