Nagios Support Forum

We've been running Nagios Core in our business for the last 9 months and are looking at moving to Nagios xi due to the addition of UAC which has been a big problem with the core product and trying to use it in an organization of our size. I've been playing with the Nag xi demo and have run into a few features we feel are lacking:

1. NagQL just doesn't meet our requirements for configuration... it takes longer to add a new device, occasionally doesn't behave as expected and is in general more confusing (for our users) than the templating system we currently use for deployment. Just how closely tied to the new interface, UAC and backup is NagQL in order to remove it? Or at the very least is there an issue if we removed all the configuration data from it and used the static folder?

2. I love the new dashboard page and the fact you can pin various elements to them... but why on earth can you not pin a filtered set of check results? It would also be handy if there was an interface to select filter options.

3. An option for LDAP/AD integration for user auth, even with the brand new login screen we still have to use apache authentication, so now users have to logon twice and I have to maintain two sets of credentials and users need to remember two sets of passwords... it's hard enough getting them to remember one.

4. Dashlets have no UAC on them, we were hoping to port our current config utility and a few others into a dashlet but it's difficult without being able to set user restrictions.

I realise that most of these are just feature suggestions and can be worked around but the first one is fairly important as the product otherwise provides us with no major benefit over what we currently get out of the core package.

#1. NagQL is rather closely tied into xi, however, it also allows for the use of templating through the UI by defining them in the Core Config manager, which most users find preferable.

#2. You can assign host and service groups, and those group summeries, grids, or overviews can be assigned to a dashlet. Not sure how you're looking to filter your hosts or services, whether it be by status or host or whatever, but any group view can be assigned to a dashlet.

#3. Don't know enough about your configuration to respond to this, other tech team members may know a workaround.

#4. Individual dashlets don't have UAC, but you can create a new Dashboard that IS user account specific. As an admin, you can "masquerade" as a user and put whatever dashlets you want that user to see into their own custom dashboard.

xi isn't for everyone, but I think if you take some more time to explore all of the features you may find it meets a lot of these needs.

We dabbled with QL for a while on the core product and I've played a little more with it in xi (We're using the pre-built centos VM), when restarting the nagios core service after a configuration change on occasions it will not terminate the current running process so you end up with two instances of nagios... which causes fun issues like devices dissapearing from display.

The QL templating system while it's nice to have one still takes longer and is harder to use than our in-house option which provides one click deployment (Essentially a glorified web based text file editor with a bunch of templating, deployment, backup and file manipulation functions). So if we can't remove QL itself will removing all of its default host/service/notification configuration data cause any adverse affects? I.e. If we remove notification config data will the user still see the devices to which they are assigned or are these taken from the QL DB?

The second issue is prodominantly because we wanted to create a dashboard that listed all known service issues (essentially the problems screen in the core product) and attach a custom dashlet that listed the last x amount of critical traps received by the nagios box so we are able to use a single overview window display to get a snapshot of the exact current issues affecting our environment that need to be addressed.

The issue with dashlet restriction is more so if we wanted to create a dashlet that performed an administrative function we can't restrict only administrative users from having access to it. We are still required to use an external web app, the ability to consolidate would be another "nice to have".

I like xi, but it seems like its added as much as its removed in terms of flexibility.

I would agree that there's always a trade off in making something more "user friendly" and a decrease in flexibility. One of the goals of xi is to make it usable to a wider audience, and some of the flexibility is restricted to make it easier to support as well.

If you've got an in-house option that's faster and better than NagiosQL, that's awesome, and more power to you. We use it because it's currently the best open-source tool out there that we've found so far. I'm guessing that taking QL out of xi would make it something that we couldn't actually support anymore, but that'd have to be discussed with our sales team.

Those are some interesting ideas for dashlets. Those might be some items we'll have to look into developing. We're currently working on a PHP interface to replace a lot of the CGI's, but those are some interesting ideas that we could probably put on a to do list.

Calling our in-house solution better would probably be stretching it a bit, it's just better suited to the current business needs. I suppose I will continue this discussion with the sales team.

Good to hear those ideas have been taken on-board. Thanks for the help guys.

No problem, let us know if you have any other questions!