WoW!!
disregard my last post as this one answers it.
This project never ceases to amaze me! Ethan, and the other Nagios
developers, you are doing an incredible job of seeing the seemingly
countless ways to use Nagios. Everytime i read the docs i am flabbergasted
at the attention to detail with respect to what-ifs and possible scenarios.
Can't wait to get my hands on v2.0
later,
dean
-----Original Message-----
From: Ethan Galstad [mailto:nagios@nagios.org]
Sent: Monday, October 21, 2002 12:48 AM
To: nagios-devel@lists.sourceforge.net
Subject: RE: [Nagios-devel] Database Support in Nagios 2.0
I should clarify why I want to nuke DB support in 2.0....
First, I am all for people storing config data in a DB of their
choice. I understand that for large organizations this is necessary
to maintain everyone's sanity.
The only real reason why DB support is better than the text files
(for config data) at this point is speed issues with the CGIs.
Hopefully this will become a non-issue, as I hope to incorporate
support for FastCGI (http://www.fastcgi.com) into the CGIs in 2.0.
The CGIs will read a cached copy of the config files when they first
start up. After the first time the files are read, the won't need to
reparse anything except the status data file. Any speed difference
between reading status data from a text file and DB is probably
negligible. If anything, leaving a DB server out of the equation
leaves one less thing that can break the interface and daemon.
If config data is stored in a DB, it should be simple to write a
small script that dumps the data into template-based text file format
that the daemon and CGIs can use. The script would only have to be
run to regenerate the text config files when the definitions in the
DB changed. Since you have to restart Nagios to take advantage of
any new object definitions, the script could be easily stuffed into
the init script. Extended information (graphics, coords, etc)
probably doesn't change that often, so that shouldn't be a big
problem for people either.
As far as logging events, etc. to a DB in addition to the default log
file, that will be easy to do once I finish writing an external addon
specifically for this purpose. Basically Nagios will pass
information (log entries, check results, events, etc.) to an exernal
daemon. That daemon will be able to load user-defined modules that
can handle some or all of that data any way they choose (modules will
register callback functions for different types of data they want at
load time). A simple module might trap host/service alerts and all
log file entries and dump them into a DB. Other modules might take
performance data from host/service checks and dump it to a DB, pipe
it into an RRDTool-enabled app, etc.
Current DB support is rather hokey in Nagios right now and I want to
clear it out. If it turns out that people can't live without the
current horrible incarnation of DB support, I can always put it back
in at a later point.
On 18 Oct 2002 at 19:56, Daniel Geske wrote:
> Hi all,
>
> In a nutshell: Please keep the DB support.
> Actually I hope that one day I can have all the config completely in DB
> only. It would make administration much easier for me and my colleagues.
> Now, since I have just read about Anders Karlsson's plugin to switch from
> text file based object DB to mysql based I'm anxious to try it.
> Please continue to support storing data in a db, don't "nuke" this
feature.
>
> Thank you!
> Sincerely
>
> Daniel
>
> > As I've mentioned before, I would like to kill off the DB support (as
> > it current stands) in Nagios 2.0. This includes MySQL/PostgresQL
> > support for the following data types:
> >
> > - status data
> > - retention data
> > - comments
> > - downtime
> > - extended info
> >
> > Is there any really good reason why people want/need this data to be
> > stored in a database?
> >
> > Extended info is not dynamic like the other items on the list - its
> > more static like object definitions. If people want to store this
> > info in a db, it would be fairly simple to just
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: than Galstad [mailto:nagios@nagios.org