Tag Archive for 'Icinga'

Icinga vs. Nagios –Tabled

It’s coming to a year since our first RC 1.0, and we’re still getting much interest in Icinga. Of course, the age old question arises time again–“What’s the difference?”

We’ve tried it in words, we’ve tried it on YouTube and now we’ve tabled it! Thanks to a clever suggestion made by an Icinga user – kudos to Dorian Gray!

Check out the Feature Comparison Table, which puts the latest Icinga 1.0.3, Nagios 3.2.1 and Nagios XI side by side. But as always, the best way to compare is to try it for yourself- download it and let us know what you think.

  • Share/Bookmark

Icinga at the FrOSCon 2010

We’re currently represented at the FrOSCon fair in Sankt Augustin, Germany, with our own booth.

It’s good to see that there’s a lot of interest in Icinga and we got a lot of positive and constructive feedback from all different kinds of users, developers and administrators. Sometimes people even had to stay in line to ask their questions.

It’s particularly exciting to see the reactions on the new web interface, which will be released as stable in October. It seems that we really met the communities expectations of a modern monitoring solution. But also the improved made to the classic-interface (sending multiple commands, for example) got a lot of positive reactions by long term Nagios® users. Most visitors decided to switch to Icinga (or at least try it out) after they saw the advantages.

Today we’re still at the FrOSCon the whole day. Why don’t you come over and visit us?
There are also a lot of other interesting free and open source projects, just take a look at the exhibitor list.

  • Share/Bookmark

Released: Icinga 1.0.3 & Icinga Web 1.0.3

Icinga reaches the next level of open source monitoring – releasing Icinga 1.0.3 and Icinga Web 1.0.3 to the world!

While Icinga Core unifies the Classic UI, IDOUtils and API in 1.0.3, Icinga Web steps from 1.0.1 directly to 1.0.3 unstable, preparing for a unified release version in October.

Several new config options have been added to Icinga Core, next to reworking check execution with execvp. We’ve also fixed several bugs, e.g. wrong service alerts in the logs and persistent comments disappearing after restart.

Icinga IDOUtils now provide extended syslog output while fixing major NULL binding errors in Oracle and enhancing column length for MySQL/Postgresql/Oracle.

We have also been working on an outstanding new feature for the Classic UI: Multiple Host/Service selection in the status views, sending commands to the Core.
Next to that, we have added a pause/continue page update button, the possibility to show only HARD states in the tactical overview and optional long_output in the status pages.

Icinga API now provides unit tests and its own debug log, next to our own oci8 implementation instead of pdo_oci. Bugs and more Queries have been added too.

Icinga Web features a new tactical overview including an underlaying template engine. Sending commands is now possible to specific instances only or doing a broadcast. A session expiry watchdog has been added such as http basic auth.
Several IE and other bugs have been fixed, code quality has been improved and configure now allows you to set the API credentials e.g. for IDOUtils DB directly. Watch out for our cool Icinga throbber after login!

Checkout Changelog or What’s New section in the docs for more information!

Please report feedback and/or bugs to our development tracker, the mailinglists and the Icinga Portal! :-)

Enjoy Icinga 1.0.3 and stay tuned for more to come! =)

  • Share/Bookmark

RELEASED: Icinga 1.0.2 & Web 1.0.1

A new release, a new level of performance – Icinga 1.0.2 promises to be faster and well on the way to being fully robust. This release unifies the Core, API and Docs to version 1.0.2 with Web out of beta and into 1.0.1. Have a look below to see what’s been keeping us busy the last 60 or so days:

Web/Api/Docs

  • Core code reduced and made more robust
  • Core code detached to its owning modules
  • Module framework defined, extractor and installer
  • Principals now works in one step (one function code)
  • Instances included
  • Ajax driven filters, made some new filters
  • REST/Json api interface (web/api, https://dev.icinga.org/issues/305)
  • New summary cronk (faster, faster, faster)
  • New cronk list (also categories, faster, faster, faster)
  • Single click in the web interface
  • UI Translation (not complete)
  • Docs translations (not complete)
  • Docs can now be converted into .pdf

Core/CGIs/IDOUtils

  • Schedule Downtime for host and all services now works as expected
  • Servicechecks with excluded timeperiods are correctly re-scheduled
  • Fixes for Notification not/incorrectly being sent/calculated
  • Error out if service_description is missing in service definition
  • Added syslogd local facility
  • Use execv for active checks w/o metacharacters
  • Speed up loading retention.dat into the Core
  • Initscripts handle the lock file now correctly and outputs config errors
  • Add event profiling option and dumping entire scheduling queue
  • display_name on host/service defs displayed in classical UI (CGIs)
  • multiple urls for notes|action_url on host/service defs in classical UI
  • Resolved performance issues in IDOUtils, improved SQL queries and upgrade scripts

There was a long list of pending patches on the mailing lists and trackers, so check the changelog for more. As always, your feedback is welcome and we hope you like it!

You can also check out the new features in our updated Demo-System.

  • Share/Bookmark

News from Core, CGIs & IDOUtils – Part III

Now that you have read about IDOUtils and the CGIs, it is time for the big one :-)

Icinga Core

All changes, fixes and enhancements do not affect compatibility to Nagios ™ – you’ll just get more fixes and enhancements if you decide to move over to Icinga.

The list of fixes and code improvements is rather long thanks to Andreas Ericsson who is working on his own Nagios ™ development branches. All those recent commits have been reworked into Icinga Core (if not already done). There were some nifty patches making developers life more easy and the source code a bit more readable and reusable.

Furthermore protection against typos in macro names has been added next to missing  NOTIFICATIONISESCALATED macro.  Performance data files are now closed correctly and the pipes are also set properly on configuration re-read.

SIGSEGV in checks on Solaris have been fixed thanks to Thorsten Huebler. There are also some other fixes for Solaris which are currently in development (thanks Alexander Skwar).

The fix by Ton Voon for choosing next valid time on day of DST change when clocks go one hour backwards is also in 1.0.2.

Next to that Ton Voon provided the in sync retention facility on the core by Opsera Ltd which has been reworked into Icinga – we think this might be useful.  Also, there was a Nagios ™ patch for adding new is_volatile setting of 2 for services, which respects the re-notification interval for notifications which also can be found applied and tested in Icinga Core.

There was a bug removing comments – now it is fixed and removing one comment will not remove all of them.

Scheduling a downtime for all services and the host now works as expected. Also custom notifications are not sent anymore during downtimes (thanks Sven Nierlein).  notification_period inheritance for services has been fixed using a patch by Gordon Messmer.

Notifications not being sent out when scheduled downtime is cancelled is also fixed next to the fix for first notification delay being calculated incorrectly causing notifications potentially going out early.

The initscript has been slightly reworked in order to show config errors as an own option. Furthermore the output is saved into a file which will can be looked up after a normal start. The initscript also does not remove the pid file anymore if Icinga did not stop in a timely manner. If a lockfile without running PID is found during startup, it will be removed instead of bailing out.

Starting the Core now throws an error if contactgroups are not matching. This happens now too if a service description is missing on a service object definition (if defined in used template there won’t be an error!).

Servicechecks with timeperiods containing ‘exclude’ directives are now correctly re-scheduled – this is noted in Nagios ™ Changelog for 3.4 and will be fixed in Icinga 1.0.2.

Steven D. Morrey implemented a patch for an extended scheduling queue which has been slightly reworked and improved for Icinga. The -S option functions much like -s but will dump the entire scheduling queue is it would run, in addition to providing the summary data.

Steven also created another patch long time ago – adding an event profiling option for stats of event counts and time taken for events. We integrated that as a config option in icinga.cfg and took the chance to add those stats to the current CGIs in ‘Performance Info’ – in case the option is enabled of course.

We finally implemented the state-based escalation ranges feature by Mark Gius: “The directives first_notification and last_notification apply to the total count of notifications on a particular service or host. It is sometimes desirable to escalate after the Nth critical notification, rather than after a total number of N notifications have been sent.”

Max Schubert’s patch to add enhanced diagnostic output when a regular expression fails to compile also has been added to Icinga.

There have been questions about another syslog facility – Icinga can now send log messages to syslogd using a local facility instead of the default one.  If enabled you can chose between 0 to 7.

Currently Icinga uses popen and system to run active check commands with shell intepretation. If using execv instead so there won’t be no shell expansion required. This means that 1 less process (sh) is required to execute an active check, which should give a performance improvement. When running the active check, check if there are any shell metacharacters. If there are, fallback to the shell invocation. Otherwise use the new execv method.

We had a speedup of parsing status.dat a while ago, now Matthieu Kermagoret provided another patch for minimizing loading time of the retention file. From his reports, they used  a standard setup with 1500 hosts, 19000 services and around 80 000 comments – before the restart took 20 minutes. Having the patch applied, only 2.6 seconds (!).

Icinga Core, CGIs & IDOUtils fit perfectly together with Docs, the API and the new Web. Please help us test for the upcoming release on 30.6.2010 (counter is GMT+1) and report issues !!! :-)

Interested in Icinga development and (re-)implement features and resolve performance issues? – Then please get in touch:

* Mailinglists

* IRC: irc.freenode.net #icinga #icinga-devel

* Icinga Portal

* Twitter

  • Share/Bookmark

News from Core, CGIs & IDOUtils – Part II

Part II of this series catches up on our work on the CGIs – what happened with them since 1.0.1?

Icinga CGIs

Next to the new Icinga web there was some space to fix and enhance the current classical UI (“the CGIs”).

Some minor typo fixes reported by community users have been applied, missing js files have been added and the check_daemon_running function has been modified in order to work with MacOSX again.

The quick search has been added again next to the live search (which is now called “extended search”). During a research on older patches it came up that if a user is authorized for a host all service authorizations views are derived from that. If you don’t want that you can now modify show_all_services_host_is_authorized_for in cgi.cfg to 0 (only if the user is not globally allowed to view all services).

The docs mentioned that display_name on host and service definition would fulfill another displayed name on the classical UI. This is now available exclusively to Icinga in 1.0.2 – if you don’t set display_name, the default host_name/service_description will be used instead.

Thanks to Jochen Bern from LINworks GmbH the CGIs now allow adding multiple urls for notes|action_url on host|service object definition – if you ever needed more of them (like me) :-)

Stay tuned for Part III – it will catch up on Icinga Core – and a lot of things to talk about =)

  • Share/Bookmark

News from Core, CGIs & IDOUtils – Part I

Hi there,

it’s been a while since recent release of 1.0.1 in March. Quite a lot of things happened – Hiren Patel and Massimo Forni joined the Core developer team while Hendrik moved on to new projects. But not only refreshening the team makes Icinga Core, CGIs & IDOUtils more valuable this time.

Regarding the GIT commit history and the issue roadmap for 1.0.2 you can imagine the evolution – but this is just an historical listing and does only show basic “who did commit and fix/create what on which date”.

Today Icinga will be “feature frozen” and is up for testing – we need testers for the upcoming Icinga release !!! Guides are available within our development wiki :-)

What exactly happened since 1.0.1?

Many people were asking what exactly changed in Icinga on the core side – in an easy and readable way. So let’s try it here in 3 Parts :-)

The changes and enhancements will be split into the Core itsself, the CGIs and the IDOUtils – all of them more or less historically summarized.

Part I starts with …

Icinga IDOUtils

There were some bugs, one major causing data inconsistency but also some enhancements regarding usage and performance.

The current database schema implies a centralized view on the objects table on which all relations are built and joined. During startup of Icinga Core normally old configs get deleted and existing objects marked as inactive. After that, the new config is being checked against those objects and if none found, a new one inserted. This is the expected behavior but a bug leading from the libdbi rewrite caused this check to fail and always inserting a new object. This caused an explosion of the objects table and decreasing overall performance on select/update roundtrips.

Thanks to William Preston the source is fixed, and the remaining data inconsistency with active and inactive objects related to historical checks in the RDBMS also has been fixed. Within the docs you will find a more detailed description and upcoming 1.0.2 will include upgrade SQL scripts in order to keep your database consistency!

Next to that, the string escaping has been modified again not to provoke any more errors. Some RDBMS specific fixes on wrong datatypes were added to.

The source has now completely been rewritten (s/ndo/ido/) and in order to keep everything clean, the core neb api now provides an Icinga specific object version which is used in IDOMOD 1.0.2. The old Nagios ™ one has been kept for compatibility. This implies upgrading both, Core and IDOUtils in 1.0.2.

Another performance issue on MySQL – the binary selects were a nice idea but resulting in major memory and performance problems. Just for getting case-sensitive compare this can be resolved defining the correct collation on the affected columns – thanks again William Preston.

The internal linked hash list for objects has been extended in order to minimize objects selects. This increases overall performance a bit – thanks Opsera Ltd for their Altinity patch.

Some SELECT queries asked for all columns instead of just the primary key if they were just checking for an existing row. Altering this minimizes overall unused RDBMS traffic.

IDO2DB now writes to syslog if it fails to connect to the RDBMS or if the database schema cannot be accessed – and not just quitting without error.

The IDO2DB initscript has been rewritten not to depend only on the lockfile (just like Icinga Core) and if the startup fails this will be shown too, also removing the lockfile.

Jan Drogi (ja5kier on irc.freenode.net #icinga) was asking about persistent configuration during a core restart where IDOUtils clean the config by default – e.g. to keep custom variables relations. Therefore 2 new config options for ido2db.cfg have been added: clean_realtime_tables_on_core_startup and clean_config_tables_on_core_startup. If set to 0 no startup cleaning will be performed.

Stay tuned fo the second part of this series! Meanwhile keep on testing :-)

  • Share/Bookmark

feedback.icinga.org

There are already many ways to interact with the icinga team and the community; using mailing lists, comments in the blog and also our Redmine system. From today we have also created feedback.icinga.org, making it easier for you to let us know about your suggestions and ideas for icinga.

You can find the link to that system on the left border of our sites like www.icinga.org, docs.icinga.org and dev.icinga.org. Let’s start a new ways to interact with each other and weigh up the pros and cons.

Missing a view in the new interface? Ideas for the website? Find out what the others think and be the first to share your idea with the community and subscribe our feed to never miss a thing.

  • Share/Bookmark

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

  • Share/Bookmark

Icinga meets Nabaztag!

Now for most of us we would not know what a Nabaztag is right? (yes!) Well a Nabaztag is a robotic rabbit that interfaces into your WiFi network and can be used for a range of clever things! to explain this rabbit better you can see the introductory clip here

Hans Moser has set up his cleaver little rabbit to announce his Icinga notifications using PHP.  Here is a short clip on how he went about it and what this little rabbit is capable of…

You can find the full details on Hans’s blog post here also Hans has expanded further on this to also include Icinga status messages, the details can be viewed here

A rather nice alternative to an E-mail or SMS !!!

  • Share/Bookmark