![]() |
Consumption Analytics Documentation |
The vCenter API provides usage data for a number of resources. The resources supported by Cloud Cruiser are in the <
install_dir>/resource_groups/vcenter.csv
file. This file always reflects the resources supported by the collector.
The “Source” and “Metric” fields in the resource tables for this section indicate exactly what metric, as specified in the corresponding API, is being collected.
Because there cannot be multiple instance of the same identifier or resource in a single record, in the cases where identifiers and resources span multiple instances, you can use the NormalizeUnknownResources
transform in the job XML to merge an identifier and resource into a unique resource name that can be extracted later in the transform process.
The following is an example of its use:
<bean class="com.cloudcruiser.batch.transform.NormalizeUnknownResources"> <property name="active" value="true"/> <property name="resourcePattern" value="vcenter.disk.datastoreCommitted\.(.*)"/> <property name="targetResource" value="vcenter.disk.used"/> <property name="targetIdentifier" value="datastoreName"/> <property name="exceptionProcessing" value="true"/> </bean>
For example, in the case of bytes used in a volume, a VM could be using more than one datastore or virtual disk. So instead of having an identifier of datastoreName=MyDatastore
and a resource of vcenter.disk.used=12345
, the collector instead merges these together into a resource like the following:
vcenter.disk.datastoreCommitted.MyDatastore=12345
The identifier value becomes part of the unique name of the resource and the NormalizeUnknownResources
processor allows you to separate these parts into the datastoreName
identifier and vcenter.disk.used
resource later in the transform process.
The following is a list of resource prefixes that can also be included in output records:
vcenter.net.network
vcenter.net.portgroup
vcenter.net.switch
vcenter.disk.datastoreCommitted
vcenter.disk.datastoreUncommitted
vcenter.disk.datastoreUnshared
Where applicable, these resource prefixes will have identifier values appended in the output record. For example, if a particular VM has an association to a network object called internal_only
, a “ vcenter.net.network.internal_only=1
” would be included in the output record.
These prefixes are useful when a particular naming convention is used for objects and you want to charge differently based on the object name. For example, if you charge different costs for access to the “ DSTier1xxxx
” datastore versus the “ DSTier2xxxx
” datastore, you can have a batch transform step in your collection job that performs this pattern matching and generates new custom resources based on the result.
The collector cannot anticipate what the possible names will be in a given environment so there are no costs associated with these resources, by default.
(c) Copyright 2017-2020 Hewlett Packard Enterprise Development LP