si scusa non sono molto sveglio questa mattina: il server http e httpclient hanno un filtro che logga (sempre con eventi) tutto in entrata e uscita, su tutti i ms, così possiamo fare tracing ecc. probabilmente tu hai lo stesso.
intendevo comunque che non abbiamo log.debug "sto per fare questo" / "finito di fare questo" sparsi per il codice. 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 >>>> >>> >
