Got Cacti? Proper disclosure – the author have never properly used Cacti as a monitoring system in a production environment.
So what’s Cacti? – I’m not sure that after the proper disclosure I can actually comment too much, but from my first impression, Cacti is a fairly comprehensive server and network monitoring platform for Unix.
It’ll support graphing of performance counters, alerting, polling of SNMP MIB counters from various devices (that are not necessarily computers, but also routers, switches, etc.) and probably many other functions that unfortunately I can’t mention – because I’m unfamiliar with.
I usually dislike to write articles about things I’m not fluent about, but in this case, fortunately, Cacti is not the issue. Yes, you’ve guessed correctly, it is again Monitis.
After I recently introduced Moominitis, which integrates Monitis and Munin, It’s time to prove yet again the versatility of Monitis, and this time to integrate Cacti’s RRD data into it.
If you’re following our github projects in monitisexchange, you would have probably seen that the Munin & Monitis integration actually included a generic interface to integrate with any future or existing RRD based platform.
Will it… work?
I can’t say that the RRD integration with Cacti was anything exciting to implement, everything was already in place. There has been only minor changes required to get the RRD integration from Munin to work also with Cacti.
However, Cacti is a bit more comprehensive than Munin and I must admit that the integration is slightly incomplete. Unlike Munin, Cacti features a fairly complex SQL scheme and unfortunately some of the data I needed for proper integration lies somewhere within it.
There are 2 TODOs that I’ve left myself over there and I urge readers who are more familiar with Cacti to fix them (or give me pointers so your loyal servant can fix them) if they would like to use this plugin with Monitis.
Instead of adding a proper graph title and UOM (Unit Of Measurement), it’ll add a ‘TODO’ tag. Sorry about that.
The promised example – taming the Cacti
It’s easy as integrating Munin with Monitis.
First and foremost, please make sure you have some RRD data in Cacti’s data directory:
# ls /var/lib/cacti/rra/
By default, Cacti does not collect RRD data for hosts, you have to explicitly add it, as far as I’m concerned.
I’m going to repeat myself a bit here (some copy & paste from the previous article), but I don’t care:
# mkdir -p /usr/share/monitisexchange && cd /usr/share/monitisexchange # git clone git://github.com/monitisexchange/Monitis-Linux-Scripts.git # cd Monitis-Linux-Scripts/RRD # vim monitis_config
While editing monitis_config you should add your proper API key and secret key. This can be easily obtained from the Monitis interface under ‘Tools -> API -> API key’.
After this is working, we can start playing with Monitis and Cacti. E.g.:
# ./monitis_rrd.sh cacti list_hosts /var/lib/cacti
monitis_rrd.sh takes a couple of parameters:
1. RRD interface to use (Munin and Cacti are supported, read on if you want to discover how to add another RRD interface)
2. Function to perform, supported functions are:
- list_hosts – List the hosts that Cacti has collected RRD data for
- list_monitors – List all the monitors that are configured for a certain host
- list_counters_for_monitor – List all counters a monitor can produce
- add_monitor – Adds a monitor using the Monitis REST API
- update_data_for_monitor – Update the latest data for a monitor using the Monitis REST API
3. The rest of the arguments are plugin specific, for Cacti, like Munin, we’ll always specify as the 3rd argument the cacti data dir (commonly /var/lib/cacti)
The last command showed us the hosts Cacti has collected RRD data for.
Integration with Monitis is similar as Munin, this is as much as I’m allowing myself to repeat the previous article.
This is authentic data sampled from my humble computer by Cacti, graphed by Monitis:
Adding another RRD interface
The addition of another RRD interface is easy.
Considering you followed the previous instructions and have your sources at
/usr/share/monitisexchange, under RRD you’ll see 2 directories, munin and cacti:
# ls -d */ cacti/ munin/ # ls cacti/ interface
Under each of these you’ll see a file named interface. You can guess what you have to do with it – implement one of your own.
Say you have a fictitious monitoring platform with a RRD backend called ‘lasagna’ (maybe I should get myself something to eat…), the following can be done to integrate lasagna to Monitis.
# mkdir lasagna # cp munin/interface lasagna/
All that you have to do now is to edit lasagna/interface and implement the relevant functions.
The functions you must implement are:
Invocation of the functions and testing is possible via monitis_rrd.sh e.g.:
# ./monitis_rrd.sh lasagna list_hosts # ./monitis_rrd.sh lasagna list_monitors
Mind you interface can be written in any programming language as long as you implement the correct command line arguments. So feel free to use your favorite programming language for the implementation of your favorite lasagna.
So Cacti or Monitis?
I can’t hide it, both Cacti and Monitis thrive to do more or less the same thing – be a comprehensive monitoring system.
First of all, the nice thing is that you don’t have to choose in between them, you can have them both.
However, if you are unfamiliar with Cacti – I’d probably go with Monitis.
Why? – because it’s much easier to install Monitis – actually you don’t have to install it.
And here is a tale I have to tell:
Once I had to service my motorcycle not in my regular garage. The owner of the Garage had a classic 1982 Yamaha XT550 (I’m pretty sure it was this bike, but it’s not the point), which by itself is a classical bike. It was in superb condition. I was impressed. He rode it daily to work, back and forth.
A few weeks later, while passing through my garage and visiting my regular mechanic, I told him the tale of the classic 1982 XT550 motorcycle.
Both of us are riding modern day motorcycles, and without hesitating my mechanic told me: “This guy, he doesn’t like to ride motorcycles, he likes to fix them.”
You, the SysAdmin, should decide if you like to maintain monitor systems, or actually use them.