Glossary
Sampling
Keeping a representative fraction of telemetry instead of all of it, to cut ingestion volume and cost while keeping counts and percentiles statistically useful.
With sampling on, an SDK or agent keeps, say, one request in ten and records on each kept item how many it stands for. In Application Insights that number is the itemCount column, which is why queries should count with sum(itemCount) rather than count().
Good sampling keeps whole operations together: if a request is kept, so are its dependency calls, exceptions and logs, so the trace you open is complete. Application Insights has offered several flavours over time:
- Fixed-rate sampling keeps a set percentage. In the classic SDK the percentage must be close to 100/N for a whole number N (50, 33.3, 25, 20 and so on).
- Adaptive sampling (classic .NET SDK) adjusts the percentage to stay near a target rate of items per second.
- Rate-limited sampling in the OpenTelemetry-based distros caps traces per second; a percentage (ratio) sampler is the alternative.
- Ingestion sampling drops items at the service after they were sent, which saves storage cost but not network traffic.
Sampling is different from filtering. A filter drops items by rule (health checks, a noisy dependency) and leaves no itemCount trace behind, so counts become lower than reality; sampling keeps the totals recoverable. The sampling and cost calculator turns a daily cap into a sampling percentage.