Following the Icinga Notifications beta announcement, we already had a more general post on how to get started and one going into the details of schedules. This week’s blog post is a follow up in this series and will describe incidents, escalations, and event rules in Icinga Notifications in more detail. In case you haven’t seen the first two referenced blog posts, you might want to have a look at them first, otherwise, you could miss out on the big picture.

From time to time we want to bring not so widely known features of Icinga into spotlight. In this effort it’s a not so obvious feature, that was available in the monitoring module of Icinga Web 2 at some point already. It has also been available in Icinga DB Web since its release. We’re talking about selecting multiple list items. Our goal was to make it as obvious as possible, without wasting screen space for those users who are already aware of the feature.

Today we are very happy to announce the first beta release of Icinga for Windows with with version 1.13.0.0! This new release provides a huge number of improvements and changes to the Framework as well as the default Windows Plugins, which we will talk about later on.

Over use of dictionaries in monitoring leads to complex and ugly configurations. This in turn makes monitoring complicated. Hence, it is advisable to use it, only if it is needed or in special cases. Even in these cases it is worthwhile to keep it simple. On that note, in this blogpost let me demonstrate how to clone dictionary row entries for objects from import sources to object properties in Icinga Director.

This is a guest blogpost from Dave Kempe from Sol1 At Sol1, we provide services around scaling and automating Icinga rollouts for customers. In large environments, we make heavy use of the excellent distributed monitoring features of Icinga to build redundant clusters across datacenters. Icinga uses the object types of Endpoints and Zones to designate the cluster layout, where a Zone contains Endpoints, and may have a parent Zone. Using this logic, a Zone with no parents is the top level zone.

A few weeks ago, we released the first beta version of the Icinga Notifications Web module. The Configuration tab provides the option to create schedules that can be used as recipients for notifications.

Icinga Notifications and Icinga Notifications Web just celebrated their first beta release. This post will try to help you get started by walking you through the interactive configuration, explaining both the underlying concepts and their actual effects. First, to get an understanding of what Icinga Notifications does, please read both the mentioned blog post and the introduction from the manual carefully.

With the release of Icinga Web 2.12, we’ve streamlined and simplified the process for performing database schema upgrades for both Icinga Web and its modules. This new feature not only indicates when an upgrade is pending but also allows for automatic execution of the upgrade. Previously, users had to consult the upgrade documentation and perform the upgrade manually. While it’s still important to read the upgrade documentation, this new feature simplifies the process significantly.

This release has the version 0.1.0 and is available via our package repositories. Be sure to check the documentation on how to install it. So what is Icinga Notifications actually? It is not possible to explain every single detail now. We will eventually publish separate articles on our blog, which will go into more detail about topics this post only mentions briefly.

I’ve already dropped a hint at this topic in a previous post of mine which reflected the history of Icinga on Windows: And this time I’m going to prove this concept, since both required components have been released by now: Icinga 2.14 and IfW 1.11. Precisely speaking, an existing Icinga master will run checks remotely on Windows, directly via the IfW REST API – without an intermediate agent.