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:
- 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.com/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
- 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.
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 sid – http://packages.debian.org/sid/icinga – fire up apt and enjoy =)
Icinga marches on with the release version 1.0.1 and a heap of improvements to boot:
Core 1.0.1: If you haven’t been keeping up with Michael F’s updates, the Core team has been making a whole heap of improvements in IDOUtils with optimized indexes and housekeeping, oracle enhancements and two fantastic new features from the community – cheers to Vitali Voroth, DECOIT GmbH for his escalation condition patch and Bill McGonigle for his service_check_timeout_state suggestions! The list goes on, so check out the changelog for more info.
Docs 1.0.1: The Docs team has kept up to speed with new help topics on escalation conditions, using Oracle as the RDBM and of course how to upgrade it for Icinga Core 1.0.1.
Web 0.9.1 beta: As previously hinted, the Web team has developed a bunch of new features including compound commands, status icons, built in persistence and even more flexible user settings.
So click on that download button on the right to check it out for yourself – and don’t forget to give us your feedback in the comments or issues lists!
One last shot this time for upcoming Icinga 1.0.1 and IDOUtils:
After getting several core patches into the master and also fixing duplicated service/hoststatus updates being sent to the neb module (thanks to Matthieu Kermagoret) there will be more improvements for IDOUtils.
Since the threaded housekeeper is doing fine, it is possible to periodically clean more tables. By popular demand, the following options have been added to ido2db.cfg
They can be used for your likings, by default they are not set.
If you want to help us test for the upcoming release, you are very welcome to do so!
To help you with GIT, we now have a quite detailed tutorial how to use GIT based on Icinga in our Developer Wiki =)
First of all – many thanks to Vitali Voroth and DECOIT GmbH and also Bill McGonigle for providing such great stuff and improving Icinga.
So what it’s all about?
As you might know, we are “monitoring” the Nagios world too and recently on the developer mailing list, an interesting patch popped up:
Currently the Icinga core sets state to CRITICAL if a service check times out. This is the default and can only be changed by recompiling the code. For several reasons you might want to define that yourself – and also, what does CRITICAL mean in this context? If the load on the monitoring box is too high, a service check may generate a timeout, not only a connection loss or similar.
We’ve been asking Bill McGonigle if we can take his patch for Icinga (it’s not applied in current Nagios CVS where it was built against), test it and in case apply it to give it back to the community. It’s a great idea to add the service_check_timeout_state to icinga.cfg and let the user decide upon his demands what state will be set in case of emergency. Bill suggested a new approach for Icinga too – changing the default state from CRITICAL to UNKNOWN. We think this is a great idea and so will it be in upcoming Icinga 1.0.1 🙂
That’s not all, folks …
Vitali Voroth on behalf of DECOIT GmbH sent a rather huge and exclusive improvement for Icinga core: escalation conditions.
Better to describe with an excerpt of the docs:
Using a patch it is now possible to define an escalation_condition (similar to escalation_options [w,u,c,r]). An escalation with a defined condition will only be escalated if the current state of a particular host/service fits the condition. One possible example of use for this could be the following scenario:
Think of two different escalations for the same service foo. One of them should only escalate when service bar is OK, the other should escalate if bar is CRITICAL or WARNING. Now think about foo being the main service offered by a company and the admin has to react immediately if it is down. bar could be a service indicating if the admin is in the office or at home and the escalation would react as following:
* If the admin is in the office, send an email first, after 5 minutes send an SMS
* If the admin is at home, send an SMS first and after 30 minutes a second SMS to the admin and the head of department
A really nice patch and Team Icinga is very happy about this core related enhancement! 🙂
And as you will expect – Icinga Core provides the enhancements, while the documentation will be updated too for Icinga 1.0.1 =)
You want more?
If YOU ever wanted your ideas and patches within Nagios/Icinga, do not hesitate to contact us. And even if you want to contribute and develop Icinga, you are very welcome to do so!
Spread the word and show love for Icinga 🙂