Normally, Alexei is the one that directs Zabbix development: which bugs are meant to be fixed and which features are meant to be implemented. However, sometimes Alexei is too busy to pay enough attention to what developers are doing, and that is a chance to do some hacking. Here is one of them.

It all started out when Pavel Timofeev pointed out a problem with vm.memory.size checks on FreeBSD: some of the memory checks on FreeBSD as supported by Zabbix 1.8 agent are not very meaningful (see ZBXNEXT-1024 for more details). So we started looking into the issue and discovered that some memory checks on other operating systems are not very meaningful either. One of these operating systems was Mac OS X. Since it is not a common guest in our office, developers decided to take the opportunity and take a look at Zabbix code for Mac OS X. Among other things, support for Mac OS X lacked network checks. So we started looking at network checks for other platforms and so it went…

Mac OS X

Since we do not see Mac OS X very often, the documentation page for 1.8 has a bunch of question marks to indicate that we did not know which checks are supported. During this development we have added some and documented all checks supported for Mac OS X on the documentation page for 2.0.

Here is a summary of new items supported on Mac OS X:

• system.boottime
• system.cpu.num[max]
• net.if.collisions
• net.if.in
• net.if.out
• net.if.total
• vfs.fs.discovery

In 1.8, item system.cpu.num[online] actually returns the number of available CPUs. This has been fixed and support for system.cpu.num[max] was added. There is now also a possibilty to monitor network traffic and discover file systems!

net.tcp.listen and net.udp.listen

As the development when along, item net.tcp.listen has been added on Mac OS X and item net.udp.listen has been added on FreeBSD, Mac OS X, and Solaris.

vm.memory.size

The main part of development was related to a single memory check: vm.memory.size. The problem pointed out by Pavel was that, for instance, vm.memory.size[used] on FreeBSD did not return very useful information and there was no way to monitor FreeBSD-specific types of memory: active, inactive, wired. Other platforms turned out to have the same problem and it was clear that vm.memory.size had to be redesigned a bit.

Clearly, it is necessary to monitor platform-specific types of memory, so item vm.memory.size now provides access to most of them. For instance, Zabbix can now monitor pinned and free memories on AIX, as well as active, inactive, wired, anon, exec, file, free memories on NetBSD. The complete list for all platforms is available at the documentation page for 2.0.

It is also apparent that monitoring platform-specific types of memory is not always necessary. What is required is a user-level estimate on how much memory is used and how much memory is available. Items vm.memory.size[used], vm.memory.size[pused] and vm.memory.size[available], vm.memory.size[pavailable] are intended to provide these estimates – in bytes and in percentages from total.

Note that vm.memory.size[used] plus vm.memory.size[available] do not necessarily equal total amount of memory. For instance, on FreeBSD active, inactive, wired, cached memories are considered used, because they store some useful information. At the same time inactive, cached, free memories are considered available, because these kinds of memories can be given instantly to processes that request more memory. So, for example, inactive memory is both used and available simultaneously. Because of this, item vm.memory.size[used] is designed for informational purposes only, while item vm.memory.size[available] is designed to be used in triggers. These user-level estimate items are available for all platforms. More information is available on the page describing vm.memory.size parameters.

One notable consequence of these changes is that we have removed item vm.memory.size[pfree]. Since free is a platform-specific memory type, getting its percentage from total is not very useful. Item vm.memory.size[pavailable] now provides the necessary functionality.

A final small note is that vm.memory.size[shared] has been dropped for Linux 2.6, because it always returned 0. It is still supported for Linux 2.4 and corresponds to “shrd” memory in top(1) output.

That’s what happens when management isn’t looking. Beware. 🙂