We know how Zabbix deals with information once that information has been received, but there's a whole process to get it. That process is interesting on its own, but there're also parameters to tune in addition to StartVMwareCollectors, which we discussed earlier. First, let's examine how the values end up in items. The following diagram shows a data flow starting with VMware and ending with the Zabbix history cache:
Here, the steps happening inside the Zabbix server are grouped, and arrows indicate the data flow direction; connections are actually made from the VMware collectors to the VMware SDK interface. The collectors start by grabbing data and placing it in a special cache; caches are indicated with a dashed border here. Then pollers—the same processes that are responsible for passive Zabbix agents, SNMP, and other item types—grab some values from that cache and place them in the Zabbix history cache. For now, ignore the details in the history cache; we'll discuss it more in Chapter 20, Zabbix Maintenance.
Now is a good time to look at the VMware-related configuration parameters in the server configuration file. We already covered StartVMwareCollectors, the processes that connected to the VMware interface and placed information in a special VMware cache. This cache by default is set to 8 MB, and this size can be controlled with the VMwareCacheSize parameter. How would we know when that should be changed? The best way is to monitor the usage and adjust accordingly. We'll discuss the monitoring of internal caches in Chapter 20, Zabbix Maintenance.
Sometimes, connections to the VMware interface could get stuck. It could either be a single slow instance that slows down the monitoring of other instances, or it could be a single request going bad. In any case, connections to VMware instances will time out after 10 seconds by default. This time can be controlled with the VMwareTimeout parameter.
We just have two VMware-specific parameters left, VMwareFrequency and VMwarePerfFrequency. Zabbix queries some of the information using the VMware internal performance counters. At the time of writing this, the following item keys on the hypervisor level are extracted from the following performance counters:
- vmware.hv.network.in
- vmware.hv.network.out
- vmware.hv.datastore.read
- vmware.hv.datastore.write
- vmware.hv.perfcounter
On the virtual machine level, the following keys are extracted from the following performance counters:
- vmware.vm.cpu.ready
- vmware.vm.net.if.in
- vmware.vm.net.if.out
- vmware.vm.perfcounter
- vmware.vm.vfs.dev.read
- vmware.vm.vfs.dev.write
What does this actually mean? The item keys, listed previously, get new information as often as VMwarePerfFrequency is set to. To put it differently, it doesn't make sense to set the frequency of any items listed here lower than VMwarePerfFrequency. All other items, including low-level discoveries, get their information as often as VMwareFrequency is set to, and it doesn't make sense to set the frequency of other items and LLD rules lower than VMwareFrequency.
We could also say that both of these parameters should be set to match the lowest frequency for their corresponding items, but we have to be careful; setting these too low could overload VMware instances. By default, both of these parameters are set to 60 seconds. This is fine for small and average environments, but on a large VMware instance, we might want to increase them both, while potentially increasing VMwareTimeout as well.