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.
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.
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.
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.
NagiosMonitor application is written to Mac OS X 10.5 specifications and includes the following functional details:
NagiosMonitorwill know it and not bother wasting time trying to fetch an update it can't get to.