Live metrics

Hi @Sylvain Michel ,

Thanks for reaching out to Microsoft Q&A.

Update:

We found out that that we had update from "applicationinsights": "^2.9.5",to "applicationinsights": "^3.15.0",and looks like there is a glitch with an OpenTelemetry dependencies. We reverted to 2.9.5 and everything looks to be fine !!!!!!

Since you already see no restarts and KQL ingestion is continuous, next is to validate the app/container runtime health metrics are also steady:

• In the Azure portal, go to your Container App → Monitoring → Metrics
• Validate resource trends over time, especially:
  • CPU Usage
  • Memory (including Memory Percentage (Preview) if available)
  • Replica count and RestartCount (to confirm nothing is silently recycling)

Container Apps metrics are exposed through the Microsoft.App/containerapps namespace (and environment/runtime metrics through Microsoft.App/managedEnvironments). You can visualize these in Metrics explorer and also split by Replica/Revision using metrics explorer filters/splitting.

If pods/replicas were failing early in lifecycle (even briefly), Live Metrics could lose its active QuickPulse connections, while ingestion via the SDK could still appear “healthy” overall depending on buffering and polling behavior. If the application process isn’t created or traffic can’t enter the environment, some metrics may not appear but in your case telemetry ingestion looks fine, which is consistent with “app is actually running.”

1. Use “Diagnose and Solve Problems” to look for anything correlated with the Live Metrics disconnect windows

Even if KQL ingestion looks good, you want to correlate whether the platform thinks there were any issues around the time Live Metrics drops to 0.

• In the portal, open the container app and check Diagnose and Solve Problems
• Look for detectors related to runtime issues (the docs specifically mention cases like memory and other performance/health symptoms)
• Also confirm Environment Provisioning State and Managed Cluster Provisioning State are healthy, because the metrics troubleshooting guide notes that unhealthy provisioning can cause metrics emission failures.

2. Validate any network constraints that could affect Live Metrics streaming paths

Even if Application Insights ingestion is working (you’re seeing telemetry in KQL), Live Metrics connectivity can still be impacted by client-side or network path differences.

Check for:

• Outbound network restrictions (UDRs / outbound NSGs) that might block the specific Live Metrics streaming connectivity
• “Client-side network setups such as VPNs or other private/corporate networks” can affect access to Logstream (the doc explicitly mentions client-side network issues for logstream; it’s at least a strong hint to consider local network middleboxes for any live streaming channel)

If your Container Apps environment is integrated with restrictive networking, ensure outbound connectivity allows traffic to what the observability components need.

3. Consider metric/telemetry “source” configuration and timing differences

• Verify the application pod/container is actually running (metrics may be missing if lifecycle ends early)
• Validate upstream metric source configuration if metrics/logs are sent to external providers
• Initial enablement/switching between logging options can take up to ~15 minutes for data to appear

In your case, you likely don’t have onboarding-time issues (it’s 24/7), but it’s still worth confirming:

• The Application Insights SDK configuration version you’re using is correct (you listed [email protected])
• Any custom telemetry pipeline (if used) isn’t interfering specifically with QuickPulse/live streaming vs normal ingestion. Hope this helps!

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.