atom feed3 messages in net.sourceforge.lists.nagios-develRe: [Nagios-devel] NDOUtils Developer...
FromSent OnAttachments
Ethan GalstadJun 22, 2009 6:33 pm 
shadih rahmanJun 23, 2009 7:54 am 
Michael FriedrichJun 29, 2009 2:08 am 
Subject:Re: [Nagios-devel] NDOUtils Developers Wanted
From:Michael Friedrich (mich@univie.ac.at)
Date:Jun 29, 2009 2:08:36 am
List:net.sourceforge.lists.nagios-devel

Hi,

just as a remark to your TODO list.

Ethan Galstad wrote the following on 23.06.2009 03:33:

- Optimize table structures

Supporting Oracle, you will have to remove the table_prefix (saves 7 characters) and rename at least one table (31 chars). And, of course, the primary key needs to be only 'id' instead of '[table_name]_id'. All other stuff will remain in the *.sql definitions like optimizing stuff and adding indexes. For what it's worth, the main db scheme has to be reworked, too... but this will take more time in C.

- Optimize table record cleaning

...and to check which data is really necessary. E.g. the timed_events queue will be written to the database and heavily cleaned up. In larger environments, this will fail at startup of ndoutils and during running the process, too. Imho, there's the need of either "outsourcing" the housekeeping or changing the data_processing_options to another default than -1 - get less but more performance in the first place. Meanwhile some unused data could be completely dropped off, but this has to be evaluated with the main Nagios plugins and which data they normally are using.

- Add libdbi support for multiple databases (Postgres, Oracle, etc)

Be aware of the fact that the current libdbi driver implementation is heavily broken and unfinished work. It won't work right now as you may have read on the users mailinglist. Even though not all queries are the same for all RDBMS, there is need of customized queries per RDBM too. Normalized INSERT statements (no SET, but VALUES) and adapted UPDATE(INSERT ON DUPLICATE KEY vs. MERGE queries. Also the time functions are RDBM specific and different.

Right now, there will be 3 applications using the libdbi and wanting Oracle RDBM support:

* NDOUtils * IDOUtils * Merlin

All of them will focus on the libdbi. So the biggest problem is to rewrite the libdbi driver for Oracle. I have started to discuss on the libdbi-devel mailinglist, the libdbi as is needs to be adapted e.g. for using parameter bindings. Taking a deeper look on heavily used queries in the NDOUtils parameter bindings are a big advantage causing lesser performance problems (cached queries). Actual code of NDOUtils Oracle has finished that for the most often called queries but in this direction there is need of doing that more often.

Summed up, libdbi and Oracle are not really an option right now. Maybe re-implementing the driver and adapting the libdbi api (which will take some time to code, debug and finally get the packages into repositories too) or seeking other solutions independently of the libdbi. The ocilib is such a project but the code in NDOUtils would be like:

switch(db_type) { case mysql: libdbi_init(mysql); case pgsql: libidbi_init(pgsql); case oracle: ocilib_init(oracle);

Or similar - need to get more deep into that but my ressources a quite low this time.

Besides I hope that the actual ideas of the IDOUtils from Icinga will be merged into actual NDOUtils code and the development can be done on quite the same code base (and if it's GIT on both sides, merging won't be that big problem).

Kind regards, Michael

Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria