Generated banner for Appinsights Instrumentation
Generated logo for Appinsights Instrumentation

Appinsights Instrumentation

MicrosoftOfficialCreated by Microsoft

  • Skill
  • Tool integration
  • Cloud and DevOps
  • MIT
  • Low risk
  • Has scripts

From the author

Guidance for instrumenting webapps with Azure Application Insights. Provides telemetry patterns, SDK setup, and configuration references. WHEN: how to instrument app, App Insights SDK, telemetry patterns, what is App Insights, Application Insights guidance, instrumentation examples, APM best practices.
— the description by Microsoft

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

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/microsoft/appinsights-instrumentation/download
  2. Unzip 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

Platform-Specific Guides

Files

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 none only for BYOB (bring-your-own-backend) scenarios.

System Logs vs Application Logs

Log TableContentRetention
ContainerAppConsoleLogs_CLstdout/stderr from containersWorkspace default
ContainerAppSystemLogs_CLPlatform events (scaling, restarts, image pulls)Workspace default

⚠️ Note: The _CL suffix and _s column suffixes apply to the Log Analytics destination. Environments using the newer Azure Monitor destination use ContainerAppConsoleLogs / ContainerAppSystemLogs (no _CL, no _s suffixes). 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:

MetricDescriptionDimensions
ReplicasCurrent replica countrevision
RequestsHTTP request countstatusCode, statusCodeCategory, revision, replica
UsageNanoCoresCPU usage per replicarevision, replica
WorkingSetBytesMemory usage per replicarevision, replica
RestartCountContainer restart countrevision, replica
RxBytes / TxBytesNetwork I/Orevision, 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:

LanguagePackageInit Pattern
Node.js@azure/monitor-opentelemetryCall useAzureMonitor() before app startup
Pythonazure-monitor-opentelemetryCall configure_azure_monitor() at entry
.NETAzure.Monitor.OpenTelemetry.AspNetCorebuilder.Services.AddOpenTelemetry().UseAzureMonitor()
JavaAgent 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:

  1. Every microservice has the SDK initialized with the same Application Insights resource

  2. HTTP clients use instrumented libraries (e.g., requests in Python, fetch/axios in Node.js)

  3. Verify end-to-end traces in the Application Map blade

💡 Tip: Use operation_Id in 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: endpointAddress should 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 == 0

Note: This query only covers apps with existing environment variables. Apps with no env vars are excluded by the mv-expand and should be identified separately (e.g., filter for containers where env is 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 50
Replica 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 desc
Scaling events
ContainerAppSystemLogs_CL
| where Reason_s in ("ScalingUp", "ScalingDown")
| project TimeGenerated, ContainerAppName_s, Reason_s, Log_s
| order by TimeGenerated desc
Console log volume by revision
ContainerAppConsoleLogs_CL
| where isnotempty(Log_s)
| summarize logCount = count() by RevisionName_s, bin(TimeGenerated, 5m)
| render timechart
Request 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 requests and dependencies tables 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 or Microsoft.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download appinsights-instrumentation.zip