Application Insights: workspace-based, and where OpenTelemetry fits
Verdict: Workspace-based Application Insights buys cross-querying, longer retention and table-level RBAC. OpenTelemetry is the server-side path - the JavaScript SDK explicitly does not use it. On AKS, metrics belong to managed Prometheus, not Application Insights.
| Criterion | Application Insights | OpenTelemetry |
|---|---|---|
| What it is | APM: traces, dashboards, alerts on error and quality metrics | Instrumentation standard feeding Application Insights |
| Workspace-based gains | KQL cross-querying with Azure Monitor data; longer retention; table-level RBAC | Unaffected - transport, not storage |
| Functions setup | Bound via APPLICATIONINSIGHTS_CONNECTION_STRING | telemetryMode: OpenTelemetry in host.json; not supported for C# in-process |
| Where it does NOT apply | Node/pod counters (that is managed Prometheus with PromQL) | Browser: the JavaScript SDK does not use OpenTelemetry |
Rules
- Choose workspace-based Application Insights for cross-querying, longer retention and table-level RBAC - it does not add paired-region replication.
- Wire Functions to OpenTelemetry via telemetryMode in host.json plus the connection string setting - and know C# in-process is unsupported.
- For AI agents on Foundry: start tracing in Foundry, then add the Azure Monitor OpenTelemetry Distro - Application Insights carries the token, latency, error and quality dashboards.
- Node and pod CPU/memory counters as PromQL time series belong to managed Prometheus in an Azure Monitor workspace - not to Application Insights or Container Insights.
Traps
- The Application Insights JavaScript SDK does not use OpenTelemetry - browser instrumentation is its own path.
- Collapsing AKS metrics into Container Insights pays log-ingestion rates for high-cardinality counters and loses PromQL.