Please discuss: modification of the notification service

In the current constellation, it looks like the icinga2 core can process many types of notifications:

  • telegram
  • slack
  • sms
  • email
  • … your own shizzle

This makes everything flexible … and also inflexible again.

Everyone can do what he wants. Script in any form, which can be distributed throughout the system.

To do this, you might have to install a lot of additional dependencies on the host where the core is running, which you might not want to have.

I would radically rebuild the whole thing and I would like to discuss this with you.

I would build my own service. The technology behind it should not matter as long as it provides a ReST interface.

This ReST service accepts a corresponding request, in which it can also be stored to which target systems the notifications should go.
This makes it relatively easy for a notification to go to n end points, or to have to make big orgies in the configuration.

This would leave only one configuration in the core - that of the notification endpoint - and that’s it.
All extensions, plug-ins, whatever, can then be carried out in a separate service and is therefore independent of the core.
Plugins can be integrated there via a corresponding loader:

  • old-school: bash scripts
  • new-stuff: … name it.

With this you can integrate a small, slim service that can use other APIs out-of-the-bos and only needs credentials for them.
Which can be integrated into a docker container.
And, if you can plan it well, it can be HA capable.

In the course of my certificate service I had even started to implement such a service in go. (Also to learn go)
But then something can go Dacian and I can’t find the code. :frowning:

But now it’s your move!
Come on, tear up my proposal with good arguments!

1 Like

The notification service within Icinga itself is fine. It’s simple, clean, and flexible. That flexibility is important and is a functionality that should be kept.

That said, the default install just has simple mail notification scripts and I’ve often thought it could be better from that point onward with something that is a bit more robust. I’ve even replaced it with something better for a project that had specific needs, but sadly that code is not mine to share.

I’ve often thought of taking some of the cool concepts I came up with for that project (which was python based) and applying them in a Go-based service. I just haven’t found the time and wasn’t sure if there would be any interest.

1 Like