In the current constellation, it looks like the icinga2 core can process many types of notifications:
- telegram
- slack
- sms
- … 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. 
But now it’s your move!
Come on, tear up my proposal with good arguments!
