2009-02-11 10 views
5

Per vari motivi comuni, volevo utilizzare la traccia per la mia applicazione ASP.NET. Soprattutto da quando ho scoperto la possibilità di utilizzare lo strumento Service Trace Viewer che ti consente di esaminare le tue tracce in modo potente.Tracciati ASP.NET e System.Diagnostics: mi è sfuggito qualcosa o è una cattiva idea?

Poiché non avevo mai usato questa traccia prima, ho iniziato a studiarlo. Dopo un po 'di tempo su Google, SO e MSDN ho finalmente una buona idea di come funzionano le cose. Ma ho anche trovato una cosa molto distruttiva.

Quando si utilizza la traccia nelle applicazioni ASP.NET, ha molto senso raggruppare i messaggi di traccia insieme con le richieste Web. Soprattutto perché uno dei motivi per cui voglio usarlo è studiare i problemi di performance. Lo strumento sopra menzionato supporta anche questo utilizzando i tag <Corrleation> nei file XML generati. Che a turno provengono da System.Diagnostics.Trace.CorrelationManager. Permette anche altre interessanti funzionalità come l'avvio/l'arresto delle attività, che fornisce un gruppo ancora migliore di messaggi di traccia. Fantastico, giusto?

Anche se così tanto, fino a quando ho iniziato a controllare dove viveva lo . Dopotutto, era una proprietà statica. Dopo aver giocato con Reflector ho scoperto qualcosa di orribile: è memorizzato in CallContext! Qual è il tipo di cosa we shouldn't be using in ASP.NET, giusto?

Quindi ... mi manca qualcosa qui? La traccia è davvero fondamentalmente difettosa in ASP.NET?

Aggiunto: Emm, sono quasi sul punto di riscrivere questa roba da solo. Voglio ancora usare lo strumento pulito per esplorare le tracce. Qualche ragione per cui non dovrei farlo? Forse c'è ancora qualcosa di meglio? Sarebbe davvero bello se ricevessi presto delle risposte. :)

Aggiunto 2: Un mio collega ha confermato che questo non è solo un problema teorico. Ha osservato questo nel sistema su cui sta lavorando. Quindi è sistemato. Costruirò un nuovo piccolo sistema che fa le cose proprio come voglio io. :)

Aggiunto 3: Wow, cool ... i ragazzi di Microsoft non hanno trovato nulla di sbagliato nell'usare Correlation Manager in ASP.NET. Quindi a quanto pare non abbiamo ancora una soluzione per questo errore ...

risposta

1

OK, ecco come è finita.

Il mio collega ha chiamato Microsoft e ha segnalato questo bug a loro. Essere partner certificati significa che abbiamo accesso ad alcune code di fixing più prioritarie o qualcosa del genere ... non conosciamo quella roba. Comunque, ci stanno lavorando. Speriamo di vedere presto una patch. :)

Nel frattempo ho creato la mia piccola classe di tracciamento. Non supporta tutti i campanelli e fischietti che fa il framework di traccia di default, ma è proprio quello di cui ho bisogno. :) Più precisamente:

  • Scrive nello stesso formato XML del valore predefinito XmlWriterTraceListener così posso utilizzare lo strumento per analizzare i registri.
  • Ha una rotazione del registro incorporata, qualcosa che il mio collega ha dovuto fare da solo sopra XmlWriterTraceListener.
  • La registrazione effettiva viene posticipata a un altro thread in modo che le prestazioni possano essere misurate in modo più accurato.
  • Le correlazioni sono ora memorizzate in HttpContext.Items pertanto le particolarità di threading ASP.NET non influiscono su di esso.

Felice fine, spero. :)

3

Hai sollevato una domanda molto interessante. Dopo aver consultato Reflector, vedo anche che CorrelationManager sta utilizzando CallContext per memorizzare l'ID dell'attività. Non ho lavorato molto sulla tracciatura, quindi non posso parlare a nome di quali tipi di attività tiene traccia, ma se traccia una singola attività lungo l'intero ciclo di vita di una richiesta di pagina, per l'articolo che hai fatto riferimento sopra, è una possibilità che l'ID attività possa essere dissociato con l'attività effettiva. Questa attività sembrerebbe morire a metà strada.

HttpContext sembra ideale per tenere traccia di un'intera richiesta di pagina dall'inizio alla fine, poiché verrà trasferita anche se l'esecuzione passa a un thread diverso. Tuttavia, HttpContext non verrà trasferito ai tuoi oggetti business, come avrebbe fatto CallContext. In una nota a margine, ho visto che CallContext può anche essere trasferito quando si utilizza la comunicazione remota tra applicazioni client e server che è piuttosto elegante, ma nel caso di tracciamento del sito Web, questo non sarebbe davvero così utile.

Se non l'hai già, controlla this guy's site. Il problema descritto in questo articolo non è specificamente lo stesso problema descritto in Cup(Of T) article, ma è comunque piuttosto interessante. Fornisce inoltre numerosi link molto istruttivi sulla pagina che descrivono i componenti di CorrelateionManager.

Sfortunatamente, non ho una risposta alla tua domanda, ma sicuramente trovo l'argomento interessante e continuerò a esaminarlo. Quindi, per favore aggiorna questo post mentre impari di più. Sono curioso di vedere cosa tu o altri (spero che qualcuno là fuori possa far luce sull'argomento) trovare mentre guardi questo.

Ad ogni modo, buona fortuna. Parlerò con alcuni dei peep al mio lavoro su questo e pubblicherò più tardi se trovo qualcosa.

Chris

+0

Bello. Non ho ancora trovato quell'articolo. In realtà, è praticamente impossibile per Google qualsiasi cosa sull'argomento. Strano che più persone non l'abbiano capito. –

+1

Il collegamento al "sito di questo ragazzo" è stato modificato: http://sticklebackplastic.com/post/2007/08/14/One-mighty-gotcha-for-SystemDiagnostic-activity-Ids.aspx –

+0

il collegamento è stato aggiornato, grazie Chris – regex

Problemi correlati