Adaptive Sampling leads to self-starvation in default configuration when app uses TrackEvent

[zakimaksyutov]

Current implementation of adaptive sampling counts towards sampled in quota all items which don't satisfy filter criteria. As a result the default configuration leads to self-starvation.

		<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
			<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
			<ExcludedTypes>Event</ExcludedTypes>
		</Add>
		<Add Type="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel.AdaptiveSamplingTelemetryProcessor, Microsoft.AI.ServerTelemetryChannel">
			<MaxTelemetryItemsPerSecond>5</MaxTelemetryItemsPerSecond>
			<IncludedTypes>Event</IncludedTypes>
		</Add>

Repro Steps

1. Write a console app which does 100 TrackRequest calls/sec and 10 TrackEvent calls/sec
2. Observe the behavior that two adaptive processors conflict with each other leading to self-starvation and not sending almost any telemetry

Actual Behavior

In picture below every line represents 10 seconds. First number - actually sent, second number - tracked.

Expected Behavior

For both streams - requests and events - AI SDK should have sent 5 documents / sec (so, first column should have been 50 for both types).

Fix

Process function (https://github.com/Microsoft/ApplicationInsights-dotnet/blob/7321d2bf7b9c4733fb43b6c186e381863931eb1a/src/ServerTelemetryChannel/SamplingTelemetryProcessor.cs#L146) should return control to estimator only for "//// Ok, now we can actually sample:" items.

[zakimaksyutov]

After leaving test console app to run for a long time it ended up with these ratios:

[SergeyKanzhelev]

closing than. Thanks @d3r3kk