You cannot fix what you cannot see, and in production you cannot see anything without help.

The problem of invisible software

When software runs on a developer’s laptop, you can watch it, pause it and poke at it. When it runs in the cloud for thousands of users, it becomes invisible. It runs on servers you never touch, across several services, under traffic you cannot predict. Errors happen for some users and not others. A page loads fast in the morning and slowly at night. A new release quietly breaks one rarely used feature. Without monitoring, you learn about all of this from angry emails.

Application performance monitoring, usually shortened to APM, is the practice of collecting information about how an application behaves while it runs, so that teams can detect problems early, find their causes quickly, and understand how people use the product. Application Insights is Azure’s APM service. It is a feature of Azure Monitor, Microsoft’s broader platform for collecting and analyzing data about cloud and on-premises systems.

What it can tell you

Understanding the family tree prevents a lot of confusion about names and billing.

Azure Monitor is the umbrella. It collects metrics, which are numbers measured over time, and logs, which are detailed records of events, from Azure resources, applications, virtual machines and containers. Log Analytics is the storage and query engine for logs inside Azure Monitor. A Log Analytics workspace is a container in your subscription where log data is kept and queried. Application Insights is the application-focused part of Azure Monitor, with a special set of features and tables for application telemetry.

flowchart TD
  AM["Azure Monitor"] --> M["Metrics"]
  AM --> L["Logs in Log Analytics workspace"]
  AM --> AI["Application Insights features"]
  AI --> T["Application telemetry tables in the workspace"]
  L --> T
  AM --> AL["Alerts and action groups"]
  AM --> W["Workbooks and dashboards"]
        

Workspace-based Application Insights

Earlier versions of Application Insights kept their data in a separate private store. Today, a resource is created as workspace-based, meaning its telemetry is stored in a Log Analytics workspace that you choose. This has important consequences. You can query application data together with infrastructure and platform logs in one place. You can apply workspace-level security, retention, data export and cost controls. And billing follows the workspace pricing model. The older classic form has been retired and migrated, so any new resource should be workspace-based.

Telemetry is data sent automatically from a running application to a monitoring service.

The three pillars of observability

Modern monitoring talks about three pillars: logs, which are detailed event records; metrics, which are aggregated numbers over time; and traces, which follow a single request through many components. Application Insights stores all three in the same place and lets you jump between them. You may notice a spike in a metric, drill into the traces of slow requests, and read the logs around one failing step.

A short journey with several places where data can be lost or delayed.

sequenceDiagram
  participant APP as Application with instrumentation
  participant BUF as Local buffer
  participant ING as Ingestion endpoint
  participant WS as Log Analytics workspace
  participant PORT as Portal, alerts and queries
  APP->>BUF: Create telemetry items
  BUF->>ING: Send batches over HTTPS
  ING->>WS: Validate and store
  WS->>PORT: Available for queries and alerts
  Note over APP,PORT: Typical delay is seconds to a few minutes
        

There is more than one way to switch monitoring on, and the choice affects control, effort and future flexibility.

What OpenTelemetry means for you

OpenTelemetry is an open industry standard, supported by many vendors, for generating and exporting telemetry. Using it means your instrumentation is not locked to a single vendor. You can send the same data to Azure Monitor today and to additional destinations later if needed. Because it is a community standard, it also benefits from many ready-made integrations with popular libraries and frameworks.

The connection string

Every Application Insights resource has a connection string: a small piece of text that tells instrumentation where to send data. It includes the ingestion address and an identifier for the resource. Older setups used a bare instrumentation key, which has been phased out for ingestion in favor of connection strings, so use the connection string in all new configuration. Store it in application settings rather than in code, and use a separate resource, or at least a separate role name, for each environment.

One click by a user may touch ten services. Tracing stitches them into one story.

Modern applications are rarely a single program. A request to place an order might pass through a web front end, an orders service, an inventory service, a payment service and a database. When something is slow, which one is guilty? Distributed tracing answers this by giving each request a unique identifier that travels with it through every service. Each service records its own piece of the work, called a span, tagged with the shared identifier, so that the whole journey can be reassembled later.

flowchart LR
  U["User request"] --> W["Web front end"]
  W --> O["Orders service"]
  O --> I["Inventory service"]
  O --> P["Payment service"]
  O --> D["Orders database"]
  P --> X["External payment provider"]
        

Correlation across messaging and background work

Not every call is a direct web call. Messages through queues, scheduled jobs and event streams break the simple chain. To keep correlation, the sender must attach the trace context to the message and the receiver must read it. Many libraries do this automatically for common services; for custom setups you must check that context is propagated, otherwise the trace appears to end at the queue.

Two views that turn a pile of records into a picture.

Application map

The application map draws your system automatically as boxes and arrows. Each box is a component, such as a service or a database, and each arrow is a call between them. It shows call counts, average durations and failure rates on each connection, and colors problem areas. When an alert fires, the map is often the fastest way to see which component is the source and which are merely suffering from it.

flowchart LR
  A["Web app: healthy"] --> B["Orders API: slow"]
  B --> C["Inventory API: healthy"]
  B --> D["SQL database: high duration"]
  B --> E["Payment API: failing calls"]
  E --> F["External provider: timeouts"]
        

End-to-end transaction diagnostics

When you pick one specific request, this view shows a timeline of everything that happened for it, across services: the incoming call, each dependency call with its duration, any exceptions and related log messages. You can see at a glance that, for example, four seconds of a five-second request were spent waiting for one external call.

The two most common reasons you open Application Insights.

The failures view

This view groups failed requests, failed dependency calls and exceptions, and ranks them by how many occurred and how many users were affected. You can see which result codes dominate, which operations fail most, and which exception types are most frequent. Selecting an item takes you to sample records and to the transaction timeline.

The performance view

This view shows the duration of each operation, often at several percentiles. A percentile describes the experience of the slowest portion of requests. For example, the ninety-fifth percentile is the duration under which ninety-five percent of requests complete, so the remaining five percent are slower. Averages hide pain: a service with a pleasant average can still leave a noticeable group of users waiting several seconds. Looking at high percentiles reveals this.

Common root causes

Sometimes seconds matter, and a few minutes of delay is too long.

Live Metrics shows what your application is doing right now with a delay of about a second. It displays request rates, failure rates, response times, dependency calls, exceptions, and server health such as processor and memory use, across all the instances. You can also see a live stream of sample requests and traces. This is not the place for historical analysis; it is the place to watch a deployment roll out, a load test run or an incident unfold.

Internal telemetry cannot report that your application is completely unreachable, because a dead application sends nothing.

If your application crashes entirely, or its web address stops resolving, it cannot tell you. Availability tests solve this by acting like a user from outside: at regular intervals, from several locations around the world, they call your application and record whether it responded correctly and how fast. If several locations fail, an alert is triggered.

flowchart LR
  T1["Test location: Europe"] --> A["Your application"]
  T2["Test location: Asia"] --> A
  T3["Test location: Americas"] --> A
  A --> R["Results stored in Application Insights"]
  R --> AL["Alert if multiple locations fail"]
        

Design guidance

Test the important journeys, not just the home page. A home page may load while login, search or checkout is broken. Use a dedicated, lightweight health endpoint that checks critical dependencies, but do not make it so heavy that frequent testing overloads the system. Alert when several locations fail at once to avoid false alarms from a single regional network issue. Make sure the test runs against the same address the real users use, including any gateway or content delivery layer.

Monitoring tells you the app works; usage analytics tells you whether anyone cares.

With browser and custom event telemetry, Application Insights can reveal how people use the product. These views help product teams make decisions with evidence rather than opinions.

Custom events with care

Define a small, meaningful set of events named after business actions, such as “checkout completed”, and attach useful properties such as plan type or feature name. Avoid sending personal information in event names or properties. Document your event catalog so that different teams use consistent names; inconsistent naming makes funnels and comparisons unreliable.

When the built-in views are not enough, you can ask your own questions.

All telemetry in the workspace can be queried with the Kusto Query Language, usually called KQL. It reads like a pipeline: start with a table, then filter, group, count, sort and chart step by step. Because everything is in one workspace, one query can combine application data with data from virtual machines, databases and platform services, which makes cross-cutting investigations possible.

Questions that KQL answers well

Metrics are numbers over time, cheap to store and fast to alert on.

Custom metrics: use with discipline

Custom metrics are powerful, but each unique combination of metric name and dimension values can create a separate series, and a high number of series raises cost and slows queries. Use dimensions with a small, bounded set of values, such as region or tier, and never use identifiers that are different for every user or request as a dimension.

Dashboards help when someone is looking. Alerts help when nobody is.

Types of alerts

flowchart LR
  A["Telemetry"] --> B["Alert rule evaluates condition"]
  B -->|Condition met| C["Action group"]
  C --> D["Email or mobile push"]
  C --> E["Chat message to team channel"]
  C --> F["Incident tool or ticket"]
  C --> G["Automation such as scale out or restart"]
        

Designing alerts that people trust

Turn queries into shared, living reports.

A workbook is an interactive report built from text, queries, charts, tables and parameters. It is more flexible than a simple dashboard: you can offer drop-down selectors for environment or time range, link visuals so that clicking one filters another, and tell a story with headings and explanations. Azure dashboards, in contrast, are collections of tiles for a quick overview, suitable for wall displays or a daily glance. Many organizations also bring Application Insights data into external visualization tools used by operations teams.

Sometimes you know a request is slow or failing but not which line of code is responsible.

Collecting everything is expensive. Collecting smartly is usually enough.

Busy applications can produce a huge volume of telemetry. Sampling reduces it by keeping only a percentage of items while preserving statistical accuracy. The system keeps related items together, so if a request is kept, its dependencies and exceptions are kept too, which means traces remain complete. Metrics that were pre-aggregated before sampling stay exact.

flowchart TD
  A["Telemetry volume too high or too costly"] --> B{"Can you change the application?"}
  B -->|Yes| C["Use adaptive or fixed-rate sampling in the SDK"]
  B -->|No| D["Use ingestion sampling or collection rules"]
  C --> E["Filter noisy items such as health probes"]
  D --> E
  E --> F["Keep errors and slow requests at higher fidelity"]
  F --> G["Set a daily cap as a safety net"]
        

Telemetry can contain sensitive details, so treat it as sensitive data.

Who can see and send data

flowchart LR
  A["Application in virtual network"] --> B["Private endpoint"]
  B --> C["Azure Monitor private link scope"]
  C --> D["Application Insights and Log Analytics workspace"]
  E["Public internet"] -.->|Blocked when public access is disabled| D
        

Protecting personal data

Telemetry can accidentally capture sensitive details: email addresses in request addresses, names in exception messages, tokens in headers, card numbers in log text. Prevent it at the source: avoid logging sensitive values, mask or remove them using processors before sending, and review custom properties during code review. Also set retention appropriate to your policies, and know how to delete data if a person exercises a privacy right.

How you organize resources decides how easy investigation, access control and billing will be.

Separate production from the rest

Send development and test telemetry to different resources, or at least different workspaces, from production. This keeps test noise out of production dashboards and alerts, allows different retention and cost controls, and prevents test data from triggering real on-call pages.

Retention and archiving

Telemetry is kept for a retention period that you configure. Newer workspace-based setups include a default period for application tables at no extra retention charge, with longer interactive retention and low-cost archive options available at additional cost. Check current limits and prices. Keep detailed data only as long as it is useful for investigation, usually weeks to a few months, and archive or export summaries for long-term trend and audit needs.

Monitoring bills grow quietly. Understand what you pay for and steer it.

The main cost is data ingestion: you pay by the amount of data stored in the workspace, measured in gigabytes. Retention beyond the included period, archive storage, certain test types, alert evaluations and queries on some data plans add smaller charges. Commitment tiers, where you agree to a daily volume in exchange for a lower per-gigabyte price, can reduce cost for steady high volumes. Pricing details change, so check the current official pricing page before budgeting.

Monitoring is most valuable when it connects to how teams already work.

flowchart LR
  A["Deployment pipeline"] -->|Release annotation| B["Application Insights"]
  B --> C["Alert fires"]
  C --> D["Team chat channel"]
  C --> E["On-call incident tool"]
  C --> F["Automation: scale or roll back"]
  B --> G["Create work item from exception"]
        

When telemetry does not show up, follow a checklist from the application outward.

Habits that make monitoring valuable, and habits that make it noise.

Patterns worth adopting

Anti-patterns to avoid

A review list before going to production and at regular intervals afterward.

How teams use Application Insights day to day.

Short answers to common beginner questions.

It is the application performance monitoring feature of Azure Monitor, collecting requests, dependencies, exceptions, logs, metrics and usage data so that you can detect, diagnose and understand problems and behavior in running applications.

Modern Application Insights resources are workspace-based, which means telemetry is stored in a Log Analytics workspace. You can query it with the same language and combine it with other logs.

Not always. Many hosting platforms offer auto-instrumentation through a setting. For custom events, filtering and finer control, you add a library to your application.

It is a piece of text that tells instrumentation where to send telemetry. It replaces the older instrumentation key for ingestion. Keep it in configuration and use a different one per environment.

It follows one request across many services by passing a shared identifier, so that all the work done for that request can be reassembled and viewed as a single timeline.

Usually because services share the same cloud role name. Give each service a distinct role name so that they appear as separate components.

Sampling is probably active. Detailed records are reduced, while standard metrics are pre-aggregated and remain accurate, so use metrics for counts and rates.

Use availability tests that call your application from several locations, and alert when several locations fail. A dead application cannot report its own absence.

Find the top sources of volume, filter noise such as health probes, apply sampling, lower production log verbosity, consider commitment tiers where they fit, and alert on sudden increases.

Yes, using a private link scope for Azure Monitor and private endpoints, optionally with public access disabled and identity-based ingestion. Plan DNS and exceptions carefully.

Treat telemetry as sensitive. Avoid logging personal data or secrets, redact before sending, restrict access, and set retention according to your policies and regulations.

Microsoft has been steering new work toward the OpenTelemetry-based approach, with auto-instrumentation as a quick start. Check the current recommendation for your language before deciding.

The concepts are stable, but features, test types, SDK recommendations, table names, pricing and retirement dates change. Confirm details in the current official documentation before finalizing a design.

Application Insights gives your applications a dashboard, a diagnostic port and a bell. Instrumentation collects requests, dependencies, exceptions, logs, metrics and usage data. That data travels to a Log Analytics workspace, where built-in views such as the application map, failures, performance and live metrics help you see what is happening, and the query language lets you ask any question you can think of. Distributed tracing connects the work of many services into a single story. Availability tests watch from the outside, and alerts tell the right people at the right time. Sampling, filtering and sensible retention keep cost under control, while role-based access, identity-based ingestion, redaction and private networking keep the data safe. Because Azure Monitor and its standards keep evolving, hold on to the lasting ideas in this guide and verify the details in current documentation. With those habits, monitoring stops being a cost and becomes the way your team ships with confidence.