Re: [Nagios-devel] Database Support in Nagios 2.0

Support forum for Nagios Core, Nagios Plugins, NCPA, NRPE, NSCA, NDOUtils and more. Engage with the community of users including those using the open source solutions.
Locked
Guest

Re: [Nagios-devel] Database Support in Nagios 2.0

Post by Guest »


> I don't see any really good reasons for keeping DB support around for
> the rest of the data, but I'd like to hear some comments before I
> start nuking code.

I run a fairly large site [130+ hosts, 3100+ service checks] using
netsaint (soon to move to nagios), and that size makes for different
requirements than someone using it on a small site.

I'm not committed to integrating nagios with databases, but it seems an
easy solution to some of my problems. Other solutions could probably
work just as well however.

Some of the things that I require for nagios to be useful to me:
* Passive check results have to be processed, missing some is
potentially troublesome. Using a database means that the
results get stored somewhere even if nagios isn't running.

* All the reporting mechanisms (avail, trends, etc) should be able
to generate a report for a years worth of reports in a short
amount of time. Using a database to store the results means that
you can pull the results for, say, a single host without needing
to look at the results from other hosts.

There are other issues that are related to running nagios at a large
site that don't have to do with databases, such as user interface
stuff, that I won't detail here. Also having a pre-`compiled' version
of the config (such as the way cricket does it) would also speed things
up for those with lots of config entries. Having to parse thousands of
lines of icky text files every time someone clicks a button on their
browser certainly isn't optimal to my way of thinking.

Currently I think the database support is too capable in some areas
which causes more code than there needs to be, and thus more
maintenance hassles. I can't see too many people whingeing if it only
supported one database at a time, rather than mysql for status data,
postgres for comment data, etc.

Also life would be easier if the current database routines where
generalised, so there is one db_query instead of xrddb_query,
xsddb_query, xeddb_query, etc. which is how it is currently organised.
Having an interface layer to databases would also make supporting new
databases such as oracle far easier.

If the nagios developers keep in mind the issues to do with the larger
sites as well as the smaller one, nagios could rival BMC Patrol and
similar in terms of capabilities, and for millions of dollars less.

--
Dougal Scott Connect Internet Solutions
dwagon@connect.com.au 9/114 Albert Rd
Senior Systems Administrator South Melbourne, Australia, 3205





This post was automatically imported from historical nagios-devel mailing list archives
Original poster: dwagon@connect.com.au
Locked