Linee guida per la registrazione (tracing) in un'applicazione Windows

Question

Come la vedo io ci sono due diversi tipi di registrazione:

• tronchi user-oriented, come quelle prodotte dal mio antivirus ("ha iniziato scan", "minacce trovato", etc.)
• tracce developer-focused, che può essere semplice come un log di eccezioni o dettagliato come un registro di ogni chiamata di metodo

attualmente sto progettando come incorporare il secondo tipo di registrazione nella nostra applicazione, in modo da poter ottenere un registro di ciò che è andato w rong quando un utente segnala un problema. Ho visto diverse discussioni su come dovrebbero essere verbose queste tracce e sui framework disponibili, ma qui sto cercando alcune linee guida più generali.

domande particolare ho includono:

• Dovremmo registrazione in un file, il registro eventi di Windows o da qualche altra parte? Per questi log focalizzati sullo sviluppatore che probabilmente non interessano all'utente, ritengo che un file sia il più appropriato. Ma in questo caso:
  
  
  • Dove dovrebbe essere il file trova?
  • Dovremmo implementare qualche forma di rotazione del registro per impedire che il file cresca troppo?
  • Come possiamo gestire più istanze dell'applicazione che accedono al log contemporaneamente?
    
    
• Qualora questo tracciato essere acceso per impostazione predefinita? Se lo è, sono un po 'preoccupato per le prestazioni; ma se non lo è, finiremo per rispondere ai problemi di molti utenti con "attivare la traccia e provare a riprodurre il problema"? Questo non sembra troppo utile.

Spero che tu possa aiutarmi con queste domande. Apprezzerei anche qualsiasi altro consiglio che hai su questo argomento.

Answer 1

è necessario utilizzare un quadro di registrazione stabilita per la piattaforma se è disponibile. Per log4j (java), log4net (.net) ecc. I framework più consolidati avranno modi per aumentare e diminuire la registrazione (e quindi influenzare le prestazioni) in modi molto precisi. Dovresti replicare tutto questo.

In caso contrario, il ETW (event tracing for windows) è un sistema di registrazione altamente performante integrato direttamente in Windows. E lo consiglierei in ogni caso in cui il framework di registrazione non fosse disponibile.

Oh, e non preoccuparti di prestazioni fino a quando il suo un problema (questo non vuol dire non pensare a questo proposito, solo che non micro ottimizzare fino a che necessario).

Answer 2

The Art of Logging ha alcune linee guida utili.

Per la registrazione, sto utilizzando Simple Logging Façade come un'astrazione per il framework di registrazione reale utilizzato.

Maggiori informazioni:

• An Introduction to SLF, the Simple Logging Façade
• SLF Hands-on Tutorial, Part 1

Answer 3

Ho trovato log4net molto efficace. Normalmente utilizzo sia un appender rolling file nel formato XML log4j che può essere letto e visualizzato in modo ordinato da Chainsaw e un altro appender che si collega direttamente alla console di debug.

Il livello di registrazione può essere facilmente impostato in un file XML. Per la distribuzione, accendo il livello di registrazione su Info o disattivo. In caso di problemi, è possibile tornare a eseguire il debug.

Trovo potente perché registra sia il filo e la funzione della voce di registro è stato chiamato da.

Answer 4

Sono d'accordo che il registro eventi di Windows è un luogo improprio per i log degli sviluppatori. Sebbene fungano da comoda posizione di registrazione, l'esportazione delle informazioni di registro è alquanto problematica e, in definitiva, ritengo che il registro degli eventi debba essere utilizzato solo per registrare le informazioni di interesse per l'amministratore di sistema.

Per quanto riguarda la posizione in cui questo file deve essere memorizzato, dovunque la posizione sia consapevole del fatto che Windows 7 e Vista si stanno orientando verso ulteriori utenti che isolano, il che significa che la scrittura nella cartella Programmi richiederà i privilegi amministrativi. Lavora con questo e non richiedere che l'applicazione venga eseguita come amministratore. Oltre a questo non ho raccomandazioni.

io non sono sicuro di che tipo di applicazione che si sta lavorando con, ma ho trovato che troppe informazioni di traccia a caso è inutile. Spenderei la maggior parte dei miei sforzi identificando ampie porzioni di codice che utilizzano solo un insieme molto limitato di informazioni. Se fatto correttamente, questo ti permetterà di riprodurre la maggior parte degli errori di runtime con una sola istruzione trace. Ciò renderebbe anche le dimensioni del log insignificanti.

A meno che più istanze dell'interfaccia dell'applicazione uno con l'altro, devono cercare i file di log separati. Non ci sarebbe alcun motivo per combinare le informazioni di registro di due processi completamente separati.

La traccia a tutti gli effetti dovrebbe essere disattivata per impostazione predefinita. Se un cliente segnala un errore che non è possibile riprodurre, è consigliabile consigliare di attivare le informazioni di tracciamento in modo da poter identificare ulteriormente il problema.

Answer 5

Si potrebbe voler utilizzare Enterprise LibraryLogging Application Block. Questo è un semplice logger configurabile con molte funzioni facili da usare. Di seguito entrambi i link sopra ti renderanno funzionale in poco tempo.

Answer 6

Suggerisco di utilizzare una libreria esistente come log4net o blocco applicazione di registrazione lib di Ent.

Personalmente il blocco dell'applicazione Logging era eccessivo e complicato per i miei scopi.

Eventuali eccezioni devono essere registrate per impostazione predefinita e si dovrebbe avere l'opzione di abilitare una modalità dettagliata di traccia/registrazione per gli strani problemi che non si riescono a raccogliere sufficienti informazioni con la registrazione di eccezioni standard.

Non si sa mai cosa succederà quando gli utenti utilizzano il codice. più informazioni devi trovare e risolvere i problemi, meglio è.