В чем разница между ApplicationInsights TrackEvent и ILogger LogInformation

Обычно ILogger используется для регистрации трассировки. Когда журналы из ILogger также направляются в Application Insights, они отображаются как трассировки в таблице traces. Трассировки имеют уровень серьезности (информация, предупреждение, критический и т. д.), как и у Ilogger (с использованием LogInformation, LogWarning и т. д.).

События в Application Insights отличаются от трассировок. Например, у них нет уровня серьезности. События обычно используются для более важных событий пользователя или приложения, а трассировки используются для регистрации выходных данных приложения для диагностики.

Документы объясняют это следующим образом:

Вы можете создавать элементы телеметрии событий (в Application Insights), чтобы представить событие, произошедшее в вашем приложении. Обычно это взаимодействие с пользователем, например нажатие кнопки или оформление заказа. Это также может быть событие жизненного цикла приложения, такое как инициализация или обновление конфигурации.

Семантически события могут быть связаны с запросами, а могут и не быть. Однако при правильном использовании телеметрия событий важнее, чем запросы или трассировки. События представляют собой бизнес-телеметрию и должны подвергаться отдельной, менее агрессивной выборке.

Добавление событий — это то, что мы делаем регулярно, чтобы регистрировать определенные бизнес-события, такие как OrderCompleted или UserAdded.

Чтобы ответить на ваш комментарий

Они идут к разным таблицам — трассировкам и пользовательским событиям... Но в чем преимущество TrackEvent("OrderCompleted") по сравнению с LogInformation("OrderCompleted")?

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

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

Наконец, разделив их, вы можете применять разные настройки выборки для трассировок и событий. Например, вы можете захотеть сохранить 100 % событий вместо, скажем, 25 % трассировок. Это также упоминается в документах, на которые я ссылался ранее в этом посте:

Однако при правильном использовании телеметрия событий важнее, чем запросы или трассировки. События представляют собой бизнес-телеметрию и должны подвергаться отдельной, менее агрессивной выборке.

И последнее, но не менее важное: вы можете определить отдельные настройки экспорта для событий и трассировок.