So I wanted to share a quick post on something that is rather small but I was surprised at how little documentation there was with regard to how to implement it.

Monitoring is honestly one of the most important things you can do with regard to cloud applications. There’s an old saying, “what gets measured…matters.” And I find this expression to be very true in Application Development.

So if you are building out an azure function, what steps are required to enable Azure Application Insights for your Functions. For this post I’ll be focusing on adding it to a DotNetCore function app.

Step 1 – Add the nuget package

No surprise, it all starts with a nuget package, you are going to want to add “Microsoft.ApplicationInsights.AspNetCore”, shown below:

But additionally, you are going to need the nuget package “Microsoft.Azure.Functions.Extensions” shown here:

Step 2 – Update the Startup.cs

Now if you haven’t configured your function app to have a startup.cs file, then I’m of the opinion you’ve made some mistakes. Because honestly I can’t understate the importance of dependency injection to ensure you are falling recommended practices and setting yourself up for success. Once you’ve done that, you will be able to add the following line to the override of “Configure”, shown below:

[assembly: FunctionsStartup(typeof(SampleProject.Services.Startup))]namespace SampleProject.Services{ public class Startup : FunctionsStartup { public override void Configure(IFunctionsHostBuilder builder) { builder.Services.AddScoped<ITelemetryProvider, TelemetryProvider>(); builder.Services.AddApplicationInsightsTelemetry(); } }}

The above code will use the “AddApplicationInsightsTelemetry()” method to capture the out-of-the box telemetry.

That leaves the outstanding question of capturing custom or application specific telemetry, for that I recommend implementing a wrapper class around the Telemetry client. Personally this is a general practice I always implement as it removes the hard dependencies in an application and helps with flexibility later.

For this, the “TelemetryProvider” is the following:

public class TelemetryProvider : ITelemetryProvider { private TelemetryClient \_client; public TelemetryProvider() { \_client = new TelemetryClient(TelemetryConfiguration.CreateDefault()); } public void TrackEvent(string name) { \_client.TrackEvent(name); } public void TrackEvent(string name, Dictionary<string, string> properties) { \_client.TrackEvent(name, properties); } public void TrackEvent(string name, Dictionary<string, string> properties, Dictionary<string, double> metrics) { \_client.TrackEvent(name, properties, metrics); } public void TrackMetric(string name, double value) { \_client.TrackMetric(name, value); } public void TrackException(Exception ex) { \_client.TrackException(ex); } public void TrackDependency(string name, string typeName, string data, DateTime startTime, TimeSpan duration, bool success) { \_client.TrackDependency(typeName, name, data, startTime, duration, success); } }

With an interface of the following:

public interface ITelemetryProvider { void TrackDependency(string name, string typeName, string data, DateTime startTime, TimeSpan duration, bool success); void TrackEvent(string name); void TrackEvent(string name, Dictionary<string, string> properties); void TrackEvent(string name, Dictionary<string, string> properties, Dictionary<string, double> metrics); void TrackException(Exception ex); void TrackMetric(string name, double value); }}

After you’ve implemented this provider, it makes it very easy to capture telemetry relates to specific functionality in your application and leverage application insights as a total telemetry solution.