AWS-native monitoring using CloudWatch Dashboards

7 min readJun 6, 2018

5/Jun 2018 By nisabek

Like Google +1 Share on LinkedIn Tweet

Cloud computing has introduced incredible flexibility in creating and managing servers. Every one of us can now bring up a machine of almost any size and power in a matter of minutes. One can host everything from a simple static blog page to flexible, scalable datacenter distributed across continents.

There is one thing all of these use cases have in common though: you still need visibility of your infrastructure state. When things go wrong — you need a way to figure out which parts of your system are causing issues — be that a blog with 100 visitors a day or a multi-million transaction system.

Just like in your good old Windows home PC, when things start getting slow, first you open the resource monitor to see what is going on and watch the CPU/network/memory graphs.

Wouldn’t it be nice to have the same overview of your cloud server? To have a presentable set of graphs and dashboards, with short-lived historical data, which give you observability of your system, help you investigate issues and watch the behaviour of your system under different conditions…Sounds good, but I’m afraid firstly you would need to think about setting up:

an agent running on your instances collecting the required data
probably some time series database to store that data
then, of course, you’d want to index the data
and query it somehow too
until you’d finally get to setting up a visualizer

after which, you’ll have some presentable data showing up… most likely somewhere externally, where your team members would need to have separate credentials to.

Now, this might have been a little bit over exaggerated, and you could get away with combining some of those steps, making compromises here and there…But honestly, sometimes all you want is an overview of what is going on, and you want it now.

The Tool in the Cloud

If your infrastructure is running in AWS I have good news for you: CloudWatch already did most of the work for you — the agents are installed, the data is collected, stored, most-likely indexed too. Visualization is covered as well, and it’s just a click away…

Most of AWS services send metrics to CloudWatch, allowing you to not only monitor your services, but also create alarms, and actions based on those alarms. In this post, we’ll cover different ways of setting up dashboards for basic EC2 instance metrics.

Since all of your instances are already sending basic metrics to CloudWatch, this is what you can get, without any additional configurations on your instances:

Setting up CloudWatch

As with most of the AWS services, you can create CloudWatch Dashboards using AWS Console, AWS CLI or the REST API.

In this post, we’ll cover

the process of creating dashboards through AWS Console
possibilities of using the AWS CLI to achieve the same result
certain bottlenecks of using the existing API and reasons for us to come up with our API to support setting up CloudWatch

TL;DR?

If you are already familiar with basics of CloudWatch Dashboards and wish you could set up all available EC2 Metrics in a single CloudWatch Dashboard for all or a subset of your instances using a simple HTTP request — please have a look into our AWS Marketplace SaaS solution.

The product is brand new, and we value your feedback. In exchange for evaluation and honest review, we are happy to provide with free trial access. For trials, please contact us at trial@envimate.com.

For all the people who would like to know more about CloudWatch dashboards, let’s dive into our example.

Setup Sample Server

To demonstrate a simple AWS CloudWatch dashboard, we would need a couple of ec2 instances running.

Amazon EC2 sends basic(every five-minute) metrics to CloudWatch for your EC2 instances. You can enable detailed(one-minute) monitoring with some additional charges.

These are the current Metrics available for all EC2 instances:

CPUUtilization
DiskReadOps
DiskWriteOps
DiskReadBytes
DiskWriteBytes
NetworkIn
NetworkOut
NetworkPacketsIn
NetworkPacketsOut

For the sake of this example, we’ll concentrate on CPUUtilization.

For us to see something on the graph, let’s make sure our instance produce some CPU load. We’ve prepared a CloudFormation template, which creates 2 basic t2.micro instances and schedules generation of some CPU load in the user-data section using stress tool. It’s scheduled to spawn 4 workers for the first one and 8 for the second one, spinning on sqrt() with a timeout of 30s using crontab every minute.

Create Dashboard from AWS Console

Steps you need to perform:

Go to CloudWatch Service page
Create Dashboard
In the list of metrics, choose the CPUUtilization Metric of the newly created instances
Save the Dashboard

Since the default interval on which EC2 sends metrics to CloudWatch is 5 minutes, you might need to wait a bit, until you see the CPUUtilization graph going up.

Create Dashboard with AWS CLI

Clicking in the console can get you a quick overview of what CloudWatch Dashboards are capable of, but at some point, we might want to add the creation of the Dashboards to our management scripts, or even CI/CD pipelines. Hence let’s see how can we achieve the same result as above, using aws-cli.

The dashboards in CloudWatch are represented using JSON syntax. To create a dashboard using aws-cli, we would need to supply the body of the dashboard definition. Let’s inspect, copy and save the source of the dashboard created in the previous step:

aws cloudwatch get-dashboard --dashboard-name CloudWatchExample --query 'DashboardBody' --output text |tee dashboard.json

This command creates a file dashboard.json with the contents of the dashboard body definition. Let’s say we don’t want to see those cryptic ids as a label; instead, we only need the instance name. For that, we need to update the JSON definition and supply a “label” field according to the CloudWatch Dashboard body structure and syntax

Lastly, issue the put-dashboard command with the new dashboard body.

aws cloudwatch put-dashboard –dashboard-name CloudWatchExample –dashboard-body “$(< dashboard.json)”

If you go back to your Dashboards and hit refresh, you should see that the id of the first instance is now replaced with the label we set.

You can go ahead and add more “Widgets” for all the exported Metrics and play around with different styles.

Getting Back to Earth

As you can see, CloudWatch gives you a good foundation for building data visualisation for your instances, with no effort spent on the instances themselves. However, there are following points to keep in mind:

Maintenance — The definition of the dashboard body grows with the number of widgets and instances you add and with that grows the maintenance effort.

Let’s do a quick calculation — say we have a service with 3 instances running in different Availability Zones, and we want to have those in a single dashboard, with all available default metrics.

3 instances X 9 Metrics = 21 widgets

Maintaining that in a script or CloudFormation template could get tedious.

Changing instance ids — CloudWatch uses instance ids in the dashboard definition. In the modern immutable infrastructure world, a recreation of an instance is something that happens quite frequently. Every time that happens, you need to update the definition of the dashboard with the new instance id; otherwise, it will contain stale data.
Linked data — In real-world examples, the instances you have would most likely contain EBS volumes. Although CloudWatch supports several EBS-related metrics, when it comes to linking those to the instances they belong to, you need to modify the definition again yourself and keep track of related instance and EBS ids.

Enter CloudWatch envimation

In order to automate envimate this process, we created a simple HTTP endpoint, which allows you to create CloudWatch dashboards in just 1 HTTP request, without the need to maintain the JSON body. This way, you can easily get an overview of all available Metrics, for the instances you want using name based filtering.

We have made this endpoint available to you via our envimation SaaS product on AWS Marketplace.

You can get to know how to use the product in our Getting-Started page. In upcoming blog posts we will describe in more details how to configure and use the product, what are the benefits when it comes to managing EBS-backed instance monitoring and how to make infrastructure monitoring a part of your CI/CD pipeline.

CloudWatch also provides metrics for ELBs, RDS databases and much more. Our team is working on automating envimating these and we would be glad to hear, which of the CloudWatch options are most of interest to you.