You cannot fix what you cannot see.

Modern applications are rarely a single program on a single machine. A typical web shop might involve a browser, a front-end web service, several back-end services, a database, a cache, a payment provider and a message queue. When a user clicks a button and waits too long, the delay could hide in any of those places. Observability is the ability to understand what is happening inside such a system by looking at the data it produces, and telemetry is the name for that data: requests handled, calls made, errors thrown, timings measured and messages logged.

Application Insights is the application performance monitoring capability of Azure Monitor. It collects telemetry from your application, stores it, and gives you tools to search it, chart it, trace requests end to end, detect problems automatically and send alerts. It works for web applications and back-end services written in many languages, running in Azure, on premises or in other clouds.

It answers a handful of everyday questions that every team asks. Is the application up? Is it fast enough? Which pages or operations fail most? Where is the time going inside a slow request? What are users actually doing? Which dependency is dragging everything down? Without a tool like this, answering any of them means reading raw log files on several machines, which does not scale.

Monitoring versus debugging

People sometimes treat it as a debugging tool, and it certainly helps with that. But its larger value is operational. It tells you about problems before customers complain, shows trends over weeks, and gives product teams evidence about how features are used. Think of it as three tools in one: a health monitor, an investigation microscope and a usage report.

Application Insights is a feature of Azure Monitor, not a separate island.

Azure Monitor is the umbrella platform for collecting and analysing data about Azure resources, operating systems and applications. Application Insights is the part focused on the application layer. Understanding how the pieces relate removes a lot of confusion, especially around where your data actually lives and how it is billed.

flowchart LR
  A["Your application"] --> B["Instrumentation: agent or OpenTelemetry"]
  B --> C["Ingestion endpoint using connection string"]
  C --> D["Application Insights resource"]
  D --> E["Log Analytics workspace"]
  E --> F["Investigation tools: maps, failures, performance, search"]
  E --> G["Queries, workbooks and dashboards"]
  E --> H["Alerts and action groups"]
        

Notice that the workspace sits in the middle of everything. Because telemetry lands in a Log Analytics workspace, you can query it together with data from other Azure services, apply the same retention and access rules, and build combined dashboards. Older, so-called classic Application Insights resources that kept data in their own separate store have been retired in favour of this workspace-based design.

A small vocabulary unlocks every screen and every query.

Application Insights organises what it collects into a handful of telemetry types. Each one answers a different question. Learn them once and the portal, the documentation and the query tables will all make sense.

Four words that glue telemetry together

What you run, what Azure runs and what sits in between.

Viewing the solution as a chain of cooperating parts helps you decide where to look when data is missing, late or too expensive. The table below separates the responsibilities.

Two storage styles for similar data

Telemetry can be analysed in two forms. Logs keep every individual record in tables that you query with a powerful query language. Metrics are pre-aggregated numbers stored in a fast time-series database. Standard charts of things like request rate and failure rate can draw on metrics for speed, while detailed investigation uses logs. Knowing which style a screen uses explains why a chart can be near real time while a detailed query takes longer.

From a user’s click to a row you can query.

Following one piece of telemetry from creation to analysis shows where delays, losses and costs can arise. The path is shorter than you might fear, but each step has its own behaviour.

sequenceDiagram
  participant User
  participant App as Instrumented application
  participant Inst as Instrumentation layer
  participant Ing as Ingestion endpoint
  participant LA as Log Analytics workspace
  participant Tool as Portal tools and alerts
  User->>App: Sends a request
  App->>Inst: Request and dependency calls observed
  Inst->>Inst: Add context, apply sampling, batch items
  Inst->>Ing: Send batch using connection string
  Ing->>LA: Store as table rows
  Tool->>LA: Query for charts, maps and alert rules
  LA-->>Tool: Results
        

The biggest change in recent years is how telemetry gets collected.

To produce telemetry, your application needs instrumentation. There are three broad ways to get it, and the right one depends on how much control you need and how much code you are willing to touch.

Why OpenTelemetry matters

OpenTelemetry is an industry-wide, open standard for producing and sending telemetry. If your code is instrumented with it, you are not locked into a single vendor. You can send the same data to Application Insights today and to another system tomorrow, or to both at once. Libraries and frameworks increasingly emit OpenTelemetry data on their own, which means richer telemetry with less work from your team.

Every telemetry type becomes a table you can query.

Because Application Insights stores its data in a Log Analytics workspace, each telemetry type lands in a table with a recognisable name. Knowing the mapping helps you move from portal screens to custom investigations.

The data model in one picture

Think of an operation as a tree. At the top sits the incoming request. Beneath it hang the dependency calls it made, each possibly a request into another service with its own children. Exceptions and traces attach to whichever node produced them. The operation identifier is shared by every node in the tree, and a parent identifier records which node called which. This structure is what makes end-to-end tracing possible.

Follow one request through every service it touches.

The feature that surprises newcomers most is end-to-end tracing. When service A calls service B, which calls a database, the instrumentation passes a small piece of context along with each call. Because every hop shares the same operation identifier, Application Insights can reassemble the whole journey afterwards, even when the services are written in different languages and run on different platforms.

flowchart TD
  U["Browser"] --> W["web-frontend"]
  W --> O["orders-api"]
  W --> C["catalog-api"]
  O --> P["payments-api"]
  O --> D[("Orders database")]
  C --> R[("Cache")]
  P --> X["External payment provider"]
        

What the application map gives you

The application map draws exactly this picture automatically from your telemetry. Each box is a component identified by its cloud role name, and each arrow is a call between them. The boxes show call volume, average duration and failure rate, so a slow or failing dependency stands out visually, often coloured to draw your eye. It is the fastest way to answer “where is the problem?” before you ask “what is the problem?”.

The end-to-end transaction view

Clicking into a slow or failed request opens the end-to-end transaction view. It shows a timeline of every operation in that request across all services, with durations laid out like a waterfall. You can see at a glance that, for example, eight hundred of the nine hundred milliseconds were spent waiting for one database query, and you can open the related exceptions and traces right there.

Different questions call for different screens.

Application Insights offers a family of investigation tools. Rather than memorising them, it helps to match each to the question you are asking at that moment.

A calm investigation routine

Your own telemetry cannot tell you the app is down if the app is too dead to speak.

Everything discussed so far is produced from inside your application. If the whole application crashes, or a network problem blocks users from reaching it, no telemetry is produced at all, and silence can look like peace. Availability tests solve this by acting like a user from outside: they call your application on a schedule from several locations around the world and record whether it answered correctly and how quickly.

Designing a useful test

A test that only checks for a successful response code can be fooled by an error page served with a success code. Make tests verify something meaningful, such as the presence of expected content, and point them at a lightweight health address that exercises key dependencies without doing heavy work. Run them from several locations so a single regional network glitch does not wake your team at night.

The server’s view is only half the story; the other half happens in the user’s browser.

A page can be served by your back end in fifty milliseconds and still feel slow because of heavy scripts, large images or a slow device. To see that half of the experience, you add the JavaScript monitoring library to your pages. It records page load timings, browser exceptions, calls made from the browser and, importantly, links them to the matching server requests so one trace can span browser and back end.

Usage analytics for product questions

Beyond health, the same data answers questions about behaviour. Teams use it to understand how many people use a feature, in what order they move through steps and where they drop out.

Ready-made screens answer common questions; queries answer yours.

Built-in screens cover many needs, but real investigations soon outgrow them. Because the data lives in Log Analytics, you can query it with the Kusto Query Language, usually shortened to KQL. It reads like a pipeline: you start with a table, then filter, group, summarise and sort step by step. Even a few basic operations, such as counting failures per operation over the last day or finding the slowest percentile per dependency, answer questions that no fixed screen anticipated.

Three ways to present what you find

Be told about trouble before your users tell you.

Collecting data is pointless if nobody looks at it in time. Alerts turn data into attention. An alert rule defines a condition to watch, such as failure rate above a threshold for five minutes. When the condition is met, the rule fires and triggers an action group, which is a reusable list of things to do: send an email or a mobile notification, call a webhook, start an automation or open a ticket in your incident tool.

flowchart LR
  T["Telemetry in workspace"] --> R["Alert rule evaluates condition"]
  R -->|"Condition met"| A["Alert fires"]
  A --> G["Action group"]
  G --> E["Email or mobile push"]
  G --> W["Webhook to incident tool"]
  G --> M["Automation runbook"]
  R -->|"Condition not met"| S["Keep watching"]
        

Kinds of alert rules

What makes an alert good

A good alert is actionable, urgent and rare. If it fires and nobody needs to do anything, it teaches people to ignore alerts. Alert on symptoms users feel, such as high failure rates or slow responses, rather than on every internal cause, such as a single processor spike. Link each alert to a short runbook that says what it means and what to try first.

Telemetry is billed by volume, so volume deserves design.

The main cost driver is the amount of data ingested into the workspace, measured in gigabytes. Pricing tiers, free allowances and commitment discounts exist and change over time, so check the current Azure Monitor pricing page for exact figures instead of relying on older articles. What does not change is the principle: more telemetry means more cost, and a few simple habits keep both reasonable.

flowchart TD
  A["Telemetry volume too high?"] --> B{"Which type dominates?"}
  B -->|"Dependencies and requests"| C["Apply sampling"]
  B -->|"Traces and logs"| D["Raise minimum log level and filter noise"]
  B -->|"Custom metrics"| E["Reduce dimensions and frequency"]
  A --> F["Set a daily cap as a safety net"]
  C --> G["Review in Log Analytics usage views"]
  D --> G
  E --> G
        

Sampling explained

Sampling means keeping only a fraction of the telemetry, for example one item in five, while still letting charts show correct totals. Good sampling keeps related items together, so that if one request is kept, its dependency calls and exceptions are kept too. Some instrumentation adjusts the rate automatically as traffic changes, while other setups use a fixed rate. Sampling is the biggest single lever you have, and for high-traffic services it is nearly always worth using.

Other cost habits

Telemetry is data, and data needs protecting.

Telemetry often contains more than people expect: web addresses with identifiers in them, user names, internal server names, error messages with fragments of data and even request bodies if someone logged them carelessly. Treat the monitoring system with the same seriousness as the application itself.

Decisions made on day one are hard to change after a hundred applications.

Small teams can put everything in one place and be happy. As the number of applications grows, the way you arrange resources and workspaces shapes cost visibility, access control and the quality of tracing across services.

Resources per application or shared?

Workspace strategy

Because data lives in a workspace, you choose how many to have. A common pattern is a small number of workspaces per environment and region. Fewer workspaces make cross-service queries easy and can lower cost through shared commitment tiers. More workspaces give stronger isolation for data ownership or regulation. Decide based on who needs to see what, and where data must be stored.

Habits for tidy operations

Shapes that work, and shortcuts that hurt later.

Patterns worth adopting

Anti-patterns to avoid

Habits that separate calm operations from constant firefighting.

Best practices

• Instrument early. Switch on monitoring in development and test, not only after the first production incident.
• Name your components. Unique, meaningful role names make maps and queries readable by anyone on the team.
• Trace across boundaries. Check that queues, background jobs and browser calls carry trace context.
• Watch outside-in. Pair internal telemetry with availability tests from several locations.
• Alert on symptoms. Choose a few high-value alerts and tune them until they are trusted.
• Control volume. Use sampling, filter noise and review ingestion by table every month.
• Protect the data. Use role-based access, Entra ID authentication and strict rules on what may be logged.
• Record releases. Mark deployments on charts to link changes in behaviour to changes in code.
• Automate setup. Keep resources, alerts and dashboards in code so environments stay consistent.
• Practise using it. Run game days where the team finds a planted fault using only the monitoring tools.

Common mistakes

How different teams put the flight recorder to work.

The following scenarios are typical patterns rather than descriptions of specific companies. They show how the same capabilities combine for very different needs.

Quick answers to questions that come up again and again.

No. It is the application monitoring capability within Azure Monitor. Its data is stored in a Log Analytics workspace, so it sits alongside other Azure Monitor data.

No. Applications on premises or in other clouds can send telemetry too, as long as they can reach the ingestion endpoint and are configured with a connection string.

Microsoft’s current guidance is to start with OpenTelemetry using the Azure Monitor distribution. The classic API is treated as superseded and has published migration guidance, so new projects should avoid building on it.

Logs store individual records that you can search and explain. Metrics store pre-aggregated numbers over time that are fast to chart and ideal for alerting on trends.

Instrumentation passes trace context along each call, and every item carries the same operation identifier. The tools then reassemble the whole journey from those shared identifiers.

Typical causes are a wrong connection string, blocked network access to the ingestion endpoint, aggressive sampling or filtering, a reached daily cap, or authentication enforced without an identity for the application. Also allow a few minutes of ingestion delay.

Apply sampling, filter noisy items such as frequent health checks, raise the minimum log level in production, keep metric dimensions low in cardinality and set retention intentionally. Review ingestion by table every month.

Use standard availability tests from several locations, ideally against a lightweight health address. The older URL ping test type has an announced retirement, so move to standard tests and check the official page for the latest date.

Yes. Adding the JavaScript monitoring library records page loads, browser errors and calls made from the page, and links them to the matching server requests.

It is best not to. Collect the minimum, scrub sensitive fields before they leave the application, restrict access with roles and set retention that fits your legal duties.

Use Entra ID authentication with a managed identity or service principal. Access through API keys has an announced retirement, so update any tools that still depend on keys.

Application Insights is the flight recorder for your software. Instrumentation inside your application produces requests, dependencies, exceptions, traces and metrics, a connection string sends them to Azure Monitor, and a Log Analytics workspace stores them so maps, traces, queries, workbooks and alerts can turn raw data into understanding. The recommended way to feed it has shifted to OpenTelemetry, with auto-instrumentation for quick starts and the classic SDKs in the process of being superseded. Success depends less on switching it on and more on a few design choices: naming components well, tracing across every boundary, alerting on symptoms users feel, controlling volume and protecting the data you collect.