CustomApplicationInsightsConfig is too opinioned and breaks standard Azure Portal features about azure-functions-telemetry

[gabrielweyer]

Published as 2.0.1.

[gabrielweyer]

Thank you for reaching out, it's always good to get feedback from users!

There are a few execution charts in the Azure Portal. Are you talking about the one on the Function App Overview page:

Or are you looking at the one on the Function Overview?

Or maybe another one altogether?

So that I can reproduce the issue, can you please provide additional information?

• Is your Function App using the v3 or the v4 runtime?
• Is it an in-process or isolated Function App?

The reasoning behind overriding the cloud role name is to make it easier to write queries that work across environments. As the cloud role name is identical across environments, so can be the alert queries.

I'm interested to hear about how you version your binaries. I set the application version so that I can differentiate telemetry when I have two versions of the Function App running at the same time.

Can you please elaborate on:

it would probably also make sense to make all default configuration settable without forcing a configuration-section

Are you saying you would rather use a Fluent API (e.g., WithSomething()) instead of an appsetting (e.g., ApplicationInsights:WithSomething)?

[Skovvart]

The one I noticed broken is from a specific Function's Monitor blade, where the "Run query in application insight" button I posted is located:

The reasoning behind overriding the cloud role name is to make it easier to write queries that work across environments. As the cloud role name is identical across environments, so can be the alert queries.

It is not a major issue as I can source the environment from other telemetry properties, but the inability to differentiate the environment from the application name was not a positive in my case 😅

I'm interested to hear about how you version your binaries. I set the application version so that I can differentiate telemetry when I have two versions of the Function App running at the same time.

Build info is added during CI and exposed through my healthcheck endpoint and added to telemetry through a telemetry initializer. It is maybe "needlessly custom" but it works well enough (and I would likely retain most of the functionality even if I converted one "number", i.e. DevOps build id, to be the assembly version).

The app in question is an in-process v4 function app.

Are you saying you would rather use a Fluent API (e.g., WithSomething()) instead of an appsetting (e.g., ApplicationInsights:WithSomething)?

Generally I prefer the appsettings approach (also why I wrote I believe it's a good default :)), but in this case I only wanted to tweak the HealthFunction setting, so an overload like .AddCustomApplicationInsights(Action<CustomApplicationInsightsConfig>) would be great

            .AddCustomApplicationInsights(config => {
                config.ApplicationDescriptor = new("My App", myVersion); // leave null to not override
                config.HealthCheckFunctionName = nameof(HealthCheckFunctions.HealthCheck);
                config.DiscardFunctionExecutionTraces = true;
                config.DiscardServiceBusTrigger = true;
                config.ServiceBusTriggeredNames = FunctionsFinder.GetServiceBusTriggeredFunctionNamesFromAssemblyContaining<Startup>(); // new[] { nameof(ServiceBusFunctions.Function1), nameof(ServiceBusFunctions.Function2) }
            })

[gabrielweyer]

Broken Function's Monitor blade

I see the same behaviour. Interestingly, the Azure web jobs SDK supports overriding the cloud role name by setting an environment variable named WEBSITE_CLOUD_ROLENAME. When this environment variable is set and the value is not the Function App's name, the Function's Monitor blade will be broken as well.

Cloud role name and application version

You would like setting the cloud role name and application version to be optional. This would allow you to either:

• Rely on the default behaviour (cloud role name will be the Function App name and application version will not be present)
• Add your own telemetry initializer to set the cloud role name and / or application version (this works already today but is inelegant because the library also forces you to set them)

Would it be an acceptable solution to have an overload that wouldn't require CustomApplicationInsightsConfig? E.g., something like this:

builder.Services.AddCustomApplicationInsights();

If this were to be called, the library would neither set the cloud role name, nor the application version.

Discarding a Function's request

To discard a health check using the library, all you have to do is add the below appsetting:

  "ApplicationInsights:HealthCheckFunctionName": "HealthFunction"

If you're concerned that the appsetting could get out of sync with the Function's name, a telemetry processor might be more appropriate for your requirements.

[Skovvart]

Would it be an acceptable solution to have an overload that wouldn't require CustomApplicationInsightsConfig? E.g., something like this:

Yes, that would work great for me :)

[gabrielweyer]

After reviewing the implementation, I decided to keep the typeFromEntryAssembly parameter. I'm using it to discover the Service Bus triggered Functions and apply custom handling to them.

I published 2.0.1-alpha.0.9. Can you please try the pre-release package and let me know what you think?

You'll now be able to write:

var appInsightsConfig = new CustomApplicationInsightsConfigBuilder(typeof(Startup)).Build();
builder.Services.AddCustomApplicationInsights(appInsightsConfig);

This will leave both the 'Cloud role name' and the 'Application version' untouched.

[Skovvart]

I am trying it out now - early indications seem good. Thanks! :)