We've implemented Nagios for services on our network and it is working great. The notifications are nice and the wide range of configuration options are very handy. Up to this point, we've done all of the configuring by hand by modifying the files directly.

As we start to open this up a little to some of the other administrators, I'd like to implement a GUI that will reduce the likelihood of errors. I've checked out a few different GUI projects and so far it seems like NagiosQL and NConf are the top contenders so far.

Are there any recommendations between these two, or perhaps others that should be considered? How about stories of installation and use, "gotchas" and tips that may be useful in deciding?

closed as off-topic by masegaloeh, HopelessN00b Mar 11 '15 at 18:34

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

locked by HopelessN00b Mar 11 '15 at 18:39

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.

  • I would also be interested in this - as well as info about how difficult it is to migrate a significant existing installation to the gui tool. – Brent May 29 '09 at 14:48

We're in front of the same decision and currently nconf is our favorite. It has the big advantage of beeing designed for big distributed enviroments.

It creates you automatically configuration files for different nagios server, one beeing some kind of a collector and one beeing the monitor, which receives only passive checks from the colletor.

On the downside, currently you can't handle escalations with nconf!



We use OpsView at work. It's a web based GUI, and handles things like scaling up the Nagios service via clustering. You can add new hosts, new services, via the web, and acknowledge the outage. It also records a historical view of services, should you wish to know things like how much CPU a server regularly needs.

You still won't be able to add Nagios scripts via the web, however.

  • It looks pretty solid and I think we'll give it a test run since they have a VM that can be downloaded. Do you know if you can import your existing Nagios configurations? – palehorse May 29 '09 at 15:59

We've had good experience with Opsview for managing Nagios. However, it's a mistake to think of it as a "front-end" for Nagios; instead, think of it as a monitoring system that uses Nagios as its underlying engine.

The Nagios config is stored in a DB and the Nagios config files are generated programmatically, so if you're used to, say, storing your Nagios configs in source control, or generating them using some script of your own, you'll need to give up those procedures.

What you get instead includes the following:

  • centralized management of a distributed Nagios system
  • integrated SNMP trap management
  • integrated Nagiosgraph
  • integrated NMIS
  • automated stats aggregation and report generation
  • no more syntax errors in your Nagios config files :)
  • centralized downtime management
  • an XML API that exposes a subset of Opsview's management functionality
  • automated migration from your existing Nagios config


  • It looks pretty solid and I think we'll give it a test run since they have a VM that can be downloaded. Do you know if you can import your existing Nagios configurations? – palehorse May 29 '09 at 15:59
  • I haven't tried this functionality myself, but I believe it is present; check with the developers, they're quite responsive. – hakamadare Jun 19 '09 at 13:52
  • appreciate the clarification about the relationship between opsview and nagios – Brad Mace Oct 7 '10 at 16:27

The gotcha I'm leery of is that the configuration frontend can sometimes create really garbagey config files that aren't intuitive to edit by hand should you need to later. This is sort of a problem with any system that uses machine generated config files, and is fairly well understood even if it's not intuitive.

My usual approach with Nagios has been to use the templating and inheritance features extensively, and to split my configs out into many, many, many, many files.

It's worth noting here that the Nagios community recently forked because the main developer's kind of lacking in leadership skills, and Nagios really hasn't improved or changed much in ten years. Icinga is supposedly the new cool, but I haven't tried it yet.

  • Thanks for the heads up. I hadn't realized it had forked. Good to keep an eye on. – palehorse Jun 4 '09 at 20:06

UbuntuGeek just posted an article on this very subject today. Its along the same lines as the http://www.ducea.com answer by Xerxes, but just a little more current article with some of the newer projects added in. Anyway, its a decent quick overview covering several Nagios config gui, which should give you a good starting point.



The new official nagios exchange opened up today as well, here is a link to the Configuration section for quick reference:



Nconf do not support service and host escalations


you can "extend" the application to support it directly from the web gui via the administration menu creating two new classes "hostescalation" and "serviceescalation" in each new class you must define an escalationid attribute with "Naming Attribute" set and not writed to the output a dedicated configuration file

then define any attribute related to the escalation and that must be written to the configuration file, for example: host_name linked to the host class contact_groups to a list of contactgroups class and so on


For the same reason as you, we had to implement a front-end. Personally I find them all a little clumsy and would prefer to manage the configuration files by hand (less effort). But seems like you don't have much choice.

We use monarch, but I don't like it all that much.

I haven't tried anything else either, but you can start here...



I would definitely recommend Centreon as a Nagios frontend. It doesn't only ease the configuration process, but can also be used for status display and collection of performance data returned by Nagios checks which is than transformed into nice looking graphs. Thus, in a way, obsoleting Cacti as well.


The retail product NagiosXI is reasonably priced and hides all of the underlying text config files. We've been using it for about six months and are happy with its cost/benefits.

Not the answer you're looking for? Browse other questions tagged or ask your own question.