Release announcements, development news and monitoring goodies
Today I am happy to announce that Icinga is now part of the Chef Cookbook Program. We were able to get certified with our Icinga2 Cookbook which can be used to install and manage either Icinga2 Core or Icingaweb2. A big shout-out goes to Virender Khatri for maintaining and developing most of this Cookbook.
Chef is a configuration management software that helps automating the installation and configuration of software on your servers. By turning infrastructure to code Chef makes it possible to abstract installation processes and configurations into Cookbooks.
The Partner Cookbook Program sets guidelines and best practices for cookbook creation and maintenance. By using cookbooks with the partner badge users can be sure that the cookbook has been reviewed and fulfils Chefs quality standards.
Michael Medin released NSClient++ 0.5.0 this week. We’re of course considering to update the bundled NSClient++ installer inside the Windows package.
First things first – the NSClient++ 0.5.0 Changelog mentions breaking changes, so we’ll need to test the ITL CheckCommands still working prior to the next Icinga 2 release (follow #12733). In case you want to help test yourself – you can safely upgrade the NSClient++ application in Windows yourself and fire your Icinga 2 checks against it (just install the new 0.5.0 package).
One cool thing to note about NSClient++ 0.5.0 – it comes with its own web server which also provides a REST API. That could introduce a solution for querying metrics via REST API which require rate calculation (CPU) from a running nscp service. This could be easily integrated into a native Icinga 2 client check plugin then. Let’s just try this out on my Windows 10 VM! :-)
You can build simple Icinga 2 setups where everything is checked and notified 24×7. If you are planning with bigger setups and multiple user groups being notified on problems, you’ll certainly get the task to filter specific time ranges or notification types. Or you’ll consider partial check times e.g. when a service is definitely not available and you don’t want your SLA reporting faked with downtimes.
One common thing is to limit the notifications sent to users to “9 to 5”. The configuration requires the following addition:
- TimePeriod object named “9to5” (available in the example configuration in timeperiods.conf)
- Referenced as “period” attribute in your Notification object or apply rule
Human beings don’t work 5 days a week and 52 weeks over the whole year. Vacation is needed, finding some rest without any work. And you obviously don’t want to get notified about Icinga problems during that period of time. In addition to that there are several days or hours where no-one wants to get notified except for the 24×7 support (new year’s eve, christmas, etc.).
We keep working together as an open source community. We’re here to listen what you say – keep it polite and encourage/motivate us to solve your problem with you as best as we can. Lean back and think how others would react if you click “send”, frustrated with an issue tab opened in your browser. Sometimes it doesn’t hurt to just close the tab or rephrase. The person on the other end (dev and/or user) will appreciate it. In the end we all are human beings with emotions, language & culture differences and offline needs (friends, family, hobbies, etc.). What we have in common – we all want to build a great Icinga monitoring product together :)
When it comes to monitoring we like to send out a notification as soon as the problem occurs. What’s better than a system that reports a problem the very moment it appears, right? However, we are aware that alerting alone is not always enough. To identify the problem’s root cause it is often necessary to have more information about a service besides its availability state. To meet this claim, most of the monitoring plugins used with Icinga 2 can return performance data. Additionally, the output contains a string showing one or more performance data metrics, for example the time a host or service check took to execute, the number of bytes being transferred, or the free disk space. With the new InfluxDBWriter feature of Icinga 2.5 it’s possible to automatically store this data in an InfluxDB database – without detour. In order to achieve that, the corresponding Icinga 2 object communicates with the native InfluxDB HTTP API. read more…