The art of simplicity

Note: this is part 2 of a series on the Azure Monitor Profiler. Part 1 covered what the Profiler is and where to find the results - this post covers actually turning it on. There are two ways to enable the profiler: through app settings on App Service, or by wiring it into your code directly. Which one you need depends on where your app runs and how much control you want over the setup. Option 1: codeless enablement on App Service If your app runs on App Service (Windows) and your Application Insights resource is in the same subscription, this is the easiest path - no code changes, no redeploy. From the portal: In your App Service instance, select Monitoring > Application Insights Select Turn on Application Insights , then Enable Scroll down to the .NET or .NET Core tab Set Collection level to Recommended Under Profiler and Code Optimizations , select On Apply , then confirm with Yes Or skip the portal entirely and set the app settings directly...

Yesterday one of our Application Insights dashboard showed a P95 latency spike and we had no idea why. The telemetry told us that a request was slow. But it didn't tell us why . Was it a database call? A CPU-bound loop? Lock contention? A GC pause? The naive approach would have to been to add logging statements around the code you suspect, redeploy, wait for the issue to reproduce, and repeat. In production, that's slow and it doesn't scale - you're guessing, and every guess costs a deployment cycle. We stayed away from all that guess work and reached out to the Application Insights Profiler . Instead of reasoning from logs, you get actual flame graphs of real production requests, showing exactly where time was spent. What the profiler actually captures The profiler runs as an agent alongside your application and periodically captures traces of live requests - not synthetic load, actual production traffic. For each captured request, it builds a trace you can in...

In a previous post I showed how to add the .NET runtime version as an OpenTelemetry resource attribute: ResourceBuilder.CreateEmpty() .AddService($"{_sofaSettings.ApplicationName}-{_sofaSettings.EnvironmentName}") .AddAttributes(new Dictionary<string, object> { ["deployment.environment"] = _sofaSettings.EnvironmentName, ["service.name"] = _sofaSettings.ApplicationName, ["runtime.dotnet.version"] = Environment.Version.ToString() }) .Build(); The idea was clean: attach facts about what is running directly to the resource, and let OpenTelemetry carry them along with every trace, metric, and log automatically. Unfortunately, there is a catch. The problem Azure Monitor's OpenTelemetry exporter only maps a fixed set of well-known resource attributes onto Application Insights fields. service.name and service.namespace become Cloud Role Name, service.instance.id becomes Cloud Role Insta...

On-premises VMs don't disappear just because you are working on a cloud strategy. We are running a lot of Windows workloads on-prem — application pools, Windows services, scheduled tasks — and still need visibility into whether they're healthy. Traditional on-prem monitoring solutions could work, but they come with their own operational overhead and are directly tied to our on-premise infrastructure. When an incident happens, we don’t want to context-switch between our cloud monitoring stack and our on-prem monitoring stack. It's not ideal. We wanted a single, cloud-native view into the health of our on-prem workloads without having to lift and shift them into Azure. Azure Arc made this possible by extending Azure's management plane to our on-premises infrastructure. By combining Arc with Log Analytics and Workbooks, we built a unified health dashboard that sits alongside our cloud monitoring, uses the same query language (KQL), and requires no additional on-prem in...

I want to start this blog post by stating that I have a new hero and his name is Stijn. Let me explain why… I recently upgraded an older .NET Full Framework application to the latest Application Insights NuGet package. This to make the switch from the obsolete instrumentationkey to the newer connectionstring approach. After upgrading our packages.config file (yes, this project is so old) looked like this: Looking good right? Unfortunately, the same could not be said about our telemetry itself as our Application Insights logs remained awfully empty. I doublechecked all the config files, reinstalled the nuget packages, tried to explicitly force to flush the telemetry data, everything I could think of I tried. But nothing worked. I handed the problem over to another team member (Stijn, my new hero) and he found the solution. After debugging the Application Insights code he arrived at a no-op method: This method should have all the logic to read the configuration information ...

I’ m currently working on a new feature in one of our microservices. As this new feature could have large performance impact, we did some performance benchmarks up front through BenchMarkDotNet . The results looked promising but we were not 100% confident that these results are representative for real life usage. Therefore we decided to implement A/B testing. Yesterday I showed how to implement A/B testing in .NET using .NET Feature Management . Today I want to continue on the same topic and show you how we added telemetry. Measuring and analyzing results The most critical aspect of A/B testing is measuring results. You need to track relevant metrics for each variation to determine which performs better. The most simple way to do this is to fall back to the built-in logging in .NET Core : Although this is a good starting point, we can simplify and improve this by taking advantage of the built-in telemetry through OpenTelemetry and/or Application Insights. Using OpenTelemetry...

Last week we had a production issue at one of my customers where a server went offline due to high memory usage. So far the bad news. The good news is that we had Azure Application Insights monitoring in place, so we could easily validate that the high memory usage  was causing the issue as our Application Insight logs showed a long list of OutOfMemoryException s. However as a separate Application Insights instance was used per application, we couldn’t easily pinpoint which application was the main culprit. Remark: Unfortunately it isn’t  possible to show multiple resources on the Metrics tab, so that is not an option(you can upvote the feature if you like it): I could go through every Application Insights resource one by one, but that wouldn’t be very efficient. Therefore I decided to turn to KQL and write a query on top of the Log Analytics workspace where all the data was consolidated. Here is the query I used in the end: And here is how the result looked like wh...

If you are a regular reader of my blog, you've certainly seen my earlier post on how to integrate Application Insights telemetry in your HotChocolate based GraphQL backend. IMPORTANT: Although the code below will still work, I would recommend to switch to the integrated OpenTelemetry functionality and send the information to Application Insights in this way. Today I had to upgrade an application to HotChocolate 13 and (again) I noticed that the application no longer compiled. So for people who are using the ApplicationInsightsDiagnosticsListener I shared, here is an updated version that works for HotChocolate 13: As I wanted to track the full operation I have overwritten the ExecuteRequest method, however if you only want to log any exception, I would recommend to override the RequestError and ResolverError methods: More information HotChocolate OpenTelemetry (bartwullems.blogspot.com) GraphQL HotChocolate 11 - Updated Application Insights monitoring (bartwullem...

About 2 years ago I blogged about the possibility to collect performance counter data as part of your Application Insights telemetry. If you missed the original post, first have a quick read here and then come back. Back? As mentioned in the original post, to be able to collect this performance data, the Application Pool user needs to be added to both the Performance Monitor Users and Performance Log Users group. Although I updated our internal wiki to emphasize this, I still noticed that most developers forget to do this with no collected data as a result. (Who reads documentation anyway?) So let’s do what any developers does in this case, let’s automate the problem away… I created a small tool that can be executed on the IIS web server. It goes through all the application pools, extracts the corresponding user and add it to the 2 groups as mentioned above. I think the code is quite self-explanatory. Here is the part where I read out the application pools: And here I ad...

If you are using the Application Insights SDK inside your ASP.NET (Core) application, every incoming HTTP request will start an operation context and will allow you track this request including any dependencies called along the way. But if you are using a console application(as a batch job for example) , there isn't the concept of an incoming request so the SDK doesn't track a lot out-of-the-box. Configure your Console app to use Application Insights Let me show you how you can still track operations in a Console App. Start by adding the Microsoft.ApplicationInsights.WorkerService nuget package to your console app: dotnet add package Microsoft.ApplicationInsights.WorkerService Now you can add the bootstrapping logic to configure App Insights for your console app: The code above will build up the required services and allows you to resolve a TelemetryClient instance that we’ll use in the next part. Remark: Notice the FlushAsync method at the en...

OpenTelemetry is becoming THE standard of telemetry instrumentation. And thanks to the Azure Monitor OpenTelemetry Exporter we can keep using Application Insights as our tool of choice. In this post I'll walk you through the steps to link your OpenTelemetry enabled ASP.NET core application to Azure Monitor Application Insights. Important to mention is that this feature is still in preview! At the moment of writing distributed tracing and metrics are supported but some of the other features that we like from the Application Insights SDK are not available(yet). What is not supported? I copied the list from the documentation : Live Metrics Logging API (like console logs and logging libraries) Profiler Snapshot Debugger Azure Active Directory authentication Autopopulation of Cloud Role Name and Cloud Role Instance in Azure environments Autopopulation of User ID and Authenticated User ID when you use the Application Insights JavaScript SDK ...

HotChocolate remains my favorite GraphQL client for .NET. As I find it really important to monitor my applications, I have written multiple posts (here and here ) on how to integrate monitoring with HotChocolate. At the beginning of this year, with the release of HotChocolate 12.5 , support for OpenTelemetry was introduced. Although I updated my applications to start using it, it took me until now to write a corresponding blog post about it. Instrument your GraphQL Server with OpenTelemetry Let me walk you through the steps: We’ll start with an ASP.NET Core application with OpenTelemetry enabled. Therefore we added the following NuGet packages: OpenTelemetry.Extensions.Hosting OpenTelemetry.Instrumentation.AspNetCore OpenTelemetry.Instrumentation.Http OpenTelemetry.Instrumentation.SqlClient We also add a reference to the AzureMonitor exporter because we want to use Application Insights: Azure.Monitor.OpenTelemetry.Exporter O...

When adding the Application Insights SDK to your application, a set of Performance Counters is tracked by default. This is the list of default counters for ASP.NET web applications: % Process\Processor Time % Process\Processor Time Normalized Memory\Available Bytes ASP.NET Requests/Sec .NET CLR Exceptions Thrown / sec ASP.NET ApplicationsRequest Execution Time Process\Private Bytes Process\IO Data Bytes/sec ASP.NET Applications\Requests In Application Queue Processor(_Total)\% Processor Time However Performance Counters are a windows only feature. With .NET being cross-platform, is there a solution that works on both Windows and Linux? Of course there is! (Otherwise I wouldn’t be writing this blog post). Collecting EventCounters with Application Insights The documentation has the following to say about EventCounters: EventCounter is .NET/.NET Core mechanism to publish and consume counters or statistics. EventCounters are suppor...

This weekend I had the honor to speak at CloudBrew , a 2 day conference organized by AZUG, the Belgium Microsoft Azure User Group. I really enjoyed the conference; great sessions, nice location, good food. I had the time to chat up with some other community members. Advanced telemetry with Azure Monitor Application Insights I did a session about Application Insights: You've added the Application Insights NuGet or NPM package to your application, but now what? This demo-driven session will show you how to get the maximum out of Application Insights and achieve true insights in your application behavior and performance. Profiling, dependency tracking, snapshots, extensibility, availability,... no feature remains untouched. In case you are looking for my slides, they can be found here: https://github.com/wullemsb/presentations/tree/main/CloudBrew%20-%202022 During my presentation I used 2 demo applications. They are both an adaption of the eShopOnWeb reference appli...

One of the nice features of Application Insights, is the Application Map. This gives you a visual clue of all the parts of your application and their dependencies. I blogged before on how you could tweak this application map through a custom TelemetryInitializer: In your C# backend In your Angular SPA Today I want to share another option when you are using the Javascript snippet inside your web frontend. Inside the snippet you should use the onInit callback to inject a TelemetryInitializer: Here is the full snippet as well:

I think that everyone agrees when I say that logging and monitoring are important for almost every application. My preferred way is to use a 'Structured logging' approach in favor of the non-structured logging alternative. Structured vs non-structured logging With non-structured logging, the log message itself is handled as a string. . This makes it hard to query or filter your log messages for any sort of useful information. With structured logging, log messages are written in a structured format that can be easily parsed. This could be XML, JSON, or other formats. But since virtually everything these days is JSON, you are most likely to see JSON as the standard format for structured logging. A popular library that introduced the structured logging approach in .NET is Serilog . Starting from .NET 5, it became available out-of-the-box as part of the Microsoft.Extensions.Logging package. Here is an example where we are using structured logging using the default ILogger: ...

If you have read all my previous posts about Application Insights , my hope is that you would start to use a lot more of the great features it has to offer. However this comes with one big 'disadvantage'; you'll start to collect a lot more data which of course leads to increased telemetry traffic, data costs, and storage costs. Let's have a look at 3 ways to keep this under control: Limit the amount of data by changing the retention duration Use sampling to reduce traffic Setting a daily data volume cap Changing the retention duration Data ingested into either classic or workspace-based Application Insights is retained for 90 days without any charge. For data ingested into your Log Analytics workspace can be retained at no charge for up to first 31 days (or 90 days if Azure Sentinel is enabled on the workspace). If you are using a classic Application Insights resource, you can change the retention duration after opening the Application Insights r...

One of the features that Application Insights has to offer is ‘Dependency Tracking' . It allows you to monitor components that are called by your application. This can be a service called using HTTP, or a database, or a file system. Application Insights measures the duration of dependency calls, whether its failing or not, along with additional information like name of dependency and so on. You can investigate specific dependency calls, and correlate them to requests and exceptions. Automatically tracked dependencies Out-of-the-box the following dependencies are tracked automatically: Dependencies Details Http/Https Local or Remote http/https calls. WCF Calls Only tracked automatically if Http-based bindings are used. SQL SQL Calls made with SqlClient. Azure storage Calls made with Azure Storage Client. EventHub Client SDK   Eve...

I've talked about how to setup Application Insights in an Angular application and also shared how to set the cloud role name in ASP.NET Core to improve the telemetry reporting. Let's build on top of these 2 posts and show you today how to update the cloud role name in an Angular application. We’ll start by extending our environment.ts file with an extra configuration setting to store the application name: Once that is done, we need to go the service ( app-insights.service.ts ) where we create our Application Insights instance. There we need to add a custom telemetry initializer by calling the addTelemetryInitializer method: Now when we run our Angular application, the cloud role name should be reported correctly to Application Insights.

One way to improve our Application Insights telemetry, is by setting the cloud role name yourself. I shared how to do this in an ASP.NET application in a previous post . In this post I'll show you how to use this approach in an ASP.NET Core application. The first steps are quite similar.  We still need to create a custom TelemetryInitializer. Therefore we create a class that implements the ITelemetryInitializer interface and implement the Initialize method: Now, in the Startup.ConfigureServices method, we register that telemetry initializer as a singleton: Or if you are using .NET 6 minimal API’s: