Monitoring and Metrics in VMware Data Services Manager v1.4

VMware Data Services Manager (DSM) v1.4 has a substantial amount of built-in monitoring, not just for analyzing the health and behaviour of the vSphere environments where the databases are running, but also the databases themselves. In this post, I will highlight what those metrics are, and where to find them in the Provider UI. We will begin by looking at the ‘Environment’ monitoring and metrics, before turning our attention to the ‘Database’.

Environment

The first interesting view of an environment is the Health. This view shows us the health of the agent, and whether any of the major components that run on the agent VM is having any difficulties. The agent is the component of DSM that is responsible for returning details about the vSphere resources that have been discovered, and which can be used for database deployments. In the output below, everything is green / OK.

Many of these health status are self-explanatory, but others might need some explaining. The agent uses  InfluxDB for storage and retrieval of metrics and events. It uses Telegraf for collecting metrics and events  from the databases. You can see if any of these critical components on the agents have generated any events by clicking on the Events tab, as shown below.

Events are raised only when the status of any Alert is changed. Thus, there is no fixed frequency for the ‘triggered time’ field, but rather it updates when an event is triggered. This brings us to the metrics views, of which there are a few. These include ESXi host metrics, database metrics, storage metrics and agent VM metrics. Below are the host metrics from one of the ESXi hosts that is used for running database VMs in my vSphere environment. Network, CPU and Memory usage are all displayed.

Possibly the most interesting information comes from the Agent VM view. There are 2 options here. One is to view the VM metrics, whilst the other provides detailed DSM System database metrics. The metrics that we get from the DSM System database are as follows:

ROWS_RETURNED
ROWS_FETCHED
ROWS_INSERTED
ROWS_UPDATED
ROWS_DELETED
TRANSACTION_COMMITTED
TRANSACTION_ROLLBACK
DEADLOCKS
READ_TIME
WRITE_TIME

Here are the Agent VM views. The first are the disk metrics and the second displays the database metrics.

So, as you can see, there is a significant amount of monitoring and metrics available to the admin from within the DSM UI. Let’s now see the monitoring and metrics associated with a database.

Database

Once again, there are a number of monitoring checks to make sure that the database health is OK. This is the Health Status view. A total of 12 checks are run, and in this case all are normal with 0 warnings and 0 errors.

At this point, the DB metrics can now be chosen for displaying. What is displayed in this view is dependent on whether or not the ‘Enhanced Monitoring‘ option was chosen when the database was created. This is one of the options available in the database creation wizard. It is enabled by default. If Enhanced Monitoring is disabled, then mostly only CPU, Memory, and Disk metrics are displayed, and no specific internal database metrics are captured.

In the following example, we are looking at a clustered MySQL database with Enhanced Monitoring enabled. This gives the following additional views:

• Queries & Questions
• Bytes Received and Sent
• Slow Queries Per Second
• InnoDB Buffer Usage (clustered MySQL)
• InnoDB Reads & Writes (clustered MySQL)
• Command Reads & Writes

The metrics are different for PostgreSQL. PostgreSQL displays information about Active Connections. You can learn more about which metrics are controlled by Enhanced Monitoring in the official documentation found here.

I hope this post has given you some insights into the sort of monitoring and metrics that VMware Data Service Manager displays for both the vSphere environment and the databases that are deployed on the infrastructure. Of course, another option is to integrate with Aria Operations, and the True Visibility Management Packs that we have for many of the databases found in VMware Data Services Manager. I will follow up on a blog on this in the near future, and show you what we can do with it.