Unable to see the attributes under customdimenstions of Application insights when set the attributes using ILogger.BeginScope

Question

Unable to see the attributes under customdimenstions of Application insights when set the attributes using ILogger.BeginScope

Rayappa Bankapur (CSEC) 0

was trying to set attribute and its value using ILogger.BeginScope in Azure function. theory says when we set the attributes using ILogger.BeginScope, we can see those attributes under customdimensions section of Application insights. have tried and troubleshooted possible ways but don't see those attributes in Application insights. Is there proven steps/configurations? please share with me.

Fabian Zankl 345 Reputation points

2026-09-09T14:26:49.8133333+00:00
Hi @Rayappa Bankapur (CSEC) ,

Before proposing a fix, two details from your setup would narrow this down considerably, because the scope values from ILogger.BeginScope travel a different route depending on how the app is hosted and how it is connected to Application Insights.

Which hosting model is the app on: in-process (worker runtime dotnet) or isolated worker (dotnet-isolated)? If isolated, does Program.cs call AddOpenTelemetry(), AddApplicationInsightsTelemetryWorkerService(), or neither?

Open one of the affected rows in the traces table and check the value of customDimensions.Category.

The reason for the second question: in the isolated model, application logs by default go worker -> Functions host -> Application Insights, and only a direct integration in the worker changes that route (see Custom application logs). The Category value shows which route actually delivered the entry, and that determines whether the scope values were dropped on the way or never attached.

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Learn page linked above.

2 answers

Your answer

Fabian Zankl 345 Reputation points

2026-09-09T14:26:49.8133333+00:00

Hi @Rayappa Bankapur (CSEC) ,

Before proposing a fix, two details from your setup would narrow this down considerably, because the scope values from ILogger.BeginScope travel a different route depending on how the app is hosted and how it is connected to Application Insights.

Which hosting model is the app on: in-process (worker runtime dotnet) or isolated worker (dotnet-isolated)? If isolated, does Program.cs call AddOpenTelemetry(), AddApplicationInsightsTelemetryWorkerService(), or neither?

Open one of the affected rows in the traces table and check the value of customDimensions.Category.

The reason for the second question: in the isolated model, application logs by default go worker -> Functions host -> Application Insights, and only a direct integration in the worker changes that route (see Custom application logs). The Category value shows which route actually delivered the entry, and that determines whether the scope values were dropped on the way or never attached.

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Learn page linked above.

Answer 1

I reproduced this to see exactly what reaches Application Insights. In the .NET isolated worker, two things decide whether your scope values show up in customDimensions.

1. The log has to reach Application Insights at all

With AddApplicationInsightsTelemetryWorkerService(), the Application Insights logger only sends Warning and above by default. In my test, a LogInformation call inside a scope sent nothing at all, while LogWarning arrived with the scope values. The current func init template registers Application Insights but doesn't remove this rule, so new apps hit it straight away.

Remove the default rule in Program.cs:

var

2. Pass the scope as key/value pairs

What you pass to BeginScope decides how it's stored. These are the results from my test:

Scope passed to `BeginScope`	What appears in `customDimensions`
`Dictionary<string, object>`	Each key as its own field: `OrderId`, `CustomerId`

`Dictionary<string, object>`	Each key as its own field: `OrderId`, `CustomerId`
Message template: `BeginScope("Processing order {OrderId}", orderId)`	`OrderId` as its own field
Plain string: `BeginScope("OrderId=A-1001")`	One `Scope` field containing the text
Anonymous object: `BeginScope(new { OrderId = "A-1001" })`	One `Scope` field containing the text

So use a dictionary:

using

Then check in Application Insights:

traces
| where timestamp > ago(30m)
| where message == "Order received"
| project timestamp, message, customDimensions

You should see OrderId and CustomerId as separate entries in customDimensions.

If your app uses the in-process model (FUNCTIONS_WORKER_RUNTIME = dotnet), the logs go through the Functions host instead, and the keys may appear with a prop__ prefix, as Tejaswini mentioned.

Answer 2

Hello @Rayappa Bankapur (CSEC) ,

Thank you for reaching out to Microsoft Q & A!

There are a couple of common reasons why BeginScope values don't appear as individual customDimensions entries:

Verify the type passed to BeginScope. Application Insights expands scope values into custom properties only when the scope is an IReadOnlyCollection<KeyValuePair<string, object>> (for example, a dictionary). Otherwise, the scope is typically stored under a single Scope property. See: Application Insights logging scopes.

Verify the property name being queried. For Azure Functions in-process apps, custom properties are often prefixed with prop__. For example, MyKey may appear as customDimensions.prop__MyKey. Reviewing the raw customDimensions payload can help confirm how the properties are stored.

If using .NET isolated worker, verify that Application Insights is configured directly in the worker process, as scope properties may not be preserved when logs are relayed through the Functions host. See: Azure Functions isolated worker Application Insights guidance.

Could you confirm whether the Function App is running in-process or .NET isolated, and share a sample customDimensions payload from a trace where the scope values are expected?

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