Making sampling percentage dynamically adjust (adaptive smpling) about applicationinsights-dotnet HOT 3 CLOSED

Is there a recommendation we can provide on how to understand effectiveness of default values for these settings and what value to set them: MovingAverageRatio, SamplingPercentageDecreaseTimeoutSeconds and SamplingPercentageIncreaseTimeoutSeconds?

My opinion that adaptive sampling should be THE sampling. So we don't need to complicate API by introducing two distinct extension methods - UseAdaptiveSampling and UseSampling.

Sampling today takes into consideration user id, operation id, etc. I assume this sampling processor will do the same. Would it be nice to detach the logic of sliding window and actual sampling logic? Maybe one processor is "counting" and another is filtering based on adjusted value?

What scenario do you see for change callback? Maybe we can make it via tracing so one can subscribe on EventSource and listen for change events instead? What logic do you expect will be made by customer beside tracing here?

from applicationinsights-dotnet.

1. Re: setting values & effectiveness of "penalty box" and "moving avg" parameters. These are for fine-tuning the process. Defaults should work for most cases. One example where penalty box parameters may need adjusting is spikes in telemetry production with certain period of time... The idea is to apply defaults and if that does not work, analyze why volume of telemetry is still high and/or throttling is in effect. Analysis may show a need to fine-tune these parameters. I do not think we can provide "rule of thumb" way of adjusting these. Start with defaults, than apply analysis on a case-by-case bases...
2. Re: "THE sampling". I strongly want to have static sampling available and public. It encapsulates complex sampling logic and in case someone wants to build their own sampling percentage algo, they can using the same approach as we do for adaptive sampling. Adaptive sampling will be the default in config - that is enough, I think.
3. Re: decoupling sampling itself and "counting". this is, in fact, how adaptive sampling is done. It uses static sampling telemetry processor as is and one more processor - sampling percentage estimator ("counting" processor in your terms) plus a little bit of glue between them.
4. Re: Callback. Two clear scenarios are tracing and turning it into a metric/counter. The callback provides nice structured event that is very simple to subscribe to (unlike ETW).

from applicationinsights-dotnet.

Adaptive Sampling feature was implemented and included in 2.0.0-beta3 SDK version.

from applicationinsights-dotnet.