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.
In a Nutshell
Icinga Notifications is a new and separate component of the Icinga ecosystem. Notifications were always part of Icinga 2, but in a very basic way. With Icinga Notifications we want to establish a platform to re-imagine how notifications in a monitoring environment work and to enhance them with long desired features. It consists of three main parts, a daemon, a database and a frontend.
Various configurable sources provide events to Icinga Notifications, which will transform them to notifications, to then transmit them via different channels. More on that below.
Not Just Icinga
Of course, Icinga 2 primarily provides events for which notifications will be transmitted. But let us be honest, we all created a host or service before, where its sole purpose was to integrate something into Icinga 2 that wasn’t strictly a host or a service. We established such fake hosts and fake services ourselves already with the automation integration of Icinga Certificate Monitoring in Icinga Director. Not everything should – or can – be represented in this old-fashioned structure. This is even more apparent with the advent of Icinga for Kubernetes.
This is why Icinga Notifications accepts events from any (authorized, of course) provider about a host, a pod or your coffee machine.
Pluggable Channels
The way notifications are transmitted is based on the specific channel being utilized. Out of the box Icinga Notifications comes with support for email and webhooks.
As you probably expect, this can easily be extended with plugins. So if you’re not into emails, or don’t want to migrate to a webhook solution, you can also receive alerts via different channels.
Be sure to also keep an eye on this blog in this regard. We will certainly provide our own channel plugins in the future. Though, not necessarily as part of Icinga Notifications.
Track Incidents
The Frontend is a module for Icinga Web, fittingly called Icinga Notifications Web. It lets you easily track events and resulting incidents. You can take responsibility for one (just like you’ve acknowledged a problem in Icinga 2) or just subscribe to it, to not miss the recovery.
If there is an integration for a related source in Icinga Web, it can also hook into Icinga Notifications Web to provide customized rendering of certain details. An integration for Icinga DB Web (as can be seen on the screenshot, click to enlarge it) is of course already part of this!
Configuration via UI
We have done away with configuration files for notifications. Most of the configuration for Icinga Notifications will happen in the frontend. Though, a HTTP API to manage it is planned!
The UI allows you to configure rules which are used to route notifications to specific recipients. These can also be configured and can take the shape of contacts, groups of contacts, or schedules. The latter can be seen on the screenshot and provides a way to set up rotations which combine contacts and contact groups with chronological patterns.
Desktop Notifications
The Frontend does not only let you keep track on incidents or to configure Icinga Notifications, it can also alert you.
We took the chance to introduce this feature with Icinga Notifications Web, but we are aware that it might not be what we will settle on in the end. So we are eager to hear…
…your Feedback!
We hope that you will try Icinga Notifications out and share your impressions with us. Be it positive or negative, don’t hesitate! You can reach out to us via the usual social channels and if you join the Icinga Insiders, you might also get the chance to be interviewed 😀
