Support worker roles through HostBuilder

[lmolkova]

Starting with NET Core 2.1, the concept of HostBuilder/Host was introduced:
https://www.stevejgordon.co.uk/using-generic-host-in-dotnet-core-console-based-microservices

It decouples host creation and management (DI, configuration) from the Asp.NET Core and HTTP stack and enables worker role scenarios.

Application Insights AspNet Core SDK should be split into 2 packages:

• first one that works for any app and configures everything not specific to HTTP server: majority of telemetry initializers, dependency collection, performance counter collection, heartbeats, quick pulse, sampling. .Net Full Fx apps perhaps may also benefit from it.

• second one that depends on AspNetCore and enables http: request collection, JS injection, etc...

Perfect example where this is needed Azure WebJobs/Functions: they don't necessarily have http stack and have to configure the SDK from scratch.

[vitalybibikov]

We need that feature as some of our Service Fabric services are simple console apps,
that are listening to Service Bus, so they are not using WebHostBuilder

[lmolkova]

@EvilAvenger, thanks for the feedback, I appreciate it. BTW you can configure dependency collection (including ServiceBus) manually, see https://docs.microsoft.com/en-us/azure/application-insights/application-insights-console. Hope it helps.

[xiaomi7732]

@lmolkova Thanks for looking into it. As a matter of fact, I am asked to provide an example of AI.K8s for HostBuilder. Could you please take a look at this PR: 141.

Personally, I think the work to support HostBuilder is minimal, well, without the splitting of the packages, of course. Is there any good reason not to do it?

[lmolkova]

Sure, I'll have a look.

There is no reason not to do it except there are no resources planned on it and no active feature to require this work. I assume we'll be happy to accept the contribution 🥇

[xiaomi7732]

@lmolkova I read the code briefly. It seems a simple but clean way to reach this is:

1. Add an extension method (or a set of methods) of UseApplicationInsights() that extends Microsoft.Extensions.Hosting.IHostBuilder, which calls AddApplicationInsightsTelemetry in the following bullet;
2. Add an extension method (or a set of methods) of AddApplicationInsightsBaseTelemetry that extends IServiceCollection that injects all initializers or modules that is not Asp.NET specific;
3. Update the existing extension methods to reuse the implementation in bullet 2.

That way, we don't need a new package; different extension method will provide the end user an easy way to enable application insights. You can claim this package works for .NET Core than only ASP.NET Core.

What do you think? I am intend to spend some spare time to make a PR for this but I want to check with you first since you are the repo owner. My fallback plan is to create those extension methods in my other packages, but it won't be as good as making them stay here.

[davidfowl]

@lmolkova Maybe we point people to the new logging package?

[lmolkova]

@davidfowl good point!

Microsoft.Extension.Logging.ApplicaitonInsights is now shipped separately from Microsoft.ApplicationInsights.AspNetCore and can be used on generic hosts.

It helps with logging, and we still should deliver support for other scenarios on the generic host: dependency collection, perf counters, sampling, correlation.

[cijothomas]

This is being addressed with a new nuget package Microsoft.ApplicationInsights.WorkerService the 1st beta of which is ~1 week away. There will be docs when it releases.

[cijothomas]

https://docs.microsoft.com/en-us/azure/azure-monitor/app/worker-service