Aspnetcore: EventSource? DiagnosticSource? ¿Ambas cosas?

@rynowak : ¿tenemos alguna orientación sobre esto que podamos compartir?

Algunos pensamientos rápidos que he repetido muchas veces internamente, pero no estoy seguro de los externos ...

EventSource

Suponga que cualquier uso de EventSource también implica el uso de un mecanismo de registro fuera de proceso como LTTNG o ETW. EventSource es excelente cuando desea activar algunos puntos de datos con información de baja fidelidad para verlos más tarde y, más probablemente, compilarlos en algún tipo de estadísticas o resumen. Digo baja fidelidad porque el uso común de EventSource es canalizar los eventos a un archivo (ETW) y luego usarlos para hacer análisis post mortem. Las herramientas que miran datos de EventSource como PerfView tienen un conocimiento especial de algunos eventos (JIT, GC) pero para los eventos que escribe, muestran una vista genérica. Mostrar una vista genérica o resúmenes / tablas de datos funciona porque todos son tipos simples. Por supuesto, puede crear herramientas especializadas, pero el caso común es usar algo como PerfView.

La siguiente declaración parecerá obvia, pero espero que mi razón para mencionarla se aclare en un momento. Con EventSource, la interpretación de los eventos que dispara se determina de antemano. Todos los datos que desea registrar están especificados por el autor del componente y tienen un significado fijo, generalmente asociado con el nombre del evento. Con EventSource, a menudo dice cosas como "leer 4096 bytes de datos" o "archivo cargado en 5,6 ms". Estas pequeñas declaraciones de hechos pueden compilarse en resúmenes como "150 ms dedicados a la E / S de archivos" o profundizarse específicamente si son valores atípicos.

DiagnosticSource

Suponga que cualquier uso de DiagnosticSource se realiza en proceso mediante un 'complemento' u otro sistema de registro que destilará sus datos en pepitas significativas. DiagnosticSource es excelente cuando desea pasar el contexto completo del estado de la aplicación a un oyente y ese oyente agregará su propia interpretación basada en el acceso al estado de la aplicación. DiagnosticSource tampoco tiene un formato de registro nativo ni una comprensión genérica de sus puntos de datos (ya que no suelen ser tipos simples); requiere un sistema adicional para crear algo que los usuarios quieran ver.

Los eventos de DiagnosticSource tienden a ser más voluminosos y dicen cosas como "Estoy a punto de procesar una solicitud" o "Detecté una excepción lanzada por el middleware". Estas siguen siendo declaraciones de hechos, pero el alcance es mucho mayor. Dado que las herramientas tienen acceso a un contexto rico, son libres de capturar cualquier información que sea significativa según el contexto. En última instancia, el equipo de ASP.NET no define el conjunto de información que captura una herramienta como Application Insights. Les proporcionamos todo el contexto que tenemos y capturan lo que creen que es importante.

También puede canalizar datos de DiagnosticSource a EventSource a través de un puente. No he hecho esto personalmente, pero parece que tengo la intención de evitar duplicar la cantidad de código de diagnóstico necesario en algunos lugares. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 No asumiría que usaría DiagnosticSource en todos los mismos lugares que lo haría EventSource. No estoy seguro de cómo se desarrollaría una estrategia que aproveche esto, no lo he probado.

Para nosotros, esta área ha cambiado varias veces. Comenzamos aquí asociándonos con Glimpse, finalmente llegamos a asociarnos con Application Insights. A lo largo del camino, se han construido algunas otras cosas sobre la fuente de diagnóstico, pero no estoy seguro de cuál es el estado de esas otras herramientas en este momento.

Nuestros planes

No puedo hablar de la estrategia más amplia en torno a EventSource o DiagnosticSource, pero puedo responder cómo los veo y cómo la mayoría del equipo ve nuestro enfoque. No creamos DiagnosticSource como reemplazo de EventSource. En mi opinión, sirve a un consumidor y un conjunto de escenarios diferentes.

Agregamos eventos de fuente de diagnóstico donde creemos que agregarán mucho valor. Algunos de estos recorren un largo camino porque son como extensibilidad para que otra persona construya diagnósticos. Me atrevería a aventurar que el alojamiento tiene quizás 3-5 puntos de origen de diagnóstico y MVC tiene más de 10. No estoy seguro de si hay lugares en los que estamos rastreando y agregando más. Si alguien tiene una necesidad genuina, lo consideraríamos.

Estamos creando una fuente de eventos. Esto es algo con lo que nuestros ingenieros de soporte de campo están familiarizados y, en general, es una parte importante del análisis de rendimiento para los equipos de Microsoft. Seguimos intentando solucionar el vacío dejado por la ausencia de contadores de rendimiento. El equipo de .NET está trabajando para hacer EventCounters (construido sobre EventSource) como reemplazos adecuados. La razón principal de un retraso en el equipo de ASP.NET que invirtió más en EventSource es que durante un tiempo no estaba claro cuál sería la estrategia para las que no eran de Windows. Queríamos evitar la construcción de otra cosa adicional en el futuro si EventSource no iba a ser para plataformas * nix. Eso ha sido aclarado.

Hay un buen documento aquí: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener con algunas ideas de algunas personas que son más responsable de la estrategia en esta área.

Para ti

Bueno, parece que puedes hacer ambas cosas o ambas cosas. No estoy muy familiarizado con lo que está trabajando, así que lo que sigue es un consejo general.

Primero, piense en quién es su consumidor. ¿Esto es para ti? (perf) ¿Esto es para desarrolladores de aplicaciones? (depuración y resolución de problemas) ¿Es esto para los autores de herramientas? ¿Las herramientas se ejecutan post mortem o dentro de la aplicación?

En segundo lugar, piense en cuántos lugares planea instrumentar y qué tipo de datos cree que son significativos. ¿Cómo comprenderán e interpretarán los consumidores estos datos? ¿Son los puntos de datos individuales significativos o deberían agregarse los datos?

Periódicamente cerramos temas de 'discusión' que no se han actualizado en un largo período de tiempo.

Pedimos disculpas si esto le causa algún inconveniente. Le pedimos que si todavía tiene un problema, registre un nuevo problema con información actualizada e investigaremos.