An ASP.NET Core app with the Application Insights SDK is producing bursts of telemetry that cause ingestion errors. You need to reduce telemetry volume and costs while ensuring HTTP request/response correlation remains possible. Which approach should you use?

Disabling adaptive sampling and enabling fixed-rate sampling directly addresses the problem of telemetry bursts and high volume. Adaptive sampling dynamically adjusts the sampling rate based on current telemetry volume, which can still lead to bursts during high-traffic periods. Fixed-rate sampling allows you to define a consistent percentage of telemetry to be sent, providing predictable volume control and cost management. Crucially, both adaptive and fixed-rate sampling preserve the correlation of HTTP requests and responses because they apply the sampling decision consistently across related telemetry items. Configuring a Log Analytics workspace DCR and KQL filter would process data after ingestion, meaning the full volume is still sent and incurs costs before filtering. Setting a daily cap on the Log Analytics workspace would simply stop collecting data once the cap is hit, leading to data loss rather than controlled reduction. Increasing the metric aggregation interval would reduce the frequency of metric reporting, but wouldn't address the volume of other telemetry types like traces or requests, and wouldn't prevent bursts.