CloudWatch Logs Dashboards
Amazon CloudWatch Dashboards is a feature of AWS CloudWatch that offers a basic monitoring home page for your AWS account. It provides status and performance views of resources via graphs and gauges. Dashboards can monitor resources in multiple AWS regions to present a cohesive account wide view of your account.
Dashboards works with with other CloudWatch features to provide log management, performance metrics, events streams and alarms.
Multiple Dashboards are supported with one dashboard being designated the default dashboard to display when the CloudWatch Dashboards page is displayed.
Your first three dashboards are free, thereafter, dashboards are priced at $3 per month per dashboard. Not very cheap. As dashboards can be unlimited in length, you may wish to have multipage dashboards rather than creating many separate smaller dashboards.
- Can have cross region dashboards
CLI Console API CloudFront Terraform CDK
Dashboards are composed of a grid 24 cells wide upon which graphical widgets can be positioned. CloudWatch supports line, stacked area, numeric, query and text widgets.
It is easy to align and resize widgets by draging and stretching widgets into your desired order and position.
//Image of each type?- Charts: line, stacked area, numerics - Markdown to share playbooks, references, links - Colors - Missing: gauges, (see graphana), On/Off indicators
Markdown widgets can contain text, links, images and buttons. These are useful to provide context, operational playbooks and immediate actions.
- Live updating
- UTC / Local ? Link Graphs
- Full screen
- Metrics are specific to a region in which they are created
You can also use Metric Math to create computed metrics and include them in your dashboards. For example, the Status Codes widget below uses Metric Math to calculate the number of 2XX responses which is not available as a metric
How you specify a dimension is different when you use different commands. With put-metric-data, you specify each dimension as MyName=MyValue, and with get-metric-statistics or put-metric-alarm you use the format Name=MyName, Value=MyValue. For example, the following command publishes a Buffers metric with two dimensions named InstanceId and InstanceType.
Resolution Each metric is one of the following:
- Standard resolution, with data having a one-minute granularity
- High resolution, with data at a granularity of one second
Search expressions in dashboards
You can now use search expressions to define Amazon CloudWatch dashboards. This enables you to create dashboards that update automatically as new resources are created that match the search query, providing up-to-the-minute visibility with reduced operational overhead.
The search function is an enhancement of Amazon CloudWatch metric math and can be combined within math functions like SUM, AVG, MIN, and MAX. For example, you can combine SUM with SEARCH to track the count of failed health checks across all EC2 instances in an account.
aws cloudwatch put-metric-data --metric-name Buffers --namespace MyNameSpace --unit Bytes --value 231434333 --dimensions InstanceId=1-23456789,InstanceType=m1.small
Aggregated multiple values
aws cloudwatch put-metric-data --metric-name PageViewCount --namespace MyService --statistic-values Sum=11,Minimum=2,Maximum=5,SampleCount=3 --timestamp 2016-10-14T12:00:00.000Z
If you call this command with a new metric name, CloudWatch creates a metric for you. Otherwise, CloudWatch associates your data with the existing metric that you specified.
When you create a metric, it can take up to 2 minutes before you can retrieve statistics for the new metric using the get-metric-statistics command. However, it can take up to 15 minutes before the new metric appears in the list of metrics retrieved using the list-metrics command.
It’s simple and tells me the general health of the API at a glance.
“Keeping it simple” is easily the most important advice for building effective dashboards. It’s also the most difficult to follow because the temptation is always to add more information to dashboards. As a result, they often end up cluttered, confusing to read and slow to render as there are far too many data points on the screen.
Here are a few tips for building service dashboards:
Use simple (boring) visualizations. Use horizontal annotations to mark SLA thresholds, etc. Use a consistent colour scheme. Put the most important metrics at the top to create a hierarchy. Also bear in mind that widgets below the fold are rarely seen.
This page has some simple guidelines for designing dashboards. Stephen Few’s Information Dashboard Design is also a great read if you want to dive deeper into data visualization with dashboards.
Tip 1: yes, you can get metrics using your timezone
Is this a relief or what! I spent too much time calculating what my time is compared to UTC so I could figure out when my latency peak is, until I found this little jewel at the top of the dashboard, in time selection. It’s not so easy to spot so here it is:
Tip 2: Put some reference (annotation) lines in there
Metrics in your charts change over time, so it’s helpful to set a few reference lines. AWS calls them annotations. You can set them in the Graph Options tab in the metric edit view.
Tip 3: Look at peaks instead of averages
By default, the metrics you create in the AWS CloudWatch dashboards are averages. This is good information, but what if you need to identify peaks, for example CPU peak times? They don’t show up in the averages at all. Consider this visualisation