iNag for iPhone
At a Glance
iNag Nagios Viewer
Amazon Shop buttons are programmatically attached to all reviews, regardless of products' final review scores. Our parent company, IDG, receives advertisement revenue for shopping activity generated by the links. Because the buttons are attached programmatically, they should not be interpreted as editorial endorsements.
Like many network administrators, I use Nagios to monitor my network. Nagios is an open-source network monitoring system that uses SNMP, Perl, and other languages to monitor your network, with a Web UI for viewing the current state of your network and the devices within. While Nagios has a simple HTML-based interface, it’s rather kludgy to view on an iPhone. There have been some attempts to create a Web app front-end for the iPhone, but, up to this point, they’ve been overly complicated and tedious to set up.
iNag, from John Fullington, is a native iPhone app that can talk to an existing Nagios system without a complicated setup. It does solid job of giving you the information you need in a clear, concise manner. It’s not perfect, certainly, but it’s not missing much. iNag costs $15 in the App Store, and in my use thus far, I've definitely gotten my money’s worth.Read more…
Setting up iNag is a two-step process. The first part is buying and downloading the app itself from the iTunes Apple Store. Once that’s done, you have to download a separate PHP file that acts as an interface between iNag and your Nagios server. (Just to be clear: You have to have an existing Nagios server to use iNag. iNag is not a network monitoring server by itself, it is a front end to an existing Nagios server. If you’re not using Nagios, iNag will be of no use to you at all.)
There’s a small amount of customization you have to do to the PHP data feeder file, (inag.php) to set it up for use. First, you have to tell inag.php the paths to your Nagios status file, external command file, and your log file. (If you’re somewhat new to Nagios, the paths to these are in the nagios.cfg file in /etc in your nagios base directory.) You should use the full path, not just the relative path, since depending on how you installed it, the base Nagios directory may not be the standard /usr/local/nagios/ tree.
Once that’s done, you have to set up read-only and read/write values, for the $ROkey and $RWkey variables. In the current version of iNag, “read/write” only lets you acknowledge problems. You can’t actually modify or even restart Nagios from iNag as of yet, so unless you use the problem acknowledgment function, the $ROkey variable is all you’ll need. You then copy inag.php into the directory where the HTML files used by Nagios are. I just copied it into the Nagios root web directory, for convenience sake.
Next, you configure iNag’s settings on the iPhone. iNag’s settings are pretty straightforward. It needs the full URL to the inag.php file, the value for either $ROkey or $RWkey, and the user name and password you’ll be using to log into Nagios with iNag, as in the screenshot to the right:
Stern security warning: I highly recommend that you only use HTTPS to talk to Nagios, whether with iNag, or a “regular” Web browser. Depending on how your system is set up, Nagios can give an attacker a wealth of information about what’s on your network, what services you’re running on your network, and a logical map of your network. While there is encryption support in SNMPv3, there are a lot of platforms out there, such as switches, most printers, wireless access points, routers, and Windows that do not support SNMPv3. Many of the Nagios plugins don’t encrypt their data either. If you’re connecting to Nagios via an unencrypted connection, and someone manages to tap into that, you could give that person a ton of information you’d rather they not have.
Once you’ve got the setup done (it took me about five minutes), start iNag and go. This brings me to what is my major annoyance with the application: when you first start iNag, the initial screen is not necessarily what your Nagios server sees. To see the current data, you have to hit the refresh button, and it’s annoying. If I start iNag, it is a reasonable assumption that as part of that, I want it to talk to my Nagios server, and not make me hit “refresh/reload” just to get initial data. This pattern repeats throughout the application, and it just adds a thin layer of annoyance to things. However, once you hit refresh, you see a nice tactical display that gives you the overall status of what Nagios is monitoring at a glance, as shown to the right.
I scrolled down a bit to show the services more clearly. What’s cut off are the number of Ok hosts. However, the overall display is clear. You can see the status of both hosts and servers. (In Nagios-speak, a host is a device on the network, and services run on a device). If you tap on the “Warning” section in Services, you’re taken to a display that more clearly tells you what the problem(s) are:
This page shows each problem service categorized by host. If you tap on one of the entries here, you get taken to a detail screen for that service:
In this case, the problem with the ping service for that host resolved itself by the time I got to this screen. The nice thing with iNag is that it worked how I expected it to. Tapping on an item showed me more detail on that item if it was available.
iNag can also show you a list of all the hosts in Nagios, as shown on the right.
Notice that this only gives you the host status, not the status of any services on the host. This brings me to my second annoyance with iNag: No support for Nagios hostgroups. Nagios lets you create hostgroups to organize your hosts in. That let you apply services to groups, rather than individual computers. It’s much easier to create an LDAP service check and add a “LDAP Servers” group once, then add multiple individual servers every time you create a new service. Hostgroups also aid in visually organizing things in Nagios. As you can see here, even though I only have 60 hosts, trying to see each one in the Hosts display is going to require a lot of flick-scrolling. Considering that a large Nagios install might have hundreds or even thousands of servers, the need for iNag to support hostgroups in the hosts display becomes apparent.
Services are somewhat better, in that they’re organized by host (pictured right), but having each host’s list of services be expandable/hide-able or supporting Nagios servicegroups would be a big help, usability-wise.
I’d like an option to organize services by either service name or host. If I have ten Web servers, I’m more interested in the status of those services in one quick glance, than scrolling from server to server to look at one service on each. I’d also like to be able to refresh a view from either the Hosts or Services views, instead of just the Tactical and Event Log views.
iNag lets you view the Nagios event log, but just like iNag’s tactical display doesn’t show you real data until you refresh at least once, iNag’s event log display is blank until you refresh at least once.
Here’s a look at the display before you refresh:
And here’s what it look like after you refresh:
None of the issues I have with iNag keep it from being useful and worth the money, but they just create annoyances that shouldn’t be there. One other annoyance is that iNag doesn’t allow you to remotely restart or halt Nagios, nor does it allow you to modify the settings for a given host
Macworld’s buying advice
If you are running Nagios on your network, have an iPhone or iPod touch, and need to be able to talk to Nagios from those devices, iNag is a no-brainer at $15. Even the annoying UI issues don’t materially detract from the usefulness of this application to a Nagios administrator.
iNag Nagios Viewer is compatible with any iPhone or iPod touch running the iPhone 2.2.1 software update.
[John C. Welch is a senior systems administrator for The Zimmerman Agency, and a long-time Mac IT pundit.]