If I'm already logging certain "events" via ILogger (_logger.LogInformation), are there any advantages to adding (or changing to) telemetryClient.TrackEvent?

CodePudding user response：

Normally the ILogger is used to log traces. When the logs from ILogger are also routed to Application Insights they appear as traces in the traces table. Traces have a severity level (Info, warning, critical etc.) like the Ilogger has (using LogInformation, LogWarning etc).

Events in application insights are different from traces. They do not have a severity level for instance. Events are generally used for more important user or application events where traces are uses to log application output for diagnostics.

The docs explain it as follows:

You can create event telemetry items (in Application Insights) to represent an event that occurred in your application. Typically it is a user interaction such as button click or order checkout. It can also be an application life cycle event like initialization or configuration update.

Semantically, events may or may not be correlated to requests. However, if used properly, event telemetry is more important than requests or traces. Events represent business telemetry and should be a subject to separate, less aggressive sampling.

Adding events is something we do regulary to log certain business events like OrderCompleted or UserAdded.

To address your comment

They go to different tables--traces vs. customEvents... But what advantage is there to TrackEvent("OrderCompleted") vs LogInformation("OrderCompleted")?

The traces table is also filled by the runtime logging if you are running a web app, function or whatever on Azure. So it is hard to distinguish regular traces from events when you query for events stored in the traces table.

Also, events do not have a severity attached, traces do. If someone raises the minimum loglevel to warning in order to reduce the log volume you could lose your the information about what event happened when.

Finally, by seperating them you can apply different sampling settings for traces vs events. For example, you might want to retain 100% of the events vs, say, 25% of your traces. This is also mentioned in the docs I referred to earlier in this post:

However, if used properly, event telemetry is more important than requests or traces. Events represent business telemetry and should be a subject to separate, less aggressive sampling.

Last but not least you could define seperate export settings for events vs traces.