DB store for cfg data

[Andreas Ericsson]

local.coder wrote:
> Ethan has said that he saw DB storage as a module. An option to be put in place.
> In 2.0 we should see a common set of functions and classes for pushing the data
> into nagios and pulling host status data and entries from nagios.
> 

It's a good thing, as it opens up the field to the DBD's and DBAP's out 
there, without him having to do lot of work for it. Apache didn't really 
take off either before it had loadable module support, so this might be 
an intrigueing project to the many wannabe altruist hackers of the world.

> This will eventually be tied to "name your DB" and frontend for working with
> hosts. There are several times when I cures the text files, but there are
> others where I can add strange things quickly and easily. I know that setting
> up the right DB to give me the same functionality will be difficult. Things
> like having all the possible options but just setting the basics and still
> allowing flexibility. I am a DB person by work and even I can see why Ethan
> wanted to stay away from it on this. DB alone would take all the time and
> effort to tweak and make work right.
> 
> 2 things are certain. We will see a web interface for configuring Nagios and we
> will see a way to store all the data in a DB. It's all about when and who.
> 

The who might be me, if I can convince the boss to distribute our 
webconfiguration interface as free source, but insofar we haven't added 
the database-support (getting a random nagios config into 3NF without 
M-to-M relations is a pain in the ass).

It's written in PHP though, so I suspect that will come about the same 
time as nagios gets a PHP-based GUI, if not before. We might commit some 
company funding to take care of that if I haggle enough about it, and 
the basics have been written already.

Besides, with a GOOD free webconfiguration interface it wouldn't matter 
if configuration options were a bit reduced, since most of them are 
actually there to save the users a lot of the typing.

> Derrick
> 
> Quoting Andreas Ericsson <ae at op5.se>:
> 
> 
>>Ed L. wrote:
>>
>>>I'm looking for a suitable monitoring system, and have recently spent some
>>>time evaluating Nagios.  I notice that 1.2 appears to have some support for
>>>local storage of cfg data (eg., hosts, groups, contacts, dependencies) in a
>>>relational database (pgsql/mysql) as opposed to the flat files in
>>>nagios/etc/*.cfg.  A brief glance at the cvs logs since 1.2 seems to
>>>suggest it's all been gutted long ago (Dec 2002?), and also appears to be
>>>removed from the latest configure script on the cvs trunk.
>>>
>>>Is there a current nagios developer consensus on the value of cfg storage
>>
>>in
>>
>>>an RDBMS?  Not worth doing?  Others working on it?  Is it desired?
>>>
>>
>>I think it was axed due to the problems involved in normalizing the
>>database for the nagios configuration.
>>
>>To get the nagios config to 3NF would require a herculanean effort, and
>>nobody seems willing to do it until there's a decent web-interface to
>>set up the configuration anyway. Ofcourse, it's impossible to write the
>>web-interface without having the layout done, so the breakdown comes
>>full circle before we even gained momentum.
>>
>>Besides, adding support for one type of RDBMS would soon raise voices to
>>add support for others as well, and that means even more work without
>>actually adding functionality.
>>
>>The GUI for Nagios 2.0 is a whole lot faster anyways (hashing code,
>>cached static form object data), so performance is not really an issue,
>>and most users are more comfortable with emacs, vi or regular
>>expressions than with sql queries for updating their config.
>>
>>
>>
>>>TIA.
>>>
>>>Ed
>>>

-- 
Sourcerer / Andreas Ericsson
OP5 AB
+46 (0)733 709032
andreas.ericsson at op5.se


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND