Andrew Mercer
on this page

A workspace-based Application Insights resource exposes two identifiers that are easy to confuse: an instrumentation key (inside the connection string) and a Log Analytics workspace ID. They do different jobs, and a healthy resource has both.

Two identifiers, two jobs

The instrumentation key / connection string is the front door. It is how applications send telemetry to the Application Insights resource: the value the SDK, OpenTelemetry Distro or auto-instrumentation agent uses to say "this data belongs to this Application Insights component." It has always existed and still exists on workspace-based resources.

The Log Analytics workspace ID is the filing cabinet. It says where the telemetry is stored once it arrives. When Microsoft moved Application Insights to the workspace-based model, the backend storage changed from a proprietary per-resource store to a Log Analytics workspace. That is what gives you the App* tables and cross-resource querying via _ResourceId. The front-door ingestion mechanism stayed the same.

Telemetry flow

Application (OpenTelemetry Distro / SDK / auto-instrumentation)
    │
    │  authenticates with the connection string (contains the instrumentation key)
    ▼
App Insights ingestion endpoint
    │
    │  stores data in
    ▼
Log Analytics workspace (AppRequests, AppTraces, AppExceptions, ...)
    │
    │  surfaced back through
    ▼
App Insights query endpoint and portal (requests, traces, exceptions, ...)

Both must exist and be correctly linked for the resource to work, so finding an instrumentation key and a workspace ID on the same resource is the standard modern setup, not a misconfiguration.

Same data, two names

Because the data lives in the workspace but is also served through Application Insights, each telemetry type has two names depending on where you query it:

Query from Application Insights Query from the workspace
requests AppRequests
dependencies AppDependencies
exceptions AppExceptions
traces AppTraces
customEvents AppEvents
customMetrics AppMetrics
pageViews AppPageViews
availabilityResults AppAvailabilityResults

Column names differ too: for example timestamp becomes TimeGenerated and operation_Id becomes OperationId.

What would be unusual

  • A workspace-based resource with no instrumentation key or connection string. Nothing could send it data.
  • A classic (pre-workspace) resource with no workspace ID. Classic Application Insights was retired in February 2024 and remaining classic resources were migrated, so every resource should now report a workspace ID. One without is worth investigating.
  • An application configured with only the bare instrumentation key. It may still ingest, but technical support for instrumentation-key-only ingestion ended on 31 March 2025. Switch it to the full connection string, which also carries the regional ingestion endpoint.

Checking a resource

With the Azure CLI (application-insights extension):

az monitor app-insights component show \
  --app <app-insights-name> \
  --resource-group <resource-group> \
  --query "{connectionString: connectionString, instrumentationKey: instrumentationKey, workspace: workspaceResourceId, ingestionMode: ingestionMode}"

ingestionMode should be LogAnalytics and workspaceResourceId should point at the expected workspace.

See also