The last couple of months, I have been amazed about the Raspberry Pi. I won’t go into great detail on this wonderful device, other than the obvious.
- It is cheap
- It comes with Ethernet, HDMI
- It runs Debian Linux
- It has GPIO, general purpose input output, pins on the board
So, the device itself is just screaming for some interesting projects, interfacing with stuff that normally are not integrated with your IT stack. I’ve tried it out in a few different ways already, and I’ve bought a handful of devices. One of them has a fixed position, connected to my TV, running XBMC.
Well, let’s go back a few years in time. Quite many years, will say. Back to the days when I had just started growing a beard, and was just that naïve that only youngsters freshly out of high-school can be. I headed off to university and one of the first day of the introduction week we went to the student pub. There I saw one of the coolest things since the invention of sliced bread, a pedestrian crossing light.
Normally, such thing would not leave that much of an impression with me, but this one was special. Our own student pub was one of three student pubs in the same basement corridor. But there was only one WC. In principle, this was not a problem early in the evening, but as the night went on, the line to the WC was an annoyance. In our pub, the one with the crossing light, we were less stressed about it than people in the other pubs, since our crossing light was connected to the lock of the WC door. Whenever the lock was locked, our crossing light was red; hence when the door was unlocked it was green.
When we relocated the pub, we ended up in a location where the WC situation was much better. I had personally made sure that we brought the crossing light with us, but I could never come up with as good of a use for it. This was a long time ago, but the bright idea (pun intended) stuck with me over the years.
When I implemented Nagios/OP5 at my new workplace, I started playing with the thought that I wanted some way of raising the attention of the monitoring with my guys. The classical “big screen on the wall” was of course one of the first things that crossed our minds. This was easy, and people notice it – goal achieved. But I wanted something else, something more… catchy.
Just by a coincident, I got in contact with a guy who is responsible for replacing old bulb-based traffic lights with new LED-based traffic lights. He gave me a handful of 3-light (red, yellow, green) pedestrian crossing lights, and now I was able to get going with my latest project.
A Nagios/OP5 installation that shows service states on a traffic light.
Note that you are on your own when connecting the things together. If you are not completely sure of what you are doing, then don’t. I’ve been doing things like this for a while, so I trust myself. But I do not take any responsibility what so ever for any mistakes you do yourself. This project involves 220V, which can be lethal. Don’t blame me if things go bo-boo. End of disclaimer.
All in all, I’ve got a Nagios/OP5 installation in a virtual machine. In this example, one of my services is configured with an event handler, pointing to a command configured in checkcommands.cfg. I decided that the communication between my monitoring system and the Raspberry Pi would go over nrpe, which is anyways the standard Nagios Agent. Adding a couple of scripts on the server to take care of events, and the client side, to control the GPIO, was fairly simple.
Let us go through the whole chain on both hosts, the Nagios/OP5 system and the Raspberry Pi. I will start in a reverse order, as the Nagios configuration is simple and does not require much of explanation. Which service to chose for your traffic light is up to you. There are a couple of interesting constructs that come with OP5, that is not readily available out of the box in a Nagios installation. One of these is the “Business process view”, that allows you to perform logical operations on service states. You can also create new services from these aggregations. I will leave this part out of this blog entry, but the principle is so easy, that if you manage with the rest in this article, your should not have a hard time figuring that part out either.
In principle, I just chose one service and added an event_handler to it. That’s it. The event_handler is configured as any other command in the _checkcommands.cfg_ file. An event handler should take care of a couple of checks, so that you are sure that you really want to do something when the event hander is triggered, as it is triggered quite often. Basically, check the state (OK, WARNING, CRITICAL) and the state type (hard, soft) and make up your mind.
As mentioned before, I chose to use _check_nrpe_ to integrate Nagios with my Raspberry Pi, since it is readily available and very simple to configure. All I need to do, is to remotely run a script on the Raspberry Pi, which nrpe allows me to do after a very simple configuration. I just had to come up with a name for my remote command, add it to the nrpe configuration on the Raspberry Pi, restart nrpe, and start using check_nrpe on the Nagios/OP5 server.
On the Nagios/OP5 server, you need to get the following into your configuration files. When using OP5 there is a very simple web-gui to do this in. Othervise just fire up your favorite editor (which should be _vi_).
Here is the service in the Nagios/OP5 services.cfg for my dummy service to monitor and display on the traffic light. The magic is in the sauce, I mean event_handler:
1
2 3 4 5 6 7 8 |
# service ‘remote debug’
define service{ use default-service host_name pi-s001 service_description remote debug check_command check_nrpe!-H $HOSTADDRESS$ -c kmg_dummy event_handler event_ampel } |
This event handler is configured in the Nagios/OP5 configuration file checkcommands.cfg. Note the arguments I am sending to the script.
- $SERVICESTATE$ – Nagios macro for the current state of the service
- $SERVICESTATETYPE$ – Nagios macro for the current type (soft or hard) of the service
- $HOSTNAME$ – Nagios macro for the service’s host
- $SERVICEDESC$ – Nagios macro for the name of the service
- $SERVICEATTEMPTS$ – Nagios macro for the number of attempts
1
2 3 4 5 6 |
</div>
# command ‘event_ampel’ define command{ command_name event_ampel command_line $USER1$/kmg/event_ampel $SERVICESTATE$ $SERVICESTATETYPE$ $HOSTNAME$ $SERVICEDESC$ $SERVICEATTEMPT$ } |
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
#!/usr/bin/kshstate=$1
statetype=$2 serviceHost=$3 service=$4 serviceattempt=$5raspberryPi=10.64.150.5logfile=/opt/monitor/var/eventhandler.log # Sep 25 14:53:14 case “$state” in /opt/plugins/check_nrpe -H $raspberryPi -c $command >> $logfile |
If you by any chance had the Raspberry Pi setup and running already, you could test the event handler and the integration in two ways from the Nagios/OP5 host:
1
2 3 4 5 6 |
#— check that nrpe works (i.e allowed_hosts on the pi is set properly)
op5$ /opt/plugins/check_nrpe -H 10.64.150.5 #— check that the commands config on the pi works op5$ /opt/plugins/check_nrpe -H 10.64.150.5 kmg_ampel_green #— check that the whole stack works op5$ ./event_ampel kmg_ampel_red |
So far, the Nagios configuration. We also need the relay control and the Raspberry Pi configuration. This is the hardware you need to complete this project:
- One Raspberry Pi
- 5V DC source (Micro USB charger)
- 12V DC source (to drive the relays)
- 3 x 5kOhm resistors
- 3 x BC237C transistors
- 3 x Relays, 12VDC activation/250AC switching
- A few cables.