.NET 8 Isolated Azure Functions – Duplicate Logs in App Insights / Log Analytics

Question

Hello,

I am using .NET 8.0 isolated Azure Functions with Application Insights enabled for logging.

App Insights is connected to a Log Analytics workspace.

Issue:

• Each function invocation appears duplicated in Log Analytics.
• Logs are duplicated for every run.
• The OperationId and timestamp are identical across the duplicates.

Environment details:

• Runtime: .NET 8.0 isolated Azure Functions
• Logging: Application Insights → Log Analytics workspace
• No custom telemetry initializers or sampling configured

Expected behavior:

• Each function invocation should produce a single set of logs.

Actual behavior:

• Duplicate entries are created in Log Analytics for every invocation.

Questions:

• Is this a known issue with .NET 8 isolated functions and App Insights integration?
• Could this be due to misconfiguration in the telemetry pipeline?
• How can I prevent duplicate logs and ensure accurate monitoring?

Any guidance or confirmation would be appreciated.

Duplicate invocations

Duplicate Logs

Each Invocation Its duplicated logs

Answer 1

Hello Vigneshwaran Balu (EXT),

your .NET 8 isolated Function is sending the exact same telemetry twice into the same Log Analytics workspace—once from the Functions host and once from your worker/App Insights pipeline (or once via App Insights→LA and again via a resource Diagnostic Setting). Because both pipelines stamp logs with the same OperationId and timestamp, you see perfect duplicates.

Here’s how to eliminate the dupe:

Pick a single ingestion path

• Host-only integration (the default): • Remove any direct SDK calls (e.g. AddApplicationInsightsTelemetryWorkerService() / ConfigureFunctionsApplicationInsights() in Program.cs). • Keep your Application Insights connection string or instrumentation key in the Function App settings.
  • Worker-only integration (direct SDK in isolated process): • In your Function App’s Application Settings, remove the APPINSIGHTS_INSTRUMENTATIONKEY or portal-configured AI connection so the host doesn’t auto-stream. • Keep your AddApplicationInsightsTelemetryWorkerService() + ConfigureFunctionsApplicationInsights() calls in Program.cs.
    • Diagnostics-only (Azure Monitor Diagnostic Setting): • If you’re using the Function App’s “Diagnostics” blade to send FunctionAppLogs into your workspace, disable that setting and rely on the above AI pipeline instead.
    Double-check your settings

    - Ensure you’re not setting both `APPINSIGHTS_INSTRUMENTATIONKEY` *and* `APPLICATIONINSIGHTS_CONNECTION_STRING`. Only the connection string is preferred.
    
       - Confirm you don’t have a Diagnostic Setting on the Function resource sending *FunctionAppLogs* into the same workspace that App Insights is already feeding.
    
       Validate it went away Run a quick Kusto query in Log Analytics to find any ops with more than one record per minute:
    
       ```sql
       union requests, traces
    

| summarize cnt = count() by operation_Id, bin(timestamp, 1m) | where cnt > 1 ```

           If you only see `cnt == 1`, you’ve successfully removed the duplicate stream.
           

Follow-up questions if you’re not sure:

• Do you have any Azure Monitor Diagnostic Settings on the Function App resource sending FunctionAppLogs/FunctionAppMetrics to the workspace?
• Did you manually wire up Application Insights in Program.cs (with AddApplicationInsightsTelemetryWorkerService() / ConfigureFunctionsApplicationInsights()) and also set the AI key/connection string in App Settings?
• Which Functions runtime version are you on, and what hosting plan (Consumption, Premium, Dedicated)?

That should get you back to a single, accurate set of invocation logs.

Reference docs: • Application Insights logs missing or incorrect: https://learn.microsoft.com/troubleshoot/azure/azure-functions/monitoring/functions-monitoring-appinsightslogs • .NET isolated process + App Insights guide: https://learn.microsoft.com/azure/azure-functions/dotnet-isolated-process-guide?tabs=ihostapplicationbuilder%2Ccode%2Clinux#application-insights • Troubleshoot Azure Function App Log Analytics: https://learn.microsoft.com/azure/azure-functions/monitor-functions-reference#supported-resource-logs-for-microsoftwebsites • Application Insights Duplicate logs deep dive: https://supportability.visualstudio.com/AzureAppService/_wiki/wikis/AzureAppService/1215633/Azure Function App/Monitoring resources, using metrics, logs and alerts/Application Insights/Application Insights Duplicate logs • Troubleshooting duplicate records in Azure Monitor Logs: https://learn.microsoft.com/azure/azure-monitor/logs/get-started-queries#why-am-i-seeing-duplicate-records-in-azure-monitor-logs

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

 

Answer 2

This behavior matches a known pattern where the same request or operation is tracked twice by two different telemetry pipelines.

In Azure Functions, the host process already emits request and trace telemetry for each invocation. If the worker process (the .NET 8 isolated app) is also instrumented with its own request-tracking or telemetry pipeline, each invocation is reported twice with the same OperationId and nearly identical timestamps.

Relevant points from the documentation:

• The host automatically emits request telemetry for triggers such as HTTP, Service Bus, and others.
• When the worker process is also instrumented with request tracking libraries (for example, via additional OpenTelemetry/Azure Monitor instrumentation), “the same request is reported twice” as duplicate request telemetry.
• OperationId in Azure Functions comes from the incoming traceparent. If multiple telemetry emitters use the same traceparent, all items share the same OperationId, which is what appears in the screenshots.

To prevent duplicate logs and ensure accurate monitoring:

1. Avoid double-instrumenting the worker:
   • Do not add additional request-tracking instrumentation (for example, Azure Monitor Distro, AspNetCoreInstrumentation, or a second telemetry pipeline) inside the worker when using the built-in Functions host telemetry.
   • Use the Functions-provided Application Insights integration (for isolated worker, AddApplicationInsightsTelemetryWorkerService() plus ConfigureFunctionsApplicationInsights()) as the single telemetry path.
2. If OpenTelemetry/Azure Monitor Distro is currently enabled in the worker, remove or disable it:
   • The guidance explicitly states to avoid using the Azure Monitor distro in the worker process because it typically includes request instrumentation that causes duplicate request telemetry.
3. After configuration changes, validate in Application Insights / Log Analytics:
   • Use a query like requests | where timestamp > ago(30m) to confirm that each invocation now appears only once.

This is therefore not a fundamental issue with .NET 8 isolated Functions themselves, but with overlapping telemetry instrumentation. Ensuring only one request-tracking pipeline (the Functions host + standard isolated worker integration) is active will remove the duplicates.

---

References:

• Use OpenTelemetry with Azure Functions (programming-language-csharp)
• Use OpenTelemetry with Azure Functions (programming-language-java)
• Use OpenTelemetry with Azure Functions (programming-language-powershell)
• Guide for running C# Azure Functions in the isolated worker model
• Analyze Azure Functions telemetry in Application Insights
• Diagnostics in Durable Functions