How to reduce Application Insights telemetry from Azure Functions and understand daily caps

To reduce Azure Functions telemetry and control costs, use a combination of sampling, selective logging, and daily caps.

1. Configure sampling for Azure Functions

Sampling is the primary tool to reduce telemetry volume while keeping metrics statistically meaningful.

For Azure Functions, sampling is configured in host.json under logging.applicationInsights.samplingSettings. Sampling is enabled by default and can cause partial/missing logs if the rate is low.

Example default-style configuration (from the documentation):

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Key points:

• isEnabled: turn sampling on/off.
• maxTelemetryItemsPerSecond: cap the number of items; lower values reduce volume more aggressively.
• excludedTypes: telemetry types that are never sampled (for example, keep all Request and Exception items, but allow sampling of traces and dependencies).

To verify the effective sampling rate, use a query like:

union requests,dependencies,pageViews,browserTimings,exceptions,traces
| where timestamp > todatetime("mm/dd/yyyy hh:mm:ss") and timestamp < todatetime("mm/dd/yyyy hh:mm:ss")
| summarize TelemetrySavedPercentage = 100/avg(itemCount), TelemetryDroppedPercentage = 100-100/avg(itemCount) by bin(timestamp, 1d), itemType
| sort by timestamp asc

If TelemetrySavedPercentage < 100 for a type, that type is being sampled.

2. Tune what is logged (traces, requests, dependencies)

Use these levers together:

• Log levels and trace volume: Reduce noisy traces by lowering log levels in the Functions app so that only warnings/errors or selected information logs are written. This directly reduces entries in the traces table, which is often a major cost driver.
• Disable or limit specific auto-collected telemetry: For some SDKs (for example, Java agent), you can disable specific instrumentation or logging modules, or suppress telemetry for specific methods or health checks. While the example in context is Java, the pattern is the same: disable unneeded modules and suppress low-value telemetry to reduce traces and dependencies volume.
• Selective telemetry collection: Focus on essential telemetry in production (exceptions, key requests, and a subset of traces). Avoid excessive custom telemetry unless it provides clear value.

3. Use Application Insights cost-optimization practices

Recommended practices for Application Insights cost control include:

• Use sampling as the primary control to tune data volume.
• Disable unneeded modules and limit noisy logging (for example, host/general traces) using log levels.
• Limit custom metrics and use preaggregated OpenTelemetry metric instruments where applicable.
• Ensure workspace-based Application Insights is used so that features like Basic Logs, commitment tiers, and table-level retention can be applied.

If high ingestion is already occurring, the documented methods to reduce costs include:

• Adjust the daily cap configuration.
• Switch table plans (for example, use Basic Logs where appropriate).
• Use SDK features and sampling overrides to reduce specific tables such as traces and dependencies.

4. Daily caps: Application Insights vs Log Analytics workspace

The understanding of daily caps is correct:

• Application Insights daily cap
  • Configured per Application Insights resource.
  • Limits how much telemetry that specific Application Insights resource can ingest per day.
  • When the cap is reached, ingestion for that resource stops until the next day.
• Log Analytics workspace daily cap
  • Configured on the Log Analytics workspace.
  • Limits total data ingestion into that workspace per day, across all connected resources (including all Application Insights resources and other Azure Monitor data sources).
  • By default, the workspace daily cap is off; it must be explicitly enabled before adjusting the limit.

If multiple Application Insights resources send data to the same workspace:

• Each Application Insights resource’s own daily cap applies to that resource’s telemetry.
• The workspace daily cap applies to the aggregate of all data sent to the workspace.
• Once the workspace cap is reached, ingestion to that workspace stops for all connected resources, so all Application Insights resources using that workspace are affected.

5. How to use caps safely

• Use sampling and selective logging as the primary tools to stay within the free allowance and control costs.
• Use daily caps (on Application Insights and/or the workspace) as a last-resort safety net to prevent unexpected cost spikes, understanding that hitting a cap will create gaps in telemetry until the next day.

6. Summary configuration approach for Azure Functions

For each Function App:

1. Configure host.json sampling so that:
   • Exceptions and key requests are excluded from sampling.
   • Traces and dependencies are sampled to reduce noise.
2. Adjust log levels so that only important logs (for example, warnings/errors and selected information logs) are emitted.
3. Disable or suppress low-value auto-collected telemetry where supported by the SDK.
4. Optionally set an Application Insights daily cap per Function App resource.
5. Optionally set a Log Analytics workspace daily cap to protect against aggregate spikes across all apps.

This combination keeps telemetry useful (exceptions and key signals preserved) while limiting ingestion volume and helping stay within the free allowance.

References:

• Application Insights logs are missing or incorrect for Azure Function App
• Analyze Azure Functions telemetry in Application Insights
• Cost optimization in Azure Monitor
• Troubleshoot high data ingestion in Application Insights
• Daily cap unexpected behaviors in Application Insights
• Sampling in Azure Monitor Application Insights with OpenTelemetry
• Monitor executions in Azure Functions
• Understand and control costs