Nagios configuration GUI [closed]

Solution 1:

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!

http://sourceforge.net/apps/mediawiki/nconf/index.php?title=Main_Page

Solution 2:

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.

Solution 3:

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

-steve

Solution 4:

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.