GWME-7.2.1-00 version 4122 Rollup Patch Details

Overview

The 7.2.1 Rollup Patch installer version 4122 includes fixes for issues in the downtime scheduler, SLA reports and SLA dashboards, and in the Cloud Hub VMware and AWS connectors.

The following is a description of the main issues that are addressed by applying the Rollup Patch installer version 7.2.2-gw4122, incrementally. If you have an unpatched 7.2.1 system, this rollup patch will include all changes and updates made through patch 4118, and the additional changes listed here. There is no need to install other patches first.

Each patch installer creates a backup directory that contains all the changed files for that patch. You may view the changed files on your system at

 /usr/local/groundwork/backup-gwNNNN/files

where NNNN is the number of the patch prior to the one currently installed. Thus, the files changed by patch 4118, for example, will appear when you install patch 4122 in

 /usr/local/groundwork/backup-gw4118/files

, and can be restored (rolled back) from there.

Changes made in this patch installer

(beyond those included from patch 4118)

Issues addressed with RStools components

1. SLA processing doesn't respect day borders if duration is more than one day
   This patch fixes this issue with SLA processing in GroundWork. Some processes were not computing SLAs correctly.

Cloud Hub fixes and enhancements

1. VMware connector support for TLS1.2
   The VMware connector now supports TLS v1.2, allowing you to connect to later vSphere™ servers.
2. VMware support of FQDN or VM Name
   The VMware connector now allows you to use the fully qualified domain name (as listed in the VMware VM information) as the Hostname in GroundWork, or to use the VM instance name. Previously, only the instance name was supported. This allows you to more easily use GDMA on the VM and "merge" the hosts. See the "FQDN" checkbox in the VMware Cloud Hub connector screen.
3. AWS connector format support
   There was a bug in the AWS connector in that it did not support metric format strings. This would make for less detailed readings for some metrics (e.g., EBS.VolumeReadTime, which would show as zero if the measured value was < 1). You can now edit the metrics and apply the format string you want to them (e.g., %.3f to get 3 digits after the decimal point).
4. AWS connector perfomance fixes
   The AWS connector was not using spring or caching. This has been added. Testing indicates about a 35% increase in speed.
5. Added aggregations for AWS metrics
   The AWS connector now supports all metric aggregations, where previously only AVERAGE was supported. You can select the aggregation for each metric, where supported. You will need to determine which aggregation is supported, as some metrics do not support some aggregations. See the CloudWatch API documentation for details.
6. Added support for dynamic synthetic metrics
   Previously, new synthetic metrics would need to be specified for each instance of a dynamic resource (currently this is limited to a volume ID). The connector now allows such synthetics to use macros to represent the dynamic volume IDs as "VolumeID", so that newly added volumes will get the metric automatically. For example:

   <metric serviceType="storage" name="volume-{{VolumeId}}-read-write-ops-sum" monitored="true" graphed="true" warningThreshold="2000" criticalThreshold="2500" computeType="synthetic" sourceType="storage" format="%.0f" expression="EBS.{{VolumeId}}-VolumeReadOps + EBS.{{VolumeId}}-VolumeWriteOps" 
   description="Example of dynamics in synthetic metrics""/>

7. Support for VPC name
   VPCs in AWS are represented as host groups in GroundWork. These are now reported by VPC Name, as opposed to the more arcane VPC ID. There is no longer a host resource object created for each VPC, as the utility of that object was questionable and it did consume a licensed host entry.
8. Added support for additional metrics in the AWS connector
   Certain metrics were not available for monitoring unless they were in the profile xml already. All metrics in a given category can now be selected from the "Add Normal Metric" dialog in that category.
9. Thresholds by Hostname (via tags in AWS)
   The AWS connector now supports adding thresholds specifically for hosts with a particular tag key and value. For example, if you have a tag called "Name", you can specify a threshold for a given metric by adding the tag key "Name" and tag value "host1" to the threshold definition to have that threshold apply to just that host. At the moment this is only possible by direct editing of the profile xml file.
   Here's a quick example. Once you create an AWS Cloud Hub connector, it will create an active configuration using the defaults in the file:

   /usr/local/groundwork/core/vema/profiles/amazon_monitoring_profile.xml

   The active file is of the form:

   /usr/local/groundwork/config/cloudhub/profiles/amazon-ede884ed-813f-4087-8974-8208cad49f50.xml

   To override a threshold for a given metric, copy the metric definition to near the bottom of the file, adding an overrides section, for example:

       <overrides>
           <metric serviceType="hypervisor" name="EC2.CPUUtilization" monitored="true"
   graphed="true" warningThreshold="90.0" criticalThreshold="100.0"
   description="Percentage of allocated EC2 compute units currently in use on EC2 instance"
   tagName="Name" tagValue="myhost"/>
       </overrides>

   This will override the default thresholds for the EC2.CPUUtilization service metric specifically for the host called "myhost", provided that this host has a tag key called "Name" with value "myhost". This can be generalized to any tag key and value, allowing threshold overrides for any subset of the infrastructure monitored by this connector.

As always should you have any questions about this rollup patch, please contact support for assistance.