Configuring Performance Metrics for vCloud Director 9.5

With vCloud Director version 9.0, performance metrics of virtual machines can be directly displayed in the new HTML5 Tenant portal for customers. All it takes is a Cassandra database cluster and a few small configurations on the vCloud Director side. Sounds simple, doesn’t it? That’s it, too, if you consider a few pitfalls.

Yesterday I published an article on how to get a Cassandra database cluster running for vCloud Director 9.5. Today I’ll show you how to use it for the metric collection and how to display these metrics for customers in the vCD Tenant UI.

Some of these performance counters are already implemented in vCloud Director, but they can only be used if you connect Cassandra to vCD. In addition, we want to make more metrics available to our customers.

So, let’s start with the simple part.

Which performance metrics does vCloud Director already know and which ones are basically available?

By default, vCloud Director 9.5 is aware of the following performance metrics:

  • cpu.usage.average
  • cpu.usage.maximum
  • cpu.usagemhz.average
  • mem.usage.average
  • disk.provisioned.latest
  • disk.used.latest
  • disk.write.average

But vCenter knows much more performance counter. You can see this if you look at the performance views for virtual machines in the vSphere (Web) Client.

Chris Greene has written a PowerCLI script that outputs all available performance counters including name and description as CSV file. Thanks for that, Chris.

And this list is long. In total there are about 564 performance metrics for vSphere 6.7, but only a small part of them is useful for vCD customers.

How can I implement these metrics in vCD?

For this we have to create a configuration file, which vCD can read via the cell-management-tool. The VMware documentation gives some information about how this file should look like and which additional parameters are available for the metrics collection.

It is important that this configuration file does not contain metrics that vCloud Director already knows. Otherwise, errors will occur during the Cassandra database configuration.

My configuration file is called “metrics.groovy” and looks like this:

configuration {

As a side note:
If you only want to use the already existing performance counters, you can skip this step completely and go directly to the configuration of the Cassandra database.

This configuration file must now be applied to vCloud Director. We do this via the cell-management-tool and therefore the vcloud user has to be able to read this file as well. So maybe, you want to check the path and file permissions.

./cell-management-tool configure-metrics --metrics-config /tmp/metrics.groovy

If there is no syntax error, the cell-management-tool will not produce any output.

This allows us to move on to the next step and do the Cassandra configuration.

The configuration of metric collection in vCloud Director 9.5

It actually only needs one command:

./cell-management-tool cassandra --configure --create-schema --cluster-nodes,,, --username vcloud --password 'secretP@ssw0rd!' --port 9042 --ttl 30

With the option “–create-schema” we specify that the keyspace and tables must be recreated. If you have already configured performance metrics and only want to extend them with additional metrics, you have to use “–update-schema“. But there is a bug in vCloud Director 9.0 and 9.1 (see here).
With “–ttl” we can specify the number of days how long the historical metrics should go back. In my example 30 days.

If everything is successful, you should see the following output:

Verifying Cassandra settings...
Cassandra setting valid for node:
Cassandra setting valid for node:
Cassandra setting valid for node:
Cassandra setting valid for node:
Cassandra configuration settings verified successfully
vcloud_metrics keyspace created...
vm_metrics table created...
adding configured metrics to the schema...
adding counter: disk.write.average
adding counter: cpu.usage.maximum
adding counter: cpu.usage.average
adding counter:
adding counter: disk.used.latest
adding counter: disk.provisioned.latest
adding counter: mem.usage.average
adding counter: cpu.usagemhz.average
adding counter: cpu.usagemhz.maximum
adding counter: cpu.wait.summation
adding counter: cpu.used.summation
adding counter: cpu.idle.summation
adding counter: mem.usage.maximum
adding counter: mem.granted.average
adding counter: mem.granted.maximum
adding counter:
adding counter:
adding counter: mem.consumed.average
adding counter: mem.consumed.maximum
adding counter: net.usage.average
adding counter: net.usage.maximum
adding counter: net.bytesRx.average
adding counter: net.bytesTx.average
adding counter: disk.numberReadAveraged.average
adding counter: disk.numberWriteAveraged.average
vapp_metrics table created...
vdc_metrics table created...
org_metrics table created...
Persisting Cassandra settings...

Success. The monitoring service is now configured to persist data into cassandra nodes(,,,, vCD cell(s) must be restarted if they are already running.

The last step is to restart your vCloud Director service on each cell:

service vmware-vcd restart

It may take some time for these metrics to appear in vCloud Director. So you might want to wait a while before you start troubleshooting.

What to do if errors occur?

Most configuration errors are logged in the log files cell-management-tool.log and vcloud-container-debug.log, so you should start troubleshooting here.

But sometimes you need to delete the new configurations and start again.

To delete the additionally configured performance metrics in vCloud Director, you must first create an empty configuration file:

configuration {

And let vCloud Director read it:

./cell-management-tool configure-metrics --metrics-config /tmp/metrics.groovy

Finally, you can reset the cassandra settings in vCD:

./cell-management-tool cassandra --clean

And maybe you also need to delete the created keyspace and tables in the cassandra database. For that, you have to connect to one cassandra node, login in the cql shell and execute the following statement (But caution: This will delete the complete metrics keyspace and all collected metrics in cassandra!):

drop keyspace vcloud_metrics;


Leave a Reply

Your email address will not be published. Required fields are marked *