Posted by: Eric Hansen
when relevant content is
added and updated.
For the past week or two now I’ve been working on an application to help monitor systems and services. Kind of a bastard child of Nagios and Cacti. There’s a few reasons why I’m “reinventing” the wheel, so to speak. But, I’ve decided to post here explaining the details, trials and tribulations, as well as any other random tidbits of information to toss in as well. Some of these will most likely also be cross-posted to www.securityfor.us as well, but a bulk of the stuff will be posted here. Anyways, on to why I’m doing this…
Nagios is a great tool. For years I used it myself. Its very powerful, integrates with virtually anything you can access via SNMP or scripts, and the documentation is pretty easy to follow. There are two main points of failure in terms of usability, though, that I find.
First, there’s the fact that its written in compiled CGI (or C, can’t remember now). With a strong background of “open source” initiatives, this surprises me thats it has lasted so long in the field. Its akin to running Microsoft Office via WINE; it works and does its job, but there’s better (or more suited) alternatives. If something goes wrong, you have to wait for the Nagios team to fix it, unless its a script to check for service/host status.
Next, there’s no ACL built in. I’m not sure why this is, but essentially Nagios relies on you running Apache (or something else that provides an authentication method like an LDAP module). Writing even a moderately functional authentication system takes a day at most. I’ve never been able to understand this aspect, and I feel it hurts the rest of the usability by not being able to segregate who can see what.
There are more reasons with Nagios that sparked my interest in writing my own monitoring set up, but I want to also address the software that this is more or less based on, Cacti.
Cacti, at least to me, is more of a RRDTool learning tool or assistant than an actual monitoring solution. It helps you create RRDTool graphs (which can be a major pain at first), and thats about it. If you really look at it, about 99% of its functionality revolves around building RRD graphs. Which is great, I even use RRD graphs in my set up as well. But, what else does it bring? Products like Centreon, that rely on Nagios on the backend usually, offer graphing as well, on the same platform (PHP) and is more actively developed.
More or less, I also touched on this with Nagios, but Cacti is developed in PHP (granted, open sourced). Why I mention this is because from my stand point and feeling, PHP and CGI/Perl are absolete languages when it comes to web development. They do have their place, don’t get me wrong, but the overhead and slowness of PHP, and the over-abuse of extending a language beyond its intents in CGI/Perl is just wrong.
These are a couple of reasons why I decided to roll my own solution. It has what is currently out there, offering more, while more or less requiring less overhead. A normal Cacti installation is difficult to run efficiently on a 256 MB VPS with 256 MB swap, and Nagios just causes more overhead the more it has to monitor. While the same can be said for Python, the integrations it has with different tools and the like makes developing on said platform a lot easier. This is what most of these articles will be covering as well.
As I’ve been working on this for a week or so now, I already have a couple of more articles I’m going to be writing tonight, as I’m heavily enduced with caffeine and nothing else to do as I can’t program on laptops (they annoy me greatly).