Monthly Archive for September, 2009

Icinga 0.8.4 is out – bugfixes and updates for IDOUtils and Docu

Published on 16. September 2009 by Michael Friedrich in Core, Development, Misc, Releases and Technical. 2 Comments Tags: , , , , , , , , , , .
Download Icinga 0.8.4

Since we decided to give you the opportunity to test the new IDOUtils with re-engineered code for more RDBMs and Postgres support too we were aware of the fact that there would have been bugfixes to apply ;-)

There were several issues to fix, not only Postgres but also typos and rewritten queries. We also added some improvements to the code, to mention configure support for manual libdbi detection and also the new version handling for IDOUtils. It’s now the same als Icinga Core, the old fashioned 1.4b8 has been dropped since we implemented a lot of new stuff to the original code.

Following the Changelog what’s been done so far:

  • idoutils: fix failure_prediction_options in tables hosts, services for postgres
  • idoutils: add configure support for manual libdbi detection
  • idoutils: fix typo laste_state (wrong column)
  • idoutils: fix buffer freeing with NAGIOS_SIZEOF_ARRAY
  • idoutils: delete old mysql files coming from ndoutils
  • idoutils: add new version handling, idomod/ido2db now shows version of Icinga core
  • idoutils: rename existing mysql/pgsql files, added upgrade/fix files
  • idoutils: fix wrong typecast in servicestatusdata_add, no more segfault while query preparing
  • idoutils: add experimental db trimming interval option in ido2db.cfg
  • core: fix wrong copyright url for Ethan
  • docu: fix quickinstall guides

Those changes and improvements to the code are worth a new release!

Thanks for testing and reporting bugs and improvements to our mailinglists, dev tracker and here in the blog! =)

PS: Concerning Oracle, I’ve started preparing the code in another branch (edit Makefile for ocilib, rewrite db connection, add parameter bindings for queries and so on). I hope this will be done within the next few weeks and maybe we’ll catch up with another Icinga release before 1.0 alpha :-)

  • Share/Bookmark

A peek behind the Icinga web interface

Published on 7. September 2009 by Marius Hein in Misc and Webinterface. 7 Comments

Icinga_webinterface5screenshot3 You’ve probably already seen the paparazzi shots, but the real sneak preview is here. In the lead up to the Alpha release, we’ve put a lot of work in to the web interface – so we want your thoughts on our progress and plans. So, the Icinga web interface in a nutshell:

Ajax paradigm

We believe the major advantage of an Ajax driven web interface is that refreshes are only made to the relevant page areas as opposed to the entire page. Thus program load is significantly reduced while being also much more flexible. We expect this to also lead to faster search and configuration change times.

Widget architecture

We took some inspiration from iGoogle and Apple dashboards to design the web interface with flexibility and user customisation in mind. So Icinga’s interface is a loose collection of components we call Cronks which sit in a few containers (border, north, east and centre columns) on an open layout.

Cronks can be dragged and dropped around the screen, shown, hidden, minimised, resized and customised. Essentially widgets, these mini Javascript applications interact with the server to receive data and other information on user demand. They generally display specific and minimal information, which makes them also easily extensible. We like them because they break down check results into manageable chunks to be displayed when wanted, instead of overwhelming the user with a screen full of 20 different pieces of blinking information.

So these Cronks can be dragged and dropped into panels, tabs and containers much alike gadgets on an iGoogle page or Apple dashboard, offering the user flexible control over their interface.

Bildschirmfoto-ICINGA - Shiretoko02 Icinga_webinterface2 screenshot1

Growl-like pop up notifications

Similar to the Apple notifier, balloons emerge on the browser margins to directly inform the user of changes. This kind of global notification system offers multiple notifications from multiple sources – which we believe is perfect for monitoring.

ExtJS, Json and CSS

Behind all the features on screen we have endeavoured to create a flexible and open layout from the outset which has been easily achieved with CSS and ExtJS Javascript library. In our opinion, ExtJS is one of the best libraries around, offering many features, while being easily extensible and independent of external libraries. Json was naturally our choice for data exchange between the server (PHP, Agavi), framework and Cronks, being itself native Javascript.

The thinking behind the Icinga web interface was flexibility, speed and customisability. We wanted to give the user the freedom to mould their interface to suit their needs. Let us know if you think we’re on the right track in the comments.

  • Share/Bookmark

PostgreSQL supported Icinga v 0.8.3 is out

Published on 2. September 2009 by Karolina Kalisz in Documentation, Misc and Releases. 7 Comments Tags: , , .

Basic RGBWe heard the call and we answered: Icinga is out with PostgreSQL support with working queries, sequences and all. Good news for users who have been looking for a Nagios based open source monitoring system which has database flexibility for not just MySQL but also Postgres. A big hand to Michael and Hendrik!
Applause should also go to Lara and Wolfgang for their hard work on the Icinga documentation, as we also have the first edition out in Docbook format.

A big release before the first Alpha in October, we hope you like it and share your thoughts with us. This version’s proof that your ideas count.

  • Share/Bookmark

Playing with IDOUtils and Postgresql

Published on 1. September 2009 by Michael Friedrich in Core, Development and Technical. 1 Comment Tags: , , , , .

After a long time debugging, code re factoring, implementing and testing new stuff another success story for Icinga!

Let’s start with the details :-)

IDOUtils is a “simple” kind of INSERT, UPDATE and DELETE application so no worries about difficult SELECT and JOIN. Meanwhile the biggest problem are the queries which are not normalized and truly MySQL specific.  Since Hendrik provided the normalization of the INSERT queries I stepped further into the INSERT OR UPDATE queries. Those are non-standard and i.e. Postgres or Oracle do not support them.

Oracle queries can be taken from NDOUtils Oracle mostly using a trick to MERGE statements (props to David Schmidt!), but the main goal is to rewrite all of them to fit parameter bindings. Check this article for more information.

Postgres is a bit more difficult because MERGE or UPSERT (another approach to INSERT OR UPDATE)  is not yet supported. The documentation points to a function written in plpgsql.

The biggest problem – how to break up the code and create functions which are deciding upon RDBM which query to build and execute?

My first approach using on single function which gets different queries as string and decides what to do was a nice try but simply failed looking at the design – being generic and making the code more readable, too.

So I tried it the hard way and split the code for the SQL-queries from dbhandler.c into a new file called dbqueries.c – for the INSERT OR UPDATE queries for the first part.

One single function for each query has been implemented and performs then the RDBM specific query. For Postgres I decided to try an UPDATE in the first place and if there are now rows affected an INSERT will be issued instead. Unique constraints defined in table scheme are matching the UPDATE constraints.

Furthermore there were other issues to fix for Postgres – string escaping, Unix time conversion functions and the task of getting the last insert ID. MySQL doesn’t use defined sequence ids (dunno yet how last insert id works…) but Postgres does that for each table. After a hard night debugging I fixed that too – now the table relationship is working for Postgres too.

Concerning the fact that each value is stored in the data array it’s quite simple to implement more queries for more RDBMs – MySQL and Postgres will take care of giving you examples on how to build the queries :-)

You’re very welcome to test Postgresql in upcoming Icinga 0.8.3!

Please report bugs or feature request to our mailinglists and at our development section.

Looking forward to Oracle and ocilib =)

  • Share/Bookmark