Deprecating TelemetryConfiguration.Active singleton
lmolkova opened this issue · 40 comments
With ApplicationInsights SDK 2.11-beta1 we are deprecating TelemetryConfiguration.Active on .NET core apps, see #1148.
ApplicationInsights exposes TelemetryConfiguration.Active singleton to enable auto-configuration scenarios in the absence of a dependency injection framework.
It is used on ASP.NET Classic apps (in Microsoft.ApplicationInsights.Web SDK). The configuration is read from the ApplicationInsights.config file by auto-collectors when an application starts.
User can access configuration that is used by auto-collectors and is able to customize it.
It is not the case for ASP.NET Core application where Dependency Injection is part of the framework - ApplicationInsights configuration is done and could be accessed and customized through DI container. The details and examples could be found here; https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core
Active singleton creates issues typical for static singletons - lifetime it tight to process, testing is complicated. This is especially problematic in ASP.NET core apps, Azure WebJobs, and generic host apps, where one process may host multiple applications. So there ApplicationInsights SDK configures an instance of TelemetryConfiguration per host. It frequently results in confusion around which instance of configuration to use: one in the DI container or Active.
-
If you use ApplicationInsights SDK for ASP.NET Core apps - follow this document for guidance on how to configure AppInsights: https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core
-
If you use AzureFunctions v2+ or Azure WebJobs v3+ - follow this document: https://docs.microsoft.com/en-us/azure/azure-functions/functions-monitoring#version-2x-3
-
If you have other kind of application where you configure
TelemetryConfigurationyourself - do not useTelemetryConfiguration.Activesingleton.
You should create configuration instance and may carry it explicitly in your code, leverage DI from Microsoft.Extensions.DependencyInjection or any other available DI framework or even create your own global static variable to storeTelemetryConfigurationinstance you create.
@lmolkova In the context of this change, what is the recommended replacement for the popular pattern of creating an instance of TelemetryClient via the parameter-less ctor at multiple places, instead of carrying around an instance?
Will TelemetryClient() use something other than TelemetryConfiguration.Active?
If so - what? If not - what is the recommendation? I was that doing
var client = TelemetryClient();
client.TrackStuff(..);
at multiple places is a very common usage pattern.
Thanks!
[EDITED]
In console apps, where ApplicationInsights SDK or AppInsights ILogger provider are used, get TelemetryConfiguration instance from the DI container and create TelemetryClient whenever you want.
Check out how you can customize configuration for ILogger provider and ASP.NET Core SDK
When building container yourself, you decide how to customize the configuration and register it in the container. The baseline: you can just register TelemetryConfiguration instance and still use dependency injection to resolve it. Pay attention to nuances like
- when registering an instance without a factory, an instance is not disposed with the host, so always use factories to register disposable instances
- use
services.Configure<TelemetryConfiguration>, but be careful with correlation and addOperationCorrelationTelemetryInitializerto ensure correlation still works:
services.Configure<TelemetryConfiguration>(
(o) => {
o.InstrumentationKey = "123";
o.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());
});If you don't want to use DI, and have pure console app, create config once and pass it around however you want.
When creating configuration instance yourself, use TelemetryConfiguration.CreateDefault() and not the parameterless constructor (to enable correlation):
var config = TelemetryConfiguration.CreateDefault();
var client = new TelemetryClient(config);Keep one TelemetryConfiguration per app lifetime (a few is also fine), but you may create as many clients as you want.
Do not forget to dispose TelemetryConfiguration when gracefully shutting down the application.
I think we advise using IOptions<TelemetryConfiguration> instead of a raw TelemetryConfiguration instance. At least that's what you get with the ILogger extension.
If building the DI container yourself, of course you're free to do whatever you want, but I think we prefer services.Configure<TelemetryConfiguration>(...) over services.AddSingleton<TelemetryConfiguration>(...).
I've used TelemetryConfiguration.Active to programmatically configure the configuration used with Microsoft.ApplicationInsights.NLogTarget. From the above information, it's not clear to me what the rewrite strategy should be in the case of Microsoft.ApplicationInsights.NLogTarget.
This is causing a lot of confusion in logging frameworks like Serilog. We now don't have a way to catch early startup failures. See here: serilog-contrib/serilog-sinks-applicationinsights#121
@xantari Could you open a new issue describing the issues with serilog intergrations?
This is difficult since it's used on my ServiceBase, which is inherited over 400 times in my project... I don't even think there's a Resharper refactoring for this type of cascading dependency quagmire.
However, if someone does in fact have a way to automate this with Resharper or otherwise, this might be a good place to mention it...
This is difficult since it's used on my ServiceBase, which is inherited over 400 times in my project... I don't even think there's a Resharper refactoring for this type of cascading dependency quagmire.
However, if someone does in fact have a way to automate this with Resharper or otherwise, this might be a good place to mention it...
Actually, I think I found it: https://stackoverflow.com/questions/6543078/resharper-or-visual-studio-shortcut-to-cascade-changes-to-a-constructor
So how do we make logs in the Startup.cs file now? Before we would create the configuration of ApplicationInsights inside Program.cs and then inject TelemetryClient into Startup's constructor:
public Startup(IConfiguration configuration, TelemetryClient insights)
{
_configuration = configuration;
_insights = insights;
}
But now the instance of TelemetryClient is not going to be available in Startup.ConfigureServices() method.
I received code that uses new TelemetryClient() to setup mock objects in tests (in the core application it is done properly using DI).
For this new TelemetryClient() instances in my tests I get a warning that it is deprecated with a link to this issue - how can we best mock a TelemetryClient instead?
Should I just do
var config = TelemetryConfiguration.CreateDefault();
var client = new TelemetryClient(config);as per #1152 (comment)?
Microsoft, you mentioned that we should use "codeless" application insights integration for azure functions, but problem is that this integration ignore all soft of parent/child relations, w3c context context and make disturbed tracing - impossible. https://github.com/w3c/correlation-context/
From my perspective - suggest only "codeless" is a bit too strong best practice.
The issue with Microsoft.ApplicationInsights.NLogTarget persists and is related to #1457 and specifically that the obsolete method is used at
with suppressed warnings and no way to override.Can you please update the readme file on the applicationinsight pages?
https://github.com/serilog/serilog-sinks-applicationinsights
The example provided still uses the obsolete version. Can you provide an example that reads the intrumentation key from the environment?
For serilog - can you please open a separate issue in serilog repo, as we (owners of this repo) don't own serilog integration.
The execution of this change was not done well.
https://github.com/microsoft/ApplicationInsights-dotnet/blob/develop/Readme.md has under "Getting Started":
using Microsoft.ApplicationInsights;
var tc = new TelemetryClient();
tc.InstrumentationKey = "INSERT YOUR KEY";This now gives "This construct is depreciated. We do not recommend using "TelemetryConfiguration.Active on .Net Core", linking to this thread.
Problems:
- Using the code in the readme should be ready to use and should not give a depreciation warning message.
- The package is netstandard, but the warning message guesses that it may be used on .Net Core.
- The linked thread (this one) gives no guidance about how to fix the code, suggesting different methods based on where the code will be used (with different links from ASP.NET Core apps, Azure functions, etc.), and recommending config file approaches instead. But code can provide a much simpler api than config files.
My guess about a fix:
- Replace the code in Readme.md with:
using Microsoft.ApplicationInsights;
var tConfig = new Extensibility.TelemetryConfiguration { InstrumentationKey = "INSERT YOUR KEY"};
var tc = new TelemetryClient(tConfig);- Remove "on .Net Core" from the depreciation message.
- Remove the link to this thread from the depreciation message. Remove references to typical config files from the TelemetryConfiguration and TelemetryClient constructors.
I also don't get a bit why netstandard2.0 ApplicationInsights library says "We do not recommend using TelemetryConfiguration.Active on .NET Core". Nestandard2.0 library is not necessary will be used in .NET Core app..
I have an idea to create a reusable telemetry package for bunch of our (micro)services, with identical or similar telemetry configuration, filtering, etc. However not all of these services are .NET Core based, therefore I don't want to rely purely on (ASP).NET Core DI (which in general is often quite a blocker for many things, especially for reusable libraries).
The obsolete warning is only for .NET Core apps. It is not shown .NET Framework apps.
The obsolete warning is only for .NET Core apps. It is not shown .NET Framework apps.
Obsolete warning is shown in netstandard2.0 code. I wasn't speaking about "apps" at all..
Also usually "obsolete" means, that it's not supported anymore and might be removed in upcoming next releases.. So if it's still might be used and won't be gone in next few versions - then how it is now, it's at least confusing. I don't want to rely on obsolete code creating brand new library. :)
It'll be removed only in next major version change to 3.xx. We are in 2.13 now. No ETA on when 3.xx is coming, but whenever that comes, all obsolete will be removed.
@cijothomas What is the correct approach for .NET Core GUI apps that use this? For example, NuGet Package Explorer and many other apps are now using it similar to this:
There is no DI container. The code is reading the ApplicationInsights.config for the initializers and the the InstrumentationKey. They instrumentation key is explicitly done in config so that it's not checked into source control, and put in on the build agent.
@clairernovotny For application which don't use DI, you can create TelemetryConfiguration yourself, and configure it, just like you would for TC.Active.
var tc = new TelemetryConfiguration()
tc.TelemetryInitializers.Add()...
..set ikey..etc.
var client = new TelemetryClient(tc);
client.Track..()
@cijothomas Thanks -- how does new TelemetryConfiguration() differ from TelemetryConfiguration.CreateDefault()?
CreateDefault adds some default functionality.
OperationCorrelationTelemetryInitializer is added by default when using CreateDefault. When using new TelemetryConfiguration(), everything has to be added manually including OperationCorrelationTelemetryInitializer.
If you are using .NET Core, (and NOT Asp.net core), you could the worker service SDK.
(https://docs.microsoft.com/en-us/azure/azure-monitor/app/worker-service)
If you construct TelemetryConfig by hand, you'll likely miss new features. Also setting up everything is not very easy and, unfortunately not documented clearly anywhere.
What confuses me is that all the documentation available today (e.g. https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core#how-can-i-track-telemetry-thats-not-automatically-collected: A singleton instance of TelemetryClient is already registered in the DependencyInjection container) suggests that dependency injection happens out of the box, yet that is not true or at least not what I'm experiencing: a TelemetryClient is NOT already registered in the DependencyInjection container.
Specifically, I'm adding a TelemetryClient object as a parameter to the constructor, and it does not contain either of the properties, initializers etc. configured.
In the past, I would configure a TelemetryClient object by instantiating it during service configuration, but since that option is obsolete, I'm confused how dependency injection should be handled now.
Do you mind elaborating that, please?
What confuses me is that all the documentation available today (e.g. https://docs.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core#how-can-i-track-telemetry-thats-not-automatically-collected: A singleton instance of TelemetryClient is already registered in the DependencyInjection container) suggests that dependency injection happens out of the box, yet that is not true or at least not what I'm experiencing: a TelemetryClient is NOT already registered in the DependencyInjection container.
Specifically, I'm adding a TelemetryClient object as a parameter to the constructor, and it does not contain either of the properties, initializers etc. configured.
In the past, I would configure a TelemetryClient object by instantiating it during service configuration, but since that option is obsolete, I'm confused how dependency injection should be handled now.
Do you mind elaborating that, please?
Please open a new issue with the description of what you are facing along with a minimal repro.
Which repo. This one? I've already opened one related to the docs, but that's a different repo.
Which repo. This one? I've already opened one related to the docs, but that's a different repo.
Please share the link. What I am saying is - open new issue instead of commenting on closed ones. Closed ones are not actively tracked.
That's fair - good point. I've created a new issue inside this repo (see mention above). The one for the docs is MicrosoftDocs/azure-docs#59590
Hi,
I am using TelemetryClient for adding correlation between 2 azure functions communicating with each other using Azure Event Grid. Unlike the Service Bus, the end-to-end transactions don't appear on the logs out of the box with the Event Grid.
However, I am hitting a problem here.
- When I am injecting the TelemetryConfiguration into my function, it is completely empty.
- When I am injecting the
IOptions<TelemetryConfiguration>to my function, the TelemetryConfiguration is there but missing the actual config, even the instrumentation key. - When I am injecting my customized TelemetryConfiguration as below, it works but the end-to-end transaction logs get weird and loses significant correlations in the logs:
return services
.AddSingleton(sp =>
{
var telemetryConfiguration = TelemetryConfiguration.CreateDefault();
telemetryConfiguration.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());
var config = sp.GetService<IConfiguration>();
var instrumentationKey = config.GetValue<string?>("APPINSIGHTS_INSTRUMENTATIONKEY");
if (instrumentationKey != null)
telemetryConfiguration.InstrumentationKey = instrumentationKey;
return telemetryConfiguration;
});
However, when using the deprecated TelemetryConfiguration.Active it works perfectly. I noticed the Active config has more initializers in addition to the OperationCorrelationTelemetryInitializer, namely speaking:
- Microsoft.Azure.WebJobs.Logging.ApplicationInsights.WebJobsRoleEnvironmentTelemetryInitializer
- Microsoft.Azure.WebJobs.Logging.ApplicationInsights.WebJobsTelemetryInitializer
Not sure if that is there reason, but I couldn't find any good documentation or solution for this! Is there an alternative solution to make this work like the TelemetryConfiguration.Active?
@mehric Please open an issue in the Azure Web Jobs SDK where the relevant code is hosted.
Hi @cijothomas,
Thanks for the reply, however, I don't believe this is an issue with the Web Jobs SDK. The issue is that there was a way to get the active telemetry configuration before but it is deprecated now. Unfortunately, I couldn't find a working alternative for it and would appreciate it if someone could point out a working solution for it.
I actually created another issue here for it: #2144
@mehric WebJob/Functions uses this SDK is a special way. Hence I suggest to open it in their repo.
If you have issues in a non Functions environment, please feel free to open a new issue in this repo, with steps to repro and we can definitely help.
In terms of unit tests the code that is using injected telemetry client through the method AddApplicationInsightsTelemetry() how can we mock telemetry client? What would be recommended best practice?
Thanks.
So excuse my asking on a 2yr closed issue but I've read the thread this far and I still don't quite see:
What's the solution for logging startup ?
Yesterday my Azure web app told me 'http 500.30 failed to start' and without startup logging I'm blind.
So excuse my asking on a 2yr closed issue but I've read the thread this far and I still don't quite see:
What's the solution for logging startup ?
Yesterday my Azure web app told me 'http 500.30 failed to start' and without startup logging I'm blind.
Please review the docs (https://docs.microsoft.com/en-us/azure/azure-monitor/app/ilogger) and open a new issue if required. This question doesn't seem to be related to this issue.
Does the advice above change with the new AddApplicationInsightsTelemetryWorkerService feature?
https://docs.microsoft.com/en-us/azure/azure-monitor/app/worker-service
In terms of unit tests the code that is using injected telemetry client through the method AddApplicationInsightsTelemetry() how can we mock telemetry client? What would be recommended best practice? Thanks.
did you find a solution to this?
@cijothomas
@asjvarsity Please see #342 (comment) for an example of using a mock TelemetryChannel for unit testing.
FYI there are live public links to this article but the general public do not seem to have access to this article. For example https://learn.microsoft.com/en-us/azure/azure-monitor/app/api-custom-events-metrics is publicly accessible but then you cannot follow the link to this page from a public account.