2.4 Application Insights & Diagnostic Monitoring Design

Why This Topic Matters on AZ-305

This section is the second half of the split Recommend a monitoring solution bullet, focused on application-level observability rather than platform infrastructure. AZ-305 scenarios test whether you know when infrastructure-level Azure Monitor data (VM metrics, NSG flow logs) is insufficient and an Application Insights design is required to answer "is the problem in my code or in the platform underneath it?" — a distinction the exam metadata itself calls out as a defining design skill for this credential.

Core Concepts: Application Insights as an APM Layer

Application Insights is the Application Performance Monitoring (APM) feature of Azure Monitor. It is not a replacement for platform-level Azure Monitor — it is a complementary layer that instruments application code to answer questions platform metrics cannot: which specific dependency call is slow, which exception is spiking, and how a single user request traced across multiple services.

Two facts define a modern Application Insights design:

• Workspace-based resource model. Every current Application Insights resource stores its telemetry inside a Log Analytics workspace, using dedicated App* tables (AppRequests, AppDependencies, AppExceptions, AppTraces, AppEvents, AppMetrics, AppPageViews, AppAvailabilityResults, AppBrowserTimings, AppPerformanceCounters, AppSystemEvents). Each of these tables defaults to 90 days of free retention, independently adjustable.
• OpenTelemetry-based instrumentation. Microsoft's current recommended path for server-side apps (web apps, VMs, Azure Functions, AKS) is the Azure Monitor OpenTelemetry Distro, built on the vendor-neutral OpenTelemetry (OTel) standard, rather than the older classic per-language SDKs. Many platforms also support auto-instrumentation ("codeless") for zero-code data collection, while switching to the code-based Distro unlocks deeper configuration. Browser telemetry is the one major exception: client-side JavaScript still uses the dedicated Application Insights JavaScript SDK, which is not OpenTelemetry-based.

Key Application Insights Capabilities

Sampling: The Cost/Completeness Trade-off

High-traffic applications generate more telemetry than is cost-effective (or useful) to ingest in full. Application Insights supports:

• Adaptive sampling (the default) — automatically adjusts the volume of telemetry sent to hit a target ingestion rate, preserving proportional visibility without manual tuning.
• Fixed-rate sampling — a manually configured, constant percentage of telemetry is retained.

The architectural trade-off to recognize on the exam: sampling reduces both ingestion cost and the risk of throttling under load, but overly aggressive sampling can hide rare, high-value events such as an infrequent but critical exception. A production design for a high-traffic, cost-sensitive app typically defaults to adaptive sampling; a design where every failure must be captured (for example, a payment processing path) may instead exclude or minimize sampling on failure telemetry specifically.

A Diagnostic Settings Trap Specific to Application Insights

There is one Application Insights-specific constraint worth memorizing because it appears as a plausible-sounding wrong answer on architecture questions: a diagnostic setting on an Application Insights resource cannot target the same Log Analytics workspace that resource is already based on. Practically, if you need to also export Application Insights diagnostic data via a diagnostic setting (for example, to a Storage account or a different workspace for cross-tenant consolidation), the destination workspace must be a different one than the resource's own backing workspace, and the requesting user should not have simultaneous RBAC access to both, to avoid duplicate data appearing in queries.

Scenario Walkthrough

A multi-tier e-commerce application runs on Azure App Service (web tier) and Azure Kubernetes Service (order-processing tier). During a promotional sale, the team needs to determine whether checkout latency comes from application code or the underlying platform, needs an early warning if a payment API dependency starts failing, and must control ingestion cost given a 50x traffic spike. The correct design: instrument both tiers with the Azure Monitor OpenTelemetry Distro feeding a workspace-based Application Insights resource on the same Log Analytics workspace already used for platform-level diagnostic settings (so App* tables and infrastructure resource logs can be correlated in one KQL query); enable Application Map to visually separate app-code latency from platform latency; configure adaptive sampling to absorb the traffic spike economically while carving out an exception to fully capture payment-dependency failures; and layer a Smart Detection-derived alert rule plus an availability test hitting the checkout endpoint from multiple regions for synthetic uptime monitoring.

Key Takeaways

• Application Insights is Azure Monitor's APM layer for code-level visibility; it complements, not replaces, platform-level diagnostic settings and metrics.
• All current Application Insights resources are workspace-based, storing telemetry in App* Log Analytics tables with 90 days of free default retention.
• The Azure Monitor OpenTelemetry Distro is the current recommended server-side instrumentation path; browser telemetry still uses the separate JavaScript SDK.
• Adaptive sampling controls ingestion cost automatically; use fixed-rate sampling or sampling exclusions only when specific telemetry (like payment failures) must never be dropped.
• A diagnostic setting on an Application Insights resource cannot target its own backing Log Analytics workspace — remember this as a common wrong-answer trap.