Icinga 2.11.1 release

Icinga 2.11.1 release

2.11.0 unveiled a critical bug in the cluster config sync. Before you panic – upgrading the config master as documented before any other instance keeps you safe. The 2.11.1 release is for everyone upgrading their satellites/agents first. For those who cannot do a major upgrade on their masters, we also release 2.10.7 where we added an additional fix to prevent this behaviour.

The online documentation additionally covers troubleshooting topics for configuration problems with command endpoint agents and zone-in-zone synchronization.

Check the Changelog for 2.11.1 and 2.10.7 prior to upgrading. Packages are available on packages.icinga.com as always.

Icinga Web 2.7.2

Icinga Web 2.7.2

We are happy to announce a new bugfix release for Icinga Web 2. Official packages are available on packages.icinga.com. You can find all issues related to this release on our Roadmap.

 

Less Smoky Database Servers

The release of v2.7.1 introduced a change which revealed an inefficient part of our database queries. We made some
general optimizations on our queries and changed the way we utilize them in some views. The result are faster
response times by less work for the database server.

  • Consuming more CPU resources since upgraded to 2.7.1 #3928

 

Anarchism Infested Dashboards

Recent history already showed signs of anarchism. (Pun intended) A similar mindset now infested default dashboards
which appeared in a different way than before v2.7.0. We taught their dashlets a lesson and order has been reestablished
as previously.

  • Recently Recovered Services in dashboard “Current Incidents” seems out of order #3931

 

Solitary Downtimes

We improved the host and service distinction with v2.7.0. The downtimes list however got confused by this and didn’t
knew anymore how to combine multiple downtimes. If you now instruct the list to select multiple downtimes this works
again as we removed the confusing parts.

  • Selection of multiple downtimes fails #3920

 

Icinga Director v1.7.0 has been released

Icinga Director v1.7.0 has been released

Over the last four years, the Icinga Director has grown from an optional configuration add-on to a mature Software product with lot‘s of features. Most Icinga installations are now driven by the Director, no matter whether they are small or huge, manually curated or fully automated.

Icinga Director - Daemon health

But it will not stop here. Many cool ideas are eager to finally become reality. Director v1.7 is a huge step in that direction, as it lays the foundation for a completely new type of features. We are now able to delegate complex tasks to a dedicated background daemon that has been introduced with this version. New library modules have been published, allowing us to share cool bleeding edge funtionality among different modules in a more efficient way.

What’s new?

The UI comes with new features like cloning a Service to a different Host, Downtime-related features or autosuggestion for fields based on Data Lists. Please check our changelog for more details.

Some artificial limits have been increased. Host address length does no longer limit cloud people who want to fire their checks against super long hostnames instead of IPs. For large setups with tens of thousands of hosts in a single zone the maximum size for generated single configuration files has been increased.

Import and Sync

Ever wondered what WOULD happen when pressing “Trigger this Sync”? Sync now offers a preview, showing what to expect. This works fine even if thousands of objects might be subject to change. New Property Modifiers have been added, and a generic REST API Import Source has been implemented. Import Sources will now provide detailled errors hinting right to the problem in case of erraneous data.

Configuration Baskets

Available since v1.6.0, configuration baskets got a lot of interest. They became a valuable tool when it goes to exchange Service Sets or Automation Pipelines, either with the Community, when asking an Icinga Partner for support or just between your very own testing/staging and production systems. In this release many related issues have been addressed, and more object types are now supported.

Extensions and Hooks

Icinga Partners and Community members are building products based on Icinga and the Icinga Director. To satisfy their needs a couple of new Hooks have been introduced. For example it’s now possible to run custom code at deployment time. Experienced developers are allowed to do black magic by extending many of our web forms.

UI, Translations

Last but not least the German translation has been refreshed, and we have now a Japanese translation. Many thanks to Chisato Hashimoto!

Get it now

As always, please check our Upgrading Documentation and then have fun with the shiny new Icinga Director v1.7.0.

Icinga 2.11

Icinga 2.11

Now we are here, after many months of development – we proudly release Icinga 2.11 available today.

 

Bleeding edge

It has been an emotional ride with many changes under the hood. The most obvious change is that Icinga’s distributed cluster operates more stable, the past quirks with hanging certificate signing requests or dead-locked TLS handshakes are now gone. This required us to go an unusual route: Evaluate new libraries and programming techniques in order to replace hand-written lower layered code, with later replacing the entire code base for the network stack operations in Icinga. This is a massive effort in quality and stability where users had called out for 3.0 already.

The core components of Icinga are checks and notifications. Thanks to sponsoring from a customer, Icinga now immediately send notifications after a downtime ends whenever hosts/services are still NOT-OK. Lost notifications during restarts in HA zones also have been tackled and fixed.

In the past years, we’ve seen operation problems with the config sync inside the cluster system. This has been tailored to a more robust deployment with staged syncs as well as preventing unwanted sync loops for comments/downtimes. The local storage for runtime created objects also is more robust. Also, note additional HA capabilities for features like Graphite or Elasticsearch.

We care about security. The setup steps with TLS certificates and signing requests in addition to the trusted zone hierarchy is necessary to keep your monitoring data safe. Icinga can see many details in your environment and must not be compromised. Taking things serious, Icinga 2.11 enforces TLS 1.2 as a minimum and also hardens the available cipher lists by default. Older agent versions still work granted that they support TLS 1.2 (OpenSSL 1.x.y).

 

More Icing on the cake

Icinga aims to run in small environments as well as large distributed enterprise systems. With the general availability of Debian Buster on Raspberry Pi, Icinga 2.11 is ready for your home lab and IoT setups.

To all the fans of on-demand certificate signing: You’ll get more tooling to manage/revoke satellite and agent certificate requests. A small but nifty addition are environment variables which can be retrieved with the new getenv() DSL function – for sensitive data or getting the path of HOME into your command’s context.

A small but gentle addition is the “all_services” attribute when setting a host in downtime with the REST API. Aside from the more visible fixes, many changes have been applied to improve our code base for the next years and avoid future bugs. This includes more unit tests e.g. for timeperiod ranges or version comparisons in the built-in icinga check.

Coming late to the party, we’ve fixed crashes from Nessus scanners on Linux and following up on Windows. Well, this wasn’t easy – a technical monster to debug and fix. Cheers to our friends Stefan and Philipp in Linz who have helped us to reproduce the issue. The technology now used in Icinga 2.11 proves the rule for scaling monitoring for the next decade.

Icinga uses the well-known Boost library as part of the network stack rewrite, thanks to everyone who contributes to their development. Also we’d like to cordially say thanks to Niels Lohmann for the magic JSON library, and Nemanja Trifunovic for making UTF8 handling in C++ a breeze. And to you, our fellow community contributors!

In the late development stages for 2.11, we’ve also tackled a problem with systemd reloads resulting in a killed process. The only way to prevent this from happening is actually a new feature: A real umbrella process managing the reload signal. Turns out, this implements a long standing feature request for running Icinga in a (Docker) container.

 

Docs, docs, docs

Our community forum with many great users and contributors helping each other raised the bar for the documentation. We are addicted to making the Icinga experience as easy as possible, and for 2.11, we have improved the documentation in many ways: From the basic setup to configuration to distributed environments to service monitoring to features and addons.

This includes a clear cut specification of the plugin API, with best practices from experienced plugin developers. Speaking of development, packagers and future developers are key to Icinga’s success. The development chapter as been overhauled to motivate everyone out there. Those wanting to learn about the design decisions, the technical concepts chapter highlights new bleeding edge insights.

 

Get Icinga 2.11, check the Changelog & upgrading docs and say cheers to the biggest release we’ve ever done.

Icinga Module for AWS

Icinga Module for AWS

Some say you have to move all of your server infrastructure into the cloud. Others counter that you should keep your data safe and secure in your own datacenter. And then there are many people in between who use cloud services as an addition to their self-hosted servers. In fact, there’s no right or wrong, because as always in IT: It depends. We at Icinga always try to find a way to make everyone happy with their monitoring – be it in the cloud or on premise. Today we’re pleased to announce version 1.0 of our Icinga Module for AWS!

Automation and integrations are important parts of every Icinga setup since ever then. The Icinga Module for AWS follows this path by embedding into your existing monitoring setup. The module is an addition for the well-known Icinga Director, whose main purpose is to manage Icinga configuration at a glance – the Icinga Module for AWS is yet another Director Import Source. Import sources are a crucial factor of the Director as they enable you to import data from multiple data providers. The collected data is transformed into Icinga 2 configuration. Learn more about import sources and automation in our guide Monitoring Automation with Icinga – The Director.

This module collects data about your EC2 Instances, RDS Instances, Load Balancers and Auto Scaling Groups. The Director uses the regularly collected information to create Icinga 2 configuration out of it. Since this can be automated, you can just continue on spawning and deleting new instances in AWS without having to take care about if they’re going to be monitored or not – without any human interaction.

 

Import EC2 Instances

The following example demonstrates how you can use this module to import details about your currently running EC2 Instances into Icinga. Before you get started, make sure you have your AWS Access Key by hand. This is required, so you can establish a connection to your account and pick up the information we need for monitoring. Make sure to add your Key details to the modules configuration at “Configuration > Modules > aws > AWS Keys”.

 

Installation and Configuration

Extract or clone this module to your Icinga Web 2 module path. The directory name must fit the module name, aws. This would usually lead to /usr/share/icingaweb2/modules/aws

Additionally, the module requires the AWS PHP SDK v3 which you have to install manually. The easiest way to do this is by downloading it from the release page and unpacking it into /usr/share/icingaweb2/modules/aws/library/vendor/aws

 

Configuring the Import Source

The first step is to create a new Director Import Source:

  • Import source name: A general identifier, choose something that you will recognise later
  • Source type: Select Aws module
  • AWS region: You may create an import source for each region you use
  • AWS access method: Select your previously configured AWS Key from the dropdown
  • Object type: We use EC2 Instances for this demo purpose, you may create multiple import jobs for each object type you want to import

Save the details and open the newly created Import Source again. We now continue with adding a Modifier.

 

Import only running Instances

Director Modifiers are used to handle the incoming data and transform it or filter it by certain conditions. Since you usually want to monitor only running instances, we’re using a Modifier to filter for the state of the EC2 Instances.

  • Property: We refer to the status property, in order to filter by states
  • Modifier: The Black or White-list modifier allows you to whitelist only certain instances
  • Filter: We filter by running systems only
  • Policy: Here we decide to keep only matching rows, therefore only running systems are whitelisted

Hit the save button to save your Modifier.

 

Trigger Import Run

You’re now ready to trigger the first import run. This will not create any Icinga configuration yet, but allow you to see a preview of the collected information in the “Preview” tab. There you can now see a variety of data that was synchronised from your AWS account. All of these information can be used to create Icinga hosts for example. Additionally you may use part of the data and add it as custom variables to your monitoring objects.

Your next step is to create a Sync Rule which will use the gathered AWS data to generate Icinga configuration. If you’re not familiar with Sync Rules, you may refer either to the Director Documentation to learn about it or read our guide Monitoring Automation with Icinga – The Director

Icinga Web 2.7.1

Icinga Web 2.7.1

We are happy to announce a new bugfix release for Icinga Web 2. Official packages are available on packages.icinga.com. You can find all issues related to this release on our Roadmap.

 

Sneaky Solution for Sneaky Links

Usually we try to include only bugs in minor-releases. Sorry, bug-fixes, of course. But thanks to @winem_ we have also a little enhancement this time: Links in comments, notes, etc. are now highlighted as such.

  • Highlight links in the notes of an object #3888

 

Nobody’s Perfect, Not Even Developers

We knew it. We saw it coming. And forgot about it. Some views, especially histories, showed an anarchic behavior since v2.7.0. The change responsible for this has been undone and history’s order is reestablished now.

  • Default sort rules no longer work in 2.7.0 #3891

 

Restrictions Gone Wild Cagey

A fix unfortunately caused restrictions using wildcards to show no results anymore. This is now solved and such restrictions are as permissive as ever.

  • Wildcard filters in chains broken #3886