Collecting additional data

Why would an administrator want to import data from other monitoring systems or data sources into vRealize Operations, especially when the data for those systems is already being managed by an existing monitoring solution? This is a fair question. The obvious advantage is to have all the data in one place, accessible via a single pane of glass. The real power of vRealize Operations is in how it handles relationships, and the benefits that this provides to the administrators out there.

Say we have installed vRealize Operations and we are successfully importing vSphere data and providing various types of useful information and reports. When an incident ticket is created and reports that there is a performance problem in a VM or a number of VMs, we can look at that VM in vRealize Operations and see what cluster it belongs to, what host it is currently sitting on, and what datastore the VM's disks are located on. We can see the overall health of the VM collected from the hypervisor and rule out any anomalies or bottlenecks that might be occurring.

Then the ticket starts its journey to the SAN team, to the network team, and to the application team, with generally everyone saying everything is fine at their end.

But what if we could go deeper than the logical datastore, further than the physical NIC or up into the application in the guest OS of the VM? Well, we can, and this is done through solutions.

Picture for a moment what can currently be seen when looking at the health relationship objects of a VM. We get stopped at the datastore level. But if we were using EMC Storage Analytics (ESA) solutions we could then break through the datastore and keep moving down to see the array that the datastore belongs to, then to the disk pool the LUN belongs to, then finally hit the physical disks themselves. All the while we would have access to all the metrics, logs, and alerts for all of these objects.

Then onto the networks—what if we could see the upstream switch and port the NIC is plugged into and all the metrics and data that goes along with it? Then, using new features like End Point Operations (EPO) monitoring, we could go into the guest and see the services that make up the application and all the relevant application-level metrics. For example, for Microsoft Exchange, we'd be able to see the number of incoming and outgoing messages, number of people logged in, response times, and so on.

Having all this data on a single pane of glass is great, but having a full end-to-end view of the infrastructure supporting a virtual machine and the applications within it allows for the service desk or the server administrator to more accurately pinpoint where the problem most likely is in the stack.

While solutions can take advantage of different vRealize Operations analytics such as dynamic thresholds and capacity management, relationship linking is the key to making a big difference in the day-to-day operational running of the environments.