16. 04. 2021 Dominik Gramegna Icinga News, Icinga Web 2, NetEye

Improving the Process of Scheduling Downtimes by Introducing a New “Custom Actions” Module for Icinga Web 2

In my first blog I’d like to talk about a common process in the life of everyone who manages their monitoring system daily, along with an approach to improving it with a new module for Icinga Web 2 named Custom Actions, which we recently implemented for one of our clients.

The process of scheduling downtimes in the Icinga Web 2 UI can be rather time consuming when the number of objects to include gets long. It can be even worse if the selection is built on a collection of filters based on variables and attributes of hosts.

For situations regarding regular and scheduled activity, the task of defining downtimes can be automated via the concept of “recurring downtimes”. It’s not always possible to automate the creation of downtime scheduling – in some situations, emergency patches require the ad-hoc restart of your entire IT infrastructure. This is a situation where operators of the NetEye monitoring suite are required to spend time arranging complex filters, selecting the host and/or service objects within the lists in the UI, and compiling the scheduling form. This process might be time consuming, especially if you have a large or complex IT-infrastructure. (Note: In this blog I will refer to host and service objects as simply objects.)

Why is the Module so Useful?

The big improvement over the normal way of scheduling downtimes is to avoid the steps of selecting the desired object one-by-one, or assembling a filter containing the desired objects in the overview page. Instead you can abstract the filter into “filter objects” and choose one or more objects simply by clicking.

Defining downtimes in this way is not limited to one filter object only. It’s possible to choose as many filters as desired. You can assemble rather complex object selections without the need to deal with the complexity of a filter made up of multiple aggregators. Even better: avoiding potential human mistakes, too.

Organizing filter objects into categories is the next dimension to guiding the user. What exactly are categories, anyway? Nothing more than a logical organization layer to distinguish between filters, and to prevent mixing them with other elements that don’t have anything in common. For instance, it’s not possible to set downtimes for filters of different categories.

Why Introduce a Module for Icinga Web 2?

Having identified the problematic nature of the current downtime planning process, the objective was an implementation where the steps of filtering and selecting objects would be abstracted. This concept embraces the ability to predefine host and service filters and generate Icinga2 API calls to perform the desired action(s).

After thinking about how to implement this, the best solution was the introduction of a new Icinga Web 2 module allowing us to build easy-to-maintain custom logic while also reusing existing libraries. The module should be as flexible as possible, including for Icinga2 API calls apart from downtime planning – this motivated our calling it “Custom Actions”.

Currently the functionality of the module is limited to just creating new downtimes for objects. But since the API is very powerful and is able to execute many different actions beyond just downtimes, the module’s potential is enormous. If developed further, it could reach its full potential, and be usable for every action the API supports. Some of these uses are: creating acknowledgements, notifications, and comments, but also cancelling them again, and many more. Until now, scheduling downtimes is the only action you can execute, but conceivably many different actions will eventually follow.

Using the Module and Defining New Filters

The module consists of 2 main sections: the “Configurator” and the “Downtime planner”. In the “Configurator” you can create, edit and delete your categories and filters in the same way you would make them in other modules like Director.

A category consists only of two elements: a name and a description. This is because, as I said before, a category’s only use is to categorize the filters.

A filter instead has more attributes: a name, a description, a category it belongs to, a host filter and a service filter. The filters are split out because the Icinga2 API prohibits them from being mixing together in the same call. The filter logic is based on the specifications of the Icinga2 API and according to the documentation .

To create a host or service filter you can use Director to make a new host- or service-group and build your filter there until it looks like you want with the Apply editor. After that you can save it and copy the created filter, which is shown in the “Preview” tab. Finally, you can insert it into the host- or service-filter.

In the “Downtime planner”, on the other hand, you can choose which filters you want to select, insert the necessary information in the form element, and send it off to schedule the downtime(s). After the API call you will get a message if the downtimes were set successfully or if there were problems.

Availability of the Module

In this early stage, Custom Actions has not been released as a generally available module. Due to several dependencies on NetEye-specific libraries, the module must be run on a recent NetEye release 4.15 or higher.

To understand if there is general interest in the features of this module, we would appreciate any feedback you might have. Leave your comments on this blog article, or drop me an email.