Unable to access TelemetryConfiguration in DefaultTelemetryClientFactory (App Insights)

[erick-thompson]

I have some additional App Insights modules that I would like to use (one of our own, and DependencyTrackingTelemetryModule). The existing code to configure App Insights for web jobs is DefaultTelemetryClientFactory, which does not have overloads or access points to modify the configuration. Normally, I would write my own factory, but three of the types I need are internal only (WebJobsRoleEnvironmentTelemetryInitializer, WebJobsTelemetryInitializer, WebJobsSanitizingInitializer).

Why do I need this?
We track custom metrics, ensure that all dependencies are tracked, and measure end-to-end performance, all use Application Insights. The packages Mircosoft.Azure.Webjobs.Logging.ApplicationInsights (3.0.0-beta4) has a number of AI related types that are very useful, but they don't have everything we need. As a result, we either have to stop using the AI pacakge for web jobs, fork the package, or do some nasty reflection to ensure all components are initialized.

What do I want?
The easiest option is to provide some virtual/protected methods to DefaultTelemetryClientFactory to either allow me to provide TelemetryInitializers (see DefaultTelemetryClientFactory line 95), or make the TelemetryConfig public.

There are a number of other ways this could be done, but the upshot is that I need to have some control in the setup of Application Insights.

[paulbatum]

@brettsam I think we have an open issue tracking this feature request? Is this a dupe?

[erick-thompson]

I didn't see a related issue. If you can point me to it, I can update that. I might take a stab at it if nobody is working on it.

[brettsam]

There was a similar issue here: #1416.

To unblock yourself, your best bet may be to just grab those types directly from github and build them yourself locally. We'll use anything that implements ITelemetryClientFactory so there's no issue with you modifying it yourself. Not ideal, but it should work.

Would creating a virtual AddInitializers() unblock you?

Exposing the TelemetryConfig (or having a virtual method that we'll call into at some point) would be another route. But it doesn't give you much control over the ordering of Initializers/Modules/Processors/etc.

I want to keep this issue open to track improvements we can make here.

[erick-thompson]

A virtual AddInitializers() would work fine for now, but you're right that it doesn't give a deal deal of flexibility. I'll take a look at the workaround in 1416 and respond back to this thread. Thanks.

[julKali]

Hi, I'm having a similar issue and for me, a virtual AddInitializers() would help me a lot! Do you think you guys could implement that?

Alternatively, you could set _config protected or public, that would make things a lot easier too!

[erick-thompson]

@julKali In the meantime, I forked the AppInsights part of the SDK and made changes there. The AppInsight part of the project is fairly clean and easy to get building.