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 >>> >> >
