Aspnetcore: EventSource? DiagnosticSource? Ambos?

@rynowak - temos alguma orientação sobre isso que possamos compartilhar?

Alguns pensamentos rápidos repeti muitas vezes internamente, mas não tenho certeza sobre externamente ...

EventSource

Suponha que qualquer uso de EventSource também implique o uso de um mecanismo de registro fora do processo, como LTTNG ou ETW. O EventSource é ótimo quando você deseja disparar alguns pontos de dados com informações de baixa fidelidade para serem examinados posteriormente e, mais provavelmente, compilados em algum tipo de estatística ou resumo. Digo baixa fidelidade porque o uso comum para EventSource é canalizar os eventos para um arquivo (ETW) e, em seguida, usá-los para fazer análises post mortem. Ferramentas que olham para dados de EventSource como PerfView têm conhecimento especial de alguns eventos (JIT, GC), mas para os eventos que você escreve, eles mostram uma visão genérica. Mostrar uma visão genérica ou resumos / tabelas de dados funciona porque todos são tipos simples. É claro que você pode criar ferramentas especializadas, mas o caso comum é usar algo como PerfView.

A próxima declaração vai parecer óbvia, mas espero que meu motivo para mencioná-la fique claro em um momento. Com o EventSource, a interpretação dos eventos que você dispara é determinada com antecedência. Todos os dados que você deseja registrar são especificados pelo autor do componente e têm um significado fixo, geralmente associado ao nome do evento. Com o EventSource, você costuma dizer coisas como "ler 4096 bytes de dados" ou "arquivo carregado em 5,6 ms". Essas pequenas declarações de fato podem ser compiladas em resumos como "150 ms gastos fazendo E / S de arquivo" ou aprofundadas especificamente se forem discrepantes.

DiagnosticSource

Suponha que qualquer uso de DiagnosticSource esteja sendo feito em processo por um 'plugin' ou outro sistema de registro que irá destilar seus dados em pepitas significativas. DiagnosticSource é excelente quando você deseja passar o contexto completo do estado do aplicativo para um ouvinte e esse ouvinte adicionará sua própria interpretação com base no acesso ao estado do aplicativo. DiagnosticSource também não tem formato de registro nativo e nenhum entendimento genérico de seus pontos de dados (já que eles geralmente não são tipos simples) - ele requer um sistema adicional para criar algo que os usuários desejam ver.

Os eventos DiagnosticSource tendem a ser mais robustos e dizer coisas como "Estou prestes a processar uma solicitação" ou "Detectei uma exceção lançada pelo middleware". Essas ainda são afirmações de fato, mas o escopo é muito maior. Uma vez que as ferramentas têm acesso a um contexto rico, elas são livres para capturar qualquer informação que seja significativa de acordo com o contexto. Em última análise, o conjunto de informações capturado por uma ferramenta como o Application Insights não é definido pela equipe ASP.NET. Fornecemos a eles todo o contexto que temos e eles capturam o que consideram importante.

Você também pode canalizar dados DiagnosticSource para EventSource por meio de uma ponte. Eu não fiz isso pessoalmente, mas parece que pretendo evitar dobrar a quantidade de código de diagnóstico necessário em alguns lugares. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 Eu não presumiria que você usaria DiagnosticSource em todos os mesmos lugares que você faria com EventSource. Não tenho certeza de como uma estratégia aproveitando isso funcionaria, eu não tentei.

Para nós, essa área mudou algumas vezes. Começamos aqui com uma parceria com a Glimpse, eventualmente chegamos a uma parceria com o Application Insights. Ao longo do caminho, algumas outras coisas foram construídas sobre a Fonte de Diagnóstico, mas não tenho certeza de qual é o status dessas outras ferramentas agora.

Nossos planos

Não posso falar sobre a estratégia maior em torno de EventSource ou DiagnosticSource - mas posso responder como penso sobre eles e como a maioria da equipe vê nossa abordagem. Não criamos DiagnosticSource como substitutos para EventSource. Em minha opinião, atende a um consumidor e a um conjunto de cenários diferentes.

Adicionamos eventos de origem de diagnóstico onde achamos que agregarão muito valor. Alguns deles vão muito longe porque são como extensibilidade para outra pessoa construir diagnósticos. Eu arriscaria que a hospedagem tem talvez 3-5 pontos de origem de diagnóstico e o MVC tem mais perto de 10. Não tenho certeza se há algum lugar que estamos rastreando no momento adicionando mais. Se alguém tiver uma necessidade genuína, nós consideraremos.

Estamos fazendo uma construção da fonte do evento. Isso é algo com o qual nossos engenheiros de suporte de campo estão familiarizados e geralmente é uma parte importante da análise de desempenho para as equipes da Microsoft. Ainda estamos tentando resolver o vazio deixado pela ausência de contadores de desempenho. A equipe .NET está trabalhando para tornar os EventCounters (criados com base no EventSource) como substitutos adequados. O principal motivo do atraso na equipe ASP.NET em investir mais em EventSource é que por um tempo não estava claro qual seria a estratégia para não Windows. Queríamos evitar a construção de outra coisa adicional no futuro, se EventSource não ia seja para plataformas * nix. Isso foi esclarecido.

Há um bom documento aqui: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener com alguns pensamentos de algumas pessoas que são mais responsável pela estratégia nesta área.

Para você

Bem, parece que você pode fazer os dois ou qualquer um. Não estou muito familiarizado com o que você está trabalhando, portanto, o que se segue são alguns conselhos gerais.

Primeiro, pense em quem é o seu consumidor. Isso é para você? (perf) Isso é para desenvolvedores de aplicativos? (depuração e solução de problemas) É para autores de ferramentas? As ferramentas estão sendo executadas post-mortem ou dentro do aplicativo?

Em segundo lugar, pense em quantos lugares você planeja instrumentar e que tipo de dados você acha que são significativos. Como os consumidores entenderão e interpretarão esses dados? Os pontos de dados individuais são significativos ou os dados devem ser agregados?

Nós fechamos periodicamente os problemas de 'discussão' que não foram atualizados por um longo período de tempo.

Pedimos desculpas se isso causar algum inconveniente. Pedimos que se você ainda estiver encontrando um problema, registre um novo problema com informações atualizadas e nós investigaremos.