Icinga 1.9.3 with bugfix for Postgresql

icingadbUnfortunately a fix for an ugly libdbi bug causing bad performance was applied not only for MySQL, but also Postgresql causing wrong queries. It slipped through testing and silently made 1.9.2 a faulty IDOUtils Postgresql release. My bad, sorry for that (Sundays are always sleepy 😉 ).
Other than that Eric approached me last week with an init script bug, not returning the correct lsb exit codes when called with ‘status’ – I’ve already fixed that for 1.10 but it’s now backported into 1.9.3 too.
So, if you’re happy with 1.9.2 stick with it. If you are using Postgresql, fetch 1.9.3 from Github as usual. Target bug reports towards https://dev.icinga.com or join the various community channels at https://icinga.com/support 🙂

Icinga IDOUtils – More Improvements Part II

As mentioned in the last post, there are other improvements for Icinga and IDOUtils.
This time, I want to give you a deeper look onto database performance and the housekeeping stuff.
As you might know, selecting, updating or even deleting a row from a table heavily depends on the row count. If table size grows bigger e.g. in the historical tables from IDOUtils, those queries will be slower and hold back the main process. Current approach of IDOUtils is one forked child of ido2db for one idomod connection – working sequentially on the gotten data.
So even one select taking longer will slow down the data processing and worst case the socket will get blocking and idomod complains about writing to data sink.
But how to resolve those issues?
First of all there were several approaches originally found in mysql-mods.sql – setting indexes on table columns which are being used within the WHERE clause. Regarding the fact that ido2db is not just an insert application, but also deletes historical data on demand (table trimming options), selects objects for caching and furthermore updates existing rows (service/hoststatus e.g.) we decided to apply most useful indexes on the table creation statements. It does slow down an insert a bit, but the overall benefit is much bigger than that 🙂
Also the upcoming Icinga Web benefits from that – e.g. the logentries tables select performs a lot faster when using the API and a RDBMS.
But that’s not all – indexes are only one approach of improvement. In the last few months, Hendrik, Christoph and myself discussed a lot about the periodic housekeeping. The basic approach was to remove housekeeping function from the main data processing. Simply because historical deletes on large tables will take even longer and prevent new data being written to the database.
There have been discussions about a cronjob and seperated forked processes for housekeeping, but we wanted something within ido2db and simple to use. So Hendrik came up with the idea to create an own thread within each ido2db child which runs completely seperated from the main data processing flow – the so-called threaded housekeeper.
The thread just waits for the appropriate instance getting connected and then performs the periodic housekeeping – independant from the main flow. And it does not interfere with the normal data processing. So to speak it resolves a big performance issue within IDOUtils.
Basically, this is the way it performs:

  • sleep a while after creation and intialization
  • idle wait for database connection and connected instance from main process
  • perform periodic maintenance not interferring with main process
  • will be terminated when ido2db shuts down

Best thing so far – it has been implemented and tested and improved quite a while. Mostly done in our own git branches, but the final solution is within current git master and will be one of the outstanding new features for Icinga IDOUtils in the upcoming Icinga 1.0.1 release.
Stay tuned for more updates!
… and prepare for Icinga 1.0.1! =)

Icinga development visualized by Gource

Hi there,
Icinga and the fork happened not that long ago but during this period of time a lot of nice things happened.
Providing Icinga Core with integrated IDOUtils supporting MySQL/Postgres/Oracle, fresh docbook format and therefore enhanced documentation, a completely new Icinga API based on IDOUtils and providing data for the new upcoming Icinga Web. Also lots of other improvements and enhancements.
Writing a historical overview would get boring soon. So we decided to catch up on another Idea: gource.
It’s a small program fetching all commits within our git repositories (core, doc, api, web) and presenting the timeline and changes using rendered pictures.
But that’s not all, it is possible to convert that to nice looking movies.
But there is so much to tell…
Not this time!
Just relax and watch 🙂
Icinga Core

Icinga Doc

Icinga API

Icinga Web

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

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

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 🙂