>> >> Perhaps slightly off-topic, but I thought it might be interesting to >> others and a starter for ideas for others... >> >> --- >> Building on the concept of using a Raspberry Pi as a smokeping slave >> [Thanks to Ioannis Theodoridis] for the push!] I've completed one.
JZ> This is an AWESOME idea and I would love a copy of the code. JZ> We just bought 2 Pis for this purpose. JZ> If we decide to run one as a master do they still handle the load and the config ok? JZ> Thanks a ton! JZ> Josh I tested a few different configs: [These were all the the "B" version Pi with 512M RAM.] --- 1) Smokeping/MRTG/Nagios - as a stand-alone master. [With Smokeping hitting say - 30-40 devices/60 secs with fping, MRTG polling a hundred SNMP devices/ports/60secs and Nagios handling essentially the same hosts as Smokeping - mostly for notification purposes. [I actually had nagios watching the SP RRD files and not doing it's own checks.] In this case, the Pi was pretty buried. If you OverClocked it to 900 Mhz [IIRC] it would just barely stay below a 1.0 load average - at least some of the time. But it was very touch and go - I never had a problem, but when the 15 min load avg is really close to 1 and sometimes over, then it's likely you're going to have problems at some point. Since this is a critical warning/monitoring system, I'm not so hip on running them on the ragged edge. :) --- 2) Running it as just a smokeping and MRTG master - same number of targets etc. This works great and load is much less. I'm not sure why Nagios is such a pig, but it is... --- 3) Running smokeping as a slave over an SSH tunnel back to the mothership. And running MRTG as a "master" [not that there's any other way to run MRTG] on the Pi, storing all the MRTG data locally on the SD card, and generating all the graphs locally etc. Again, this is absolutely no problem with any semi-reasonable number of targets. [Say less than 100 smokeping and 100 MRTG targets.] And with smokeping "phoning" home to give the data to a master, I can run nagios there and generate all the alerts from a central location. Load averages, even when cranking MRTG graphs [which only occur when you're viewing pages with routers2.cgi] is really no problem at all. Load is nearly always very low, or well below 1. So, I tossed my configs and have it setup as an image, with option 3. I have a few tweaks I need to make to that image, but other than that it's ready for anyone to use. It would be quite trivial to take that image and make smokeping a master on if that's what you want - as everything it needs is already installed etc. I'm not sure exactly how/where to place the image so more than a single person or two could pull it - it's about 2G. Before running it, you'll want to write it on at least a 4G card [if you're going to store much on the SD card, say running MRTG with big RRD's, like I do] and you'll want to resize the partition. [Easy with raspi-config.] I run in on the RPi-Debian distro. --- Finally, I've tried to secure it pretty substantially - blocking all inbound ports except http/81 [can't use 80, since smokeping uses it to talk to the master] https/443 and ssh/22. I've setup apache to do auth for connects to MRTG too. So, with the image - it's literally about 15 minutes to setup a full, secure SSH tunnel smokeping slave from start-to-finish. MRTG setup with say a router or two, and a switch is another few minutes - depending on how much massaging you need to do the MRTG config files. [I have some great sed scripts to hack those up quick in most of the cases I have to use it in...though those aren't part of the image.] Suggestions, questions, thoughts? I'm glad to answer. _______________________________________________ smokeping-users mailing list smokeping-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users