Discutiamo internamente nel nostro team se dovessimo continuare a gestire le nostre caselle di produzione con i registri completamente disattivati e registrare solo errori ed eccezioni con le rotazioni del registro.
Voglio sapere in che modo gli altri registrano le informazioni nel loro ambiente di produzione e qualsiasi strategia / strumento particolare che ha funzionato bene per te.
Grazie Isaq
Se sei sicuro che sarai in grado di riprodurre eventuali errori che si verificano, allora in ogni caso spegni i log. Tuttavia, raramente è così semplice e gli errori rari sono spesso quelli più difficili da riprodurre. Avere i registri ti aiuterà qui.
Se le stai spegnendo perché occupano molto spazio su disco, dovresti cercare perché sono così grandi. Che cosa stai registrando esattamente? hai bisogno di per tenere registri di tutto o puoi essere più selettivo.
Un'altra alternativa è quella di ruotare i log più velocemente in modo che ogni file copra un periodo di tempo più breve e tu delete archivi il registro anche prima.
Avrai sempre bisogno di un registro heart-beat per registrare gli alti e bassi della tua applicazione e assicurarti che l'applicazione sia ancora attiva.
Probabilmente vorrai anche un log delle transazioni che ti permetta di vedere le basi assolute del flusso di dati dell'applicazione.
Molto probabilmente NON vorrà eseguire un log di debug completo, poiché potrebbe causare un sovraccarico.
Il mio attuale approccio è di avere server di produzione con registri attivi, ma con un certo livello di verbosità. Questo livello di verbosità è ottimizzato per contenere messaggi che denotano azioni significative all'interno dell'applicazione. Quando viene segnalato un errore, quelle azioni significative sono utili per capire il contesto dell'errore. Il vantaggio di tale contesto è che è più facile capire esattamente la natura dell'errore e fornire una soluzione reale. A volte senza una precisa sequenza di eventi non sarai nemmeno in grado di individuare errori nel tuo codice (le tracce dello stack non indicano necessariamente la causa principale del problema).
Possiamo anche passare la verbosità al cosiddetto "livello di debug", dove viene registrato ogni piccolo dettaglio significativo. Questo è utile quando non riusciamo a trovare un errore da parte nostra, ma l'applicazione non si comporta correttamente. Viene attivato per brevi periodi di tempo e, come ci si potrebbe aspettare, genera molti dati da masticare.
Non prestiamo alcuna attenzione alle dimensioni del registro. Poiché i registri vengono utilizzati solo per tenere traccia degli errori, vengono rimossi dopo 14 giorni. Questo periodo è abbastanza lungo perché qualcuno possa notare e segnalare un errore e che il nostro team possa controllare i file di registro e fornire una soluzione.
Penso che sia semplicemente necessario uno schema di registrazione migliore.
Se c'è un problema di prestazioni:
Se si tratta di un problema di archiviazione:
In entrambi i casi, potresti voler effettuare una verifica dei log, potrebbe essere che le tue pratiche di registrazione non siano adeguate all'ambiente in cui ti stai evolvendo.
Ad esempio, dove lavoro, abbiamo server che elaborano alcune centinaia di transazioni al secondo. Lo schema di registrazione è adattato:
Alcune delle nostre applicazioni più prolisse rilasciano file da 50 MB due volte al secondo (che è solo ~ 15 MB una volta compressi). I loro log sono conservati per 14 giorni ancora.
Quando un cliente ti chiama, chiedendo perché la transazione che ha fatto 3 giorni fa a circa 14 ore o forse 15 ore (ora locale per lui, ovviamente) non è riuscita, non puoi rispondere senza log. E no, non può riprodurre il problema, i dati sono cambiati da allora.
Leggi altre domande sui tag logging production