Custom Azure Application Insights Telemetry Metrics with .NET

By default, Azure Application Insights comes with necessary and important telemetry capabilities to monitor the basic functions of an application and collect telemetry.

In almost all cases, however, it is necessary or at least advisable that custom metrics are also collected and transmitted to Application Insights in order to understand and monitor the functionality of an application.

App Insights Custom Events

Custom metrics can be collected in Azure Application Insights via custom events. A custom event is an event that is triggered by an application and sent to Application Insights. A custom event can also contain additional data that can be used for analysis and visualization in Application Insights.

The SDK provides the following APIs:

• TrackEvent - Sends a custom event to Application Insights.
• TrackMetric - Sends a user-defined metric to Application Insights.
• TrackTrace - Sends a custom track to Application Insights.
• TrackException - Sends a custom exception to Application Insights.
• TrackRequest - Sends a custom request to Application Insights.
• TrackDependency - Sends a user-defined dependency to Application Insights.

The latter is the variant we are particularly interested in for our Custom Metrics request. This not only allows me to monitor how individual code blocks are executed, but also monitor the duration so that I can identify performance or runtime problems.

Custom Dependency

The Custom Dependency is a direct functionality of the Telemetry Client and can be easily used through Dependency Injection as soon as Application Insights has been registered accordingly.

 1public class MyClass
 2{
 3    private readonly TelemetryClient _telemetryClient;
 4
 5    public MyClass(TelemetryClient telemetryClient)
 6    {
 7        _telemetryClient = telemetryClient;
 8    }
 9
10    public async Task MyMethod()
11    {
12       string operationName = nameof(MyMethod);
13
14       IOperationHolder<DependencyTelemetry> aiOperation =
15          _telemetryClient.StartOperation<DependencyTelemetry>(operationName);
16
17       try
18       {
19            // await  ... my actual code
20
21            aiOperation.Telemetry.Success = true;
22       }
23       catch(Exception e)
24       {
25            aiOperation.Telemetry.Success = false;
26            _telemetryClient.TrackException(e);
27
28            throw;
29       }
30       finally
31       {
32            _telemetryClient.StopOperation(aiOperation);
33       }
34    }
35}

We therefore have an OperationHolder that contains the Telemetry information. This is started by StartOperation and ended by StopOperation. If our code is executed successfully, the client is informed that the operation was successful and the TrackException also transmits the exception to Application Insights in the event of an error.

In this example, tracking is directly part of the method, but depending on the architecture of the application, it should take place in a middleware or another central point of the application. If you use MediatR as an application engine, you can implement this using a Behavior.

Own Monitoring Implementation

To enable tracking in your own context, I have created this simplified implementation (optimized accordingly in my code, kept simple here):

 1public class DepenencyOperationMonitor
 2{
 3    private readonly TelemetryClient _telemetryClient;
 4
 5    public DepenencyOperationMonitor(TelemetryClient telemetryClient)
 6    {
 7        _telemetryClient = telemetryClient;
 8    }
 9
10    public async Task<T> ExecuteAsync<T>(Func<Task<T>> action, string operationName)
11    {
12        using  IOperationHolder<DependencyTelemetry> aiOperation =
13            _telemetryClient.StartOperation<DependencyTelemetry>(operationName);
14
15        try
16        {
17            T response = await action().ConfigureAwait(false);
18
19            // no exception = succeeded
20            aiOperation.Telemetry.Success = true;
21
22            return response;
23        }
24        catch (Exception e) 
25        {
26            aiOperation.Telemetry.Success = false;
27            _telemetryClient.TrackException(e);
28
29            throw;
30        }
31        finally
32        {
33            _telemetryClient.StopOperation(aiOperation);
34        }
35    }
36}

This OperationMonitor can now simply be registered as a singleton and injected into your own classes.

 1public class MyClass
 2{
 3    private readonly IDepenencyOperationMonitor _operationMonitor;
 4
 5    public MyClass(IDepenencyOperationMonitor operationMonitor)
 6    {
 7        _operationMonitor = operationMonitor;
 8    }
 9
10    public async Task<MyResult> MyMethod()
11    {
12        const string operationName = $"{nameof(MyClass)}.{nameof(MyMethod)}";
13
14        MyResult result = await _operationMonitor.ExecuteAsync(
15            async () =>
16            {
17              // await  ... my actual code
18
19                return myResult;
20            }, operationName).ConfigureAwait(false);
21
22        return result;
23    }

Dashboard View

After the data has been sent to Application Insights, it can be viewed in the Azure Portal. Here you can see the duration of the individual operations and also filter them according to the success or failure of the operation.

For that, open your App Insights Dashboard and navigate to the Dependency Tab.

In this view you can also see that this behavior is included in many other software modules, e.g. in all Azure SDKs!

Conclusion

With the help of the TelemetryClient and the IOperationHolder we can easily monitor our own code and send the results to Application Insights. This allows us to monitor the performance of our application and identify runtime problems.

Have fun monitoring your application!