È normale scrivere tutti i log in un singolo file?

Si noti che le domande sulle "migliori pratiche" sono scoraggiate, perché hanno una risposta troppo facile come se ci fosse un modo unico di fare qualcosa che sia superiore a tutti gli altri. Quasi sempre, non c'è un modo.

Quando decidi se utilizzare un flusso di log o diversi contemporaneamente, devi valutare quale sia il costo e il vantaggio nel caso di utilizzo previsto . Scrivere tutto su un flusso è facile durante la programmazione, ma richiede uno sforzo maggiore quando devi recuperare o analizzare i registri. L'ordinamento preliminare di tutti gli output dei registri richiede uno sforzo maggiore quando si programma ogni messaggio di registro, ma si risparmia qualche sforzo durante la lettura dei registri.

Nelle situazioni che conosco, i messaggi di registro sono programmati più spesso di quanto non siano segnalati dai clienti o ricercati dal personale di supporto, quindi ha senso rendere il caso comune (in via di sviluppo) facile al costo di uno sforzo maggiore in il caso più raro (risoluzione dei problemi). L'analisi di un log comporta comunque la ricerca e la ricerca di un file più lungo non è molto più impegnativa della ricerca di uno dei tanti file più brevi perché il computer svolge il lavoro principale, non il cervello.

Ma questo è solo il mio progetto e la mia visione del mondo. Se (fortunatamente tu!) Hai milioni di clienti e un enorme traffico di richieste di supporto, i log verranno analizzati molto più spesso di quanto non siano scritti. In tal caso ha senso rendere i rapporti, analizzare e correlare i registri il più semplice possibile a costo di rendere più difficile programmare un nuovo messaggio di registro. Quindi si dovrebbe fare più sforzo per rendere efficiente il flusso di lavoro di reporting e analisi. (Ad esempio, se i clienti riscontrano problemi nella raccolta di tutti i registri pertinenti, è una buona idea programmare il recupero dei log nel software in modo che l'utente amministratore debba solo premere un pulsante per inviare tutto quanto pertinente.)

Supponiamo che tu stia parlando di file di registro con lo scopo di riprodurre gli scenari di errore che si verificano sul sito dei tuoi clienti (che non hai descritto). Supponiamo che i file di log vengano analizzati da te, non dal cliente stesso. Supponiamo che i file di registro non raggiungano una dimensione di diverse centinaia di MB. Quindi il lead della tua squadra è corretto, un file di log è probabilmente più facile da gestire rispetto a molti.

La situazione cambia se ci sono molti tipi di registri completamente diversi, e diversi utenti del tuo cliente (con ruoli diversi) devono guardare direttamente nei file di registro da soli, e ogni utente deve vedere diversi tipi di informazioni. Quindi avrebbe più senso dividere i registri tematicamente. Se le dimensioni del file di registro sono importanti, potrebbe essere una buona idea suddividere i registri su intervalli di tempo (ad esempio, un registro per ogni giorno, settimana o mese).

Qualunque cosa tu faccia, è sempre una buona idea rendere le informazioni del registro filtrabili . Ciò significa aggiungere tag leggibili dalla macchina a ciascuna voce del registro, ad esempio, quale applicazione o sottosistema ha prodotto la voce, si trattava di un avviso, di un messaggio di errore grave o di informazioni di stato e, naturalmente, aggiungere l'indicazione di data esatta. Ciò ti aiuterà a trovare le informazioni di cui hai bisogno in seguito molto più facilmente anche quando le hai tutte in un unico file.

E spesso non è necessario sviluppare il proprio analizzatore di log - ci sono ottimi strumenti gratuiti come MS log parser che può interrogare e filtrare i file di registro per te. Per alcuni scenari non hai bisogno di molto più di un foglio di calcolo decente.

Penso che preferirei addirittura un logfile con tutto ciò che contiene.

La mia esperienza fino ad ora è che i file di log sono particolarmente utili per bug in cui c'è un problema nella comunicazione tra i sottosistemi. Se tutti si collegano allo stesso file, rende il problema più facile da diagnosticare, perché è possibile vedere la cronologia di ciò che sta accadendo.

Anche per problemi di prestazioni specifici del cliente, è spesso utile essere in grado di correlare ciò che sta accadendo in tutti i sottosistemi alla stessa ora del problema.

Mettendo il mio sysadmin hat, la pratica migliore è che gli sviluppatori mettono molte chiamate di registrazione nelle loro app e poi espongono il livello di registrazione e la configurazione di destinazione per me: accedere al file potrebbe funzionare in uno scenario ma potrei davvero volere per inviare materiale a SNMP in un altro o per inviarlo a un altro. Per favore non prendere le mie decisioni per me.