Monthly Archive for November, 2009

Developer for PostgreSQL

Are you a developer for PostgreSQL? Do you have spare time to dedicate to a good cause? Do you enjoy working in a team environment? Is coding your focus?

Well no, this is not a job offer! but a request for a competent developer who is familiar with the ways of PostgreSQL & C/C++ to either join or can assist with future development of PostgreSQL within Icinga. Now is that an offer you can’t refuse?

So if this looks like something that you would like to contribute to, then please contact  Michael Friedrich with your interest …

Michael is also available on IRC #icinga-devel

  • Share/Bookmark

Demo access: Icinga’s new web interface is online!

Hi folks,

the day has come: the new web interface is online!

Let’s visit http://alpha.icinga.org/ and log in as guest by using the password guestuser.
Sneak and poke around and give us feedback at icinga-devel@lists.sourceforge.net!

Have fun,

Christian

  • Share/Bookmark

Icinga at Open Source Expo 09 Karlsruhe

icinga_oseHello from the Open Source Expo! On the second day of the second Open Source Expo 09 in Karlsruhe, we have found a few moments to report back live from our booth.

So far, there has been a steady flow of visitors and a good response – we even got into the limelight to make a presentation on the Open Stage yesterday. Cheers to Julian for coming in to help out on the microphone and promote Icinga a bit. He spoke on open source monitoring and where Icinga and Nagios fit in.

With over 700 visitors, this year’s Expo is focused on solutions for industry and the latest technologies out of the community. So Icinga fits in well, and we are pretty excited to present next to big names the likes of Ruby on Rails, OpenSUSE, OpenStreetMap, and many others.

  • Share/Bookmark

Fixes for Icinga IDOUtils MySQL

Hi there,

just wanted to give you some updates regarding several fixes for Icinga IDOUtils. There were reports about doubled rows within several tables, where data only gets inserted and not updated. During my analysis it came up that there are several mistaken unique constraint definitions within the table creation for MySQL.

The unique constraint makes sure that if an INSERT will try to insert updated data, that this will create an internal exception which is caught within the ON DUPLICATE KEY clause. If caught, an UPDATE will be issued and everything is fine.

Regarding the table servicecheck, this was missing. So the start time of the servicecheck was inserted to the database, and when the servicecheck was complete, the end time also was inserted as own row into the database. Kind of useless 2 rows isn’t it? ;-)

Today i did some further investigations on that since this happened with systemcommands too. It came up that tables timedevents and timedeventqueue had that “feature” too.

This is really bad because there are lots of those queries issued and data will grow fast. Not this time because there has been another modification to idomod.cfg – the data processing options haven been modified to ignore timedevents by default. It will improve IDOUtils a bit, but your feedback is as always very welcome!

Back to topic – those missing unique constraints have been added to actual GIT Master (fixing #173 and #181 – check for analysis and comparison) so make sure you get the latest and the greatest! :-)

For those who are using Postgresql or Oracle – I have implemented and debugged them in deep. And they have own WHERE clauses for UPDATE – so no worries about that, everything is fine! =)

  • Share/Bookmark

Playing with Oracle, ocilib and parameter bindings

Hi there,

IDOUtils queries differ quite a lot – some of the are just executed during startup, while others happen all the time. By analyzing the performance on our Oracle database with grid  it came to the top queries just like for

  • servicechecks, servicestatus
  • hostchecks, hoststatus
  • timedevents
  • programstatus

But how to improve the performance of those queries when they are called all the time?

Well, the query as is is always the same, only the values happen to change. So the basic idea is to prepare the statements with value place holders and if it comes to the query, just to bind the paramaters (values) to the prepared statement and execute that. This is a real performance boost compared to putting the query within the rdbm cache all the time.

Generally speaking the query statements are prepared after database connection and the statement handle is stored within the global dbinfo object (where the connection handler resides too).

dbinfo.oci_statement_programstatus = OCI_StatementCreate(dbinfo.oci_connection);
OCI_Prepare(dbinfo.oci_statement_programstatus, MT("MERGE INTO table USING DUAL ON (v1=:X1) WHEN MATCHED THEN UPDATE SET v2=:X2 WHEN NOT MATCHED THEN INSERT (v1, v2) VALUES (:X1, :X2)"))

When a query should be executed, all values will be binded (X1, X2) to the statement.

OCI_BindUnsignedBigInt(dbinfo.oci_statement_programstatus, MT(":X1"), (big_uint *) value1)
OCI_BindString(dbinfo.oci_statement_programstatus, MT(":X2"), (char *) value2)

Then the query gets executed.

OCI_Execute(dbinfo.oci_statement_programstatus);

Well it sounds quite simple but regarding the architecture of *DOUtils it was a hard nut to crack. The most common problem was the query buffer building – each unixtimestamp conversion is done before query building and sending the query. That does not fit for prepared statements where the whole query is pushed into the database cache.

Within the code, there is an char* array which gets the SQL-code from ndo2db_db_timet_to_sql and this is then printed to the whole statements. Not very useful since you may paste that right within each query. For the prepared statements, I’ve added all plain unixtimestamps to the data[] array and then binding the values directly.

(SELECT unixts2date(:X3) FROM DUAL)

So the bind param task has been done for the initial steps, improved delete statements and other improvements need to be implemented.

Another thing which was quite nasty is that Oracle support was dependant on libdbi, but it was not even used. So I decided to split the code completely and change configure. If you use –enable-oracle it will only require ocilib to work, it does not complain about a missing libdbi. The other way around it also works fine just like it was.

Conclusion to that – you won’t need libdbi to get Oracle support for Icinga IDOUtils – just ocilib.

Those improvements have been pushed to actual GIT master und you are very welcome to test and report bugs! =)

  • Share/Bookmark

Icinga Web UI installer (testing)

Recently work has been started on setting up an installer for the new Icinga-web UI. This is currently available via the git repository located at https://git.icinga.org/index (git clone git://git.icinga.org/icinga-web.git to get a fresh branch) then simply follow the instructions in the text file /doc/install-fromscratch.txt this will talk you through the remainder of the process.

Listed below are the configure options…

./configure --help
`configure' configures this package to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
 -h, --help              display this help and exit/
 --help=short        display options specific to this package
 --help=recursive    display the short help of all the included packages
 -V, --version           display version information and exit
 -q, --quiet, --silent   do not print `checking...' messages
 --cache-file=FILE   cache test results in FILE [disabled]
 -C, --config-cache      alias for `--cache-file=config.cache'
 -n, --no-create         do not create output files
 --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
 --prefix=PREFIX         install architecture-independent files in PREFIX
 [/usr/local/icinga-web]
 --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
 [PREFIX]

By default, `make install' will install all the files in
`/usr/local/icinga-web/bin', `/usr/local/icinga-web/lib' etc.  You can specify
an installation prefix other than `/usr/local/icinga-web' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
 --bindir=DIR            user executables [EPREFIX/bin]
 --sbindir=DIR           system admin executables [EPREFIX/sbin]
 --libexecdir=DIR        program executables [EPREFIX/libexec]
 --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
 --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
 --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
 --libdir=DIR            object code libraries [EPREFIX/lib]
 --includedir=DIR        C header files [PREFIX/include]
 --oldincludedir=DIR     C header files for non-gcc [/usr/include]
 --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
 --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
 --infodir=DIR           info documentation [DATAROOTDIR/info]
 --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
 --mandir=DIR            man documentation [DATAROOTDIR/man]
 --docdir=DIR            documentation root [DATAROOTDIR/doc/PACKAGE]
 --htmldir=DIR           html documentation [DOCDIR]
 --dvidir=DIR            dvi documentation [DOCDIR]
 --pdfdir=DIR            pdf documentation [DOCDIR]
 --psdir=DIR             ps documentation [DOCDIR]

Optional Packages:
 --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
 --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
--with-web-user=<user> sets user name to run icinga
--with-web-group=<group> sets group name to run icinga
--with-bin-user=<user> sets user name for common webfiles
--with-bin-group=<group> sets group for common webfiles

Some influential environment variables:
 CC          C compiler command
 CFLAGS      C compiler flags
 LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
 nonstandard directory <lib dir>
 LIBS        libraries to pass to the linker, e.g. -l<library>
 CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include dir> if
 you have headers in a nonstandard directory <include dir>

Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.

Report bugs to the package provider.

So at this stage the installer is just placing the files and setting the permissions for the Icinga-web UI it is not setting up Apache nor checking the necessary prerequisites this still needs to be done manually.

Please report any bug/issues to the Icinga development team at icinga-devel@lists.sourceforge.net

  • Share/Bookmark