Ignore Azure Function false positive dependency failures using TelemetryInitializers

Let me start by saying that I love Appication Insights. The level of detail it gives you out of the box to monitor and troubleshoot application issues is fantastic.

BUT, I loathe false positive error messages, especially dependency failures. If you’ve done any work with Azure storage then you’ve likely come across what I’m talking about. In many SDK functions and in the Azure Functions bindings, the code calls a “CreateIfNotExists” function behind the scenes to check that the queue or tablet that you’re trying to access exists, and in the case of tables and queues, if it doesn’t exist, as the name implies, it creates it.

This is great…..the first time it runs as it creates the table or queue that you’re trying to access if you’ve forgotten to create it first.

However, this has several downsides. The first minor one being when you’re creating a set of Azure Functions, perhaps one to add an item to a queue and another to listen on that queue. But then you go and spell the name of one of the queues wrong and all of a sudden you’re trying to track down why your queue is not working and it’s because you have two queues, processing-queue and processing-qeue! I personally would prefer by default it fail with a table doesn’t exist error unless I specifically call CreateIfNotExists.

Yes, I know that you coud easily work around this by using a shared constant, but work with me here!!

The second downside and the one this post is about, is the infinite number of times that the code runs after the first time when it throws a 409 (The specified entity already exists) error. This shows up in Application Insights as a dependency failure, when it’s actually not a failure at all. This “noise” in the telemetry hides valid errors that require investigation.

With the addition of Dependency Injection functionality in Azure Functions V3, adding the ability to filter out these false positives is very easy.

First, create your TelemetryInitializer like below that intercepts the telemetry items and sets the false positive result to a success. Now any 409 errors thrown by the Azure Functions bindings will be set as a sucessful call rather than a dependency failure.

public class AzureCheckTableExistsInitializer : ITelemetryInitializer
    {
        public void Initialize(ITelemetry telemetry)
        {
            if (
               telemetry is DependencyTelemetry dependencyTelemetry &&
               dependencyTelemetry.ResultCode == "409" &&
               dependencyTelemetry.Type == "Azure table" &&
               dependencyTelemetry.Name.EndsWith("Tables") &&
               dependencyTelemetry.Success == false)
            {
                dependencyTelemetry.Success = true;
            }
        }
    }

Then, add a Startup.cs to your Azure Functions root folder and add a Startup class inheriting from FunctionsStartup

You need to ensure that you mark your Function as type FunctionsStartup in the assemby as you can see below

[assembly: FunctionsStartup(typeof(MyApp.ScanningEngine.Startup))]
namespace MyApp.ScanningEngine
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddSingleton<ITelemetryInitializer, AzureCheckTableExistsInitializer>();
        }
    }
}

This will help your Application Insights telemetry to be a little more free of noisy false positive dependency failures

Much of the inspiration behind this post comes from Evan Neilsen’s post Application Insights and Table Storage CreateIfNotExists