Best practice per la registrazione e la traccia in .NET

Question

Best practice per la registrazione e la traccia in .NET

#1 da (15 voti)
#2 da (5 voti)
#3 da (2 voti)

50

Ho letto molto sul tracciamento e la registrazione, cercando di trovare qualche regola d'oro per le migliori pratiche in materia, ma non ce n'è alcuna. La gente dice che i bravi programmatori producono una buona traccia, ma la mettono in questo modo e deve provenire dall'esperienza.

Ho letto anche domande simili qui e tramite Internet e non sono esattamente la stessa cosa che sto chiedendo o non ho una risposta soddisfacente, forse perché le domande mancano di dettagli.

Quindi, la gente dice che la traccia dovrebbe replicare l'esperienza del debug dell'applicazione nei casi in cui non è possibile allegare un debugger. Dovrebbe fornire un contesto sufficiente in modo che tu possa vedere quale percorso è preso in ogni punto di controllo nell'applicazione.

Andando più a fondo, puoi anche distinguere tra la traccia e la registrazione degli eventi, in quanto "la registrazione degli eventi è diversa dalla traccia in quanto cattura gli stati principali piuttosto che il flusso di controllo dettagliato".

Ora, diciamo che voglio eseguire il mio tracciamento e la registrazione utilizzando solo le classi .NET standard, quelle nello spazio dei nomi System.Diagnostics . Ho capito che la classe TraceSource è migliore per il lavoro rispetto alla classe Trace statica, perché voglio differenziare i livelli di traccia e utilizzare la classe TraceSource che posso passare in un parametro che informa il tipo di evento, mentre uso la classe Trace che devo usare Trace.WriteLineIf e poi verifica cose come SourceSwitch.TraceInformation e SourceSwitch.TraceErrors , e non ha nemmeno proprietà come TraceVerbose o TraceStart .

Considerando tutto ciò, considereresti una buona pratica come segue:

Tracciare un evento "Start" all'avvio a metodo, che dovrebbe rappresentare a singola operazione logica o a pipeline, insieme a una stringa rappresentazione del parametro valori passati al metodo.
Traccia un evento "Informazioni" quando inserire un elemento nel database.
Traccia un evento "Informazioni" quando prendendo un percorso o l'altro in un importante if / else statement.
Traccia un "Critico" o "Errore" in a blocco di cattura a seconda che si tratti è un errore recuperabile.
Traccia un evento "Stop" al termine l'esecuzione del metodo.

Inoltre, ti preghiamo di chiarire quando è meglio tracciare i tipi di eventi Verbose e Warning. Se hai esempi di codice con una traccia / registrazione piacevole e sei disposto a condividere, sarebbe eccellente.

Nota: ho trovato alcune buone informazioni qui, ma non sono ancora quello che sto cercando: link

Grazie in anticipo!

.net logging

posta Levidad 11.03.2011 - 13:41

fonte

3 risposte

Leggi altre domande sui tag .net logging

Anni di esperienza oltre la laurea incompiuta? [chiuso] Due strutture con gli stessi membri ma nomi diversi, è una buona idea?

score 15 · Answer 1

L'importanza dei tipi di tracciamento deve essere scelta non a causa di dove si trova la traccia nel codice, ma perché il messaggio tracciato è più o meno importante. Esempio:

Trace a "Start" event when begining a method, which should represent a single logical operation or a pipeline, along with a string representation of the parameter values passed in to the method.

Usa il tipo di partenza quando avvii un'operazione logica. Punto. Questo non significa che la traccia iniziale deve essere all'inizio di un metodo, né significa che un metodo deve avere una traccia di avvio.

Detto questo, nella maggior parte dei casi, un'operazione logica inizierà effettivamente all'inizio del metodo. Altrimenti, dovresti chiederti se il codice è stato rifatto correttamente.

I parametri di analisi potrebbero anche essere una cattiva idea . Devi pensare a cosa tracciare, caso per caso. Ad esempio, è davvero brutto tracciare i parametri di un metodo void Authenticate(string userName, string plainPassword) .

Trace an "Information" event when inserting an item into the database.

Dipende. Alcuni elementi devono essere tracciati, ma non tutti gli articoli.

Ad esempio, immagina di inserire effettivamente un elemento del registro nel tuo database. Tracci i log? E poi registra le tracce? E quindi tracciare la registrazione della traccia?
Un altro esempio: stai inserendo un dato sensibile. Ciò richiede un controllo. Dal momento che hai verificato l'inserimento, perché tracciarlo?

Trace an "Information" event when taking one path or another in an important if/else statement.

Di nuovo, dipende.

Trace a "Critical" or "Error" in a catch block depending on weather this is a recoverable error.

L'azione intrapresa dopo un errore irreversibile può essere più che tracing. Ad esempio lato server, si desidera memorizzare l'eccezione nel database per ulteriori analisi. Inoltre, alcune eccezioni sono meno importanti di altre e non richiedono la traccia.

Trace a "Stop" event when finishing the execution of the method.

Vedi il primo punto.

please clarify when best to trace Verbose and Warning event types.

verbose:

Verbose viene utilizzato per tracciare ciò che è necessario tracciare quando qualcosa va veramente male. Significa che nella maggior parte dei casi, disabiliterai la traccia dei messaggi dettagliati, ma a volte devi eseguire il debug di alcune parti del codice per capire perché qualcosa non funziona su un caso limite.

Di solito hai molti messaggi dettagliati che ti permettono di capire molto bene il flusso dell'applicazione. Significa anche che tali messaggi devono essere disabilitati la maggior parte del tempo perché:

altrimenti, il registro crescerà molto velocemente,
non ne hai bisogno la maggior parte del tempo,
possono contenere dati sensibili sul flusso dell'applicazione.

Pensa a verbose come uno strumento da utilizzare quando non hai accesso al debugger.

Attenzione:

La traccia del tipo di avvertimento viene utilizzata quando succede qualcosa di sbagliato e importante, ma non è troppo cruciale per essere trattato come un errore. Ad esempio, una RAM bassa può emettere un avviso, ma non vi è alcun motivo per tracciare un errore, poiché l'applicazione può continuare, anche se sarà più lenta del solito.

Esempi:

Esempio 1: l'applicazione non è riuscita ad aprire il file che l'utente ha richiesto di aprire. Il file esiste e non è in uso, le autorizzazioni sono impostate correttamente, ma qualcosa blocca l'apertura di un file. In questo caso, traccerai un errore , poiché l'applicazione non può gestire questo caso e continua a funzionare come previsto dall'utente (cioè leggi effettivamente il file).
Esempio 2: dopo aver esaminato l'errore nel primo esempio, si scopre che l'errore è causato dal fatto che il percorso del file è più lungo di 259 caratteri. Quindi ti rifatti il tuo codice per prendere PathTooLongException . Quando, la volta successiva, l'utente tenta di aprire lo stesso file, la nuova versione dell'applicazione mostra un messaggio che spiega che il file è troppo lungo e deve essere spostato in un'altra cartella per abbreviare il percorso completo per poter aprire questo file in questa applicazione. Traccia anche un messaggio .
Esempio 3: la tua applicazione impiega venti secondi ad aprire e analizzare un piccolo file mentre la maggior parte dei file impiega da dieci a cento millisecondi per essere aperta e analizzata. Traccia un avviso con informazioni pertinenti: il tipo di disco in cui si trova effettivamente il file, il file system, la dimensione del file, il tempo esatto trascorso, l'ora in cui il computer era acceso, ecc. l'utente si lamenta che ci vogliono venti secondi per aprire il file, si prende la traccia per scoprire cosa succede. Ad esempio, si scopre che ci vuole così tanto tempo per caricare i file da una condivisione di rete quando il computer è appena partito. Spiega all'utente che il ritardo è dovuto alla rete e non è correlato alla tua applicazione.
Esempio 4: il file aperto viene visualizzato in modo errato. Abiliti la traccia verbose in cui effettivamente vedi come i dati vengono caricati dal file e poi analizzati, passo dopo passo.

score 5 · Answer 2

 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics è grande perché puoi configurare dove devono andare le informazioni di trace dove (file, eventlog, database, ....)

Sfortunatamente, se vuoi usare System.Diagnostics devi sapere in anticipo ( in fase di progettazione ), che i trace-stream dovrebbero essere possibili da seguire. (Nell'articolo di esempio questi sono Transfer, Resume, Suspend, ...). Questi possono essere configurati come Disabili, Debuglevel o Errorlevel.

Preferisco avere un sistema di registrazione in cui posso decidere in fase di esecuzione su classlevel / namespacelevel , come dovrebbe essere dettagliata la registrazione. Ad esempio, tutti i Debug e precedenti da MyNamespace.Business.* ma non MyNamespace.Business.Calculations .

Se si utilizza log4net (o Common.logging) ogni classe ottiene il proprio logger in modo da poter decidere facilmente quali classi vengono registrate a quale livello.

Poiché le operazioni del database si trovano in una classe separata, non c'è più bisogno di una regola distinta

Trace an "Information" event when inserting an item into the database.

Preferisco invece avere queste linee guida:

Tracelevel dovrebbe mostrare il flusso di lavoro di base
Debuglevel dovrebbe mostrare i dati dettagliati e l'elaborazione all'interno del flusso di lavoro, comprese le decisioni nel flusso di programmi con motivi (Creazione di un nuovo elemento perché l'elemento non esisteva nel DB)
Infolevel per l'avvio / arresto dei servizi e una voce per ogni flusso di lavoro / GUI azione avviata

score 2 · Answer 3

Puoi provare il framework Story , ha un approccio univoco alla registrazione poiché "fa" scrivere tutti i log ( e aggiungere altre informazioni pertinenti) nel contesto, quindi quando hai bisogno di leggerlo più tardi ottieni tutto ciò di cui hai bisogno.

Aggiungerà automaticamente i concetti "start" e "stop" come inizio e fine di una storia.

E con un sistema basato su regole puoi controllare cosa fare con ogni storia (contesto) in base alle informazioni che ha, ad esempio stampare tutte le storie che hanno un errore o provenire dall'utente "admin".

Ulteriori informazioni su questo post del blog