Aspnetcore: EventSource? DiagnosticSource? Оба?

@rynowak - у нас есть рекомендации по этому

Несколько быстрых мыслей, которые я повторял много раз внутренне, но не уверен насчет внешнего ...

EventSource

Предположим, что любое использование EventSource также подразумевает использование механизма ведения журнала вне процесса, такого как LTTNG или ETW. EventSource отлично подходит, когда вы хотите сжечь некоторые точки данных с информацией низкой точности, чтобы просмотреть ее позже и, скорее всего, скомпилировать в какую-то статистику или сводку. Я говорю о низкой точности, потому что обычно EventSource используется для передачи событий в файл (ETW), а затем их использования для посмертного анализа. Инструменты, которые просматривают данные из EventSource, такие как PerfView, обладают специальными знаниями о некоторых событиях (JIT, GC), но для событий, которые вы пишете, они показывают общее представление. Отображение общего вида или сводок / таблиц данных работает, потому что это все простые типы. Вы, конечно, можете создавать специализированные инструменты, но обычно используется что-то вроде PerfView.

Следующее утверждение покажется очевидным, но я надеюсь, что причина его упоминания станет ясна через мгновение. С помощью EventSource интерпретация запускаемых вами событий определяется заранее. Все данные, которые вы хотите записать, указываются автором компонента и имеют фиксированное значение, обычно связанное с именем события. С помощью EventSource вы часто говорите что-то вроде «прочтите 4096 байт данных» или «загруженный файл за 5,6 мс». Эти небольшие констатации фактов можно скомпилировать в резюме, например «150 мс, потраченных на ввод-вывод файлов», или детально проанализировать, если они являются отклонениями.

DiagnosticSource

Предположим, что любое использование DiagnosticSource выполняется в процессе «плагином» или другой системой регистрации, которая собирается преобразовать ваши данные в значимые самородки. DiagnosticSource отлично подходит, когда вы хотите передать полный контекст состояния приложения слушателю, и этот слушатель собирается добавить свою собственную интерпретацию на основе доступа к состоянию приложения. DiagnosticSource также не имеет собственного формата ведения журнала и общего понимания его точек данных (поскольку они обычно не являются простыми типами) - ему требуется дополнительная система для создания того, что пользователи хотят видеть.

События DiagnosticSource имеют тенденцию быть более короткими и сообщать такие вещи, как «Я собираюсь обработать запрос» или «Я поймал исключение, созданное промежуточным программным обеспечением». Это все еще констатация фактов, но масштабы намного шире. Поскольку инструменты имеют доступ к богатому контексту, они могут собирать любую информацию, имеющую значение в соответствии с контекстом. В конечном итоге набор информации, собираемой таким инструментом, как Application Insights, не определяется командой ASP.NET. Мы предоставляем им весь имеющийся у нас контекст, и они фиксируют то, что они считают важным.

Вы также можете передать данные DiagnosticSource в EventSource через мост. Я лично этого не делал, но, похоже, намеревался избежать удвоения количества диагностического кода, необходимого в некоторых местах. https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22 Я бы не предполагал, что вы будете использовать DiagnosticSource во всех в тех же местах, что и EventSource. Я не уверен, как будет работать стратегия, использующая это, я не пробовал.

Для нас эта сфера несколько раз менялась. Мы начали здесь, сотрудничая с Glimpse, в конечном итоге мы стали сотрудничать с Application Insights. Попутно на основе диагностического источника было создано несколько других вещей, но я не уверен, в каком состоянии сейчас находятся эти другие инструменты.

Наши планы

Я не могу говорить о более широкой стратегии, связанной с EventSource или DiagnosticSource, но могу ответить, что я думаю о них и как большая часть команды относится к нашему подходу. Мы не создавали DiagnosticSource вместо EventSource. На мой взгляд, он обслуживает другого потребителя и набор сценариев.

Мы добавляем события источника диагностики там, где, по нашему мнению, это принесет большую пользу. Некоторые из них проходят действительно долгий путь, потому что они подобны расширяемости для кого-то еще при построении диагностики. Рискну предположить, что хостинг имеет 3-5 диагностических точек источника, а MVC ближе к 10. Я не уверен, есть ли какие-то места, которые мы сейчас отслеживаем, добавляя больше. Если у кого-то есть настоящая потребность, мы рассмотрим это.

Мы создаем источник событий. Это то, с чем знакомы наши инженеры службы поддержки на местах, и, как правило, это важная часть анализа производительности для команд в Microsoft. Мы все еще пытаемся решить проблему, образовавшуюся из-за отсутствия счетчиков производительности. Команда .NET работает над созданием EventCounters (построенного на основе EventSource) в качестве подходящей замены. Основная причина задержки в том, что команда ASP.NET вкладывает больше средств в EventSource, заключается в том, что какое-то время не было ясно, какой будет стратегия для сторонних разработчиков. Мы хотели , чтобы избежать создания еще одного дополнительной вещи в будущем , если EventSource не будет это для * NIX платформ. Это прояснилось.

Здесь есть хороший документ: https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/DiagnosticSourceUsersGuide.md#instrumenting -with-diagnosticsourcediagnosticlistener с некоторыми мыслями некоторых людей, которые более несут ответственность за стратегию в этой области.

Для тебя

Что ж, похоже, вы можете сделать и то, и другое. Я не очень хорошо знаком с тем, над чем вы работаете, поэтому ниже приводится несколько общих советов.

Во-первых, подумайте, кто ваш потребитель. Это тебе? (perf) Это для разработчиков приложений? (отладка и устранение неполадок) Это для авторов инструментов? Инструменты работают посмертно или внутри приложения?

Во-вторых, подумайте, сколько мест вы планируете использовать и какие данные вы считаете значимыми. Как потребители поймут и интерпретируют эти данные? Являются ли отдельные точки данных значимыми или данные следует агрегировать?

Мы периодически закрываем «дискуссионные» вопросы, которые не обновлялись долгое время.

Приносим извинения за неудобства. Мы просим вас, если вы по-прежнему сталкиваетесь с проблемой, регистрируйте новую проблему с обновленной информацией, и мы рассмотрим ее.