Steve Wray put me on to Cacti the other day and I must say its pretty nice once you get over its slightly confusing interface. Cacti graphs statistics from network devices but unlike similar tools it does not try to do anything else. Think of it like bling for your network, good to look at, but maybe not that practical in a network emergency. But just like bling it is easy to put on and even better it is sure to impress your system admin friends, which in those hot and steamy server rooms we all want to do...
Installation is straightforward if you are running a typical LAMP stack (Linux, Apache, MySQL and PHP) but it can also run on a number of platforms including Windows if you are desperate. Cacti uses the PHP-SNMP extension to talk to SNMP agents on the network, keeps configuration settings in MySQL and stores accumulated network information as RRD files that get processed by RRDTool. Users can be configured with different access rights and devices/graphs can be clustered together in trees for easy viewing.
 |  |
| Click to enlarge screenshots | |
Most monitoring tasks provide graph templates that simplify the job of creating SNMP queries and laying out the graph data. This makes setting up Cacti monitoring pretty straightforward, in fact the hardest thing can be configuring all the SNMP agents. For those that want to go off the beaten track a little the graphing and data collection system is completely customisable. This means any piece of data that can be gleamed via SNMP or from local script commands can be visually displayed and turned into a template for others to use.
DebianHelp has a comprehensive list of available Cacti graph/data templates. The most useful example I have found for building your own custom queries explains how to monitor system up-time using Cacti. In the process the howto goes through data source and graphing basics and is definitely worth working through if you want to do more with Cacti than what the default set of templates provide.
I have only hit two snags when setting up Cacti, one was getting Netware CPU monitoring to work and the other was with SNMP and Intel-based OSX.
Netware CPU Utilization
After quite a bit of experimentation I could not get the default Netware CPU utilization to work. For some reason the SNMP request was not going through, or maybe if it was the data was not being saved to disk (I couldn't figure out which). The workaround I found was to do the following:1. Create a new data source using the SNMP - Generic OID Template
2. Set the server and name details and provide a path to where the RRD file will be saved, for example: <path_rra>/netware_server_cpu.rrd
3. Set the maximum value of the query to 100 as the SNMP request that will be performed will return a percentage value for CPU utilisation.
4. In the OID field enter: .1.3.6.1.4.1.23.2.27.3.16.1.4.1
This will query the first processor on the Netware server for its current utilization and it will return a single integer value that represents its utilisation in percentage terms.
Note: You can test this SNMP query out on the command line using snmpwalk, just enter:
snmpwalk -c <Community Name> -v 1 <Netware DNS Name> .1.3.6.1.4.1.23.2.27.3.16.1.4.1
5. Save the data source and then create a new Netware CPU Utilization graph using the previously saved generic SNMP query as a data source.
The results are not as accurate as what is available from Unix-based SNMP data sources as Netware does not return as much processor information via SNMP. However it will provide enough detail for you to at least understand roughly what your server is up to which after all is the point of the exercise.
Intel-based OSX
The other issue I ran into was getting an SNMP agent working on Intel-based OSX. It turns out that from OSX 10.4 running on Intel processors Apple has dropped support for /dev/mem and /dev/kmem which are used for querying the kernel on memory usage. SNMPD needs this information and even though all versions of OSX ship with SNMPD installed it will not run in its current state as SNMP is dependent on /dev/kmem.Why Apple have made this move is a little uncertain but from my limited research it seemed to be tied into copyright protection concerns (OSX on non-Apple systems). There are a few workarounds and a bug has been submitted to Apple, but for now SNMP on Intel OSX is not really available unless you are willing to undertake some rather nasty hacks.