Azure Application Insights for Web App Performance Monitoring

Application Insights is the application performance management (APM) feature inside Azure Monitor, purpose-built for watching live web applications rather than infrastructure. Once an app is instrumented, it automatically captures request rates, response times, exception traces, dependency calls to external services, and real user behavior. Its telemetry lands in a Log Analytics workspace, so the same KQL queries you’d run against infrastructure logs can also dig into application data.

What Application Insights actually monitors

Where Azure Monitor’s core metrics and logs cover infrastructure — VM CPU, storage throughput, resource-level diagnostic logs — Application Insights covers the application layer: how the code itself is behaving in production. A small instrumentation package (an SDK, or auto-instrumentation depending on the platform) added to an application’s code is what turns on this telemetry stream. Once enabled, it starts capturing:

• Request rates and response times for incoming traffic
• Exception counts and stack traces when something fails
• Page load times and other client-side, real-user telemetry
• Outbound calls the application makes to other services

It’s described as “extensible” because developers can layer custom telemetry — application-specific events, business metrics — on top of what’s collected automatically, which is what lets teams spot performance anomalies that a generic infrastructure metric would never surface.

Core diagnostic features

Four Application Insights capabilities come up repeatedly, each solving a distinct diagnostic question:

Availability tests. These send synthetic test requests to a web application’s public endpoints from multiple points of presence around the world, on a recurring schedule, to confirm the app is reachable and responding within an acceptable time. This is an outside-in check — it tells you what a real visitor in another region would experience, which internal telemetry alone can’t. Pair an availability test with an alert and you get automatic notification the moment a checkout page (or any public endpoint) becomes unreachable or slow, from anywhere in the world.

Live Metrics Stream. When you need to watch a running application during an active deployment or a live debugging session, Live Metrics Stream shows performance counters, request traffic, and failures with roughly a one-second delay — far faster than waiting for data to be processed and ingested into standard logs. It’s built for momentary, in-session observation, not historical analysis; nobody uses Live Metrics Stream to review last week’s traffic.

Dependency tracking. When an application calls an external REST API or database, dependency tracking records the timing and success/failure of each of those outbound calls. If a team suspects an intermittent failure is coming from a third-party service the app depends on — rather than a bug in the app’s own code — dependency tracking is what isolates the outbound call as the culprit.

Application Map. This renders a visual diagram of how an application’s components — front end, database calls, external dependencies — connect to each other, and highlights where slow or failing calls are occurring along those connections. It’s the fastest way to see architecture-level trouble at a glance, rather than reading through individual request traces one at a time.

Feature	Latency	Best for
Live Metrics Stream	~1 second	Watching a live deployment or active debugging session
Availability tests	Scheduled (minutes)	Confirming global endpoint reachability, outside-in
Standard charts/queries	Minutes (ingestion delay)	Historical analysis and trend investigation
Dependency tracking	Same as standard telemetry	Isolating failures in external calls

How it connects to Log Analytics

Application Insights telemetry isn’t a walled-off dataset — it’s stored in a Log Analytics workspace, the same store used for infrastructure logs elsewhere in Azure Monitor (see Azure Monitor: metrics, logs, and alert rules for how that workspace works generally). That means a KQL query can correlate an application exception spike with a recent deployment event or an infrastructure log entry, all in one place, rather than switching between separate tools with separate query languages. Application Insights hasn’t replaced Log Analytics, and the two haven’t merged into one indistinguishable thing — they’re complementary layers of the same platform, application telemetry sitting on top of the same storage and query engine everything else uses.

Choosing the right tool for the job

A recurring exam pattern presents several distinct governance and monitoring needs at once and asks you to match each to its purpose-built tool, without swapping roles:

• Application exceptions and performance anomalies → Application Insights
• Underused reserved capacity or other cost/configuration recommendations → Azure Advisor
• Planned maintenance or incidents affecting Azure services in your subscription → Azure Service Health
• Mandatory tagging or other organizational rule enforcement → Azure Policy

Application Insights only owns the first of those. It has no mechanism to flag underused reservations, and Advisor’s periodic best-practice suggestions are a completely different cadence from Application Insights’ continuous, live telemetry — mixing them up is a common wrong-answer trap.

How the AZ-900 exam tests this

• Diagnosing intermittent failures. A stem describes a web app that fails intermittently and suspects an external dependency. The tested skill is recognizing that dependency tracking (timing and success/failure of outbound calls) and reviewing captured exception traces are the two legitimate diagnostic techniques — not editing a policy definition or renaming a resource group, which are unrelated governance actions dressed up as plausible distractors.
• Real-time vs. historical needs. When a stem emphasizes watching something happen “as it occurs,” “within seconds,” or “during a live deployment,” that phrasing points at Live Metrics Stream. When it emphasizes external reachability “from multiple regions” on a recurring basis, that points at availability tests instead — don’t confuse the two just because both sound like uptime monitoring.
• Tool-matching questions. Expect scenarios bundling Application Insights alongside Advisor, Service Health, and Policy, asking you to assign each need to the correct tool. The trap answers swap two of the four roles.
• APM identification. Direct recall questions ask what Application Insights fundamentally is: an application performance management (APM) feature of Azure Monitor for live web apps — not a network-hardware monitor, not a cost dashboard, and not a resource-lock mechanism.

Quick reference

• Application Insights is Azure Monitor’s APM feature: request rates, response times, exceptions, and dependency calls for live web applications.
• Availability tests run synthetic checks from multiple global locations on a schedule — an outside-in reachability check.
• Live Metrics Stream shows near-real-time (~1 second) telemetry, built for active debugging and live deployments, not historical review.
• Dependency tracking isolates failures in outbound calls to external APIs and databases.
• Application Map visualizes component-to-component connections and highlights slow or failing calls.
• Application Insights telemetry is stored in a Log Analytics workspace, queryable with KQL alongside infrastructure logs.
• Application Insights covers application-level exceptions and performance; it does not do cost recommendations (Advisor), incident status (Service Health), or rule enforcement (Policy).

Once you can tell Live Metrics apart from availability tests and dependency tracking on sight, see the full AZ-900 study guide for how this fits into all three exam domains, then practice AZ-900 questions that mix Application Insights scenarios with the rest of the Azure Monitor family to lock the distinctions in.