If iKey is provided only in telemetry item context this item is dropped about applicationinsights-dotnet HOT 7 CLOSED

I believe it is an optimization. In case when iKey was not set for win store application - we will not try to access Context property of an item and will not construct it. @JakubOleksy, is it actually by design or not?

from applicationinsights-dotnet.

Correct, we need a way to quickly stop processing when iKey is not set and have minimum impact on the application.

from applicationinsights-dotnet.

If that is by design instrumentation key should be removed from the telemetry item.

from applicationinsights-dotnet.

I was thinking that since it's all internal - we can have internal method to check whether Context was initialized on telemetry item. If so - checking instrumentation key on telemetry item would be fast. If not - do not check it since it clearly wasn't set

from applicationinsights-dotnet.

We probably don't need to make it even settable at an item level. I am not sure the scenario that would require that.

from applicationinsights-dotnet.

Hm, I took a look and it seems that my information is outdated. Now context being instantiated in constructors of telemetry items. See ExceptionTelemetry.cs#L32 as an example. So it looks like a simple bug

from applicationinsights-dotnet.

@JakubOleksy , typical scenario is to split auto-collected data into different instrumentation keys to protect critical data from being throttled because of high volume non-important events. Examples are sending performance counters to a separate iKey or re-route verbose traces. We recommended this approach (telemetry initializer that overrides iKey) to somebody for exactly this reason.

from applicationinsights-dotnet.