rastreo de ASP.NET y System.Diagnostics: ¿me he perdido algo o es una mala idea?

Question

Por varias razones comunes, quería utilizar el rastreo para mi aplicación ASP.NET. Especialmente desde que descubrí la posibilidad de usar la herramienta Service Trace Viewer que le permite examinar sus rastros de una manera poderosa.

Como nunca antes había usado esta traza, comencé a estudiarla. Después de un tiempo de Google, SO y MSDN finalmente tengo una buena idea de cómo funcionan las cosas. Pero también encontré una cosa muy distrubing.

Al usar trazas en aplicaciones ASP.NET, tiene mucho sentido agrupar los mensajes de seguimiento mediante solicitudes web. Especialmente porque una de las razones por las que quiero usarlo es para estudiar problemas de rendimiento. La herramienta mencionada anteriormente también es compatible con el uso de etiquetas <Corrleation> en los archivos XML generados. Que a su vez provienen de System.Diagnostics.Trace.CorrelationManager. También permite otras características agradables como el inicio/la detención de la actividad, que proporciona una agrupación aún mejor de mensajes de seguimiento. Genial, ¿verdad?

Yo también lo pensé, hasta que comencé a inspeccionar dónde vivía realmente el CorrelationManager. Después de todo, era una propiedad estática. Después de jugar con Reflector descubrí algo horrible: ¡está almacenado en CallContext! ¿Cuál es el tipo de cosa we shouldn't be using in ASP.NET, derecho?

Entonces ... ¿me falta algo aquí? ¿El rastreo es realmente defectuoso en ASP.NET?

Agregado: Emm, estoy a punto de volver a escribir esto yo mismo. Todavía quiero usar la herramienta clara para explorar los rastros. ¿Alguna razón por la que no debería hacer esto? Quizás hay algo mejor todavía? Sería realmente bueno si recibiera algunas respuestas pronto. :)

Agregado 2: Un colega mío confirmó que esto no es solo un problema teórico. Él ha observado esto en el sistema en el que está trabajando. Entonces está arreglado. Voy a construir un nuevo sistema pequeño que haga las cosas como yo quiero. :)

Agregado 3: Guau, genial ... los chicos de Microsoft no pudieron encontrar nada malo con el uso del Administrador de correlación en ASP.NET. Entonces aparentemente no estamos obteniendo una solución para este error después de todo ...

Answer 1

Bien, así que así es como terminó.

Mi colega llamó a Microsoft y les comunicó este error. Ser socios certificados significa que tenemos acceso a una cola de fijación más prioritaria o algo así ... no sé esas cosas. De todos modos, están trabajando en eso. Con suerte, veremos un parche pronto. :)

Mientras tanto, he creado mi propia pequeña clase de rastreo. No es compatible con todos los detalles que el marco de seguimiento predeterminado hace, pero es justo lo que necesito. :) Más específicamente:

• Se escribe en el mismo formato XML como predeterminado XmlWriterTraceListener para que pueda utilizar la herramienta para analizar los registros.
• Tiene una rotación incorporada de registro, algo que mi colega tuvo que hacer él mismo encima de XmlWriterTraceListener.
• El registro real se difiere a otro hilo para que el rendimiento se pueda medir con mayor precisión.
• Las correlaciones ahora se almacenan en HttpContext.Items, por lo que las peculiaridades de enhebrado de ASP.NET no lo afectan.

Final feliz, espero. :)

Answer 2

Usted hace una pregunta muy interesante. Después de mirar Reflector, también veo que CorrelationManager está usando CallContext para almacenar la identificación de la actividad. No he trabajado demasiado con el seguimiento, así que no puedo hablar en nombre de qué tipo de actividades rastrea, pero si realiza un seguimiento de una sola actividad a lo largo de todo el ciclo de vida de una solicitud de página, según el artículo al que se hace referencia anteriormente, hay es una posibilidad de que la identificación de la actividad podría desasociarse con la actividad real. Esta actividad parece morir a la mitad.

HttpContext sería ideal para rastrear una solicitud de página completa de principio a fin, ya que se transferirá incluso si la ejecución cambia a un hilo diferente. Sin embargo, el HttpContext no se transferirá a sus objetos comerciales, donde lo haría el CallContext. En una nota lateral, vi que CallContext también se puede transferir cuando se usa la comunicación remota entre las aplicaciones del cliente y del servidor, lo cual es bastante ingenioso, pero en el caso del seguimiento del sitio web, esto no sería realmente útil.

Si aún no lo ha hecho, consulte this guy's site. El problema descrito en este artículo no es específicamente el mismo que mencionó Cup(Of T) article, pero sigue siendo bastante interesante. También proporciona varios enlaces muy informativos en la página que describen los componentes del CorrelateionManager.

Desafortunadamente, realmente no tengo una respuesta a su pregunta, pero definitivamente encuentro el tema interesante y lo seguiré buscando. Por lo tanto, actualice esta publicación a medida que aprende más. Tengo curiosidad por ver lo que tú u otros (con suerte, alguien por ahí puede arrojar algo de luz sobre el tema) encontrar al buscar en esto.

De todos modos, buena suerte. Hablaré con algunos de mis colegas sobre mi trabajo al respecto y publicaré más adelante si encuentro algo.

Chris