Application insights does not honor modified values in DependencyTelemetry

[RamjotSingh]

If you are reporting bug/issue, please provide detailed Repro instructions.

Repro Steps

1. Download TestAppInsightsDependencyTelemetry.zip
2. Add the AI key to Startup.cs
3. Run the code
4. Open https://localhost:8890/api/values
5. Notice the DependencyTelemetry flowing out

Actual Behavior

Target is set to bing.com

Expected Behavior

ExternalRequestTelemetryProcessor should write a custom value for Target instead of bing.com

Version Info

SDK Version : ApplicationInsights 2.5.1 + ApplicationInsights.ASPNetCore 2.2.1 .NET Version : NetCore2.1
How Application was onboarded with SDK(VisualStudio/StatusMonitor/Azure Extension) : Visual Studio OS : Windows 10 Hosting Info (IIS/Azure WebApps/ etc) : Local hosting using Kestrel

What is the application doing?

ApplicationInsights automatically tracks all the outgoing requests and assign the Target field to applications which are well known. I tried writing a TelemetryProcessor that would assign well known names to dependencies I recognize. This is done by writing the details in AsyncLocal and then reading these details as part of TelemetryProcessor and writing them into DependencyTelemetry. This works till the point the call is in my system i.e. if I was to edit the endpoint and send the telemetry to non-AI endpoint (in the above given zip look at line 30 of startup.cs) it will be sent correctly, it however seems that when the call lands on AppInsight service the data is reprocessed and target is changed the base url of the call which overrides any values set by code. Attached code has a special listener which can receive AI events and dump them into console. If this is used correct target name is used, however when I use log analytics to search for data, the wrong value (bing.com) is shown.

[Dmitry-Matveev]

@SergeyKanzhelev , AI backend does indeed use URL host as Target and will overwrite custom target sent by SDK.

Is there some scenario in play that will be broken otherwise or we can forward this issue to the endpoint team, so that custom target is preserved?

[RamjotSingh]

@Dmitry-Matveev Any updates on this?

[Dmitry-Matveev]

@RamjotSingh , I confirmed that this is an unexpected behavior of the AI Endpoint - it overwrites custom target with URL Host, although it should preserve custom Target as per @SergeyKanzhelev. Addressing this will require a fix in the backend behavior but not in SDK. I currently assigned this issue to 2.9 milestone.

P.S. Several places in the portal UI do group/filter by this fields, e.g. Application map, so custom value will appear in those scenarios (I think that's what you're aiming for, but wanted to make sure you are aware just-in-case).

[RamjotSingh]

@Dmitry-Matveev Thanks for the update. Yes I want the custom value to appear in the application map. When is the 2.9 milestone expected to ship?

[Dmitry-Matveev]

SDK-wise, 1st Beta of 2.9 is expected around November 1st. However, this particular fix is on the backend and the timing is relative as it's not attached to any SDK release and depends on the deployment schedule after the fix is in. Long story short - as soon as you see this item closed, I'd expect fix to be in production within a week. I'd also expect us to address this bug within October but it's not a hard date.

[RamjotSingh]

Thanks @Dmitry-Matveev :)

[Chewbizz]

As I said in https://github.com/Microsoft/ApplicationInsights-dotnet-server/issues/1011, there is a workaround:

When you set a custom "target", also change "data" so that it's not a parsable URL.

For instance, when your "data" value is: http://10.20.30.40:8680/api/search?q=foo Set a non-parsable URL value instead: {"url":"http://10.20.30.40:8680/api/search?q=foo"}

Hope this helps in the meantime.

[RamjotSingh]

@Dmitry-Matveev Did this get picked up?

[Dmitry-Matveev]

@RamjotSingh, the nearest window of processing backend contributions will only be available in March-April, so this issue is still not fixed.

[github-actions[bot]]

This issue is stale because it has been open 300 days with no activity. Remove stale label or comment or this will be closed in 7 days.