No Application Insight logs after ev2 bicep migration

Hello @Sean Pyo ,

the application settings path is already covered in another answer on this thread, so this adds two things it doesn't touch: what the revert was able to restore and what it could not, and which filter is actually swallowing the traces.

About the revert
In incremental mode, when an existing resource is redeployed, all properties are reapplied. Properties that are missing from the template are reset to their default values - the resource definition in the template always represents the final state, never a partial update. Reverting the template therefore does restore the declared properties. What it cannot restore is a deleted resource: redeployment creates a new Application Insights component with a new connection string, and for a classic component the previously ingested data is gone as well. For a workspace-based component the data remains in the Log Analytics workspace. Once this has happened, the resource being queried may no longer be the one the application writes to.

Reference: Deployment modes - Azure Resource Manager

In the resource group's activity log, it's worth checking the following around the time of the migration:

• a Delete entry for Microsoft.Insights/components, followed by a Write
• whether the rollout ran in Complete mode

Cheapest check of all: compare APPLICATIONINSIGHTS_CONNECTION_STRING on the Function App against the current value on the component. If they differ, that alone explains the gap.

A pitfall that can occur specifically when switching from JSON to Bicep, provided the deployment runs in Complete mode: if a resource is guarded by a condition and the underlying parameter is no longer passed in the same way, the condition evaluates to false and the resource is deleted - depending on the REST API version used for the deployment, where 2019-05-10 or later deletes it and earlier versions do not. In Incremental mode it remains untouched. The template still reads as correct on review in both cases, and the revert repeats the same evaluation.

Reference: Deployment modes - Complete mode

Regarding the symptom
Does the issue affect all telemetry, or only ILogger traces? Run this in the Application Insights resource:

union *
| where timestamp > ago(2h)
| summarize count() by itemType

If requests and dependencies are still coming through and only the traces are missing, the cause lies on the application side, and the timing with the migration is likely coincidental. Worth knowing at that point: the host.json logLevel mentioned elsewhere in this thread governs host-emitted logs. If the app runs in the isolated worker model with the classic Application Insights integration rather than OpenTelemetry, the Application Insights logger inside the worker process applies its own filter, defaulting to Warning. The host and the worker have separate log level configuration, so host.json does not affect it.

Reference: Manage log levels

Hi @Sean Pyo

Since the issue started immediately after moving the deployment from ARM JSON to Bicep, I'd first compare the deployed Function App configuration, rather than the Bicep syntax itself. Reverting the deployment won't necessarily restore application settings that were overwritten or omitted during an earlier deployment.

For Azure Functions, Microsoft specifically requires the Function App to have the APPLICATIONINSIGHTS_CONNECTION_STRING application setting pointing to the Application Insights resource. Microsoft's current Bicep/ARM deployment examples explicitly configure this setting.

I would check Function App → Settings → Environment variables and verify that:

APPLICATIONINSIGHTS_CONNECTION_STRING

exists and contains the connection string for the expected Application Insights instance.

Then compare the Bicep appsettings resource against the previous ARM deployment. One common IaC migration problem is accidentally deploying an incomplete set of application settings, which can replace settings that previously existed.

Also check host.json, particularly:

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "default": "Information"
    }
  }
}

An overly restrictive logLevel can filter telemetry before it reaches Application Insights. Microsoft notes that entries filtered by host.json won't appear in Application Insights or other logging destinations.

If you've enabled the newer OpenTelemetry mode:

"telemetryMode": "OpenTelemetry"

the configuration path is slightly different, but APPLICATIONINSIGHTS_CONNECTION_STRING is still required when Application Insights is the telemetry destination.

I'd therefore compare these four things between the last known-good ARM deployment and the current Function App:

APPLICATIONINSIGHTS_CONNECTION_STRING

Function App application settings as a whole

host.json, especially logging/telemetry settings

The Application Insights resource/workspace referenced by the connection string

If you can share the Function App/appsettings portion of the old ARM template and new Bicep file with secrets removed, we should be able to spot whether the migration changed the Application Insights wiring.

Sharing you these references:

Microsoft Learn – Automate Function App resource deployment with Bicep/ARM | https://learn.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code?

Microsoft Learn – Configure monitoring for Azure Functions | https://learn.microsoft.com/en-nz/azure/azure-functions/configure-monitoring?

Microsoft Learn – Azure Functions application settings | https://learn.microsoft.com/en-nz/azure/azure-functions/functions-app-settings?

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.