Starter Kit: Icinga Virtual Appliance

Ever wanted to hit a button and have Icinga installed with all its components, MySQL and drivers already configured? Then Christoph from the Core team has created something for you.
With a couple clicks, Icinga Virtual Appliance a.k.a. Icinga Virtual Image will install Icinga Core with a sample config, IDO Utils, API, Web and Docs, plus the Classic GUI for good measure. These are installed via RPM alongside MySQL and drivers for IDO, to offer you Icinga 1.0.3 in one easy to install package.
Once the virtual machine is booted up, Icinga and MySQL start and the user is automatically logged in as “demo” into both Icinga Web and Classic GUI in 2 Firefox tabs. Even better, the “demo” user can execute all commands per sudo without needing any password. Check out this Fedora 13 based starter kit for yourself, at Icinga on Sourceforge.
Everything in short:
Download: http://sourceforge.net/projects/icinga/files/icinga-virtual-image/
User: demo | Password: demo
User: root | Password: password
URL for Classic UI : http://localhost/icinga/
URL for new Web: http://localhost/icinga-web/
(added 11/11/11, 29/7/12) Note: For use with Virtual Box 2.2  and not intended for production environments.
As always, let us know how you go with it. Enjoy!

Icinga reaches Debian

It’s been a while since Christoph Maser joined Team Icinga sharing his knowledge about creating RPMs. Those packages can be found in RPMForge 🙂
There were a lot of questions about getting Debian packages for Icinga and finally, we are happy to welcome Alexander Wirt onto Team Icinga!
He is Debian packager for Nagios and now Icinga and did a really great job to bring fresh Icinga Debian packages to the upstream.
Currently, Debian lenny, sid/squeeze and Ubuntu Karmic are supported. They can be found here – please check it out and tell us about it!
Take a look at README.Debian after installing IDOUtils and make sure to enable the Event Broker Module in icinga.cfg – patching configs during package install is against packaging policy. But again, we are already working on a satisfying solution for that – check #162.
Icinga’s journey is not ending – are you working on BSD ports or any other applicable operating systems repository? Then please contact us and we will make sure to enlighten the path together for Icinga 🙂
Update 2010-04-09: Icinga got accepted in Debian sidhttp://packages.debian.org/sid/icinga – fire up apt and enjoy =)

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! =)

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! =)

Creating custom logos

By default your service map will show your defined services with a question mark logo, this is due to  the default logos used are unknown.gif and unknown.gd2. You can define your own custom logos thus giving a more personalised look. There have been logo packs made for use with Nagios, well theses of course will work just fine in Icinga, in this case I have made my own custom images of my router and my server.
The image types can be .jpg, .gif .png you will also need to convert the images you use to a .gd2 format as well. to do this you are going to need the pngtogd2 utility. (see notes below) I have resized these images to 40×40 pixels before conversion to .gd2 format.

pngtogd2 source_image output_imige.gd2 cs 1
  • pngtogd2 command loses transparency unless the original png file is properly formatted
  • pngtogd2 is distributed as part of the libgd-tools package in Debian and Ubuntu.
  • The image needs to be stored with an indexed rather than RGB color model. In GIMP, select Image -> Mode -> Indexed.
  • The color values for transparent pixels need to be retained.
Source : http://wiki.nagios.org/index.php/Status_Map_Images

Then create hostextinfo.cfg file in /usr/local/icinga/etc/objects and include the following…  (please note this is my configuration!)

define hostextinfo{
     host_name       IBM-eSERVER
#     notes_url       http://webserver/hostinfo.pl?host=you_can_edit_this
     icon_image      IBM-eSERVER_220.png
     icon_image_alt  IBM-eSERVER_220
     vrml_image      IBM-eSERVER_220.png
     statusmap_image IBM-eSERVER_220.gd2
#     2d_coords       100,250
#     3d_coords       100.0,50.0,75.0
     }

Your custom images need to be placed into ‘/usr/local/icinga/share/images/logos’ substitute the .png and .gd2 files to the names of the images that you will be using. Change the file ownership and permissions of your custom images and hostextinfo.cfg by using the following ‘chown dancer:icinga your_file_name’ also ‘chmod 664 your_file_name’ this matches the permissions and ownership of the files already in these directories. If you have multiple hosts then repeat the ‘define hostextinfo{…}’ that you wish to add custom logos to, if you wish to use the same logo for multiple hosts then they just need to be comma separated eg. ‘host_name     localhost1,localhost2,localhost3’
To enable your new hostextinfo.cfg you need to add the following to /usr/local/icinga/etc/icinga.cfg

# Definitions for custom logos
cfg_file=/usr/local/icinga/etc/objects/hostextinfo.cfg

Make sure that your configuration is good by running the following (as root) ‘sudo /usr/local/icinga/bin/icinga -v /usr/local/icinga/etc/icinga.cfg’ if you have no errors, then simply restart Icinga. If you do have errors then check to make sure you have defined a valid ‘host_name’ and that you have placed your custom images into /usr/local/icinga/share/images/logos
You will be rewarded with the following…

Before…

BeforeAfter…

After

These custom logos will also show up when viewing host and service details…
Services

Note: I’m using Ubuntu some commands may vary depending on distribution