Set up Application Insights

Your app is live on Azure, but you have no idea what's happening inside it. Requests are failing, latency is spiking, and you're left guessing which line of code is to blame. That's the exact pain this lesson kills: you'll learn how to set up Application Insights so every request, exception, and dependency call is tracked automatically, turning guesswork into a searchable, visual timeline of your app's behavior.

The problem this lesson solves

Debugging a distributed application without telemetry is like driving at night with your headlights off. You know something's wrong, but you can't see the road. In production, logs alone aren't enough—they're scattered, unstructured, and often missing the context you need to connect a slow response to a specific database query or an exception to a user's session.

Application Insights solves this by giving you a single pane of glass for requests, failures, dependencies, and custom events. Instead of SSH-ing into a VM to read log files, you get a live dashboard with request rates, response times, and failure counts—plus the ability to drill into a single operation's end-to-end trace.

Real-world symptoms this lesson addresses:

• Slow page loads with no clue which downstream call is the bottleneck
• Intermittent 500 errors that don't reproduce in development
• Silent dependency failures—e.g., a Redis cache that's down but the app just degrades
• No historical baseline—you can't tell if today's latency is better or worse than last week

By the end of this lesson, you'll not only have Application Insights set up, but you'll know how to use its core views to diagnose these problems.

Core concept / mental model

Think of Application Insights as a black-box flight recorder for your application. Just like an airplane records every instrument reading, your app sends telemetry about every significant event—requests, exceptions, dependencies, traces—to a central store. You can then query that store to reconstruct exactly what happened, second by second.

Here's the mental model:

• Instrumentation — you add a small SDK to your app that automatically captures events
• Ingestion — telemetry is sent over HTTPS to an Application Insights resource in Azure
• Storage & analytics — data is stored in a time-series database and exposed through the portal's query language (Kusto)
• Visualization — dashboards and charts let you spot trends, anomalies, and correlations

The key distinction from plain logging:

• Logs are messages; telemetry is structured events with properties, metrics, and parent-child relationships.
• Logs tell you what happened; Application Insights tells you why by linking a request to its dependencies and exceptions.
• Logs are often passive; Application Insights proactively maps the whole request path.

Pro tip: Application Insights is part of Azure Monitor. While Azure Monitor collects platform metrics (CPU, memory), Application Insights focuses on application-level telemetry. You'll often use both together.

Important terms you'll see throughout this lesson:

• Instrumentation Key (ikey) — a legacy identifier; now you should use the connection string which is more secure and includes the ingestion endpoint.
• Telemetry — the data points: requests, dependencies, exceptions, traces, metrics, page views.
• Sampling — a feature that reduces data volume by sending only a representative fraction of events.

How it works step by step

Setting up Application Insights is a three-phase process: create the resource, instrument your app, and verify data flows. Here's the logical flow:

1. Create an Application Insights resource

You need a place to send telemetry. This is a logical container that holds all your app's data. You choose a name, a resource group, and a region. The portal gives you a connection string that your app uses to authenticate and send data.

2. Instrument your application

The SDK does the heavy lifting. For Python, you use the opencensus-ext-azure package (or the newer azure-monitor-opentelemetry). The SDK hooks into your web framework (Flask, Django, FastAPI) and automatically tracks incoming requests and outgoing HTTP calls, database queries, and exceptions.

3. Configure the connection string

You set the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable (or use the azure-monitor-opentelemetry's configure_azure_monitor). The SDK reads this at startup and begins sending telemetry.

4. Verify telemetry

Make a few requests to your app, then check the Azure portal's Live Metrics or Application Insights blade to see requests coming in. If you see data, you're done.

The whole flow—create, instrument, configure, verify—is designed to be reversible. If you want to stop sending data, just remove the instrumentation or disable the resource.

Hands-on walkthrough

Let's get your hands dirty. We'll create a resource, instrument a simple Flask app, and verify telemetry.

Prerequisites

• An Azure subscription (free trial works)
• Python 3.8+ installed locally
• A terminal with az CLI installed and signed in

Step 1: Create the resource via CLI

Run this in your terminal:

az group create --name my-rg --location eastus
az monitor app-insights component create --app my-app-insights --location eastus --resource-group my-rg

The output includes the InstrumentationKey — but more importantly, you'll need the connection string. Get it with:

az monitor app-insights component show --app my-app-insights --resource-group my-rg --query connectionString -o tsv

Copy that value. You'll paste it into an environment variable.

Step 2: Instrument a Python app

First, install the OpenTelemetry-based SDK:

pip install azure-monitor-opentelemetry

Now write a minimal Flask app with auto-instrumentation:

# app.py
from flask import Flask
from azure.monitor.opentelemetry import configure_azure_monitor

# Configure telemetry before creating the app
configure_azure_monitor()

app = Flask(__name__)

@app.route("/")
def hello():
    return "Hello, Azure!"

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8000)

Run it with the connection string set:

export APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=YOUR_KEY;IngestionEndpoint=..."
python app.py

Note: The configure_azure_monitor() call automatically instruments Flask and many HTTP libraries. No manual code changes for basic request tracking.

Step 3: Send traffic and verify

In another terminal, hit your app a few times:

curl http://localhost:8000/
curl http://localhost:8000/

Now go to the Azure portal → your Application Insights resource → Live Metrics (under Investigate). You should see requests ticking up within seconds.

Step 4: Add a custom dependency call

Let's simulate a database call to see dependency tracking:

# app.py (continued)
import time
from flask import jsonify

@app.route("/slow")
def slow():
    time.sleep(0.5)  # Simulate a slow dependency
    return jsonify({"status": "ok"})

Restart the app, hit /slow a few times, and check Performance → Dependencies. You'll see a dependency named something like slow with a duration of ~500ms.

Expected output

After a few minutes, the Application Insights overview blade shows:

• Requests: count and success rate
• Server response time: average, median, and percentile
• Failed requests: count of non-2xx responses
• Dependencies: tracked outgoing calls

If you click on a request in Transaction search, you'll see a timeline with the request, its duration, and any associated exceptions or dependencies.

Compare options / when to choose what

There are several ways to route telemetry in Azure. Here's a comparison to help you decide:

When to choose what:

• Choose Application Insights SDK if you own the application code and want rich, auto-instrumented telemetry with minimal effort.
• Choose OpenTelemetry Collector if you have multiple services in different languages and want a unified pipeline with sampling and transformation.
• Choose Azure Monitor Agent for infrastructure-level metrics (CPU, disk) on VMs—but that doesn't replace app-level insights.
• Choose Log Analytics if you need to centralize logs from many sources beyond app telemetry.

For most Python web apps, the Application Insights SDK is the fastest path to value. Start there, and add the OpenTelemetry Collector only when you outgrow the built-in capabilities.

Pro tip: Application Insights also supports distributed tracing for microservices. If you instrument multiple services with the same SDK, a single transaction is linked across service boundaries—invaluable for debugging multi-tier architectures.

Troubleshooting & edge cases

Even with a simple setup, things can go wrong. Here are the most common issues and how to fix them.

No telemetry showing up in the portal

Symptoms: Live Metrics shows zero data; queries return empty.

Likely causes:

• Connection string is wrong or missing. Double-check the environment variable. The SDK logs a warning at startup if it can't find it.
• Firewall/network: The SDK needs outbound HTTPS to *.ingest.applicationinsights.azure.com. If your app runs behind a strict firewall, allow that domain.
• Sampling too aggressive: By default, Azure may apply adaptive sampling to reduce volume. Inexpensive for testing—use the Live Metrics view which bypasses sampling.
• SQL dependency not tracked: Some SQL drivers need explicit instrumentation. Check the SDK documentation and add a dependency import if needed.

Errors during SDK initialization

Symptom: ImportError: cannot import name 'configure_azure_monitor'

Fix: Make sure you installed azure-monitor-opentelemetry, not the older opencensus-ext-azure. The latter uses a different API. Uninstall and reinstall the correct package.

Duplicate telemetry

Symptom: Each request appears twice in the portal.

Fix: You probably instantiated the SDK twice—e.g., called configure_azure_monitor() in two modules. Call it only once at application startup.

Distorted metrics after scaling

Symptom: Response times seem wrong after running multiple instances.

Fix: Metrics are aggregated across instances by default. Use percentiles (e.g., 95th) instead of averages to get a realistic picture of user experience.

Wrong time zone in filters

Symptom: Queries show times in UTC instead of local.

Fix: In the portal, you can change the time zone in the query editor's settings. Or explicitly convert using KQL functions like datetime_utc_to_local.

What you learned & what's next

You've now got a working Application Insights setup that watches your app like a hawk. Let's recap the core ideas:

• The problem: Without telemetry, you're blind to production issues.
• The mental model: Application Insights is a black-box recorder that captures requests, dependencies, and exceptions.
• The steps: Create a resource → instrument your app → configure connection string → verify telemetry.
• The options: Use the native SDK for simplicity; OpenTelemetry Collector for advanced needs.
• The troubleshooting: Fix connection strings, sampling, and initialization issues.

You've also achieved the learning objectives:

• You can explain the core idea behind Application Insights—structured telemetry for your app.
• You've completed a practical exercise by instrumenting a Flask app and verifying telemetry in the portal.

What's next: In the next lesson, you'll learn how to set up alerts on your Application Insights metrics so you're notified the moment failures spike. That's the natural progression—first you see the data, then you act on it.