Aggiornamento: per le estensioni di System.Diagnostics, fornendo alcuni dei listener mancanti che potresti desiderare, vedi Essential.Diagnostics su CodePlex ( http://essentialdiagnostics.codeplex.com/ )
Frameworks
D: Quali framework utilizzi?
A: System.Diagnostics.TraceSource, integrato in .NET 2.0.
Fornisce funzionalità di registrazione potenti, flessibili e ad alte prestazioni per le applicazioni, tuttavia molti sviluppatori non sono a conoscenza delle sue capacità e non le sfruttano appieno.
Ci sono alcune aree in cui è utile funzionalità aggiuntiva, o talvolta esiste la funzionalità ma non è ben documentata, tuttavia ciò non significa che l'intero framework di registrazione (progettato per essere estensibile) debba essere gettato via e sostituito completamente come alcune alternative popolari (NLog, log4net, Common.Logging e persino EntLib Logging).
Invece di cambiare il modo in cui aggiungi le istruzioni di registrazione alla tua applicazione e reinventando la ruota, hai appena esteso il framework System.Diagnostics nei pochi punti in cui ne hai bisogno.
Mi sembra che gli altri framework, anche EntLib, soffrano semplicemente della sindrome di Non inventato qui, e penso che abbiano perso tempo a reinventare le basi che funzionano già perfettamente in System.Diagnostics (come il modo in cui scrivi le dichiarazioni del registro), piuttosto che colmare le poche lacune esistenti. In breve, non usarli - non sono necessari.
Funzionalità che potresti non conoscere:
- L'uso dei sovraccarichi di TraceEvent che accettano una stringa di formato e args può aiutare le prestazioni poiché i parametri vengono mantenuti come riferimenti separati fino a quando Filter.ShouldTrace () non è riuscito. Ciò significa che nessuna chiamata costosa a ToString () sui valori dei parametri fino a quando il sistema non avrà confermato che il messaggio verrà effettivamente registrato.
- Trace.CorrelationManager consente di correlare le istruzioni di registro relative alla stessa operazione logica (vedere di seguito).
- VisualBasic.Logging.FileLogTraceListener è utile per scrivere su file di registro e supporta la rotazione dei file. Sebbene nello spazio dei nomi di VisualBasic, può essere facilmente utilizzato in un progetto C # (o altro linguaggio) semplicemente includendo la DLL.
- Quando si utilizza EventLogTraceListener se si chiama TraceEvent con più argomenti e con una stringa di formato vuota o nulla, gli arg vengono passati direttamente a EventLog.WriteEntry () se si utilizzano risorse di messaggi localizzate.
- Lo strumento Service Trace Viewer (da WCF) è utile per visualizzare grafici di file di registro correlati alle attività (anche se non si utilizza WCF). Questo può davvero aiutare a eseguire il debug di problemi complessi in cui sono coinvolti più thread / attività.
- Evita le spese generali cancellando tutti i listener (o rimuovendo Predefinito); altrimenti Default passerà tutto al sistema di traccia (e incorrerà in tutte quelle spese generali di ToString ()).
Aree che potresti voler estendere (se necessario):
- Listener di tracce del database
- Listener di tracce console colorato
- Listener di tracce MSMQ / Email / WMI (se necessario)
- Implementare un FileSystemWatcher per chiamare Trace.Refresh per modifiche dinamiche alla configurazione
Altre raccomandazioni:
Usa gli ID di eventi strutturati e mantieni un elenco di riferimenti (ad es. Documentali in un enum).
Avere ID evento univoci per ogni (significativo) evento nel tuo sistema è molto utile per correlare e trovare problemi specifici. È facile risalire al codice specifico che registra / utilizza gli ID evento e può semplificare fornire indicazioni per errori comuni, ad esempio errore 5178 significa che la stringa di connessione al database è errata, ecc.
Gli ID evento dovrebbero seguire una sorta di struttura (simile alla Teoria dei codici di risposta utilizzati in e-mail e HTTP), che consente di trattarli per categoria senza conoscere codici specifici.
ad es. la prima cifra può indicare in dettaglio la classe generale: 1xxx può essere utilizzato per le operazioni di "Avvio", 2xxx per il comportamento normale, 3xxx per il tracciamento delle attività, 4xxx per gli avvisi, 5xxx per gli errori, 8xxx per le operazioni di "Stop", 9xxx per errori irreversibili, eccetera.
La seconda cifra può specificare l'area, ad es. 21xx per le informazioni sul database (41xx per gli avvisi del database, 51xx per gli errori del database), 22xx per la modalità di calcolo (42xx per gli avvisi di calcolo, ecc.), 23xx per un altro modulo, ecc.
Gli ID evento strutturati e assegnati ti consentono anche di utilizzarli nei filtri.
D: Se si utilizza la traccia, si utilizza Trace.Correlation.StartLogicalOperation?
A: Trace.CorrelationManager è molto utile per correlare le istruzioni di registro in qualsiasi tipo di ambiente multi-thread (che è praticamente qualcosa al giorno d'oggi).
È necessario almeno impostare ActivityId una volta per ogni operazione logica per correlare.
Start / Stop e LogicalOperationStack possono quindi essere utilizzati per un semplice contesto basato su stack. Per contesti più complessi (ad es. Operazioni asincrone), l'utilizzo di TraceTransfer nel nuovo ActivityId (prima di modificarlo), consente la correlazione.
Lo strumento Service Trace Viewer può essere utile per visualizzare i grafici delle attività (anche se non si utilizza WCF).
D: Scrivi questo codice manualmente o usi qualche forma di programmazione orientata all'aspetto per farlo? Vuoi condividere uno snippet di codice?
A: Potresti voler creare una classe di ambito, ad esempio LogicalOperationScope, che (a) imposta il contesto quando viene creato e (b) reimposta il contesto quando viene eliminato.
Ciò consente di scrivere codice come il seguente per concludere automaticamente le operazioni:
using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
{
// .. do work here
}
Al momento della creazione, l'ambito potrebbe prima impostare ActivityId, se necessario, chiamare StartLogicalOperation e quindi registrare un messaggio TraceEventType.Start. Su Dispose potrebbe registrare un messaggio Stop, quindi chiamare StopLogicalOperation.
D: Fornite qualche forma di granularità rispetto alle fonti di traccia? Ad esempio, WPF TraceSources consente di configurarli a vari livelli.
A: Sì, più origini di traccia sono utili / importanti man mano che i sistemi diventano più grandi.
Mentre probabilmente si desidera registrare in modo coerente tutti i messaggi di avviso e sopra, o tutti i messaggi Informazioni e sopra, per qualsiasi sistema di dimensioni ragionevoli, il volume di Activity Tracing (Start, Stop, ecc.) E la registrazione dettagliata diventano semplicemente troppo.
Piuttosto che avere un solo interruttore per accenderlo o spegnerlo, è utile poter attivare queste informazioni per una sezione del sistema alla volta.
In questo modo, è possibile individuare problemi significativi dalla registrazione di solito (tutti gli avvisi, errori, ecc.), Quindi "ingrandire" le sezioni desiderate e impostarle su Traccia attività o anche su livelli di debug.
Il numero di origini di traccia necessarie dipende dall'applicazione, ad esempio è possibile che si desideri una fonte di traccia per assembly o per sezione principale dell'applicazione.
Se è necessario un controllo ancora più preciso, aggiungere singoli interruttori booleani per attivare / disattivare la traccia di volumi elevati specifici, ad esempio i dump di messaggi non elaborati. (O potrebbe essere utilizzata una sorgente di traccia separata, simile a WCF / WPF).
È inoltre possibile prendere in considerazione origini di traccia separate per la traccia attività e la registrazione generale (altro), poiché può rendere un po 'più semplice configurare i filtri esattamente come li si desidera.
Tieni presente che i messaggi possono comunque essere correlati tramite ActivityId anche se vengono utilizzate origini diverse, quindi utilizza tutti quelli di cui hai bisogno.
Gli ascoltatori
D: Quali output di log usi?
Ciò può dipendere dal tipo di applicazione che stai scrivendo e dalle cose che vengono registrate. Di solito cose diverse vanno in luoghi diversi (cioè uscite multiple).
In genere classifico le uscite in tre gruppi:
(1) Eventi - Registro eventi di Windows (e file di traccia)
ad esempio, se si scrive un server / servizio, la migliore procedura su Windows è utilizzare il registro eventi di Windows (non si dispone di un'interfaccia utente per la segnalazione).
In questo caso, tutti gli eventi di informazioni irreversibili, di errore, di avviso e (a livello di servizio) devono andare nel registro eventi di Windows. Il livello Informazioni dovrebbe essere riservato per questo tipo di eventi di alto livello, quelli che si desidera inserire nel registro eventi, ad esempio "Servizio avviato", "Servizio interrotto", "Connesso a Xyz" e forse anche "Pianificazione avviata" , "Utente connesso", ecc.
In alcuni casi è possibile che si desideri rendere la scrittura nel registro eventi parte integrante dell'applicazione e non tramite il sistema di traccia (ovvero scrivere direttamente le voci del Registro eventi). Ciò significa che non può essere accidentalmente disattivato. (Notare che si desidera anche annotare lo stesso evento nel sistema di traccia in modo da poter essere correlati).
Al contrario, un'applicazione GUI di Windows in genere li segnala all'utente (sebbene possano anche accedere al registro eventi di Windows).
Gli eventi possono anche avere contatori delle prestazioni correlati (ad es. Numero di errori / sec) e può essere importante coordinare qualsiasi scrittura diretta nel registro eventi, contatori delle prestazioni, scrittura nel sistema di tracciamento e segnalazione all'utente in modo che si verifichino lo stesso tempo.
cioè se un utente vede un messaggio di errore in un determinato momento, dovresti essere in grado di trovare lo stesso messaggio di errore nel registro eventi di Windows e quindi lo stesso evento con lo stesso timestamp nel registro di traccia (insieme ad altri dettagli di traccia).
(2) Attività: file di registro dell'applicazione o tabella del database (e file di traccia)
Questa è l'attività regolare svolta da un sistema, ad esempio la pubblicazione di una pagina Web, la negoziazione di una borsa, l'ordine preso, il calcolo eseguito, ecc.
L'attività di tracciamento (avvio, arresto, ecc.) È utile qui (alla granularità corretta).
Inoltre, è molto comune utilizzare un registro applicazione specifico (a volte chiamato registro di controllo). Di solito si tratta di una tabella di database o di un file di registro dell'applicazione e contiene dati strutturati (ovvero un insieme di campi).
Le cose possono essere un po 'sfocate qui a seconda dell'applicazione. Un buon esempio potrebbe essere un server Web che scrive ogni richiesta in un registro Web; esempi simili potrebbero essere un sistema di messaggistica o un sistema di calcolo in cui ogni operazione è registrata insieme a dettagli specifici dell'applicazione.
Un esempio non altrettanto positivo sono le negoziazioni di borsa o un sistema di ordini di vendita. In questi sistemi probabilmente stai già registrando l'attività in quanto hanno un valore commerciale importante, tuttavia il principio di correlarli ad altre azioni è ancora importante.
Oltre ai registri delle applicazioni personalizzati, le attività hanno spesso contatori delle prestazioni correlati, ad esempio il numero di transazioni al secondo.
In generale, è necessario coordinare la registrazione delle attività tra sistemi diversi, ovvero scrivere nel registro dell'applicazione contemporaneamente all'aumento del contatore delle prestazioni e al registro nel sistema di traccia. Se si eseguono tutti contemporaneamente (o immediatamente uno dopo l'altro nel codice), i problemi di debug sono più facili (che se si verificano tutti in momenti / posizioni diverse nel codice).
(3) Traccia di debug: file di testo o XML o database.
Si tratta di informazioni a livello dettagliato e inferiore (ad esempio switch booleani personalizzati per attivare / disattivare i dump di dati non elaborati). Ciò fornisce il coraggio o i dettagli di ciò che un sistema sta facendo a livello di attività secondaria.
Questo è il livello che vuoi essere in grado di attivare / disattivare per le singole sezioni della tua applicazione (da qui le molteplici fonti). Non vuoi che queste cose ingombrino il registro eventi di Windows. A volte viene utilizzato un database, ma è più probabile che stiano eseguendo il rollup dei file di registro che vengono eliminati dopo un determinato periodo di tempo.
Una grande differenza tra queste informazioni e un file di registro dell'applicazione è che non è strutturato. Mentre un registro applicazioni può contenere campi per A, Da, Importo, ecc., Le tracce di debug dettagliate possono essere qualunque cosa inserisca un programmatore, ad esempio "verifica valori X = {valore}, Y = falso" o commenti / marcatori casuali come " Fatto, riprovando ".
Una pratica importante consiste nell'assicurarsi che le cose inserite nei file di registro dell'applicazione o nel registro eventi di Windows vengano registrate nel sistema di traccia con gli stessi dettagli (ad es. Timestamp). Ciò consente di correlare i diversi registri durante le indagini.
Se si prevede di utilizzare un particolare visualizzatore di registri perché si dispone di una correlazione complessa, ad esempio il Service Trace Viewer, è necessario utilizzare un formato appropriato, ad es. XML. Altrimenti, un semplice file di testo di solito è abbastanza buono: ai livelli più bassi le informazioni sono in gran parte non strutturate, quindi potresti trovare dump di array, stack dump, ecc. A condizione che tu possa essere correlato a registri più strutturati a livelli più alti, le cose dovrebbero stare bene.
D: Se si utilizzano file, si utilizzano i log di scorrimento o solo un singolo file? Come si rendono disponibili i registri che le persone possono consumare?
A: Per i file, in genere si desidera eseguire il rolling dei file di registro da un punto di vista della gestibilità (con System.Diagnostics è sufficiente utilizzare VisualBasic.Logging.FileLogTraceListener).
La disponibilità dipende nuovamente dal sistema. Se stai parlando solo di file, allora per un server / servizio, è possibile accedere ai file in rotazione quando necessario. (Il registro eventi di Windows o i registri applicazioni di database avrebbero i propri meccanismi di accesso).
Se non si ha un facile accesso al file system, la traccia di debug su un database potrebbe essere più semplice. [ovvero implementare un database TraceListener].
Una soluzione interessante che ho visto per un'applicazione GUI di Windows era che registrava informazioni di traccia molto dettagliate su un "registratore di volo" mentre era in esecuzione e poi quando lo chiudevi se non aveva problemi, semplicemente cancellava il file.
Se, tuttavia, si è bloccato o si è verificato un problema, il file non è stato eliminato. O se rileva l'errore, o alla successiva esecuzione noterà il file e quindi può agire, ad esempio comprimerlo (ad esempio 7zip) e inviarlo via email o renderlo altrimenti disponibile.
Oggigiorno molti sistemi incorporano la segnalazione automatica di guasti a un server centrale (dopo aver verificato con gli utenti, ad esempio per motivi di privacy).
Sta guardando
D: Quali strumenti utilizzare per visualizzare i registri?
A: Se hai più registri per diversi motivi, utilizzerai più visualizzatori.
Notepad / vi / Notepad ++ o qualsiasi altro editor di testo è la base per i registri di testo normale.
Se hai operazioni complesse, ad esempio attività con trasferimenti, allora, ovviamente, utilizzeresti uno strumento specializzato come Service Trace Viewer. (Ma se non ne hai bisogno, un editor di testo è più facile).
Dato che in genere registro informazioni di alto livello nel registro eventi di Windows, allora fornisce un modo rapido per ottenere una panoramica, in modo strutturato (cercare le graziose icone di errore / avviso). Devi solo iniziare a cercare i file di testo se non ce n'è abbastanza nel registro, sebbene almeno il registro ti dia un punto di partenza. (A questo punto, assicurarsi che i log abbiano coordinato gli impegni diventa utile).
Generalmente il registro eventi di Windows rende disponibili questi eventi significativi anche a strumenti di monitoraggio come MOM o OpenView.
Altri --
Se si accede a un database, può essere facile filtrare e ordinare le informazioni (ad es. Ingrandire un particolare ID attività (con i file di testo è possibile utilizzare Grep / PowerShell o simile per filtrare il GUID particolare che si desidera)
MS Excel (o un altro programma per fogli di calcolo). Ciò può essere utile per analizzare informazioni strutturate o semi-strutturate se è possibile importarle con i delimitatori corretti in modo che valori diversi vadano in colonne diverse.
Quando eseguo un servizio in debug / test di solito lo ospito in un'applicazione console per semplicità trovo utile un logger di console colorato (ad esempio rosso per errori, giallo per avvisi, ecc.). È necessario implementare un listener di tracce personalizzato.
Si noti che il framework non include un logger di console colorato o un logger di database, quindi, al momento, è necessario scriverli se ne hanno bisogno (non è troppo difficile).
Mi dà davvero fastidio il fatto che diversi framework (log4net, EntLib, ecc.) Abbiano perso tempo a reinventare la ruota e reimplementare la registrazione di base, il filtro e la registrazione in file di testo, il registro eventi di Windows e i file XML, ognuno nel proprio modo diverso (le istruzioni di registro sono diverse in ciascuna); ognuno ha quindi implementato la propria versione di, ad esempio, un registratore di database, quando la maggior parte di quello esisteva già e tutto ciò che serviva era un paio di listener in più per System.Diagnostics. Parla di un grande spreco di sforzi duplicati.
D: Se stai creando una soluzione ASP.NET, usi anche ASP.NET Health Monitoring? Includete l'output di traccia negli eventi di monitoraggio dello stato? Che dire di Trace.axd?
Queste cose possono essere attivate / disattivate secondo necessità. Trovo Trace.axd abbastanza utile per il debug di come un server risponde a determinate cose, ma non è generalmente utile in un ambiente fortemente utilizzato o per la traccia a lungo termine.
D: E i contatori delle prestazioni personalizzati?
Per un'applicazione professionale, in particolare un server / servizio, mi aspetto di vederlo completamente strumentato con entrambi i contatori di Performance Monitor e la registrazione nel registro eventi di Windows. Questi sono gli strumenti standard di Windows e devono essere utilizzati.
È necessario assicurarsi di includere i programmi di installazione per i contatori delle prestazioni e i registri eventi utilizzati; questi dovrebbero essere creati al momento dell'installazione (durante l'installazione come amministratore). Quando l'applicazione è in esecuzione normalmente, non dovrebbe avere privilegi di amministrazione (e quindi non sarà in grado di creare registri mancanti).
Questa è una buona ragione per esercitarsi nello sviluppo come non amministratore (avere un account amministratore separato per quando è necessario installare servizi, ecc.). Se si scrive nel registro eventi, .NET creerà automaticamente un registro mancante la prima volta che si scrive su di esso; se si sviluppa come un non amministratore, lo si capisce presto ed si evita una brutta sorpresa quando un cliente installa il sistema e quindi non può utilizzarlo perché non è in esecuzione come amministratore.