Alertmanager and Icinga do not communicate with each other by default. If you want to process Prometheus alerts centrally via Icinga, you need a bridge between the two systems. That’s exactly what the Alertmanager-Icinga Bridge does: It receives alerts from Alertmanager and automatically creates them as services in Icinga. In this post, we’ll explain why we’re continuing to develop the Signalilo tool under a new name, what changes have been made to the code, and what new features have been added.
What does the Alertmanager-Icinga Bridge do?
In the Prometheus ecosystem, the Alert Manager determines which alerts should be sent to whom. The actual alerts are received via an HTTP API, run through a decision tree, and are then sent to configured endpoints (email, RocketChat, webhooks, and so on). This all works even without Prometheus, so an Alertmanager cluster can serve as the central alerting solution for the infrastructure.
However, some of our customers have a use case where Icinga is supposed to handle this central function, and Alertmanager is supposed to forward incoming alerts to Icinga. Anyone familiar with the tools will realize that this integration is not a trivial matter. The “Signalilo” tool addresses exactly this use case by receiving alerts from the Alert Manager and creating them as a “service” on the Icinga API. This allows you to use the channels defined in Icinga for notifications.
Why a fork?
The repository is no longer being maintained, as the maintainers are using other solutions. However, we at NETWAYS believe that the tool and its use case are still useful. That is why we forked the tool under the existing “BSD-3-Clause” license as “Alertmanager-Icinga-Bridge.” The name change is intended to clearly distinguish the fork from the original project.
View it now on GitHub: https://github.com/NETWAYS/alertmanager-icinga-bridge
In addition, the library used in the background to communicate with the Icinga API has been added to the repository. This makes the code clearer at this point, and we can directly incorporate the specific features we need for our use case without having to worry about keeping the library generic.
Code Modernization
As part of the fork, we also gave the code a thorough cleanup. Our main goal in doing this was to simplify long-term maintenance. In addition, we’ve removed most third-party packages as dependencies and replaced them with the fantastic Go standard library. Only a single simple CLI library remains as a dependency, which makes the SBOM (Software Bill of Materials) much leaner.
New Features and Fixes
Since we already had large portions of the code on hand, we went ahead and addressed a few issues right away.
- You can now configure the name for the Heartbeat service
- The Icinga URL CLI parameter has been simplified and no longer requires an explicit separator
- The restriction on Icinga service names has been adjusted to allow for more names
- Icinga hosts, zones, and templates can now be configured using labels
Our Icinga and Prometheus Integrations
The Alertmanager-Icinga Bridge joins our existing tools that integrate Prometheus and Icinga. This allows the strengths of the two systems to complement each other.
All tools are open source and available on GitHub:
- https://github.com/NETWAYS/icinga2-exporter
- https://github.com/NETWAYS/icingaweb2-module-perfdatagraphs-prometheus
- https://github.com/NETWAYS/check_prometheus
Would you like to integrate Icinga and Prometheus in your environment or don’t yet know which approach suits you best? We’re happy to support and advise you.
