One of the advantages of the new Icinga Notifications is that it is more loosely coupled to Icinga 2. This is made possible by the concept of sources, each of which is a possible provider of events for Icinga Notifications to act upon. While the most prominent source would be of the “Icinga” type, there is also the “Other” option, which opens up a huge field of different providers via a simple HTTP-based API.

Whether you’re new to Icinga or a seasoned user who thinks they’ve seen it all, some of these resources could surprise you with a few tricks. Let’s dive into the resources that’ll have you saying, “Why didn’t I think of this sooner?” Or send this to someone you would like to rope into the Icinga universe.

If you’re looking for a comprehensive guide to getting started with Icinga, you’re in the right place. Whether you’re new to Icinga or a seasoned user who thinks they’ve seen it all, some of these resources could surprise you with a few tricks. Let’s dive into the resources that’ll have you saying, “Why didn’t I think of this sooner?” Or send this to someone you would like to rope into the Icinga universe.

First of all, if you own a domain, the following text is for you. In production you obviously want to reduce outages. And an outage of a DNS domain as such takes down all services under that domain, no matter whether your LAMP components are all up and running. At least from users’ perspective. As usually, roughly speaking, monitoring has to “play end user” to properly discover failures end-to-end. At best you have an Icinga satellite (e.g.