Now I have noticed that I don’t look at the status bars at all, and the actual information displayed on the numbers is quite small compared to the screen estate they take. That’s maybe not a big problem to most, but if you have several gadgets running on a small screen, you might value a more compressed view.

The Gadget UI

The more I think about the optimal design, I’m returning to the idea of visual indication only. Currently I’m planning to design a gadget with just three traffic lights, that can display one of three or four colors. Their purpose would be:

1. Gadget status
   • Green for all-ok
   • Yellow/orange for warning/notice kind of states (an update for the gadget is available, an update query failed once, an update took too long to load etc.)
   • Red for errors (no connection to the server, or there was an error either loading or processing the status information etc.)
2. Host status
   • Green if all hosts are OK (acknowledged errors or scheduled downtimes are calculated as OK)
   • Yellow/orange if there is at least one host unreachable (but none down – actually, I’m not sure if this kind of situation is possible by definition)
   • Red if at least one host is down
3. Service status
   • Green if all services are OK (also acknowledged errors or scheduled downtimes on the services or their host are calculated as OK)
   • Yellow if at least one service is Unknown (but none in conditions mentioned below)
   • Orange if at least one service is Warning (but none Critical)
   • Red if at least one service is Critical

I’m aware that many Nagios users have constantly having some error conditions on their monitored hosts/services, so the blunt single traffic light interface might not be the best choice. To conquer at least some of the problems, I’ve thought of keeping the numeric information somehow (maybe inside the traffic light, in a more condensed layout), or you might be able to choose whether to show the numbers or not.

But another big change would be the indicators on state changes. Currently the gadget flashes with red rims for a few seconds, when a state change occurs. It does it on all changes (from ok to non-ok states and vice versa, and also on acknowledged/scheduled hosts and services). There’s also a possibility to play a sound, but the same limitations apply to that too. I’m planning to change the indicator to flashing the corresponding “traffic light”, and adding a configuration parameter that allows you to a) disable the flashing, b) flash (as the current behavior) for a few seconds or c) flash until you acknowledge the change (by clicking the light or acknowledging the Nagios status or something).

The Flyout UI

About the flyout UI my plans are not so refined yet. Quite possibly (to keep the update cycle reasonable) I’ll keep it unchanged at first, and start modifying it when the main gadget design has been changed. But some ideas I’ve developed so far:

• Split the flyout to two or three different pages (overall status, hosts, services; or maybe overall status, non-ok hosts and services, and ok hosts and services).
• Add more details to ok hosts/services. This would probably be somehow configurable to keep the UI usable on larger installations too. But I’ve gotten used to check some service status using the flyout (like available disk space), and only remember that it’s not displayed if it’s not in warning or critical state when I have already opened the flyout.
• Maybe some of the detailed information could be presented as a tooltip when hovering the mouse over the host/service name. This would, however, require a more refined method to request information update in a more modular fashion.

The nagxmlstatus.cgi script

Especially the last bulletpoint in the previous list made me think further about the nagxmlstatus.cgi script and it’s functionality. Currently it just converts the whole status.dat into XML and filters out the requested information. This is far from optimal, and makes it difficult to balance between how often to make this translation on the server and how much processing to do on the client.

Once again I wish that there was a real Web Service interface in Nagios itself (like SOAP or XML-RPC). I admit that it would be also heavy thing to implement, but much lighter than running my script every few seconds, and I’m sure that others would find use for such too. However, this is far out reach for my skills and resources, so I’ll have to live with the script system until someone else implements that Actually, I have found one, the NXE – Nagios XML Engine, but that project shows no updates since version 1.0 (which was released 6 years ago), so I’m not counting much on that now.

The only practical way to use the current script in larger environments is to dump the script output to a file using cron (or similar) and reading that file from clients. But this method locks down the information to quite little details (or, you could add details, but this would make the client processing much more cumbersome). Maybe I could make a wrapper daemon for the current script, which would periodically read the status.dat and transform it to XML in the memory, and you could request specific information from there, with maybe a possibility to trigger a partial or complete update of the status information.

Endnote

This list was originally titled just “Plans for Nagstatus V2.0”, but I ended up with so many changes that they will definitely not be all implemented in V2.0, if ever. So, consider it as a roadmap with possible developments for the system. As this is a hobby project, I will not set any deadlines nor make any estimates when new releases are available or what they include.

But if you have any comments or suggestions on what you as a gadget user would like to see, drop a comment below or mail me.

nagxmlstatus.cgi is a script, written in Perl, that translates Nagios status.dat file (in Nagios proprietary format) to an XML formatted file. The script was originally written to provide Nagios status information for Nagstatus Gadget for Windows Sidebar, but as it translates all data in Nagios status.dat, you can use it for other purposes too.

Requirements

To use the script, you must have Perl installed, along with XML::LibXML module. Most GNU/Linux distributions have them both available as installable packages (RPM based distros use perl-XML-LibXML, deb-based distros have libxml-perl and at least the newer Ubuntu have libxml-libxml-perl; consult your distribution documentation on how to install these). If you can’t find a ready installation package, and have Perl already installed, you can run the following command:

% perl -MCPAN -e "install XML::LibXML"

Installation and Configuration

The easiest way to install the script is to place it into the Nagios installation’s cgi-bin directory (the same where all Nagios cgi binaries are), and make sure it is executable by your http server’s user account (or, on a GNU/Linux platform, run chmod a+x nagxmlstatus.cgi).

There is one configuration parameter within the script. On line 15 is specified a variable called $STATUSFILE. This must point to the status.dat file of your Nagios installation.

Using via HTTP Requests

If you call the script seldom (like, you have only one or just a few Nagstatus gadgets running in the network), you can call the script directly via http server. For the Nagstatus gadget use, just specify “Nagios Web UI URL” config parameter (or “XML Status Provider URL”, in case you have put the script in somewhere else than the Nagios cgi directory), and choose “Script” in “URL points to:” (as is the default).

If you want to use it for other purposes, you can first try to specify “nagxmlstatus.cgi?node=all&elem=all” in a web browser url. This will return your whole status.dat content formatted as XML, and you can examine that to determine what content you really need. After that, just specify the nodes and elements you need as request parameters (you can, and probably will, have multiple node’s and elem’s). For your reference, the Nagstatus gadget uses the following request:

?node=host&node=service&elem=current_state&elem=plugin_output&elem=problem_has_been_acknowledged&elem=last_state_change&node=program&elem=program_start&elem=last_command_check&elem=scheduled_downtime_depth”

Using via Cron

If your script gets hit frequently, it might burden your server’s resources too much. The script is using a lot of pattern matching, XML libraries and other heavy methods to provide the XML result, so you probably want to lessen the times it gets run. You can use cron or other scheduling methods to run the script from commandline, and redirect it’s output to a file. Then you can access that file from the client using http or other methods. Even if you run the file every minute, it should be reasonably light on any modern server, and provides Nagios status information in a timely manner.

To do this, you must specify the wanted output using commandline parameters. The nodes are specified with –n –parameter, and elements with –e. For multiple nodes and/or elements just specify comma separated list as the parameter. For example, to use with Nagstatus gadget, use the following command line:

nagxmlstatus.cgi -n host,service,program -e current_state,plugin_output,problem_has_been_acknowledged,last_state_change,program_start,last_command_check,scheduled_downtime_depth

To use the resulting file with Nagstatus gadget, simply point the “XML Status Provider URL” setting to the file, and choose “File” as “The URL points to:”

• Gadget UI change: Unacknowledged and non-scheduled problem services on hosts that have been acknowledged and/or scheduled down are now displayed in blue (so the gadget behaves similar to the flyout after changes in V1.5.2)

Download this version here: Nagstatus V1.5.3

• Bug fixed: when integer percentage of status color bars exceeded 100% the color of the bar was not shown.
• Flyout UI change: Title “Hosts OK/Problems Acknowledged” changed to “Hosts OK/Acknowledged/Scheduled down”. Accordingly, the hosts that are in down/unreachable status and either are acknowledged or have scheduled downtime are now displayed here, whether their services have been scheduled down/acknowledged or not.

• Visual layout implementation modified and fixed some bugs.
• Gadget and flyout now recognize hosts and services that are on scheduled downtime and displays their stats in blue like the acknowledged hosts and services. The flyout flags hosts/services with scheduled downtime with [SCHED].
• If you are using cron (or similar) to run nagxmlstatus.cgi and save results to file, you must modify the commandline to contain also scheduled_downtime_depth element. See README.txt for correct commandline (there was also a typo previously in that commandline spec, that has now been fixed).
• Gadget now shows a visual alert (blinks red glow around the gadget for a few seconds and optionally plays a sound if one is specified in the settings) if a host’s or service’s state has changed since last check.
  Note that the alert is shown/played on all state transitions.
• The date and time of latest state change is displayed on the flyout.
• And to support the above changes, the nagxmlstatus.cgi adds a <last_state_change> element to <program> node that contains the timestamp of the last state change in all hosts/services.
• The settings page has been revamped. You no longer need to specify the URL to Nagios’ extinfo.cgi. Instead, you must specify the Nagios Web UI root URL, all other URL’s are derived from that (including URL to XML status provider, if you have placed it under Nagios’ cgi-bin directory; otherwise you still have an option to set it by hand). Flyout’s “Nagios Status” headline acts as a link to this URL.

• Kludged nagxmlstatus.cgi to produce compatible output with Nagios V3 status.dat file format. Thanks to Paolo Cozzi for testing it!

• Cleaned up flyout layout a bit.
• Also gadget itself now recognizes acknowledgement state of hosts and services. Error counters are displayed in blue for acknowledged services, and status bar show them as blue. Error counters are displayed as red/orange/yellow when there are at least 1 error state that has not been acknowledged.
• Fixed a bug in nagxmlstatus.cgi that caused it to error if run on commandline without -f parameter.

Modifications to nagxmlstatus.cgi:

• The script takes additional values for parameters:
            node=all returns all nodes (objects) in status.dat
            elem=all returns all elements (values) in status.dat
• The script can be run on commandline, with parameters -n and -e that specify list of nodes and elements to be returned (respectively). The parameters take comma separated list as values.

Modifications to the flyout page:

• The top row displays the date/time when Nagios was started as well as date/time when last check command was run.
• Hosts that have problems, but all problems have been acknowledged, are now listed in the right column (“All OK”), on top of the list.
• Hosts/services that have problems but have been acknowledged display a [ACK] tag before host/service name.
• All hosts/services that have problems now display the plugin output and date/time of last state change.

New setting:

• On settings page there is new setting: URL points to Script/File. The File choice is for a setup where the gadget reads a static file produced by a commandline nagxmlstatus.cgi.

nagxmlstatus.cgi now uses XML::LibXML instead of XML::DOM. It is available as perl-XML-LibXML (rpm-based) and libxml-perl (Debian based) package on most Linux distributions. This is due to that I ran into claims that XML::DOM is nowadays unsupported.

The script provides exactly the same behaviour as the previous version, so current gadget runs fine even with older script.
       
Status XML request behaviour is changed. The gadget now requests new status at intervals specified on settings page. After receiving new status XML it updates the gadget and also flyout (if it is shown). When showing the flyout, the gadget does not request new status XML, but renders the flyout based on cached status XML.
        
Also added error handling

• HTTP request timeouts after 30 seconds and displays an error message (for both gadget and flyout).