Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
If you publish your own custom metrics to AWS CloudWatch, you can quickly modify existing LogicMonitor AWS datasources or create new AWS datasources to collect these metrics. Before doing this, we recommend that you enable monitoring via a local Collector for your AWS resources, to see if LogicMonitor’s native collector datasources report the custom metrics you’d like to see. If you do need to edit an AWS Datasource in order to enable LogicMonitor to collect your custom CloudWatch metrics, you can follow the steps below.
Most of LogicMonitor’s AWS Datasources are already configured to query the CloudWatch API. You can tell whether a datasource is collecting information from CloudWatch or not by looking at the Collector field in the datasource definition:
If the Collector field has a value of ‘AWS CLOUDWATCH’, then you can easily modify or clone it to collect your custom metrics.
Once you’ve identified a DataSource and either cloned it or are ready to modify it, you’ll need to identify a DataPoint to start from – you’ll start from an existing DataPoint and modify it to collect the custom data you desire. At the bottom of the datasource definition you’ll see all of the datapoints (individual metrics) being collected. Click the manage gear icon for any normal datapoint and then click ‘Clone’ in the bottom right hand corner of the datapoint configuration dialog. Note that you need to clone a normal datapoint (cloning a complex datapoint won’t work) – you can tell whether the datapoint is complex or normal by looking at the title of the datapoint configuration dialog:
The Metric path is what tells LogicMonitor which information to collect from CloudWatch. The syntax for the Metric path is:
where Dimensions should be one or more key value pairs in this format:
Dimensions = DimensionName1:DimensionValue1>DimensionName2:DimensionValue2
and so on and so forth.
Note: Because spaces are allowed in CloudWatch metric names, white spaces in the metric path will be interpreted by LogicMonitor as a space in the specified name. Avoid using white spaces where they aren’t included in your CloudWatch metrics. Also, some metrics may not have an aggregation method or may only expose certain aggregation methods. The easiest way to ensure that you construct the metric path correctly is to use an AWS tool such as the AWS CLI to list-metrics. After doing so, you can edit the Metric Path for a cloned or new datapoint like so:
Save your new datapoint and then save the datasource. LogicMonitor will automatically begin collecting this data for any AWS device that the edited datasource is applied to.
Note: You can define custom AWS Cloudwatch metrics that include “greater than” and “less than” characters in the metric path. But because the “>” character is interpreted as a dimension separator, you need to substitute the “<” and “>” characters with “[[” and “]]” respectively. For example, the metric path cloudwatch>path should be entered as cloudwatch]]path within LogicMonitor.
The following example illustrates adding a datapoint to the AWS_Route53 datasource to monitor SSLHandshake Time. While not a custom CloudWatch metric, this is a metric that was somewhat recently introduced by AWS (and as such will be added automatically to the AWS_Route53 datasource, but the process for editing / adding datapoints to AWS datasources is still illustrated).
First, a list-metrics with the AWS CLI displays the following:
We can then clone an existing datapoint for the AWS_Route53 datasource and change the Metric Path to the following:
Typically, issues arise because of the following:
You can identify which specific issue is occuring with the Poll Now functionality for your DataSource – you can find the Poll Now option on the Raw Data tab. It’ll display the request LogicMonitor makes to AWS for your DataSource, as well as any errors AWS returns.