If iKey is provided only in telemetry item context this item is dropped

[abaranch]

TelemetryClient checks iKey in its own Context and configuration. If it is empty in both places item is dropped. But telemetry item may have instrumentation key defined on the item level which should be checked as well.

[SergeyKanzhelev]

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?

[JakubOleksy]

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

[abaranch]

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

[SergeyKanzhelev]

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

[JakubOleksy]

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

[SergeyKanzhelev]

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

[SergeyKanzhelev]

@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.