Icinga Vagrant Boxes 2.0: OpenStack provider and enhanced scenarios
It’s been a while since the last Vagrant box update and release, so here are the highlights of the past months combined into a new shiny 2.0 release :)
It’s been a while since the last Vagrant box update and release, so here are the highlights of the past months combined into a new shiny 2.0 release :)
The namespace support in 2.10 caused a regression with the registered global scope being evaluated for API permissions with filters. This release fixes the problem, next to a problem with Windows packages not fully starting up. There’s also a fixed oversight with not setting a default environment constant. This affects setups checking the SNI header in external load balancers.
Our friends from the Max-Planck-Institut for Marine Mikrobiologie kindly sponsored that acknowledgement notifications are now sent only to users which have been notified about a problem before – thanks a lot. Another sponsor asked for more child options for the ScheduledDowntime which are now released in 2.10.
Our first Icinga meetup in Salzburg, Austria is happening this week. Join fellow community members :) OSMC is near, just one month to go …. meet Jan-Piet on MQTT, Claudio as a first-time speaker on container monitoring, Nicolai with infrastructure visualization and Carsten with his “Einhornmagie” :-)
Icinga 2 v2.9 introduced performance related changes inside the configuration compilation and activation order. This was to ensure a) no unwanted notifications b) use available CPU resources to speed up the overall validation process. These changes had a bad effect on configuration depending on a specific activation order, and slowed it down with many config objects of a specific type. The Icinga Director depends on get_host() being called in service objects to support specific service set overrides.
Under the hood, Icinga 2 uses many constants and reserved keywords, e.g. “Critical” or “Zone” which are respected by the config parser and compiler. This sometimes leads to errors when users accidentally override such things, or re-define their own global constants. v2.10 introduces namespaces for this purpose, and ensures that such accidents won’t happen anymore.
Our first Icinga Camp Tel Aviv happens on December 17th, 2018, the fourth edition in Berlin takes place on March 14th, 2019 again :) The first Icinga meetup in Salzburg, Austria happens on Oct 12th, 2018 – join for more #icingalove. The Berlin meetup was a great success, Carsten and Lennart joined there too. Watch their meetup group for future dates.
Building your monitoring landscape can be a hard task. The main reason for this is the sheer amount of available solutions. Even though, each of them has their own reason for existence. One challenge during the discovery phase is to find out if the tools you selected can work together. If they have integrations for each other or if they can use the same storage backend. OpenAPM aims to help you find out which parts can work together and how you may use them in combination.
One of the biggest advantages of Icinga is its capability to interact with other tools. Integrations of Icinga cover notification mechanisms, visualisations or automatic deployment. Especially our REST API allows users to easily connect with Icinga, be it for read access or the creation of new objects.The possibility to automate allows Icinga users to monitor highly dynamical infrastructure in private and public clouds.
Stability and user experience were the main goals for this release. Please read the full Changelog for all the details and the Upgrading instructions to be on the safe side. Spoiler: as always, upgrade is safe and super easy.