Icinga 2 v2.6 and Icinga Web 2 v2.4 released

Icinga 2 v2.6

This time we’re focussing on stability and bugfixes instead of adding a ton of new features. This is not to say that there aren’t any new features at all. One notable feature is the bundled NSClient++ 0.5.0 package on Windows which itself improves stability and also offers a nice REST API for querying metrics.

Previous versions had a bug which caused DowntimeStart notifications to be sent as soon as a downtime was created – rather than when the downtime had actually started. In addition to that those notifications were also re-sent each time Icinga was restarted. In an HA setup a related bug might cause Icinga to crash in those scenarios. Debugging those issues was a lot of fun that was supported by being able to test fixes in customer environments. We’ve also fixed a crash in the HTTP server when querying the REST API for example using Dashing. There also were issues with syncing comment/downtime objects between nodes and syncing objects that were global zones.

A big change coming with this release and future versions is that we have decided to deprecate and remove the “bottom up” client configuration mode. All details for this decision can be found in this issue. From the user’s view it contains design flaws and lots of unfixed bugs. Considering the fact that the Icinga “stack” with Icinga 2, Icinga Web 2 and Icinga Director prefers to use the “top down” approach with config sync and clients with command endpoints, the “bottom up” approach does not fit into this design either.

We are aware of the fact that many of you have their setups already in production. There is a dedicated chapter inside the documentation dealing with migration tips and tricks. The removal of CLI commands such as “node list” and “node update-config” will not harm the cluster communication between the nodes at all. It just removes the possibility to import and generate configuration from the client itself. We’re planning for a grace period of 2 major releases or one year until the functionality is removed entirely. For now you can still use them including deprecation warnings but are advised to plan your migration to “top down” in 2017.

There are changes in the IDO database schema for MySQL and PostgreSQL. Icinga 2 v2.6 requires Icinga Web 2 v2.4, plan your upgrade to include both.

Updated release packages are available soon. Meanwhile make sure to read the Changelog.

 

Icinga Web 2 v2.4

This release adds the possibility to use the Icinga 2 API as command transport for e.g. rescheduling a check or sending a custom notification. If you are planning to put your Icinga Web 2 application on a different web server, you don’t have to fiddle with SSH tunnels opening a file handle for the external command pipe. In addition to that the Icinga 2 API is designed to send HTTP responses which enables proper error handling. No more fire and then grep the icinga2.log file anymore.

Another cool feature addition is the announce banner. If you are for example planning global maintenance tasks, this is the way to tell your users about it. We’ve also added a new command action toolbar on top of the detail view. That allows for scheduling a recheck even more quickly.

Other notable changes are a new icon in the detail view history to separate between SOFT and HARD states or a new clear button for the search field. We’ve also moved the status counts to the bottom of the screen. There also is a new package for SELinux installing proper policies for your secured server.

Updated release packages are available soon. Meanwhile make sure to read the Changelog.

 

Monthly Snap November: Community, Integrations and OSMC

cyhmna9xcaabwjv-jpg-largeWhy engaging in the community matters

The feeling of being able to help others with problems that I have been stuck on in the past is amazing. I try to give back to the community as much as I take from it.

… or why you just could not stop.

Post from monitoring-portal.org

Icinga2 for the win!

Am Anfang ist es echt ne Qual und ich hab Schweiß und Tränen vergossen, bis ich alles Begriffen hatte, was ich begreifen musste, damit es bei mir so läuft wie es soll. Und auch jetzt habe ich noch 10000 Fragen die immer wieder hochkommen. ABER bisher habe ich hier, was Icinga2 angeht, immer eine gute Antwort bekommen und bin mittlerweile auch soweit, dass ich versuche, mein Wissen hier zu teilen.

Und nach all den “Qualen”, die ich am Anfang hatte, liebe ich Icinga2 umso mehr. Und es gibt so viel, was man ausprobieren, erweitern, testen kann. Ich könnte den lieben langen Tag nur Icinga2 und Icingaweb2 widmen.
Und das schönste ist, es ist schlank und performant. Die Entwicklung geht stetig vorran. Es ist jetzt schon gut und wird noch besser.

(more…)

NSClient++ 0.5.0, REST API and Icinga 2 integration

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

(more…)

Timeperiod excludes/includes in Icinga 2 v2.5

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

(more…)

Icinga 2 meets InfluxDB

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. (more…)

Icinga 2 v2.5 released

We’ve come a long way with our new release Icinga 2 v2.5. After the 2.4 release in November we’ve focussed on fixing many of the remaining bugs. 2.5 isn’t just a feature release – it includes all the bugfixes from the past months. (more…)