Zuletzt aktualisiert: 30.07.2026 · Lesezeit: 2-3 Minuten
Alertmanager und Icinga sprechen von Haus aus nicht miteinander. Wer Prometheus-Alarme zentral über Icinga verarbeiten will, braucht eine Brücke zwischen beiden Systemen. Genau das leistet die Alertmanager-Icinga-Bridge: Sie nimmt Alarme vom Alertmanager entgegen und legt sie automatisiert als Services in Icinga an. In diesem Beitrag zeigen wir, warum wir das Tool Signalilo unter neuem Namen weiterführen, was sich am Code geändert hat und welche neuen Features dazugekommen sind.
Was macht die Alertmanager-Icinga-Bridge?
Im Prometheus Ökosystem kümmert sich der Alertmanager darum, welche Alarme an wen geschickt werden sollen. Die eigentlichen Alarme werden über eine HTTP API angenommen, laufen durch einen Entscheidungsbaum und werden dann an konfigurierte Endpunkte geschickt (Mail, RocketChat, Webhook, und so weiter). Das ganze funktioniert auch ohne Prometheus, so kann ein Alertmanager Cluster die zentrale Alamierungslösung in der Infrastruktur sein.
Einige unserer Kunden haben jedoch den Anwendungsfall, das Icinga diese zentrale Funktion übernehmen soll und Alertmanager einkommende Alarme an Icinga weiterleiten soll. Wer die Tools kennt, wird feststellen, dass diese Integration nicht trivial zu lösen ist. Das Tool „Signalilo“ löst genau diesen Anwendungsfall, in dem es Alarme vom Alertmanager annimmt und diese als „Service“ an der Icinga API erstellt. So können die in Icinga definierten Kanäle für Benachrichtigungen genutzt werden.
Warum ein Fork?
Das Repository wird aktuell nicht mehr betreut, da die Maintainer andere Lösungen nutzen. Wir bei NETWAYS denken aber, dass das Tool und der Anwendungsfall weiterhin nützlich sind. Deshalb haben wir das Tool unter der bestehenden „BSD-3-Clause“ Lizenz als „Alertmanager-Icinga-Bridge“ geforkt. Die Namensänderung soll den Fork klar vom ursprünglichen Projekt abtrennen.
Jetzt auf Github ansehen: https://github.com/NETWAYS/alertmanager-icinga-bridge
Außerdem wurde die im Hintergrund genutzte Bibliothek, um mit der Icinga API zu sprechen, in das Repository aufgenommen. Das macht den Code an dieser Stelle übersichtlicher und wir können Eigenheiten, die wir für den Anwendungsfall brauchen, direkt einbauen ohne darauf achten zu müssen, dass die Bibliothek generisch bleibt.
Modernisierung des Codes
Im Zuge des Forks haben wir den Code auch ordentlich aufgeräumt. Hauptsächlich ging es uns dabei darum, die langfristige Wartung zu vereinfachen. Außerdem haben wir die meisten Third-Party Pakete als Abhängigkeit entfernt und durch die fantastische Golang Standard Library ersetzt. Nur eine einfache CLI Bibliothek ist als Abhängigkeit übrig, das macht die SBOM (Software Bill of Materials) wesentlich schlanker.
Neue Features und Fixes
Da wir große Teile des Codes an der Hand hatten, haben wir uns auch gleich um einige Themen gekümmert.
- Der Name für den Heartbeat Dienst kann nun konfiguriert werden
- Der Icinga URL CLI Parameter wurde vereinfacht und benötigt kein explizites Trennzeichen mehr
- Die Restriktion der Icinga Service Namen wurde angepasst, um mehr Namen zu erlauben
- Icinga Host, Zone und Templates können nun mittels Labels konfiguriert werden
Unsere Icinga und Prometheus Integrationen
Die Alertmanager-Icinga-Bridge gesellt sich zu unseren bestehenden Tools, die Prometheus und Icinga integrieren. Damit lassen sich die Stärken der beiden Systeme komplementieren.
Alle Tools sind Open Source und auf GitHub verfügbar:
- https://github.com/NETWAYS/icinga2-exporter
- https://github.com/NETWAYS/icingaweb2-module-perfdatagraphs-prometheus
- https://github.com/NETWAYS/check_prometheus
Du möchtest Icinga und Prometheus in deiner Umgebung integrieren oder weißt noch nicht, welcher Ansatz für euch am besten passt? Wir unterstützen und beraten dich gerne.
