Idea Details

VMware probe improving

Last activity 12 days ago
Anon Anon's profile image
09-13-2016 04:39 PM

Hi to all,

 

I suggest some ehancements to the VMware probe, based in our own experience. Our virtual environment is very big and very dynamic, new hosts are created, modified and deleted every day. We have noticed the probe is not able to handle correctly virtual machine deletions. By example, when you rename a virtual machine and create a new one with same hostname freed in previous step, the probe continues monitoring and alarming old deleted machine.

 

The suggestion is the probe be improved to preview dynamic environments, close the opened alarms and disable the active monitors of deleted virtual machines, once they doesn't exist anymore.

 

Regards,


Comments

02-23-2017 06:57 AM

Hello.

While I completely agree with what you described, here is something that you may be interested in.

 

Admin Console GUI for vmware probe (optionally) supports Template (Bulk Config) feature.

The feature is disabled by default in vmware probe, but could be turned on in Admin Console GUI only.

v6.6 vmware AC Apply Monitoring with Templates - CA Unified Infrastructure Management Probes - CA Technologies Documenta… 

 

Like Admin Console GUI for the other agent-less probes, Template feature allows you to define criteria of the target the template is going to manage. This is the huge difference compared to Auto Configuration feature in IM GUI.

 

Here is an image.

Create Template A to manage monitoring rules for VM where its name starts with AAA

Create Template B to manage monitoring rules for VM where its name starts with BBB

 

Important! When you enable bulk configuration, Infrastructure Manager is disabled and the Template Editor appears in the Admin Console GUI. Once you enable bulk configuration, there is no supported process for going back to manual configuration. Be sure that you fully understand and accept the consequences of enabling bulk configuration before enabling it.

 

Hope it helps.

Regards,

Yu Ishitani

02-22-2017 08:24 PM

Hi All,

 

We also have the same experience as our environment is extremely dynamic. Everyday, there are VM's added, deleted, renamed, etc. and it seems like the vmware probe can't keep up or track this properly. We have approximately 1000 VM's and expect another 600+ over the next 18-24 months. We don't want every new VM to automatically get monitored and using static monitors is not manageable.

 

Future improvements of the vmware probe need to consider the real world VMware environments. It's great to say Auto Configurations can automatically monitor everything, but realistically, I don't think the majority of customers would want this. I could be wrong and perhaps smaller or less dynamic environments prefer it like this.

 

The first area of improvement would be to introduce an easy way of excluding monitoring. Not just at the VM level, but at all levels. We have very practical reasons where we would like to be able to exclude down from the Datacenter, Cluster, ESX Host and VM level. Some kind of "prevent inheritance" feature would be great. Auto Configurations should be able to be applied at the  Datacenter, Cluster and ESX host levels also. This would give greater control of monitoring.

 

The second area of improvement would be an option to NOT monitor all new VM's. Perhaps when the probe GUI is loaded, it can show a list of all new VM's that have been created since the last time the probe GUI was loaded. From there simply tick to include it in the Auto Configurations monitoring.

 

The third area of improvement would be for the probe to read the information in the "Summary" tab for each VM. Especially the "Annotations" where customers can type notes for each VM. Then allow regex filters for these fields so monitoring (either Static or Auto Conf) can be used to include/exclude monitoring, or apply different templates according to the filters. Even better if some of these fields can be filtered on with the NAS probe so there is more control of alerting.

 

Thanks,

Max.