Cacti, SNMP, Paid Monitor and what’s between them

• RSS Feed
• Email

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 Paid Monitoring.

Cacti, like Munin has a RRD backend for graphing some of its counters.

After I recently introduced Moominitis, which integrates Paid Monitor and Munin, It’s time to prove yet again the versatility of Paid Monitor, and this time to integrate Cacti’s RRD data into it.

If you’re following our github projects in paid-monitorexchange, you would have probably seen that the Munin & Paid Monitor 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 Paid Monitor.

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 Paid Monitor.

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/paid-monitorexchange && cd /usr/share/paid-monitorexchange
 # git clone git://github.com/paid-monitorexchange/Paid Monitor-Linux-Scripts.git
 # cd Paid Monitor-Linux-Scripts/RRD
 # vim paid-monitor_config

While editing paid-monitor_config you should add your proper API key and secret key. This can be easily obtained from the Paid Monitor interface under ‘Tools -> API -> API key’.

After this is working, we can start playing with Paid Monitor and Cacti. E.g.:

 # ./paid-monitor_rrd.sh cacti list_hosts /var/lib/cacti

paid-monitor_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 Paid Monitor REST API
• update_data_for_monitor – Update the latest data for a monitor using the Paid Monitor 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 Paid Monitor 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 Paid Monitor:

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/paid-monitorexchange, 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 Paid Monitor.

 # 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:

• list_hosts
• list_monitors
• list_counters_for_monitor
• add_monitor
• update_data_for_monitor

Invocation of the functions and testing is possible via paid-monitor_rrd.sh e.g.:

 # ./paid-monitor_rrd.sh lasagna list_hosts
 # ./paid-monitor_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 Paid Monitor?

I can’t hide it, both Cacti and Paid Monitor 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 Paid Monitoring.

Why? – because it’s much easier to install Paid Monitor – 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.

Liked it? Sign up for Paid Monitoring and try it now! Don’t forget to check also paid-monitorexchange – our github open source repository for some more future surprises.