Application Insights: Missing telemetry from FunctionApp-Investigation and Next Steps

Hi Jeff Hoffman & thx for join me at Q&A platform,

ur investigation already rules out several common causes. The key distinction is that successful ingestion from an external client doesn't prove connectivity from the actual Flex Consumption worker.

I'd recommend starting with Function App > Diagnose and solve problems and running the Connectivity Troubleshooter and Function App missing telemetry Application Insights or OpenTelemetry diagnostics.

For a direct worker-side test, temporarily execute this Python code inside a diagnostic function in the affected Function App

import socket
import ssl
host = "centralus-2.in.applicationinsights.azure.com"
socket.getaddrinfo(host, 443)
with socket.create_connection((host, 443), timeout=10) as tcp:
    with ssl.create_default_context().wrap_socket(
        tcp, server_hostname=host
    ):
        print("Application Insights DNS/TCP/TLS: OK")

Capture the result through your existing Function App diagnostic logging. This validates DNS, TCP 443, and TLS from the worker, although it doesn't test the Functions host's telemetry exporter itself.

For standard Functions host telemetry, Python 3.12 doesn't require an additional Application Insights or OpenTelemetry SDK. I also wouldn't attribute this to a known Python 3.12/Flex platform issue without supporting evidence.

If worker connectivity succeeds, I'd escalate the existing findings to Azure Functions support, requesting an investigation of the host telemetry-export pipeline. Include the Functions host version, worker instance identifiers, UTC execution timestamps, and host diagnostic logs.

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-functions/monitoring/functions-monitoring-appinsightslogs

Given the evidence you've collected, I wouldn't spend more time changing sampling or reinstalling Python telemetry packages.

Best regards,

Alex Burlachenko

💬 P.S. Did this help? Mark it as the solution: it keeps me motivated!

➕ Follow me on Q&A for more answers

📝 And feel free to visit my blog → https://ctrlaltdel.blog/

Likely cause: your backend Application Insights resource is healthy, but the Functions host -> AI ingestion path from Flex workers is the failing segment. Your evidence (successful synthetic ingest + confirmed executions + missing runtime telemetry categories) points to runtime emission/connectivity/config interaction, not a generic AI outage.

Confirmed vs possible:

1. Confirmed: AI ingestion endpoint accepts/stores telemetry when called directly.
2. Confirmed: Functions execute (platform metrics) and logs are loaded.
3. Possible: worker egress/DNS path to AI ingestion from Flex workers, host/runtime emission issue, or app-level telemetry pipeline conflict.

Recommended next steps:

1. Keep only one telemetry configuration path:
   • Prefer APPLICATIONINSIGHTS_CONNECTION_STRING.
   • Use APPLICATIONINSIGHTS_AUTHENTICATION_STRING=Authorization=AAD only when the managed identity has Monitoring Metrics Publisher on the AI resource.
2. Verify host-level logging categories and sampling in host.json (and any app-setting overrides of host.json values).
3. Validate outbound connectivity from the worker path used by Flex + VNet integration to AI ingestion endpoints over HTTPS/443.
4. Correlate by UTC window using:
   • Function executions (platform metrics)
   • AI tables (requests, traces, dependencies, exceptions)
   • Any dropped/failed telemetry indicators
5. If still reproducible, open Microsoft support with run IDs, UTC times, Flex plan details, region, connection/auth settings, and sanitized diagnostics proving “executes but no runtime telemetry emitted”.

Validation checks:

1. Trigger 3-5 controlled invocations after each config change.
2. Confirm appearance of at least requests and traces within expected ingestion delay.
3. If absent, capture current effective settings dump and attach to support case.

References:

• Configure monitoring for Azure Functions: https://learn.microsoft.com/en-us/azure/azure-functions/configure-monitoring
• App settings reference for Azure Functions: https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings
• Microsoft Entra authentication for Application Insights: https://learn.microsoft.com/en-us/azure/azure-monitor/app/azure-ad-authentication
• Azure Functions networking options: https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options
• Troubleshoot missing Application Insights telemetry: https://learn.microsoft.com/en-us/troubleshoot/azure/azure-monitor/app-insights/telemetry/asp-net-troubleshoot-no-data

“If you find this answer helpful, please upvote it. If this resolves your issue, please mark it as the accepted answer so that it can help others in the community.”

Hi @Jeff Hoffman , Thank you for reaching out to Microsoft Q&A portal. We connected and I'm glad that this is resolved.

Thanks for the detailed write-up. For anyone who hits the same symptoms, this is the troubleshooting sequence that applies to a VNet-integrated Function App that runs fine but sends no Application Insights telemetry.

Typical symptoms

• Functions execute successfully and show up in platform metrics.
• Function logs reach Log Analytics, but requests, traces and dependencies don't appear in Application Insights.
• A test call to the ingestion endpoint from outside the app (for example, Cloud Shell) works, so the Application Insights resource itself looks healthy.

Why external tests can mislead: A test from your own machine or Cloud Shell uses a different DNS and network path from the one your app uses. The app's VNet DNS settings and its outbound route decide whether it can reach the ingestion endpoint, and a successful external test doesn't prove that.

1. DNS resolution from the app's VNet

• Check whether the VNet is linked to a private DNS zone for privatelink.monitor.azure.com.
• Application Insights hostnames resolve through a chain of names that includes that zone. If the zone is linked but has no records for your resource, the lookup can fail with NXDOMAIN instead of falling through to public DNS.
• There are two ways to fix this:
  • Enable Fallback to internet on the virtual network link of the private DNS zone. Azure DNS then retries the lookup publicly when the private zone has no record.
  • Or use Azure Monitor Private Link (AMPLS) and make sure the private zone contains the required records.

2. Outbound network path

• Once DNS resolves, check whether the app's outbound traffic is forced through a firewall or NVA (for example, by a default route on the integration subnet).
• Make sure HTTPS on port 443 to the Application Insights ingestion endpoints is allowed on that path.
• Confirm that TLS inspection isn't interfering with the connection.
• Also allow the Live Metrics endpoints if you use Live Metrics. They're separate from ingestion.

3. Validate and retest

• Restart the Function App after changing DNS or firewall rules, because workers cache name resolution.
• Run a few invocations and wait a few minutes for telemetry to appear.
• If you can't run commands on the worker (Flex Consumption has no console), use a VM or a test app in the same VNet and subnet. Check DNS, TCP and TLS to the ingestion hostname in that order.

What resolved it in this scenario: Fixing DNS and then opening outbound HTTPS to the ingestion endpoints restored telemetry. The DNS fix alone wasn't enough, because the firewall was still closing the connection.

The relevant Learn articles are "Fallback to internet for Azure Private DNS zones" and "Azure Monitor endpoint access and firewall configuration."

If this answers your question, please accept the answer.

Hello @Jeff Hoffman

Your testing confirms that the Application Insights resource and ingestion endpoint can accept telemetry, but the synthetic test performed outside the Function App does not validate connectivity from the actual Flex Consumption worker. This requires the connectivity test to run from the application host.

For a VNet-integrated Function App, it requires outbound HTTPS/TCP 443 access to these Application Insights endpoints:

dc.applicationinsights.azure.com

dc.applicationinsights.microsoft.com

dc.services.visualstudio.com

*.in.applicationinsights.azure.com

This includes your regional centralus-2.in.applicationinsights.azure.com endpoint.

The supported next step is to open Function App > Diagnose and solve problems and run the “Function App missing telemetry Application Insights or OpenTelemetry” diagnostic workflow.

Test the DNS and HTTPS connectivity from the application host. If Flex Consumption does not expose an interactive worker console for this app, an external curl or synthetic-ingestion test is not an equivalent worker-path test. In that situation, Azure Support would need to inspect the worker’s DNS resolution, outbound connection to port 443, and Functions host telemetry-exporter logs.

Python 3.12 is supported on Flex Consumption. Flex Consumption also does not support pinning the Functions host through FUNCTIONS_EXTENSION_VERSION; it runs a platform-managed supported host version.

For standard Functions host telemetry, an explicit Python Application Insights or OpenTelemetry package is not required when using the built-in Application Insights integration. Application packages are required when the application itself emits custom telemetry or when you intentionally configure OpenTelemetry-based instrumentation.

Also, AppDependencies, AppExceptions, and AppEvents are not necessarily populated for every successful invocation. However, the complete absence of host request/trace telemetry while executions are confirmed is not expected under the documented configuration.

There's no verified official documentation identifying a known general issue specifically affecting standard Application Insights telemetry on Python 3.12 Flex Consumption in Central US.

Given the evidence already collected, I recommend opening an Azure support case and supplying:

• The two exact UTC invocation times.
• Function App, Application Insights, and Log Analytics resource IDs.
• The effective host.json and application settings.
• The Functions host initialization messages.
• The completed telemetry-flow diagnostic results.
• The regional ingestion hostname.
• Confirmation that the external ingestion test succeeded but that no test has yet run inside the actual worker.

Microsoft Support should specifically verify the worker’s telemetry-export pipeline and outbound path to centralus-2.in.applicationinsights.azure.com:443.

References:

Application Insights logs are missing or incorrect for Azure Function App

Troubleshoot missing application telemetry in Application Insights

Configure monitoring for Azure Functions

Azure Functions Flex Consumption plan

Target Azure Functions runtime versions

Microsoft Entra authentication for Application Insights

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.