Replace ITelemetryActivator with ITelemetryModule

[bachuv]

This PR replaces ITelemetryActivator with ITelemetryModule so we can have more flexibility with configuration. For example, with this change we can set Managed Identity credentials instead of only setting Application Insights relevant settings.

For context:

• ITelemetryActivator: Used to activate or create telemetry objects. It also initializes the telemetry client for distributed tracing, allowing settings to be verified and adjusted during initialization
• ITelemetryModule: Used to initialize and configure telemetry modules from TelemetryConfiguration. It ensures that telemetry modules are properly set up to collect and send data using the same configuration.

Also, in this PR, we remove some log statements and checks. With ITelemetryActivator, we checked if the customer was providing APPINSIGHTS_INSTRUMENTATIONKEY and/or APPLICATIONINSIGHTS_CONNECTION_STRING and logged different warnings based on the configuration. With ITelemetryModule, it automatically has the configuration in the TelemetryConfiguration object, so we no longer need to check for these configurations.

Resolves #2870

Pull request checklist

• My changes do not require documentation changes
  • Otherwise: Documentation PR is ready to merge and referenced in pending_docs.md
• My changes should not be added to the release notes for the next release
  • Otherwise: I've added my notes to release_notes.md
• My changes do not need to be backported to a previous version
  • Otherwise: Backport tracked by issue/PR #issue_or_pr
• I have added all required tests (Unit tests, E2E tests)
• My changes do not require any extra work to be leveraged by OutOfProc SDKs
  • Otherwise: That work is being tracked here: #issue_or_pr_in_each_sdk
• My changes do not change the version of the WebJobs.Extensions.DurableTask package
  • Otherwise: major or minor version updates are reflected in /src/Worker.Extensions.DurableTask/AssemblyInfo.cs
• My changes do not add EventIds to our EventSource logs
  • Otherwise: Ensure the EventIds are within the supported range in our existing Windows infrastructure. You may validate this with a deployed app's telemetry. You may also extend the range by completing a PR such as this one.
• My changes should be added to v3.x branch.
  • Otherwise: This change only applies to Durable Functions v2.x and will not be merged to branch v3.x.

[jviau]

This looks good to me overall. But is it possible to add some unit tests for the Initialize method? Also, have you verified this works manually? That initialize is called and durable tracing is configured?

Also are all the failing builds of concern or transient?

[bachuv]

@jviau - after updating this line to register an ITelemetryModule for tests, I noticed that the lambda expression here doesn't get evaluated anymore and therefore the TelemetryActivators constructor and Intialize() method don't get called. I thought it was because the new Initialize() method takes a TelemetryConfiguration as an argument so I registered a TelemetryConfiguration as a singleton before line 91, but it's still not initializing TelemetryActivator. Do you know if there are any additional services I should register to get TelemetryActivator to register?

For context, the changes in this PR work when I manually test them in a sample DF app. The tests are just not passing because of the issue I described earlier.

[jviau]

ITelemetryModule's are resolved and invoked by the AppInsights SDK. Does the test code have the AppInsights SDK hooked up?

[bachuv]

The test code references Microsoft.ApplicationInsights through the package reference to the WebJobs extension. It doesn't have any code to hook up Application Insights though. I tried adding services.AddApplicationInsightsTelemetry(), but that ended up giving me an error that it needs an IHostingEnvironment so I wasn't sure if that was correct.

[bachuv]

@jviau, were you thinking of an approach different from services.AddApplicationInsightsTelemetry()?

[jviau]

Possibly? I haven't looked at the exact test failures yet, but all of this is just a convenience part of the AppInsights SDK to have a defined hook for code to run as part of the SDK starting up. If that doesn't work for your tests, doing the same thing manually -- instantiating and calling the ITelemetryModule with the correct config instance is perfectly acceptable. What that looks like exactly I can't say without taking a deeper look.

[bachuv]

I was able to get rid of the IHostingEnvironment error by adding loggingBuilder.AddApplicationInsightsWebJobs();, but the tests are still failing.

I also tried registering TelemetryConfiguration before the call to register ITelemetryModule, tried to make services.AddApplicationInsightsTelemetry() work, and tried to instantiate and call the ITelemetryModule, but nothing worked.

I might try to go back to using ITelemetryActivator, check for if the customer provided any managed identity specific environment variables/config, then manually set those since getting managed identity working with Application Insights was the original request that the customer reported in their GitHub issue.

@jviau, let me know if there are any other approaches you recommend that I try.

[jviau]

@bachuv I don't recommend reverting to ITelemetryActivator. Doing that puts diverges durable from how AppInsights is configured from the rest of the product. Using the ITelemetryModule allows durable to be agnostic for how app insights is configured. If the host adds support for more forms of identitiy, does durable really want to have to copy that work let alone even be aware of it? This is far less code to maintain. I especially don't recommend going back as this is a test setup issue, not an implementation issue.

[jviau]

Looking at the test code, it will need refactoring as part of this to keep the same test validation. The current test code has 2 main gaps after theis change:

1. Reliance on using a test-only property TelemetryActivator.OnSend to shim in custom test hooks. That is no longer hooked up at all.
2. DI changes. TelemetryActivator was instantiated and initialized as part of starting the Durable Webjobs extension. This will not longer be the case as we are relying on AppInsights SDK to perform this call. But appinsights SDK is not configured for this test host.

I think the easiest route for this change is to:

1. As part of test setup, just don't add TelemetryActivator at all!
2. Remove OnSend property
3. You can just instantiate your own TelemetryActivator as part of tests and pass in a custom TelemetryConfiguration to Initialize.

[bachuv]

This looks good to me overall. But is it possible to add some unit tests for the Initialize method? Also, have you verified this works manually? That initialize is called and durable tracing is configured?

Also are all the failing builds of concern or transient?

I'm working on adding unit tests for the Initialize method. I verified that this works manually.

The failing build includes some existing tests that are failing now because of the changes so I'm looking into that. I left a comment in the PR that explains the issue.

[jviau]

Good call deleting this. Not something durable should be enforcing - particularly with OTel coming along which will not always be app-insights backed.