vROps Supermetric Conditionals and resource entry aliasing

Introduction

Whilst vROps supermetrics are awesome, there are two features that make them even better:

  1. Resource entry aliasing
  2. Creating condition based supermetrics

The first feature can make complex supermetrics easier to create by allowing a metric to be assigned an alias which can be reused later in the supermetric

The second feature allows logic to be applied to supermetric calculation resulting in the ability to create significantly more complex supermetrics.

The example below shows a supermetric using both of these features

${this, metric=cpu|corecount_provisioned} as cpucount>1?${this, metric=cpu|actual.capacity}/cpucount:${this, metric=cpu|actual.capacity}

The cpu|corecount_provisioned metric is assigned an alias of cpucount, and this alias is reused later in the expression. The supermetric also makes use a conditional element to evaluate the number of cores provisioned to the virtual machine and calculating a value based on whether the result is true of false.

The supermetric is determining whether the virtual machine has more than one vCPUs. If it does then a calculation is made for the Mhz per core by dividing the current Mhz size of the virtual machine by the number of cores. If the VM doesn’t have more than one core then the Mhz per core is simply the current Mhz value. This super metric is only given as an example to show the use of aliases and conditional evaluation as the same result could be derived simply by dividing the current Mhz value by the number of cores.

The format of the conditional supermetric is as follows:

Expression to evaluate ? If true : If false

Transformation of the result can also be performed once the expression has been evaluated:

Transformation(Expression to evaluate ? If true : If false)

To better understand the use of conditionals consider the following examples:

1+1 > 1 ? 10 : 20 - This would return 10 as 1 + 1 is greater than 1

A super metric involving a transformative function is as follows:

avg(2+2>3?[10,15,20]:[20,25,30]) - This would return 15 as this is the average of 10, 15 & 20

Supermetrics support a number of different means of evaluation which are similar to those found in most programming languages:

comparator Description
> Greater than
>= Greater than or equal to
<= Less than or equal to
< Less than
== Equal to
!= Not equal to

Examples of the different comparators are as follows:

sum(1+1>=3?[1,2,3]:[4,5,6]) - This would return 15 as 1+1 is not greater than or equal to 3 and the result is the sum of 4+5+6

sum(1+1<=3?[1,2,3]:[4,5,6]) - This would return 6 as 1+1 is less than or equal to 3 and the result is the sum of 1+2+3

count(1+1==3?[3,5,7]:[1,2,3,4,5,6]) - This would return 6 as 1+1 does not equal 3 and the result is the count of the objects

max(1+1!=3?[3,5,7]:[1,2,3,4,5,6]) - This would return 7 as 1+1 does not equal 3 and the result is the maximum value of 3,5 & 7

The conditional supermetrics can be further enhanced  to include AND & OR statements:

Logic Description
&& AND
|| OR
1+1==2&&2+2==4?10:20 - This would return 10 as 1+1 does equal 2 and 2+2 does equal 4

1+1==2||2+2==5?10:20 - This would also return 10 as the expression is true if either 1+1  equals 2 OR 2+2 equals 5.

These can also be combined into ever more complex supermetrics:

1+1==2&&(2+2==4||3+3==7)?25:50 - To return true (and a value of 25), 1+1 must equal 2 AND either 2+2 must equal 4 OR 3+3 must equal 7 - This expression will return true

The examples shown above all use simple integer based expressions to explain them more easily, but the real power is when these are used with actual metrics:

${this, metric=guestfilesystem|capacity_total} as totalcapacity > 200 &&${this, metric=guestfilesystem|percentage_total} as percentused<95?totalcapacity:((totalcapacity/100)*percentused)+20

In this example, the total capacity of the guest file system is evaluated to determine whether it is greater than 200GB. Also the disk usage is evaluated to determine whether it is less than 95%. If both conditions are true then the result is the total capacity but if either is false i.e the disk is less than 200GB in size or the usage is greater than 95% then the returned value is equal to the current usage plus 20GB. The result is that a value for all guests is calculated that gives at least 20GB of free space.

Setting scoreboard widget to not use colours via metricconfig.xml files

Introduction

There are often occasions when it is not desirable to use colour coding for certain metrics on scoreboard dashboards. These are often metrics for which there is no obvious change in state such as the amount of memory configured or amount of provisioned disk space. These metrics rarely change value, but more importantly a change in value does not necessitate a change in health state. For these metrics it can be more useful to not display colours on a scoreboard widget as they can distract end users from important state change data. Additionally, these metrics may have values that have valid reasons for varying between object types, thereby making assigning colour changes very challenging.

Dashboard Overview

The image below shows a dashboard with three widgets:

  1. Object picker
  2. Self providing scoreboard
  3. Scoreboard with the object being derived from the object picker and the metrics from a metricconfig.xml file

Screen Shot 2018-01-30 at 22.26.30

Each scoreboard widget has four metrics with one (co-stop) deriving its state from symptoms, two (ready time and swap wait) from custom colours and the fourth (total capacity) utilising no colours as it makes little sense for this metric to display colours as a) it could vary between hosts and b) is unlikely to ever change.

Defining state and colour changes via the widget

As a reminder, the colours for metrics that are defined directly on the scoreboard widget are configured by selecting the appropriate setting under ‘Color Method’ when editing the widget:

Screen Shot 2018-01-30 at 22.27.06

Defining state and colour changes via a metriconfig.xml file

To achieve the same result via a metricconfig.xml file the following code is used:

Screen Shot 2018-01-30 at 22.27.57

Specifically the following is added to the end of each Metric entry:

showState="false"

 

Using PowervROps cmdlets (part 3) – Adding metrics and properties to objects

Introduction

In the third part in this series of blog posts we are going to use the cmdlets to add metrics and properties to various objects, these metrics and properties can be used in exactly the same way as those from management packs, although you should be aware that metrics age and are not available on dashboards or for use in super metric calculations after a period of time. For dashboards this appears to be roughly four hours and for super metrics this is after 48 hours.

The functions

There are three functions available within PowervROps for adding properties and metrics:

  1. addProperties
  2. addStats
  3. addStatsforResources

The first and second functions enable properties and stats (metrics) to be added to a single vROps object (multiple properties and metrics can be added in a single command). The third command allows metrics to be added to multiple objects in a single command, which is much more efficient in large environments, although there is a limit of 1000 objects in a single execution. There is no comparable API method to add properties to multiple objects via a single command.

How to use

As discussed in part 1 of this blog series, before any cmdlets can be run a means of authentication needs to be configured. As with previous blog posts the examples shown will use token based authentication, although credentials based is perfectly fine. In all examples shown a variable of $token will be used.

All three functions require body content to be submitted along with the command. The functions will accept both JSON and XML (as the vROps API accepts both). For the purposes of this blog JSON will be used throughout. More information can be found about different request examples via the vROps API document (https://vropsfqdn/suite-api/docs/rest/index.html). The functions within PowervROps match the name shown in the documentation so should be easy to locate.

The addProperties and addStats functions also require an objectid to be submitted along with the request. Examples are shown in part 1 of this blog series

Examples

addProperties

In this example we are going to add a property called ‘CloudKindergarten|Demo|DevicePurpose’ with a value of ‘Active Directory Domain Controller’ to the virtual machine ‘vm-a’

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$object = getresources -resthost $resthost -token $token -name 'vm-a' -resourceKind 'VirtualMachine'
$body = @{
 'property-content' = @( @{
 'statKey' = 'CloudKindergarten|Demo|DevicePurpose'
 'timestamps' = @(getTimeSinceEpoch)
 'values' = @('Active Directory Domain Controller')
 'others' = @()
 'otherAttributes' = @{}
 }
 )
}
addProperties -resthost $resthost -token $token -objectid $object.resourcelist.identifier -body ($body | convertto-json -depth 5) -contenttype 'json'

This example shows a JSON body content. If the body was in XML format then the addProperties command would be altered as below:

addProperties -resthost $resthost -token $token -objectid $object.resourcelist.identifier -body ($body | convertto-json -depth 5) -contenttype 'xml'

We can see below that the property is displayed in the All Metrics page and can be selected in the same way as any other property:

Screen Shot 2018-01-30 at 13.22.34

We can also retrieve this property using the getResourceProperties function:

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$object = getresources -resthost $resthost -token $token -name 'vm-a' -resourceKind 'VirtualMachine'
$resourceproperties = (getresourceproperties -resthost $resthost -token $token -objectid $object.resourcelist.identifier).property | where { $_.name -eq 'CloudKindergarten|Demo|DevicePurpose'}
$resourceproperties

This returns the following:

Screen Shot 2018-01-30 at 13.40.48

addStats

The second example shows adding a single metric to a virtual machine. The metric name is ‘CloudKindergarten|Demo|SingleMetricOne and a random value of between 1 and 100  will be added. The code includes an additional unnecessary line that generates the random number, and this variable is used within the JSON body.

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$object = getresources -resthost $resthost -token $token -name 'vm-b' -resourceKind 'VirtualMachine'
$metricvalue = get-random -Minimum 1 -Maximum 100
$body = @{
'stat-content' = @( @{
'statKey' = 'CloudKindergarten|Demo|SingleMetricOne'
'timestamps' = @(getTimeSinceEpoch)
'data' = @($metricvalue)
'others' = @()
'otherAttributes' = @{}
}
)
}
addStats -token $token -resthost $resthost -objectid $object.resourcelist.identifier -body ($body | convertto-json -depth 5) -contenttype json

In the image below the results of running the command many times in a short space are shown.

Screen Shot 2018-01-30 at 15.56.27

When running this command, it is not limited to single metric, nor a single data point. In the example below values for two different metrics are being added for datapoints at five minute intervals for the last hour.

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$object = getresources -resthost $resthost -token $token -name 'vm-c' -resourceKind 'VirtualMachine'
$metricvaluesone = @()
$metricvaluestwo = @()
$timestamps = @()
for ($i = 0;$i -lt 12;$i++) {
$metricvaluesone += (get-random -Minimum 1 -Maximum 100)
$metricvaluestwo += (get-random -Minimum 1 -Maximum 100)
$timestamps += gettimesinceepoch -date (get-date).AddMinutes(($i*-5))}
$body = @{
'stat-content' = @( @{
'statKey' = 'CloudKindergarten|Demo|SingleMetricOne'
'timestamps' = $timestamps
'data' = $metricvaluesone
'others' = @()
'otherAttributes' = @{}
}
@{
'statKey' = 'CloudKindergarten|Demo|SingleMetricTwo'
'timestamps' = $timestamps
'data' = $metricvaluestwo
'others' = @()
'otherAttributes' = @{}
}
)
}
addStats -token $token -resthost $resthost -objectid $object.resourcelist.identifier -body ($body | convertto-json -depth 5) -contenttype json

The results can be seen in the image below

Screen Shot 2018-01-30 at 16.33.39.png

addStatsforResources

In the last example multiple metrics are going to be added to multiple VMs. Specifically the following metrics are going to be added:

  • CloudKindergarten|Demo|MultiMetricOne – with a random value between 1 and 100
  • CloudKindergarten|Demo|MultiMetricTwo – with a random value between 1 and 100
  • CloudKindergarten|Demo|MultiMetricThree – with a random value between 1 and 100

These metrics are going to be added to the following VMs:

  • vm-a
  • vm-b
  • vm-c
  • vm-d
  • vm-e
    import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
    $resthost = 'vrops-01a.cloudkindergarten.local'
    $token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
    $metrictime = getTimeSinceEpoch
    $allvms = @('vm-a','vm-b','vm-c','vm-d','vm-e')
    $allvmstatcontent = @()
    foreach ($vm in $allvms) {
    $object = getresources -resthost $resthost -token $token -name $vm -resourceKind 'VirtualMachine'
    $statcontent = @()
    $statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricOne';timestamps=@($metrictime);data=@((get-random -Minimum 1 -Maximum 100));others=@();otherAttributes=@{};}) 
    $statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricTwo';timestamps=@($metrictime);data=@((get-random -Minimum 1 -Maximum 100));others=@();otherAttributes=@{};})
    $statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricThree';timestamps=@($metrictime);data=@((get-random -Minimum 1 -Maximum 100));others=@();otherAttributes=@{};})
    $vmstatdetail = @{
     'id' = $object.resourcelist.identifier
     'stat-contents' = $statcontent
    }
    
    $allvmstatcontent += $vmstatdetail
    
    }
    $vmstatcontent = @{
     'resource-stat-content' = $allvmstatcontent
     }
    
    addstatsforresources -resthost $resthost -token $token -body ($vmstatcontent | convertto-json -depth 10)

The outcome of this can be seen via a view in vROps

Screen Shot 2018-01-30 at 17.00.20

As with the addStats function, multiple data points can be added with the addstatsforresources function:

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$allvms = @('vm-a','vm-b','vm-c','vm-d','vm-e')
$allvmstatcontent = @()
foreach ($vm in $allvms) {
$object = getresources -resthost $resthost -token $token -name $vm -resourceKind 'VirtualMachine'
$metricvaluesone = @()
$metricvaluestwo = @()
$metricvaluesthree = @()
$timestamps = @()
for ($i = 0;$i -lt 12;$i++) {
$metricvaluesone += (get-random -Minimum 1 -Maximum 100)
$metricvaluestwo += (get-random -Minimum 1 -Maximum 100)
$metricvaluesthree += (get-random -Minimum 1 -Maximum 100)
$timestamps += gettimesinceepoch -date (get-date).AddMinutes(($i*-5))}
$statcontent = @()
$statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricOne';timestamps=$timestamps;data=$metricvaluesone;others=@();otherAttributes=@{};})
$statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricTwo';timestamps=$timestamps;data=$metricvaluestwo;others=@();otherAttributes=@{};})
$statcontent += (@{statKey='CloudKindergarten|Demo|MultiMetricThree';timestamps=$timestamps;data=$metricvaluesthree;others=@();otherAttributes=@{};})
$vmstatdetail = @{ 'id' = $object.resourcelist.identifier 'stat-contents' = $statcontent}
$allvmstatcontent += $vmstatdetail}
$vmstatcontent = @{ 'resource-stat-content' = $allvmstatcontent }
addstatsforresources -resthost $resthost -token $token -body ($vmstatcontent | convertto-json -depth 10)

The results can be seen for the three metrics on three different virtual machines:

Screen Shot 2018-01-30 at 19.39.19

All posts in this series:

Using PowervROps cmdlets (part 1) – Introduction

Using PowervROps cmdlets (part 2) – Retrieving metrics from objects

Using PowervROps cmdlets (part 3) – Adding metrics and properties to objects

Using PowervROps cmdlets (part 4) – Working with objects

Using PowervROps cmdlets (part 5) – Working with relationships

Using PowervROps cmdlets (part 6) – Working with custom groups

Using PowervROps cmdlets (part 7) – Working with supermetrics

Using PowervROps cmdlets (part 8) – Working with reports

Using PowervROps cmdlets (part 9) – Working with alerts

 

Using PowervROps cmdlets (part 2) – Retrieving metrics from objects

Introduction

This is the second in a series of posts about PowervROps and the available functions. This post will focus on the ability to query metric data from objects in vROps. Two functions are available to query the stats held for resources:

  • getLatestStatsofResources
  • getStatsForResources

The former returns just the latest value for the given resource IDs and metrics, whilst the latter allows a large degree of customisation over the time frame of metrics and rollup of data e.g. averages or maximums within specified time frames

getLatestStatsofResources

This is the simpler of the two functions available, but as a consequence only returns the latest data point for each metric. The example below shows the value for the metric ‘mem|guest_demand’ for the VM ‘esxi-04a’

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$object = getresources -resthost $resthost -token $token -resourceKind 'VirtualMachine' -name 'esxi-04a'
$stats = getLatestStatsofResources -resthost $resthost -token $token -objectid $object.resourceList.identifier -statkey 'mem|guest_demand'
$stats.values.'stat-list'.stat

The output of this script is as follows:

Screen Shot 2018-01-30 at 21.38.28

getStatsForResources

The getStatsForResources function can return a vast amount of data and perform transformation of that data in a similar manner available within vROps views. The function requires a body element that contains the query parameters.

The example below queries all virtual machines for a single metric; mem|guest_demand. The data returned in this example returns all data at five minute intervals for the last hour

import-module c:\users\taguser\documents\github\powervrops\powervrops.psm1
$resthost = 'vrops-01a.cloudkindergarten.local'
$token = acquiretoken -resthost $resthost -username admin -password VMware1! -authsource local
$allvms = getresources -resthost $resthost -token $token -resourceKind 'VirtualMachine'
$resourcelist = @()
$metricstoquery = @('mem|guest_demand')
foreach ($vm in $allvms) {
$resourcelist += $vm.resourcelist.identifier
}
$body = @{
'resourceId' = $resourcelist
'statKey' = $metricstoquery
'begin' = (getTimeSinceEpoch -date ((get-date).AddHours(-1)))
'end' = (getTimeSinceEpoch)
'rollUpType' = 'LATEST'
'intervalType' = 'MINUTES'
'intervalQuantifier' = 5
'dt' = $false
'latestMaxSmaples' = 1
} | convertto-json -depth 10
$statsofresources = getStatsForResources -resthost $resthost -token $token -body $body
foreach ($statentry in $statsofresources.values) {
write-host ''
write-host ("Virtual Machine: " + ($allvms.resourceList | where { $_.identifier -eq $statentry.resourceid }).resourcekey.name)
foreach ($stat in $statentry.'stat-list') {
write-host ('Metric: ' + $stat.stat.statkey.key)
for ($i=0;$i -lt $stat.stat.timestamps.count;$i++) {
write-host (((Get-Date '1/1/1970').AddMilliseconds($stat.stat.timestamps[$i])).datetime + ' | ' + $stat.stat.data[$i])
}
}
}

The example above outputs the data to the powershell session, but in practice once the data has been returned then it can be used in any way.

Screen Shot 2018-01-30 at 20.49.20

The data held in vROps can be queried and returned in a number of different ways. The relevant elements to modify are as follows:

'resourceId' = $resourcelist

An array of vROps identifiers

'statKey' = $metricstoquery

An array of metrics to query

'begin' = (getTimeSinceEpoch -date ((get-date).AddDays(-7)))
'end' = (getTimeSinceEpoch)

The start and end times for the queried data. In the example above all data from the current time and for the last seven days will be queried.

'rollUpType' = 'LATEST'

How the data will be transformed. Available options are as follows:

SUM – The sum of all datapoints in each interval period
AVG – The average of the datapoints in each interval period

Screen Shot 2018-01-30 at 21.19.13
MIN – The minimum value of the datapoints in each interval period
MAX – The maximum value of the datapoints in each interval period

Screen Shot 2018-01-30 at 21.20.17
LATEST – The most recent sample of the datapoints in each interval period (see the example for interval type below to better describe the data that will be returned)
COUNT – The number of samples within each interval period

Screen Shot 2018-01-30 at 21.18.24

Take care when using a large time frame with a small interval type and a large number of metrics and resources as it can take a long time for the data to be returned

'intervalType' = 'MINUTES'
'intervalQuantifier' = 5

The time interval between data points. Note that if using any interval period beyond hours then the values returned will have time stamps of the last second of each hour. They will not be for hour points directly preceding the time at which the query is executed. An example of this is shown below:

Screen Shot 2018-01-30 at 21.15.09

In this example, the data point for 21:59:59 is the last data point in the hour between 21:00:00 and 21:59:59 which in this case is actually 9:09:13 – the query was run at approximately 21:14:00. The data point for 20:59:59 is the last value between 20:00:00 and 21:59:59 which was actually at 21:59:13

Using PowervROps cmdlets (part 1) – Introduction

Using PowervROps cmdlets (part 2) – Retrieving metrics from objects

Using PowervROps cmdlets (part 3) – Adding metrics and properties to objects

Using PowervROps cmdlets (part 4) – Working with objects

Using PowervROps cmdlets (part 5) – Working with relationships

Using PowervROps cmdlets (part 6) – Working with custom groups

Using PowervROps cmdlets (part 7) – Working with supermetrics

Using PowervROps cmdlets (part 8) – Working with reports

Using PowervROps cmdlets (part 9) – Working with alerts