Appinsights Instrumentation
MicrosoftOfficialCreated by Microsoft
- Skill
- Tool integration
- Cloud and DevOps
- MIT
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill serves as a comprehensive reference for developers looking to integrate Azure Application Insights into their web applications. It provides structured guidance on telemetry patterns, SDK configuration, and environment-specific setup requirements. The skill emphasizes best practices for observability, including when to leverage auto-instrumentation versus manual code modifications, and provides references for various programming languages and hosting environments.
What it does
- Explains concepts and best practices for Application Insights instrumentation.
- Provides guidance on selecting between auto-instrumentation and manual SDK integration.
- Offers reference material for configuring telemetry in ASP.NET Core, Node.js, and Python applications.
- Details the process for creating Application Insights resources via Bicep or Azure CLI.
- Provides quick references for OpenTelemetry SDKs and exporters.
- Outlines environment-specific observability strategies for Azure-hosted applications.
When to use it
- When you need to understand how to instrument a web application for monitoring.
- When you are researching telemetry patterns for Azure-hosted services.
- When you need specific SDK setup instructions for supported languages.
- When you need to determine the best instrumentation approach for your hosting environment.
Advantages
- Centralized reference for Azure Application Insights patterns and configurations.
- Clear distinction between automated and manual instrumentation workflows.
- Supports multiple programming languages and Azure hosting environments.
- Promotes modern configuration practices like using environment variables over deprecated files.
Usage examples
- “How do I manually instrument my Node.js app for Application Insights?”
- The agent provides the necessary steps to modify your Node.js code, including SDK installation and configuration patterns for Azure Monitor.
- “What are the best practices for instrumenting an ASP.NET Core app in Azure?”
- The agent explains the recommended approach using the Azure Monitor OpenTelemetry library and environment variables for connection strings.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/microsoft/appinsights-instrumentation/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip appinsights-instrumentation.zip -d .agents/skills
Documentation by Microsoft
AppInsights Instrumentation Guide
This skill provides guidance and reference material for instrumenting webapps with Azure Application Insights.
⛔ ADDING COMPONENTS?
If the user wants to add App Insights to their app, invoke azure-prepare instead. This skill provides reference material—azure-prepare orchestrates the actual changes.
When to Use This Skill
User asks how to instrument (guidance, patterns, examples)
User needs SDK setup instructions
azure-prepare invokes this skill during research phase
User wants to understand App Insights concepts
When to Use azure-prepare Instead
User says "add telemetry to my app"
User says "add App Insights"
User wants to modify their project
Any request to change/add components
Prerequisites
The app in the workspace must be one of these kinds
An ASP.NET Core app hosted in Azure
An Azure Container App
A Node.js app hosted in Azure
A Python app hosted in Azure
Guidelines
Collect context information
Find out the (programming language, application framework, hosting) tuple of the application the user is trying to add telemetry support in. This determines how the application can be instrumented. Read the source code to make an educated guess. Confirm with the user on anything you don't know. You must always ask the user where the application is hosted (e.g. on a personal computer, in an Azure App Service as code, in an Azure App Service as container, in an Azure Container App, etc.).
Prefer auto-instrument if possible
If the app is a C# ASP.NET Core app hosted in Azure App Service, use AUTO guide to help user auto-instrument the app.
Manually instrument
Manually instrument the app by creating the AppInsights resource and update the app's code.
Create AppInsights resource
Use one of the following options that fits the environment.
Add AppInsights to existing Bicep template. See examples/appinsights.bicep for what to add. This is the best option if there are existing Bicep template files in the workspace.
Use Azure CLI. See scripts/appinsights.ps1 for what Azure CLI command to execute to create the App Insights resource.
No matter which option you choose, recommend the user to create the App Insights resource in a meaningful resource group that makes managing resources easier. A good candidate will be the same resource group that contains the resources for the hosted app in Azure.
Modify application code
If the app is an ASP.NET Core app, see ASPNETCORE guide for how to modify the C# code.
If the app is a Node.js app, see NODEJS guide for how to modify the JavaScript/TypeScript code.
If the app is a Python app, see PYTHON guide for how to modify the Python code.
SDK Quick References
OpenTelemetry Distro: Python | TypeScript
Platform-Specific Guides
Container Apps: Observability Guide
Files
- ATTRIBUTION.mdAdded by AutoGineer1.1 KiB
- LICENSE.txt1.1 KiB
- SKILL.md3.7 KiB
- examples/appinsights.bicep759 B
- references/aspnetcore.md1.7 KiB
- references/auto.md891 B
- references/container-apps.md7.2 KiB
- references/nodejs.md1.8 KiB
- references/python.md1.8 KiB
- references/sdk/azure-monitor-opentelemetry-exporter-java.md1.1 KiB
- references/sdk/azure-monitor-opentelemetry-exporter-py.md963 B
- references/sdk/azure-monitor-opentelemetry-py.md880 B
- references/sdk/azure-monitor-opentelemetry-ts.md986 B
- scripts/appinsights.ps1Script1.2 KiB
references/container-apps.md
Container Apps Observability
Observability guide for apps running in Azure Container Apps.
Environment-Level Log Analytics
By default, Container Apps environments use a Log Analytics workspace. Configure it at environment creation (--logs-workspace-id expects the workspace Customer ID (GUID), not the ARM resource ID):
WORKSPACE_ID=$(az monitor log-analytics workspace show \
--resource-group <rg> --workspace-name <workspace-name> \
--query customerId -o tsv)
WORKSPACE_KEY=$(az monitor log-analytics workspace get-shared-keys \
--resource-group <rg> --workspace-name <workspace-name> \
--query primarySharedKey -o tsv)
az containerapp env create \
--name <env-name> \
--resource-group <rg> \
--logs-workspace-id $WORKSPACE_ID \
--logs-workspace-key $WORKSPACE_KEY \
--logs-destination log-analytics💡 Tip: All apps in the same environment share the workspace. Use
--logs-destination noneonly for BYOB (bring-your-own-backend) scenarios.
System Logs vs Application Logs
| Log Table | Content | Retention |
|---|---|---|
ContainerAppConsoleLogs_CL | stdout/stderr from containers | Workspace default |
ContainerAppSystemLogs_CL | Platform events (scaling, restarts, image pulls) | Workspace default |
⚠️ Note: The
_CLsuffix and_scolumn suffixes apply to the Log Analytics destination. Environments using the newer Azure Monitor destination useContainerAppConsoleLogs/ContainerAppSystemLogs(no_CL, no_ssuffixes). Check your environment's log destination to use the correct table name.
System logs capture events outside your code—replica scheduling, health probe results, and revision activation. Console logs capture everything your app writes to stdout/stderr.
Built-in Metrics
Container Apps exposes these metrics without any SDK:
| Metric | Description | Dimensions |
|---|---|---|
Replicas | Current replica count | revision |
Requests | HTTP request count | statusCode, statusCodeCategory, revision, replica |
UsageNanoCores | CPU usage per replica | revision, replica |
WorkingSetBytes | Memory usage per replica | revision, replica |
RestartCount | Container restart count | revision, replica |
RxBytes / TxBytes | Network I/O | revision, replica |
⚠️ Warning: Built-in metrics cover infrastructure only. For request-level tracing, response times, and dependency tracking, add Application Insights SDK.
Application Insights SDK Setup
Set APPLICATIONINSIGHTS_CONNECTION_STRING as an environment variable on the container app, then add the SDK per language:
| Language | Package | Init Pattern |
|---|---|---|
| Node.js | @azure/monitor-opentelemetry | Call useAzureMonitor() before app startup |
| Python | azure-monitor-opentelemetry | Call configure_azure_monitor() at entry |
| .NET | Azure.Monitor.OpenTelemetry.AspNetCore | builder.Services.AddOpenTelemetry().UseAzureMonitor() |
| Java | Agent JAR (manual) | Set JAVA_TOOL_OPTIONS=-javaagent:/agent/applicationinsights-agent.jar |
# Store as a secret (recommended — keeps value out of az show output and portal config)
az containerapp secret set -n <app-name> -g <rg> \
--secrets "appinsights-conn=<conn-string>"
az containerapp update \
--name <app-name> \
--resource-group <rg> \
--set-env-vars "APPLICATIONINSIGHTS_CONNECTION_STRING=secretref:appinsights-conn"Distributed Tracing Across Microservices
Container Apps with multiple services need correlation. The OpenTelemetry SDK propagates traceparent headers automatically through HTTP calls. Ensure:
Every microservice has the SDK initialized with the same Application Insights resource
HTTP clients use instrumented libraries (e.g.,
requestsin Python,fetch/axiosin Node.js)Verify end-to-end traces in the Application Map blade
💡 Tip: Use
operation_Idin KQL queries to trace a single request across all services.
Dapr Observability
For apps using Dapr sidecars, Dapr generates tracing spans for service invocation, pub/sub, and state operations when tracing is configured. Note that samplingRate: "1" means 100% sampling — consider lowering for production workloads.
Configure Dapr tracing in the Container Apps environment. The YAML below represents the config spec — in ACA, apply it via az containerapp env dapr-component set or ARM/Bicep (not as a raw YAML file):
# Dapr tracing config spec (apply via CLI or Bicep, not raw kubectl)
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
tracing:
samplingRate: "1"
otel:
endpointAddress: "<otlp-collector-endpoint>"
isSecure: true
protocol: grpc⚠️ Note:
endpointAddressshould point to an OpenTelemetry Collector (not Application Insights directly). Configure the collector with the Azure Monitor exporter to forward traces to App Insights.
Dapr generates spans for:
Service invocation — caller → Dapr sidecar → target sidecar → target app
Pub/sub — publisher → broker → subscriber
Bindings — input/output binding operations
ARG Queries — Monitoring Status
Discover Container Apps and their monitoring configuration:
// Container Apps without App Insights configured (checks all containers)
resources
| where type == "microsoft.app/containerapps"
| mv-expand container = properties.template.containers
| mv-expand envVar = container.env
| where isnotempty(envVar)
| summarize hasAppInsights = countif(envVar.name == "APPLICATIONINSIGHTS_CONNECTION_STRING") by name, resourceGroup
| where hasAppInsights == 0Note: This query only covers apps with existing environment variables. Apps with no env vars are excluded by the
mv-expandand should be identified separately (e.g., filter for containers whereenvis null or empty).
KQL Query Library
Console log errors
ContainerAppConsoleLogs_CL
| where Log_s contains "error" or Log_s contains "exception"
| project TimeGenerated, ContainerAppName_s, RevisionName_s, Log_s
| order by TimeGenerated desc
| take 50Replica restart events
ContainerAppSystemLogs_CL
| where EventSource_s == "ContainerAppController" and Reason_s == "Restarting"
| summarize restarts = count() by ContainerAppName_s, RevisionName_s, bin(TimeGenerated, 1h)
| order by TimeGenerated descScaling events
ContainerAppSystemLogs_CL
| where Reason_s in ("ScalingUp", "ScalingDown")
| project TimeGenerated, ContainerAppName_s, Reason_s, Log_s
| order by TimeGenerated descConsole log volume by revision
ContainerAppConsoleLogs_CL
| where isnotempty(Log_s)
| summarize logCount = count() by RevisionName_s, bin(TimeGenerated, 5m)
| render timechartRequest latency by instance (requires Application Insights SDK)
requests
| where cloud_RoleName has "<app-name>"
| summarize avgDuration = avg(duration), p95 = percentile(duration, 95) by cloud_RoleInstance, bin(timestamp, 5m)
| render timechart💡 Tip: Console logs don't contain latency data. For request-level latency and dependency analysis, query the
requestsanddependenciestables from Application Insights.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs Python
Security
What our scanner noticed· Low risk
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Microsoft
- Publisher
- Microsoft (Official)
- Source
- microsoft/skills · .github/plugins/azure-skills/skills/appinsights-instrumentation · commit 0696600
- Licence
- MIT License (redistribution allowed)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Also distributed in
- microsoft/azure-skills
AutoGineer is not affiliated with or endorsed by Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download appinsights-instrumentation.zip