Hyperglance Support

How can we help you today?

Configuring AWS Cloudwatch integration with Hyperglance

Modified on: Tue, 25 Sep, 2018 at 3:03 PM

Hyperglance comes pre-integrated with Cloudwatch. This integration allows the system to recognise and use pre-existing Cloudwatch metrics in Hyperglance's chart functionality.It is possible, and relatively simple, to change this pre-defined list of Cloudwatch/Hyperglance integrated metrics, either adding new ones or removing some, in Hyperglance. This configurability enables the user to view custom metrics on Hyperglance with relative ease.

1. Adding pre-existing AWS Cloudwatch metrics to Hyperglance

Firstly let's go over the process of adding a metric to Hyperglance's configuration. After we've identified a metric that is not currently being shown in Hyperglance but is available on Cloudwatch we have to collect some information about it. Let's assume we initiate a RDS Table, and we go into Cloudwatch. We would probably see something like:

Let's use the highlighted metric, NetworkReceiveThroughput as the example metric to be added to the Hyperglance configuration. Here's some useful information about this metric, that can be obtained from Cloudwatch:

Cloudwatch Name:NetworkReceiveThroughput

Unit:Bytes/Second

This information will be useful when adding the metric into Hyperglance's configuration. The letter is centralized in one XML file called metrics.xml. This file can be found in:

Note: this path may differ from your own Hyperglance installation folder.

This XML file contains all the metrics that Hyperglance accepts from Cloudwatch, regardless of Cloudwatch having more metrics or less. That is, for a metric to be shown in Hyperglance it must be available in Cloudwatch, and correctly configured into Hyperglance. For each metric configured in Hyperglance, if a data mismatch is found between Cloudwatch and Hyperglance, then that metric will NOT be shown.

Briefly going over the XML, we see that there is an entry for each Entity Type that has metrics, out of the box these include:

EC2-Instance

EBS-Volume

Dynamo-DB-Table

RDS-Instance

Elastic-Load-Balancer

Other Entity Types may support metrics, however, they have not been included in the out of the box configuration. Each entity type entry (<node-type>) has the following data, associated to it:

type - The entity type (e.g., EC2-Instance, EBS-Volume)

core dimension - The base dimension used by Cloudwatch to lookup metrics for this type. A dimension is a name/value pair that helps you to uniquely identify a metric

metrics - The metrics that Hyperglance will be interested in, for this type

Following our RDS Instance example, the XML contains the following entry:

Most likely, any possible new metric will fall under the previous entity types, so to add a new metric you just have to add an entry to the metrics list. However, if that is not the case, and a new entity type is required, then the the entity type can be found in Hyperglance's attribute panel for that node and the core dimension can be found on the AWS documentation site. For instance, the core dimension for Storage Gateway types is GatewayId. This information was taken from: http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/awssg-metricscollected.html. With this information, we can just add a new <node-type> element in the XML, and add consequent metrics for it. We will not go into greater detail into this process at the moment.

For the metrics themselves, let us go back to the RDS Instance example. The XML entry for this entity type already comes configured with some out of the box metrics, that map into Cloudwatche's own metrics. It does not, nevertheless, have NetworkReceiveThroughput configured into it, so let us add said metric. Metric XML entries (<metric>) have the following structure:

namespace - The Cloudwatch namespace for this metric

name - The Cloudwatch metric name

ui-name - The Hyperglance metric name (exists purely for UI purposes because Cloudwatch metrics may have week names at times)

unit - The metric's unit

rollups - A list of rollups. The latter represent the transformation applied to the data values obtained from Cloudwatch. A single metric can have 1 or 5 rollups. These are:

Average

Maximum

Minimum

Sum

SampleCount

dimension-groups - A dimension group is a combination of one or more dimensions that can differentiate between different data, for the same metric. We will expatiate this concept when we discuss custom metrics.

To add new metrics we must firstly obtain this information from Cloudwatch. To add NetworkReceiveThroughput to Hyperglance we just have to add an entry in the XML like:

Going over each element. Thenamespaceelement can be obtained from Cloudwatch, particularly fromhttp://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/aws-namespaces.html. Thenameelement is simply the AWS Cloudwatch name for this metric, while theui-nameis the name that will show up on Hyperglance for the specific metric (for a better aesthetic feel). Theunitcan be seen in the Cloudwatch metric page, as illustrated in the above Cloudwatch Dashboard image. Therollupswere, in this case, selected arbitrarily, and are up to each user to decide what fits their needs. Lastly, since this is a simple metric, there are nodimension-groups, represented as an empty element.

Once the metric is defined in the XML, save the changes and restart the Hyperglance server by issuing the command "sudo service wildfly restart" from the CLI. Once the server is back up, you should be able to select the new metric. On Hyperglance you should see something like:

2. Adding Custom AWS Cloudwatch metrics to Hyperglance

Adding custom metrics to Hyperglance is exactly the same process as non-custom metrics. Notwithstanding, it gives us an opportunity to explore other features related to how to customise the way Hyperglance works with AWS metrics. So before moving forward, make sure you're comfortable with the Section 1.

Lets assume, by whichever way, a user introduces a new metric for Target Groups into Cloudwatch. Moreover, lets assume that new metric has the following characteristics:

namespace - AWS/ApplicationELB

name - TargetResponseTime

ui-name - Target Response Time

unit - Seconds

rollups - Average

Additionally, we needed two dimensions for this metric, TargetGroup and LoadBalancer. The later identify the Load Balancer - Target Group pair that this metric is associated to. As a result a single pair of LoadBalancer-TargetGroup can be viewed as a dimension-group, nevertheless groups don't have a limit on how many dimensions they have. As it stands, one of the dimensions is actually a core dimension (TargetGroup) so LoadBalancer will be an extra dimension.

It would look as follows, on Cloudwatch:

To configure this metric in Hyperglance we must add a new <metric> entry in the XML, alongside metrics for Target-Group node-types. The XML would look like:

Quite similar to the previous example but with more configuration parameters, particularly the dimensions. Each <group> (dimension-group) element aggregates a set of 1 or more <dimension> elements. The latter represent an attribute name on Nodes of the type associated to this entry (in this case Target-Group). If you look at the Target-Group's dashboard you should find the attribute in question:

One last aspect is that you can, if you so please, define which rollups are default, and drilling even down, which dimension groups are also default. Default metrics are metrics that show up immediately once a node is selected in Hyperglance. In this case, both dimension-groups are default, and the default rollup for the data is Average. Note: Rollups and groups go hand in hand, and therefore to define a dimension group as default you must also set a rollup as default.

And this is all you need if you require extra dimensions besides the main one. Once again, the server must be restarted (sudo service wildfly restart) in order for new the configuration to be taken into consideration. Now, once the respective node is selected, you can see the metric in Hyperglance, as such: