--- title: "How to Observe a .NET Core App on Azure with OpenTelemetry" description: "Explore how an ASP.NET Core application can send traces, metrics, and logs to Azure Monitor, and what to consider when configuring correlation, sampling, and production alerts." author: "Rashtra Gaurav" published: 2026-10-11 updated: 2026-10-11 canonical: https://answers.mindstick.com/blog/678/how-to-observe-a-net-core-app-on-azure-with-opentelemetry category: "Azure with .NET Core" tags: ["Azure Monitor", ".NET Core", "OpenTelemetry", "Application Insights", "Observability"] reading_time: 5 minutes --- # How to Observe a .NET Core App on Azure with OpenTelemetry When a .NET service is running locally, a failing request is often easy to reproduce. Once it is deployed to Azure, the same failure may involve a particular endpoint, a downstream HTTP call, or a burst of traffic that has already passed. Good telemetry helps connect those clues instead of leaving you with a stack of unrelated log lines. This guide looks at adding Azure Monitor telemetry to an ASP.NET Core application with OpenTelemetry, then making that data useful for day-to-day troubleshooting. ## Start with traces, metrics, and logs These signals answer different questions, and they are most useful when they can be viewed together: - **Traces** show the path of a request through your application and its dependencies. A trace can reveal that an endpoint spent most of its time waiting on another service. - **Metrics** show measurements over time, such as request duration, request volume, and failure rates. They help reveal patterns that a single request cannot. - **Logs** carry the detail behind an event: what the application was doing, which operation failed, and any relevant diagnostic context. OpenTelemetry provides a consistent way to collect and export these signals. Azure Monitor and Application Insights provide a place to query and inspect them. ## Connect an ASP.NET Core application For a standard ASP.NET Core service, the Azure Monitor OpenTelemetry distribution can set up common instrumentation and export telemetry to Azure Monitor. Add the `Azure.Monitor.OpenTelemetry.AspNetCore` package, then register it during application startup: ```cs using OpenTelemetry; var builder = WebApplication.CreateBuilder(args); // Register Azure Monitor's OpenTelemetry distribution and exporter. builder.Services.AddOpenTelemetry() .UseAzureMonitor(); builder.Services.AddControllers(); var app = builder.Build(); app.MapControllers(); app.Run(); ``` Configure the `APPLICATIONINSIGHTS_CONNECTION_STRING` environment variable for the application. In Azure, set it in the app's configuration settings; locally, use your development environment's secret or environment-variable mechanism rather than committing a real connection string to source control. Keeping configuration outside the code makes it easier to use different Application Insights resources for development, staging, and production. ## Use correlation to follow a request The practical value of telemetry becomes clear when a request and its dependency calls share trace context. With standard ASP.NET Core and HTTP client instrumentation, a request trace can include an outgoing call to another service. That makes **trace context propagation** useful across service boundaries: instead of comparing timestamps and guessing, you can inspect which operation took time and where the delay occurred. Use `ILogger` for application events and include useful structured properties, such as an order identifier or operation name when appropriate. Avoid placing secrets, access tokens, passwords, or unnecessary personal data in logs. A trace can be widely accessible to engineers and retained longer than expected, so treat it as operational data with access and retention requirements. ## Choose useful signals, not just more signals Capturing every event may sound safer, but high-volume telemetry can raise ingestion costs and make important incidents harder to spot. Set sampling deliberately, especially for busy services. The goal is to retain enough representative requests to understand normal behavior while preserving useful diagnostic detail during failures. Review **telemetry sampling rules** against your traffic patterns and operational needs rather than copying a setting from another application. Likewise, instrument meaningful application behavior. Built-in request and dependency telemetry gives you a foundation, but a business operation may need its own event or measurement—for example, how long a document-processing step takes. Keep custom telemetry focused on questions someone might actually investigate. ## Make telemetry actionable in Azure In Application Insights, start with a slow or failed request and follow its operation details into dependencies and related logs. This is particularly helpful for distinguishing an application problem from a timeout or error reported by a downstream service. **Dependency telemetry in .NET** can also help identify whether a change has made an external call slower, even when the endpoint itself still returns successfully. Use dashboards and alerts for a small set of signals that indicate user impact—such as elevated failure rates or sustained latency—not every available metric. Azure Monitor live metrics can help during an active investigation, while longer time ranges are better for finding recurring patterns or comparing releases. Confirm that alerts have a clear owner and a response path; an alert nobody checks is just another source of noise. ## Check the setup before relying on it After deployment, send a test request and verify that it appears in Application Insights with the expected service name and environment. Trigger a controlled dependency failure in a non-production environment, too. Check whether the request, exception or error log, and dependency details give enough context to diagnose it. If sensitive values appear, fix the instrumentation or logging before expanding access. Telemetry is not a substitute for testing or careful error handling. It is the evidence that helps a team understand what a deployed application actually did. A modest, well-correlated set of traces, metrics, and logs is usually more useful than a firehose of events nobody knows how to interpret. --- Original Source: https://answers.mindstick.com/blog/678/how-to-observe-a-net-core-app-on-azure-with-opentelemetry Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.