While at first sight we’ve only included the monitoring plugins and their CheckCommand definitions, we’ve been working closely with community contributors and team members to make it easier for everyone to contribute their own command definitions.
There are certain advantanges sending your definitions upstream:
- everyone can use and update/fix them
- one single place for configs and documentation
- developers may suggest updates and help with best practices
- you don’t need to care about copying the command definitions to all your instances (because the icinga2 package already provides them)
There is a detailed wiki howto available. Looking forward to your contributions! 🙂
Reaching for new monitoring heights together – Icinga community spirit
Every now and again we get a compliment or two on how amazing Icinga is. These moments always bring a smile to our faces, but to be honest… what really floats our collective Icinga boat is some sort of community love.
There are so many forms this can come in that many are just not aware of. So we’ve put a list of the top 10 ways to say “thank you for the awesome software”:
10. Spread the word
Whether on Twitter, Facebook or your own blog, if you think Icinga is good then help us share it with the world. If you run Icinga at work or for charity, you can even make your recommendation official by joining our Icinga Users.
9. Offer an idea to improve Icinga
Did you know Icinga Mobile started from an idea off our Icinga Feedback channel? For all those times you think, “if only Icinga had…” don’t keep it to yourself – let the community know! It could just be that hundreds of other users could do with that one killer feature that your idea would have inspired.
8. Share how you did it
From installation on Debian and optimizing IDOUtils to integrating PNP graphs and implementing NSCA – if you have done it before, why not share how you did it by writing a guide on Icinga Wiki or Icinga Docs? Plenty of users would thank you for it.
7. Share a plugin or addon
There are thousands of plugins and addons available on repositories such as MonitoringExchange.org. These were all written by users before you, who were kind enough to share their work and save you from reinventing the wheel each time you integrate a new service. If you write a plugin then pay it forward!
6. Help a fellow user
You know that feeling when you get stuck configuring Icinga to check SNMP? After scouring the docs, wiki and web, when you finally find that one person who has had the exact same issue and knows how to solve it – don’t you just want to run up and give them a virtual hug?
Thankfully the good karma goes both ways, you can give and receive help and hugs on our user mailing list, IRC user channel and the monitoring-portal.org community forum.
5. Report a bug
Perhaps you have noticed that something is a tad strange in logs since the last release. Help us all out by reporting a bug on our Icinga Development tracker so that we can weed it out quickly.
4. Test Icinga
To save you from reporting bugs post release, we usually present a beta release a week or two prior to the final one. This is the best time to find bugs without the pain of picking them out in a production environment. So help us test, test, test!
3. Submit a patch
If you find a bug and know how to get rid of it, we welcome you to write a patch and submit it for review and application. Check out our Developer Guidelines to make sure it goes upstream the first time. When it does, we’ll salute you through our credit roll in change log of each release.
2. Package Icinga for others
We’re lucky that maintainers have come on board to serve up pre-packaged Debian, Ubuntu, FreeBSD, Gentoo, etc. versions of Icinga. However, there are plenty of distributions that are still awaiting Icinga packages. If you know your distro well, get in touch with us.
1. Help code Icinga
There is no better way to say thank you than to contribute to the Icinga code itself. If you are ready to commit (pun intended) to developing the best open source monitoring software on the planet, we love to hear from you on our IRC developer channel and devel-mailing list.
Icinga is nothing without you, our community. Your contributions – be it patches, bug reports, wiki guides or helpful online advice – are all the thanks that we, the Icinga community could ever need.
three more monitoring aficionados to the team!
Gunnar Beutner – Core
Working behind the scenes on cool projects the likes of IDOUtils’ SLA reporting extension and IcingaMQ, Gunnar has been with us as of June 2011 and has since become a bit of a database specialist.
David Gerbec – Quality Assurance & VM
On board since December 2011, David has taken the lead on our Icinga VMs from his abode in Slovenia. A Linux systems admin with experience dating back to 1995, David is in charge of several monitoring servers Agenda Open Systems.
Assaf Flatto – Quality Assurance & VM
Assaf also joined in December 2011, though his monitoring adventures started in 2001 with Netsaint (now Nagios) and Bash for init scripts as well as minor code changes in C. In the Icinga sphere he has made feature requests, provided QA and started translating Icinga Docs into Hebrew. He too helps with the VMs, as well as IDOUtils and NRPE QA.
Both David and Assaf are the first graduates of our new Icinga Jedi Apprenticeship program, with the support of Core Jedi, Michael F. The two are currently whipping up some VM magic so keep your eyes peeled!
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 🙂