tuning nworks discoveries

[keithkleiman]

I ran a SCOM discovery report for discoveries over the last 24 hours in order to identify any excessive config churn going on in our environment and it appears that the following Discoveries were run just 594 times.

nworks.vmware.vem.VMContainsWindowsComputer.Discovery
nworks.vmware.vem.VMGUEST.PropertyDiscovery
nworks.vmware.vem.VMGUESTVirtualDisk.Discovery
nworks.vmware.vem.Topology.SV100
nworks.vmware.vem.Topology.SV102LS
nworks.vmware.vem.Topology.SV103

I understand, from p.103 of the Operations Guide, that the topology discoveries are event driven and can be controlled by internally buffering the events that trigger a topology update. Can you clarify how I might buffer the events? Any suggestions how I might address the issue of the other discoveries listed, from running to frequently? I suppose that since they are running exactly the same amount of times that they are all conencted so if I control the first one that kicks them all off I should be in better shape.

Thanks,
Keith

[Alec King]

Hello Keith,

That is certainly a lot of discoveries. We should probably dive into your logs and see what is triggering that, because even many vMotions should not cause that. For example you should only see the SV100 events if an actual HOST is added, removed, or changed in some way - just movements of VMs such as vMotion will not cause that.

In any case, I also see that the specific setting for buffering VM discoveries seems to have been missed from the documentation - I'll get that fixed. Meantime, you will find the setting in our nworks UI, in Advanced Settings for the Collector (select Collector in Enterprise Manager tab)
The setting is VMDiscoveryIntervalBuffer and the default is 4, which means VM changes will be cached for 4 intervals (4 x 5 = 20 minutes) before triggering the topo update. You can increase this setting to whatever you feel is appropriate; just be aware that of course VM topology changes (such as vMotion to a new Host) will take longer to be updated in the SCOM topology view.
Note that this setting will not affect the actual monitoring of VMs for performance and events in any way - all that data continues to be delivered on the standard 5-minute schedule.

Please feel free to open a support case and we can dive into why you are triggering so many discoveries - meantime the above should help to reduce the VM-triggered events anyway.
Any questions let me know!
Cheers,
Alec

[keithkleiman]

Thanks Alec! I went ahead and modified the VMDiscoveryIntervalBuffer for each of our 5 collectors and set it to 12 so that it would trigger a topology discovery once an hour. We might be ok with even increasing it to 4 hours, but will start with 1 for now. I'll also follow up with suport shortly to submit my logs just to understand the discoveries better. Thanks again!
Keith