Skip to content
Get Started for Free

Application Insights

Azure Application Insights is an application performance management (APM) service for monitoring live applications. It collects the requests, dependencies, exceptions, traces, and custom events your application sends, and stores them in the Log Analytics workspace the component is linked to. It’s commonly used to diagnose production issues and track custom business metrics. For more information, see What is Application Insights?.

LocalStack for Azure emulates Application Insights components: the telemetry your application sends to a component’s connection string lands in the App* tables of its Log Analytics workspace, and you query it through the classic Application Insights query API or through the workspace. The supported APIs are available on our API Coverage section, which provides information on the extent of Application Insights’ integration with LocalStack.

This guide is designed for users new to Application Insights and assumes basic knowledge of the Azure CLI and our lstk az proxy. It creates a component, sends it an event, and queries the event. The Azure CLI commands below use the application-insights extension, which the Azure CLI installs the first time you run an az monitor app-insights command.

Launch LocalStack using your preferred method. For more information, see Introduction to LocalStack for Azure. Once the container is running, enable Azure CLI interception by running:

Terminal window
lstk az start-interception

This command points the az CLI away from the public Azure management REST API and toward the LocalStack for Azure emulator API. To revert this configuration, run:

Terminal window
lstk az stop-interception

This reconfigures the az CLI to send commands to the official Azure management REST API.

Create a resource group and the Log Analytics workspace that stores the component’s telemetry:

Terminal window
az group create --name rg-insights-demo --location westeurope
Output
{
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-insights-demo",
"location": "westeurope",
...
"name": "rg-insights-demo",
"properties": {
"provisioningState": "Succeeded"
},
...
}
Terminal window
az monitor log-analytics workspace create \
--name ws-insights-demo \
--resource-group rg-insights-demo \
--location westeurope
Output
{
...
"customerId": "12e2d9a9-883e-4573-9eb7-168a976a8f29",
...
"location": "westeurope",
...
"name": "ws-insights-demo",
"provisioningState": "Succeeded",
...
"retentionInDays": 30,
"sku": {
...
"name": "PerGB2018"
},
...
}
Terminal window
WORKSPACE_RESOURCE_ID=$(az monitor log-analytics workspace show \
--workspace-name ws-insights-demo \
--resource-group rg-insights-demo \
--query id \
--output tsv)
WORKSPACE_ID=$(az monitor log-analytics workspace show \
--workspace-name ws-insights-demo \
--resource-group rg-insights-demo \
--query customerId \
--output tsv)

Create a component linked to the workspace:

Terminal window
az monitor app-insights component create \
--app my-app-insights \
--resource-group rg-insights-demo \
--location westeurope \
--kind web \
--application-type web \
--workspace "$WORKSPACE_RESOURCE_ID"
Output
{
"appId": "034fcc57-a90c-578a-b210-f71b31a874eb",
...
"applicationType": "web",
"connectionString": "InstrumentationKey=bf78997c-a6b6-5711-8d76-10d6fed82df6;IngestionEndpoint=https://applicationinsights.azure.localhost.localstack.cloud:4566/;LiveEndpoint=https://livediagnostics.azure.localhost.localstack.cloud:4566/;ApplicationId=034fcc57-a90c-578a-b210-f71b31a874eb",
...
"instrumentationKey": "bf78997c-a6b6-5711-8d76-10d6fed82df6",
"kind": "web",
...
"location": "westeurope",
"name": "my-app-insights",
...
"provisioningState": "Succeeded",
...
"workspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-insights-demo/providers/Microsoft.OperationalInsights/workspaces/ws-insights-demo"
}

The component’s connection string names its ingestion endpoint. On the emulator, it’s an emulator host your application and the containers the emulator runs can reach.

There is no az monitor app-insights component list command in the Azure CLI. Retrieve one component with component show, and list the components in the resource group with az resource list:

Terminal window
az monitor app-insights component show \
--app my-app-insights \
--resource-group rg-insights-demo
Output
{
"appId": "034fcc57-a90c-578a-b210-f71b31a874eb",
...
"name": "my-app-insights",
...
"provisioningState": "Succeeded",
...
"workspaceResourceId": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-insights-demo/providers/Microsoft.OperationalInsights/workspaces/ws-insights-demo"
}
Terminal window
az resource list \
--resource-group rg-insights-demo \
--resource-type Microsoft.Insights/components
Output
[
{
...
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-insights-demo/providers/Microsoft.Insights/components/my-app-insights",
...
"location": "westeurope",
...
"name": "my-app-insights",
...
"resourceGroup": "rg-insights-demo",
...
"type": "Microsoft.Insights/components"
}
]

Application Insights SDKs and the Azure Monitor OpenTelemetry distro send telemetry to the ingestion endpoint of the connection string. Read the instrumentation key and the ingestion endpoint into variables:

Terminal window
INSTRUMENTATION_KEY=$(az monitor app-insights component show \
--app my-app-insights \
--resource-group rg-insights-demo \
--query instrumentationKey \
--output tsv)
INGESTION_ENDPOINT=$(az monitor app-insights component show \
--app my-app-insights \
--resource-group rg-insights-demo \
--query connectionString \
--output tsv | sed -E 's/.*IngestionEndpoint=([^;]+).*/\1/')

Send a custom event to the endpoint, as an SDK does:

Terminal window
curl --silent --request POST "${INGESTION_ENDPOINT%/}/v2.1/track" \
--header "Content-Type: application/json" \
--data "[{\"name\": \"Microsoft.ApplicationInsights.Event\", \"time\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"iKey\": \"$INSTRUMENTATION_KEY\", \"data\": {\"baseType\": \"EventData\", \"baseData\": {\"ver\": 2, \"name\": \"OrderPlaced\", \"properties\": {\"orderId\": \"42\"}}}}]"
Output
{"itemsReceived": 1, "itemsAccepted": 1, "errors": [], "appId": null}

Query the event through the classic Application Insights query API, which uses the classic table names, such as customEvents:

Terminal window
az monitor app-insights query \
--apps my-app-insights \
--resource-group rg-insights-demo \
--analytics-query "customEvents | project name, customDimensions"
Output
{
"tables": [
{
"columns": [
{
"name": "name",
"type": "string"
},
{
"name": "customDimensions",
"type": "dynamic"
}
],
"name": "PrimaryResult",
"rows": [
[
"OrderPlaced",
"{\"orderId\":\"42\"}"
]
]
}
]
}

The same event is a row of the AppEvents table in the workspace:

Terminal window
az monitor log-analytics query \
--workspace "$WORKSPACE_ID" \
--analytics-query "AppEvents | project Name, Properties"
Output
[
{
"Name": "OrderPlaced",
"Properties": "{\"orderId\":\"42\"}",
"TableName": "PrimaryResult"
}
]

Retrieve the current billing features and daily data volume cap of the component:

Terminal window
az monitor app-insights component billing show \
--app my-app-insights \
--resource-group rg-insights-demo
Output
{
"currentBillingFeatures": [
"Basic"
],
"dataVolumeCap": {
"cap": 100.0,
"maxHistoryCap": 1000.0,
"resetTime": 0,
"stopSendNotificationWhenHitCap": false,
"stopSendNotificationWhenHitThreshold": false,
"warningThreshold": 90
}
}

Delete the component and confirm it no longer appears among the Microsoft.Insights/components of the resource group:

Terminal window
az monitor app-insights component delete \
--app my-app-insights \
--resource-group rg-insights-demo
Terminal window
az resource list \
--resource-group rg-insights-demo \
--resource-type Microsoft.Insights/components
Output
[]

Delete the resource group, which deletes the workspace and the telemetry it holds too:

Terminal window
az group delete --name rg-insights-demo --yes
  • Component lifecycle: Create, show, update tags, list, and delete Application Insights components, each with its instrumentation key, application ID, and connection string.
  • Telemetry ingestion: The v2/track and v2.1/track endpoints accept the telemetry SDKs send, gzipped or not, as a JSON array or one item per line, on the emulator’s own ingestion host and on Azure’s, and store each item in the App* table of the component’s workspace: AppRequests, AppDependencies, AppTraces, AppExceptions, AppEvents, AppMetrics, AppPageViews, AppAvailabilityResults, and AppBrowserTimings.
  • Classic query API: az monitor app-insights query and the classic query API answer KQL queries over the classic table names, such as requests, dependencies, traces, exceptions, and customEvents, mapped onto the workspace’s App* rows. See Kusto Query Language (KQL).
  • Diagnostic settings: A component’s diagnostic setting copies its telemetry to the App* tables of the workspace the setting names.
  • Billing feature configuration: Get and update billing features, such as the daily data volume cap.
  • No managed workspace: Azure links a component created without a workspace to a managed workspace it creates. The emulator creates none, so such a component accepts telemetry but keeps none of it, apart from the copies its diagnostic settings send.
  • No Live Metrics: The Live Metrics endpoints accept what SDKs post, but keep none of it.
  • No Profiler, Snapshot Debugger, or availability tests: Availability tests (Microsoft.Insights/webtests) are stored, but never run.
  • No continuous export: Continuous export to Storage isn’t supported.

The following sample demonstrates how to use Azure Application Insights with LocalStack for Azure:

17 of 61 operations implemented

Operation ▲Implemented ▼
Page 1 of 0
Was this page helpful?