Using Azure Monitor and Application Insights for .NET apps

Modern .NET applications rarely fail in a single, obvious place. A request may pass through an API, a background worker, a database, a cache, and several Azure services before returning a response. When users report slow pages or intermittent errors, developers need more than a log file from one server. They need a connected view of application behavior, infrastructure health, and customer impact.

Azure Monitor and Application Insights provide that observability layer. Together, they collect telemetry from .NET applications, organize it around requests and dependencies, and make patterns visible through metrics, logs, dashboards, alerts, and distributed tracing. The result is a practical way to move from “something is wrong” to a defensible explanation of what happened.

For software professionals following the C# Corner Annual Conference 2020 agenda, this subject connects naturally with sessions on Azure, cloud computing, DevOps, data, and web development. Monitoring is most valuable when it becomes part of the development and delivery lifecycle rather than a tool used only during an outage.

Why observability matters in .NET systems

Application monitoring has three closely related purposes: detecting problems, diagnosing their causes, and measuring the experience delivered to users. A server metric may show high CPU usage, while an application metric reveals that checkout requests are timing out. A trace can then show that a slow database query caused the delay. Each signal answers a different part of the same operational question.

Azure Monitor acts as the broader monitoring platform. It brings together metrics, logs, alerts, workbooks, and resources across Azure and connected environments. Application Insights focuses on application performance management, capturing details such as incoming requests, outgoing dependencies, exceptions, availability tests, and performance trends.

This distinction helps teams choose the right investigation path. Azure Monitor can show whether an App Service plan is under pressure, while Application Insights can identify the controller action, dependency call, or exception associated with a failing request. Linking these views prevents application and infrastructure teams from analyzing isolated fragments of evidence.

Choosing signals that explain behavior

Telemetry becomes useful when it is structured, correlated, and relevant to a decision. For a .NET web API, request duration, response status, success rate, and throughput are essential measurements. Dependency duration and failure data add context for calls to SQL Database, Storage, Redis, external APIs, and messaging systems.

Exceptions should include enough information to reproduce or classify a problem without exposing secrets or personal data. Custom events can record meaningful business actions, such as an order submission or document processing step, while custom metrics can track values that matter to the product. These additions should support a clear operational question rather than create a large stream of data with no purpose.

Correlation is particularly important in distributed applications. A single operation may cross services, queues, and functions. Trace identifiers allow engineers to follow that operation across boundaries, helping them distinguish an application defect from a downstream timeout or a temporary platform issue. OpenTelemetry-compatible approaches can also help standardize instrumentation across mixed .NET and cloud environments.

Instrumenting .NET applications effectively

The simplest starting point is to connect a supported .NET application to an Application Insights resource and enable automatic collection. Depending on the application type and hosting model, the SDK or Azure integration can collect incoming HTTP requests, unhandled exceptions, performance counters, and common dependency calls with limited code changes.

Automatic instrumentation should be treated as a foundation, not the complete solution. Add custom telemetry at important business and technical boundaries. A payment workflow, for example, may need an event for authorization status and a metric for processing time. Use stable property names and values so that queries remain useful across deployments and versions.

Sampling helps control cost and noise in high-volume systems. Rather than storing every successful request, a team can retain representative traffic while preserving failures and slow operations. Sampling rules should be reviewed alongside diagnostic needs: aggressive filtering may reduce expenses but remove the evidence required to analyze a rare production defect.

Configuration also deserves care. Connection strings, cloud roles, and environment-specific settings should be managed securely, with production telemetry separated from development data. Sensitive request headers, tokens, passwords, and personal information must be excluded before they reach the monitoring platform.

Reading telemetry through the Azure portal

The Azure portal provides several ways to investigate application health. The Application Insights overview can reveal request rates, failures, response times, and server availability. Performance views help locate slow operations, while the failures view groups exceptions and failed dependencies. Transaction search offers a more detailed path for examining individual operations.

Logs make these investigations repeatable. Azure Monitor Logs uses Kusto Query Language, allowing developers to filter, aggregate, join, and visualize telemetry. A query can compare failure rates by application version, identify endpoints with unusual latency, or list external dependencies that frequently exceed a selected threshold.

Dashboards and workbooks turn repeated queries into shared operational views. A development team may track release health, while a support team needs availability and failure trends. Azure Monitor alerts can then notify the appropriate channel when a threshold or dynamic anomaly is detected.

Alerts should be designed around impact rather than every unusual event. A notification for each transient exception can produce fatigue, causing important incidents to be ignored. Better rules combine conditions such as elevated failure percentage, sustained latency, and sufficient request volume. The alert should also include a link to the relevant query or workbook.

Connecting monitoring with delivery

Observability is strongest when telemetry is compared across releases. Include application version, deployment slot, region, and environment as searchable dimensions. When a new build causes a rise in dependency failures, that context can shorten the path from detection to rollback or remediation.

Deployment automation can support this process by making releases consistent and traceable. Teams exploring Azure DevOps pipelines can connect build and release practices with monitoring data, using deployment markers and post-release checks to identify regressions early.

Blue-green and slot-based deployments are especially useful for controlled validation. A candidate version can receive limited traffic while engineers watch request success, response time, exceptions, and dependency behavior. If the signals remain healthy, traffic can be expanded; if they deteriorate, the release can be stopped before it affects the wider user base.

Continuous integration and continuous delivery should include observability as a quality concern. Smoke tests can verify that telemetry is being emitted, dashboards can confirm expected dimensions, and automated checks can compare performance against a baseline. This turns monitoring from a passive record into an active part of software delivery.

Practical habits for reliable monitoring

A monitoring design should be easy to use during pressure. Teams can establish a small set of conventions before production traffic makes inconsistencies expensive:

• Define service ownership, environments, regions, and release versions as standard telemetry properties.
• Create dashboards for user-facing health, dependencies, infrastructure, and deployment performance.
• Protect confidential information by reviewing automatic and custom telemetry before release.
• Set alerts for sustained customer impact, then test every alert through a documented response procedure.
• Review sampling, retention, and ingestion costs regularly as traffic and application scope increase.

Teams should also document the meaning of their most important metrics. “Failure rate” might refer to HTTP errors, business failures, dependency errors, or exceptions, and those values are not interchangeable. A short operational guide can explain which dashboard to open, which query to run, and who owns each service.

Regular review is as important as initial setup. New features introduce new dependencies and failure modes, while changes to hosting plans can alter resource behavior. Monthly telemetry reviews can identify unused alerts, missing dimensions, excessive log volume, and blind spots in critical workflows.

Building a culture of evidence-based diagnosis

Effective monitoring depends on habits across development, operations, security, and product teams. Developers should be able to inspect telemetry without waiting for another group, while operators need enough application context to interpret infrastructure signals. Shared dashboards and consistent naming create a common language for incident response.

An incident review should examine both the technical failure and the quality of the available evidence. If an outage took hours to diagnose because a queue operation lacked correlation data, the improvement may be better instrumentation rather than another alert. If an alert fired without meaningful user impact, its threshold or scope may need adjustment.

Azure Monitor and Application Insights are most powerful when they support a continuous feedback loop: instrument the application, observe real behavior, investigate anomalies, improve the system, and verify the next release. That loop is relevant across APIs, web applications, worker services, serverless components, and cloud-native .NET architectures.

Use the conference’s technical sessions and speaker material to deepen that practice, then apply the concepts to a small service before expanding them across a portfolio. Start with the requests and dependencies that matter most, connect telemetry to deployment events, and make every important alert lead to an understandable diagnostic path.