This site will act as a single point of access to all information related to the Nagios monitoring tools I've developed for Mac OS X and the web.
Nagios is a tool we use at the University of Delaware to monitor the thousands of servers, network switches, wireless access points, and other network-aware systems spread across the campus. Status updates are sent via email, and a PERL-driven website is used to view and acknowledge or comment on the service status information for each host.
With over 1800 hosts being monitored, the website can take an appreciable amount of time to render a page. While the site is definitely the most information-rich way to visualize the overall status of these 1800+ entities, it would also be nice to have a "Nagios Lite" interface which merely provides a quick overview of status, sans the full range of data the Nagios site itself supplies. This interface should provide links back to the full Nagios site in order to quickly move the interested sysadmin back to the full problem description.
The NagiosMonitor project was born to fulfill this purpose: a lightweight tool which provides simple service status feedback, driven by Nagios' data store.
Like many modern data exchange agents, the simplified status information is distributed as an XML file. I began this project by prototyping a DTD to represent the full range of data we wanted to push out to the simplified client (well, as it turned out, clients) that would display the status information.
From there, I wrote a PERL script that runs every five minutes on our Nagios system. The script scans Nagios' status data file, accumulating status information for each host as it goes. It then scans the hostgroups configuration file and adds host group memberships to each of the hosts seen in the status data file scan. Two XML files are then generated by walking the accumulated list of hosts: a file which orders the hosts by name and a file which orders them by the time of the last service status change for that host1). These files are copied to a web-accessible location where the client applications can access them.
For the 1800+ hosts that we monitor, the XML generator script runs for about five seconds, maximum. So there's really no load impact on the server. The file is pretty hefty, though, weighing in around 4.3 MB. So we serve it through Apache with pre-zipped encoding – the file is gzip'ed and Apache delivers it as though it were doing on-the-fly, inline gzip encoding of the content (a brilliant idea, and sadly I can't take credit for it).
This whole project came about as a result of my wanting to try my hand at crafting a Mac OS X Dashboard widget with Dashcode. I'd written a widget back when Dashcode was still in beta, so I was curious to see how it had evolved as a development tool.
Dashboard widgets are an interesting melangé of Javascript, CSS, HTML, and regular executables. Lately I've spent a lot of time working with adding AJAX to web services to make them a bit more than web browser-to-server ping-pong matches. Drawing on this, it was relatively easy to build some functionality that would fetch the Nagios status XML and render it into HTML. Thereafter, the programming was more or less just a matter of setting DOM objects' innerHTML values. It took one Sunday afternoon to produce a working widget, and another few hours' work another day to massage it into final form.
If writing the Dashboard widget involved Javascript code that played with a DOM document, then wouldn't it transition fairly easily to the web? I didn't even ask myself this question, I just assumed from moment numero uno that I'd port the Dashboard widget to being a regular XHTML+Javascript+XML web application. The conversion took me one afternoon of work, which mainly revolved around attempting to mimic Dashboard's placement and linking of DOM pieces.
The web application also solves a simple problem with this project: what is a Windows user to do with a Dashboard widget?!? Maybe someone with Vista knowledge will eventually write a Vista widget (is that what one calls those things?); until that time, we've got a web app that anyone can use.
Javascript remains a restrictive programming environment. My continued efforts in AJAX only serve to continually frustrate me with how haphazardly thrown-together the language feels. In the past I've written a few desktop applications using Apple's Cocoa environment; I've been itching to find a project that would warrant another excursion into that chocolatey goodness.
The problem with the Dashboard widget was that as soon as one exits from the Dashboard, good behavior indicates that a widget should shutdown any timers or intervals it was using while Dashboard was active. So basically, when the user exits Dashboard, the widget is no longer periodically refreshing itself with the Nagios XML feed. As far as desktop applications go, it would be far more helpful if the refreshes were happening on an interval, period, and the application notified me of any status changes. This was another impetus behind writing a Cocoa application to make use of the XML feed.
The NagiosMonitor application is written to Mac OS X 10.5 specifications and includes the following functional details:
NagiosMonitor will know it and not bother wasting time trying to fetch an update it can't get to.Instruments under 10.5)This site makes use of DokuWiki and the "Simple" template created by Michael Klier to present content. The "discussion" plugin is used to facilitate registered user comments on pages.