Skip to content

Custom Metrics to AWS CloudWatch from ASP.NET Core

Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


CloudWatch Custom Metrics

I was playing around with AWS CloudWatch and was curious to send custom metrics from ASP.NET Core. Specifically the execution time of an HTTP request.

AWS SDK

I created a simple middleware that starts a StopWatch before calling the next middleware in the pipeline. When it returns, stop the StopWatch and send the data to CloudWatch.

First is to add the relevant NuGet packages.

Configuration

If you’ve never used the AWS SDK/Packages, I recommend checking out my post on Configuring AWS SDK in ASP.NET Core. It goes over creating a named profile to store your AWS credentials and using appSettings or Environment variables to pass them through to ASP.NET Core.

Middleware

Next is to create a simple middleware using the SDK. The middleware is having the IAmazonCloudwatch injected into the constructor. In the Startup’s ConfigureServices is where this is configured.

We’re simply calling the PutMetricDataAsync with a list of one MetricDatum. It contains the metric name, value, unit, timestamp, and dimensions.

Startup

As mentioned, in order to use the AWS SDK and the IAmazonCloudWatch in the middleware, you can use the AddDefaultAWSOptions and AddAWSService<IAmazonCloudWatch> to ConfigureServices to register the appropriate types.

Results

If you look in CloudWatch, you can now see the new custom metrics we’ve published.

Next

Before you start using this in a production environment, there are a couple of glaring issues.

First, sending the metrics to AWS, although incredibly fast should be handled outside of the actual HTTP request. this can be done completely asynchronously from the actual request. There is no point in delaying the HTTP response to the client. To solve this, we’ll add a queue and do it in a background service.

Secondly, some of the cost associated with CloudWatch is based on the number of API calls. This is why there is a List<MetricDatum> in the PutMetricDataRequest. It allows you to send/batch multiple metrics together to limit the number of API calls.

This is a better solution is to collect PutMetricDataRequest separately and send them in batch in a background service.

More on that coming soon.

Learn more about Software Architecture & Design.
Join thousands of developers getting weekly updates to increase your understanding of software architecture and design concepts.


Leave a Reply

Your email address will not be published. Required fields are marked *