We had a request to integrate RSS feeds into Opsview. People were getting fed up with their amount of emails! Fair enough (I get hundreds of emails a day), but the idea was also that you could use a mobile phone to see the trail of alerts too.

We looked at the current offerings for RSS at Nagios Exchange, but weren’t too keen on them. Ssugar’s RSS notifications works by using a notification script for a single admin user. This writes a single RSS feed which then people can subscribe to. The main problem with this is that the feed is not personalised – if I was in the networking team, I don’t want to know about the Oracle alerts.

Steve Shipway correctly identified this problem. His software, Nagios RSS, uses a slimmed down version of the Nagios status CGIs. Again, we weren’t keen on this – it only works with Nagios 1.x, the CGIs are going to disappear by 3.x and there’s a continuous poll on the Nagios server.

So we had to design our own. Our main requirement was to get personalised, authenticated feeds. As little performance overhead would be nice too!

We originally though about some central store of alerts and then a CGI to extract just the alerts required, based on the authenticated user. But it would have been a nightmare to work out what each contact was allowed to see. The key was that Nagios already knows this information, so just let Nagios do it!

Turns out, the trick is to use notifications per contact – each contact that wants RSS feeds has to specify it. This then becomes a direct replacement for email! Superb!

define contact {
contact_name	admin
...
service_notification_commands	service-notify-by-email,service-notify-by-rss
}

Even better – because this hooks into Nagios’ notifications, re-notifications will work, as will acknowledgements and escalations.

One possible problem is that notifications only happen with HARD state changes, so you may not see a problem as quickly as you would from a web browser. However, you wouldn’t get your email either.

We store each contact’s RSS feeds in a separate file, just like their mail server. When a user comes in to read their feed, they only get their data. Perfect!

But, how do we get a user’s authentication? Originally, we were thinking that a user goes to http://nagios.server.com/feeds/username to get their feed, but that wouldn’t provide the security. As CGIs already have security, why not have a single point, but then read their RSS feed independently?

So now the URL is fixed for everyone: http://nagios.server.com/cgi-bin/rss.cgi. When authenticated, the cgi will read that contact’s feed and return that information. There is a CGI invocation overhead, but I think it is necessary one. The CGI only reads a single file, and not try to work out status of all services.

Because it is a single feed, we can use nice things like have the web browser show RSS icons. We amend our HTML headers to be:

<link title="Opsview feed" type="application/rss+xml" rel="alternate" href="/nagios/cgi-bin/rss.cgi" />

On Safari, this displays an RSS box which you can click.

Job done!

We call this software RSS4NAGIOS and you can get it here.

We’ve tested on Firefox 1.5+, but we recommend using NetNewsWire for MacOSX.

By the way, we wanted to use Atom instead of RSS2, but we just couldn’t get the XML::Atom::Syndication perl module to work nicely. This would be a good enhancement in future (we were thinking things like if a recovery happens, then the earlier failure should be marked as read – this would be impossible in email).

Let us know what you think!

[Update: RSS4NAGIOS 1.1 released to support host notifications]