Cacti, RPi, and GPIO device readings

Cacti, RPi, and GPIO device readings

Introduction – CactiPi isn’t as hard to eat as you might think.

In my earlier post, the RPi command and control features have been an excellent way to show capabilities. Webmin showed how complex admin tasks can be done graphiclly, without the need for a desktop environment. Smokeping was introduced, but not covered in detail. This tool is usefull in identifying host availability on the network, but it doesn’t go much further.

This is were Cacti comes into play. This is primarily a graphing utility based off of Tobi Oetiker’s MRTG and RRDTool efforts. I have been using these tools on systems longer than the existance of the RPi and Arduino platforms combined. Cacti is interesting due to its support of third party plugins. This is what makes the tool take on a different form and extends it to different disciplines.

Here is a description, that I found at http://openmaniak.com/cacti.php, of what Cacti is.

“Cacti is a web based PHP/MySql graphing solution using the RRDtool engine.  Classically, it can graph network bandwidthes with SNMP. But in fact, a lot of different graphs can be done with snmp, shell or perl scripts…Cacti’s strength lies in the fact that it can be installed and used incredibly easily… On the very active Cacti forum, you can share “Cacti templates” with other users which can can save you a lot of time. You can very easily add plugins to the Cacti too enabling the possiblility to integrate other free tools like ntop or php weathermap...RRDtool is developed using the “C” programming language and it stores the collected data on “.rrd” files.The number of records in a “.rrd” file never increases, meaning that old records are frequently removed. This implies that one obtains precise figures for recently logged data, whereas figures based on very old data are mean value approximations. By default, you can have daily, weekly, monthy and yearly graphs.”

Since the hard work of Cacti and getting it installed on RPi have been ironed out, lets dive in.

Purpose – Don’t reinvent the wheel, just learn how to use it.

In this section, I will go through what Cacti is and how it can be used on a RPi. I’ll also cover the installation and setup of Cacti on the RPi. Cacti comes bundled with features to allow it to monitor and graph metrics like processes, cpu usage, network traffic, and latency. I’ll also cover how to setup Cacti to poll and graph SNMP devices using non standard OID values. Leastly, I’ll cover how to use Cacti to poll and graph devices attached through the RPi GPIO header. The ability to quantify values using the RPi will be worthwhile. I’ve used VMs to perform these tasks as a solution for network diagnostics. The VMs are a point of vulnerablity and are also dependent on the host they run on. The RPi is well suited to run along side the VMs to add a layer of reliablity without high costs.

Detail – Having a way to look back at where you’ve been.

The steps to install Cacti on the RPi are available here.  You can see that the steps aren’t too involving.  I had success going through the prodecures.  However, it is worth mentioning that it is good practice to included the sudo command at the beginning of each string.

These steps also assume that fundamental things, like LAMP have already been installed.  If you’ve been following along with my posts, then you should be set.  Otherwise, go back to my post about RPi basics and start there.

This was super easy to do and Cacti is now running with some preloaded graphs about the RPi processor, memory, and network usage.  But that isn’t all we’ll be doing with Cacti.  Since it can poll SNMP devices, I’ve added a couple of my routers and storage hosts.  The built in templates can handle most SNMP needs, so adding these devices was just as easy as the install.

But there was a temperature device I wanted to graph and Cacti didn’t have a template to handle the SNMP OID.  For this I would need to identify the OIDs and create custom data, graph, and host templates in Cacti.  It seems like a lot, but it really wasn’t that bad.  Compared to the suggestions I found online that had me creating an XML file from scratch and importing it, it was a snap.

First thing I did was snmpwalk the device to list all of the OIDs.  Then I could select the one that pertained to the data I wanted to graph.

snmpwalk -v1 -c public [ip_of_device] .1.3.6.1.4.1

.1.3.6.1.4.1.17373.2.4.1.3.1 = STRING: “Attic”
.1.3.6.1.4.1.17373.2.4.1.3.2 = STRING: “Front Gable”
.1.3.6.1.4.1.17373.2.4.1.3.3 = STRING: “Rear Door”
.1.3.6.1.4.1.17373.2.4.1.3.4 = STRING: “Hot Water Return”
.1.3.6.1.4.1.17373.2.4.1.3.5 = STRING: “Living Room”
.1.3.6.1.4.1.17373.2.4.1.5.1 = INTEGER: 10 ^
.1.3.6.1.4.1.17373.2.4.1.5.2 = INTEGER: 8 ^
.1.3.6.1.4.1.17373.2.4.1.5.3 = INTEGER: 14 ^
.1.3.6.1.4.1.17373.2.4.1.5.4 = INTEGER: 40
.1.3.6.1.4.1.17373.2.4.1.5.5 = INTEGER: 21

The steps I then followed can be found in the book “Cacti 0.8 Beginner’s Guide” from Thomas Urban.  I defined the data template using the steps outlined on pages 55 – 56.  Next I defined the graph template using steps on pages 59 – 60.  In this section I also added graph template items, these are the lines and areas in the rrd graph, and graph item inputs, these are the rrd sources to graph.  Once that was complete, I then defined the host template outlined on pages 66 – 67.

Now all I had to do was add the device in Cacti and add the associated graph templates for the device, then create new graphs for the device.

I highly recommend getting the book from Thomas Urban.  It covers material that is outside the scope of this post, and will make it much easier to follow along with the steps above.  Seriously, do yourself a service, get the book.

So far we’ve covered the extent of what Cacti can do on any host system.  Here’s what raises the RPi above the rest, graphing data through the GPIO header.  I was a bit intimidated at first but managed to find a decent write up on how to gather and graph non SNMP data with Cacti.  This was a gold mine find.  Now all I had to do was connect something to the GPIO header and read it.

I settled on an analog device that reads light intensity.  For that I would use a photo resistor and a 2 channel MCP3002 ADC that is similar to the example given by Adafruit.  I had to load some libraries to read the ADC, but once they were loaded my python script (based off of Jeremy’s Blog) was ready.  Since all the working details of Python are beyond the scope of this post, you can find more on learning Python at Codecademy.  Anyway, here’s the code I used.

 #!/usr/bin/python

import spidev
import time

spi = spidev.SpiDev()
spi.open(0, 0)

def readadc(adcnum):
# read SPI data from MCP3008 chip, 8 possible adc’s (0 thru 7)
# read SPI data from MCP3002 chip, 2 possible adc’s (0 thru 1)
#if adcnum > 7 or adcnum < 0:
if adcnum > 1 or adcnum < 0:
return -1
r = spi.xfer2([1, 8 + adcnum << 4, 0])
adcout = ((r[1] & 3) << 8) + r[2]
return adcout

value = readadc(0)
print “lux:%d” % value

Now with the python script doing what it should, I copied the script to my Cacti scripts folder and made the script executable with this commnad:

sudo chmod 777 /var/www/cacti/scripts/rpi_light_sens.py

Everything was in place to step through the write up pages 24-36.  Walla!  I’m graphing data from the GPIO into Cacti.

graph_image.php

Relations – Cacti is here to stay, so what else can it do?

What else can Cacti do?  It depends on what plugin you want to load.  The list is fairly extensive, have a look here.  Some of the more popular ones are syslog, thold, and weathermap.  Syslog is great for gathering system messages and listing them.  I’ve been able to find a server disk controller fault this way.  Without it, I wouldn’t know what caused the server to die.  Thold is useful for sending alerts based on thresholds in the data.  Is the disk too full, you’ll get an alert.  Weathermap is great for identifying the overall health of what you’re tracking.  It’s visual, so it’s quick and easy.  It’s worth mentioning here that any plugin will require the Cacti Plugin Architecture.  This is the requirement, because it is a foundation for the plugins to work.  But be warned, it is a tremendous pain in the ass to install, if your cacti version isn’t the same as the PIA patch.  I’ve managed to undo a Cacti install with a botched patch.  It isn’t for the lighthearted or casual admin.  But if you’re bold and want to explore the world of Cacti plugins, start here.  Regardless, there is some good news after all, the newer versions of Cacti come with the PIA preloaded.

With all these options available, the RPi will only do what its hardware allows.  At some point, you could ask too much of it and notice a degrade in performace.  The same is true of humans.  Just because you can’t see the bottom of the well, doesn’t mean you have an endless supply of water.

So the question that’s unanswered is, does Cacti really scale well?  I don’t know.  It may see off subject but I really liked this presentation.  If anything it’s a lesson learned for experiences of others using Nagios.  These lessons can be used to critically look at Cacti in a realistic way, not just gazing at pretty graphs.

Summary – This one was packed to the hilt.

Seriously, this post has been the most jam packed with material.  We’ve covered the steps to install Cacti on the RPi.  Once installed we could see the default metrics of our RPi and add devices that offer SNMP polling.  From there we added custom OID polling to non template SNMP devices.  This expanded the graphing range of Cacti and allows it to cover a greater range of resources.  Next, we attached sensors to the RPi GPIO header and created a Python script to represent the reading in a format that was Cacti compatible.  Next we set the parameters on Cacti to execute the script and read the values into a graph.  Finally, we covered some extensible options and limitations of the RPi and Cacti.  From here, you should be able to deploy a RPi as a metric polling device and have it provide the results in a web browser.

Comments are closed.