In
my last post I gave some background on one of my recent side projects: setting up and then monitoring a Raspberry Pi running Pi-Hole. In this post, I’m going to dive into the details of how I set up the actual monitoring. As a reminder, you can download these Server & Application Monitor (SAM) templates from the THWACK content exchange:
Also, the SolarWinds legal team has persistently insisted I remind you that these are provided as-is, for educational purposes only. The user agrees to indemnify the author, the author’s company, and the author’s third grade math teacher of any unexpected side effects such as drowsiness, nausea, ability to fly, growth of extra limbs, or attacks by flightless water fowl.
Setting Up Monitoring
As I said at
the start of this series, on top of enjoying what Pi-Hole was doing for my home browsing experience, I also wanted to see if I could collect meaningful monitoring statistics from an application of this type.
I started off with the basics—getting the services monitored. There weren’t many, and it looked like this once I was set up.
In the end, the services I needed to monitor were:
- pihole-FTL
- lighttpd
- lightdm
- dhcpd
Because monitoring services is sort of “basic blocking and tackling,” I’m not going to dig too deep here. Also, because I’ve provided the template for you to use, you shouldn’t have to break a sweat over it.
Next, I wanted to capture all those lovely statistics the API is providing. The only way I could do this was by building a script-based component in SolarWinds SAM. Now I’m no programmer, more like a script-kiddie, but I
can sling code in a pinch, so I wasn’t overly worried…
…Until I realized I didn’t want to do this in Perl. It’s one thing to
shoehorn Perl into making JSON calls because I wanted to prove a point. But since I wanted to put this template on THWACK for other folks to use, I had to do it in a scripting language that hadn’t celebrated more anniversaries than my wife and I had (31 years and going strong, thank you very much. My marriage, I mean, not Perl.). So, I took a good, hard look in the mirror and admitted to myself it was finally time to hunker down and write some code with PowerShell.
Jokes aside, for a project where I knew I’d be interacting with web-based API calls to return XML style data, I knew PowerShell was going to give me the least amount of friction, and cause others who used my code in the future the least amount of grief. I also knew I could lean on Kevin Sparenberg, Steven Klassen, and the rest of the THWACK MVP community when (sorry,
if) I got stuck.
I’m happy to report it didn’t take me
too long to get the core functionality of the script working—connect to the URL, grab all the data, and filter out the piece I want. It would look something like this:
$pi_data = Invoke-RestMethod -Uri "http://mypihole/admin/api.php"
$pi_stat = $pi_data.domains_being_blocked
Write-Host "Statistic: " $pi_stat
Now I needed not only to pretty this up, but also to add a little bit of error-checking and adapt it to the conventions SAM script components expect. Luckily, my MVP buddies rose to the challenge. It turns out
Kevin Sparenberg had already created a framework for SAM PowerShell script components. This gem ensured I followed good programming standards and output the right information at the right time. You can find it
here.
As I began to pull my basic script into the SAM template, I immediately ran into a problem: Raspberry Pi doesn’t run PowerShell, but the script was attempting to run there anyway.
After a bit of digging, I realized the problem. First, I was monitoring the Raspberry Pi itself using a SolarWinds agent. When you do that, SAM “presumes” you want to run script components on the target, instead of the polling engine. In most cases, this presumption is true, but not here. The fix is to change the template advanced options to run in agentless mode.
Once that was done, the rest was simple. For those reading this who have experience building script components, the process is obvious. For those of you who don’t have experience, trust me when I say it’s too detailed for this post, but I have plans to dig into the step-by-step of SAM script monitors later!
Looking Ahead
At the time I was playing with this, script monitors were the best way to get API data out of a system. HOWEVER, as you can see on the
SAM product roadmap page, one of the top items is a built-in, generic API component.
I think I just found my next side project.
