Application Insights and OpenTelemetry-aligned observability

Overview

Application Insights is the application performance monitoring feature of Azure Monitor. It helps teams monitor live applications by collecting requests, dependencies, exceptions, traces, metrics, availability results, and user behavior telemetry.

Modern Application Insights guidance is aligned with OpenTelemetry for supported server-side scenarios. OpenTelemetry provides a vendor-neutral model for traces, metrics, and logs. Azure Monitor provides the managed ingestion, analysis, dashboards, alerts, and Application Insights experiences.

For interviews, the important idea is not just "turn on Application Insights." A strong candidate should explain what is automatically collected, what must be instrumented manually, how trace context is propagated, how OpenTelemetry spans map to requests and dependencies, how sampling and cardinality affect cost, and how Application Insights supports incident investigation.

Core Concepts

Application Performance Monitoring

Application performance monitoring focuses on application behavior from the user's point of view and from the runtime's point of view.

Application Insights commonly helps answer:

• Is the application available?
• Are requests failing?
• Which routes are slow?
• Which dependencies are failing?
• Which exceptions increased after deployment?
• Which users or regions are affected?
• Which service in a distributed transaction caused the delay?

It is most valuable when it is connected to deployment, infrastructure, and business telemetry.

OpenTelemetry Alignment

OpenTelemetry defines vendor-neutral APIs, SDKs, semantic conventions, and exporters for observability telemetry.

Why it matters:

• Instrumentation is less tied to one vendor.
• Common libraries can emit standard spans and metrics.
• Trace context can flow across service boundaries.
• Teams can use the same concepts across cloud providers and tools.
• Migration and multi-tool strategies are easier.

In Azure, the Azure Monitor OpenTelemetry Distro is the recommended setup for most new code-based server-side Application Insights scenarios.

What Application Insights Collects

Depending on platform and instrumentation, Application Insights can collect:

• Incoming requests.
• Outgoing dependencies.
• Exceptions.
• Logs and traces.
• Custom metrics.
• Custom events.
• Page views and browser telemetry.
• Availability test results.
• Live metrics.
• Performance counters or runtime metrics.

Automatic collection is useful, but production systems usually need additional domain-specific metrics and logs.

Workspace-Based Application Insights

Modern Application Insights resources are workspace-based. Telemetry is stored in a Log Analytics workspace, which enables KQL queries, retention management, cross-resource queries, access control, and integration with other Azure Monitor features.

This matters because:

• Application logs and traces can be queried with other resource telemetry.
• Access can be controlled through workspace and table permissions.
• Retention and cost settings are managed at the workspace or table level.
• Dashboards and alerts can use KQL across related data.

Requests and Dependencies

An incoming HTTP request is typically represented as a server-side request span. Outbound calls are dependencies.

Examples of dependencies:

• SQL queries.
• HTTP calls to another service.
• Azure Service Bus sends or receives.
• Azure Storage operations.
• Redis calls.
• Cosmos DB calls.

Application Insights uses this data to build transaction timelines and application maps.

Exceptions and Failure Analysis

Exception telemetry helps identify the type, message, stack, affected operation, and frequency of failures.

Useful exception context includes:

• Operation name.
• Trace ID.
• Request route.
• Deployment version.
• Tenant or bounded customer segment.
• Dependency name.
• Retry attempt.
• Message or job ID.

Do not log secrets, tokens, full personal data, or raw request bodies just because an exception occurred.

Distributed Tracing

Distributed tracing links work across services. An API request might call another API, write to SQL, publish a Service Bus message, and later run a background handler.

The trace should show:

• Root operation.
• Child spans.
• Duration of each span.
• Errors.
• Dependency names.
• Attributes such as route, status code, and service name.

When trace context cannot be propagated automatically, pass an explicit correlation ID through message properties or headers.

.NET OpenTelemetry Setup

A simplified .NET setup often includes resource identity, ASP.NET Core instrumentation, HTTP client instrumentation, and Azure Monitor export.

builder.Services.AddOpenTelemetry()
    .UseAzureMonitor(options =>
    {
        options.ConnectionString =
            builder.Configuration["APPLICATIONINSIGHTS_CONNECTION_STRING"];
    });

Production setup usually also defines service name, service version, custom instrumentation, sampling, and logging integration.

Service Identity in Telemetry

Every service should emit consistent identity attributes:

service.name = checkout-api
service.namespace = commerce
service.version = 2026.06.18.1
deployment.environment = production
cloud.region = eastus

These fields make dashboards, application maps, and incident analysis much sharper. Without service identity, telemetry from different deployments can blur together.

Custom Spans

Automatic instrumentation does not know every business operation. Add custom spans around important work.

using var activity = activitySource.StartActivity("ReserveInventory");
activity?.SetTag("inventory.reservation_type", "standard");
activity?.SetTag("messaging.message_id", messageId);

await inventoryService.ReserveAsync(orderId, cancellationToken);

Use bounded tags. Avoid high-cardinality or sensitive values unless there is a clear diagnostic purpose.

Custom Metrics

Custom metrics should describe business or application health.

Examples:

• Checkout attempts.
• Payment authorization failures.
• Queue processing latency.
• Cache hit ratio.
• Background job success rate.
• Documents scanned per minute.

Use metrics for trends and alertable signals. Do not create a metric dimension for every user or order.

Logs and OpenTelemetry

OpenTelemetry can collect logs in supported scenarios, but many .NET applications still think in terms of ILogger. The important design principle is consistent structured fields and correlation.

logger.LogWarning(
    "Payment authorization failed for order {OrderId} with provider {Provider}",
    orderId,
    providerName);

The message template creates structured fields that can be queried later. Correlation should connect the log to the active trace.

Application Map

Application Map visualizes components and dependencies. It helps identify:

• Which services call each other.
• Which dependency has high failure rate.
• Which component is slow.
• Whether a failure is localized or widespread.

Application Map is only as good as the telemetry identity and dependency tracking. Ambiguous service names create ambiguous maps.

Live Metrics

Live metrics provide near real-time visibility into request rate, failure rate, dependency behavior, and server health. They are useful during deployments and active incidents.

Live metrics are not a long-term analysis store. Use metrics, logs, and traces for historical investigation and reporting.

Availability Tests

Application Insights availability tests are synthetic checks that call HTTP or HTTPS endpoints from configured locations.

They help detect:

• Public endpoint downtime.
• Slow response.
• TLS certificate problems.
• Region-specific connectivity issues.
• Broken critical dependencies when the test exercises them.

Use current Standard tests for availability monitoring. Classic URL ping tests are retired on September 30, 2026, so new designs should not depend on them.

Browser Telemetry

Browser telemetry can track page views, client-side exceptions, performance, and user behavior. Browser Application Insights currently uses the JavaScript SDK rather than OpenTelemetry.

Be careful with:

• Personal data.
• Query strings.
• User identifiers.
• Session tracking.
• Client-side sampling.
• Consent and privacy requirements.

Client telemetry should complement server telemetry, not replace it.

Sampling and Cost

Application telemetry can be high volume. Sampling reduces ingestion, but bad sampling can hide rare failures.

Recommended thinking:

• Keep errors and slow operations.
• Sample high-volume successful requests if needed.
• Keep enough successful traffic for comparison.
• Understand how sampling affects counts and metrics.
• Monitor SDK or exporter drops and ingestion failures.

Cost control should never silently remove the evidence needed for incidents.

Migration from Classic SDKs

For new applications, prefer OpenTelemetry-based instrumentation where supported. Classic Application Insights SDKs may still exist in older applications, but migration planning matters.

An interview answer should mention:

• Avoid mixing incompatible instrumentation paths blindly.
• Preserve operation names and correlation behavior.
• Validate dashboards and alerts after migration.
• Compare telemetry volume and sampling behavior.
• Keep business-critical custom telemetry.

Security and Privacy

Observability data can be sensitive. Treat it as production data.

Controls include:

• Redaction before ingestion.
• Workspace access control.
• Table-level access where needed.
• Retention policies.
• Private networking or firewall configuration where required.
• Avoiding secrets in attributes, logs, and exception details.

Telemetry should help operations without becoming a data leak.

Common Mistakes

• Assuming automatic instrumentation captures business health.
• Not setting service name and version.
• Forgetting async message correlation.
• Creating high-cardinality custom metric dimensions.
• Logging raw request bodies.
• Sampling away all interesting failures.
• Not validating telemetry after deployment.
• Building alerts on noisy implementation details.
• Treating Application Insights as only a dashboard tool.
• Using legacy instrumentation for new apps without a reason.

Best Practices

• Use Azure Monitor OpenTelemetry Distro for new supported server-side apps.
• Set consistent service identity attributes.
• Instrument key business operations manually.
• Propagate trace context across HTTP, messaging, and background work.
• Use structured logs and bounded tags.
• Protect sensitive data before ingestion.
• Create availability tests for critical endpoints.
• Build dashboards around user impact, dependencies, and recent deployments.
• Alert on symptoms and SLOs, not every exception.
• Review telemetry gaps after incidents.