Zuletzt aktualisiert: 10.09.2026 · Lesezeit: 8-9 Minuten
Wenn Icinga einen kritischen Ausfall meldet, das aber niemand im Service-Desk mitbekommt, bleibt der Alarm wirkungslos liegen. Mit den offenen Repositories icinga-servicenow und icinga-servicenow-web verbindest du Icinga direkt mit ServiceNow: Notifications werden automatisch zu Incidents, ganz ohne manuelles Copy-Paste. Diese Anleitung zeigt dir, was du dafür brauchst und wie du beide Komponenten installierst und konfigurierst.
Die wichtigsten Punkte in 30 Sekunden
- Zwei offene Repositories verbinden Icinga und ServiceNow: icinga-servicenow (Daemon) und icinga-servicenow-web (IcingaWeb2-Modul).
- Icinga-Notifications werden automatisch in ServiceNow-Incidents umgewandelt, aktualisiert und wieder geschlossen.
- Der Daemon läuft als eigener systemd-Dienst und braucht dafür keinen separaten Server, aber eine eigene SQL-Datenbank (MySQL, MariaDB, PostgreSQL oder SQLite).
- Voraussetzung sind eine bestehende Icinga-Umgebung sowie eine ServiceNow-Instanz mit Lese-/Schreibrechten auf die Incident-Tabelle.
Warum Icinga und ServiceNow verbinden?
Stell dir vor, dein Icinga meldet einen kritischen Serverausfall, aber niemand aus dem Service-Desk merkt es, weil die Meldung ausschließlich in Icinga Web hängen bleibt. In vielen Unternehmen läuft das Ticketing über ServiceNow, das Monitoring aber über Icinga. Ohne Integration müssen Mitarbeitende Alarme manuell in Incidents übertragen, per Copy-Paste. Das führt zu Fehlerquellen, auch der Zeitverzug ist größer.
NETWAYS stellt dafür zwei Open Source Repositories bereit, die Icinga und ServiceNow direkt miteinander verbinden. Icinga-Notifications werden automatisch zu ServiceNow-Incidents.
ServiceNow und die Integration in Icinga
ServiceNow ist eine Cloud-Plattform für IT Service Management (ITSM). Unternehmen nutzen sie vor allem für Incident-, Change- und Asset-Management, also um Störungen, Änderungen und die eigene IT-Infrastruktur (CMDB) zentral zu verwalten. Anders als Icinga überwacht ServiceNow selbst keine Systeme, es verwaltet stattdessen die Prozesse und Tickets rund um den IT-Betrieb.
Genau daraus ergibt sich in der Praxis häufig eine Lücke. Icinga erkennt zuverlässig, wenn ein Host oder Service ausfällt, aber diese Information bleibt zunächst nur im Monitoring sichtbar. Damit ein Vorfall in ServiceNow als Incident auftaucht und dort dem Service-Desk zugewiesen, bearbeitet und dokumentiert werden kann, muss diese Information erst dorthin übertragen werden.
Die Integration schließt genau diese Lücke. Icinga-Notifications werden automatisch in ServiceNow-Incidents umgewandelt, aktualisiert und wieder geschlossen.
Damit lassen sich Monitoring und ITSM enger verzahnen, ohne dass jemand Alarme manuell zwischen beiden Systemen hin- und herträgt.
Vorstellung der Repos
Die beiden Repositories sind unabhängig von einander spielen aber super zusammen.
icinga-servicenow bildet das Herzstück, der Daemon wird in GO geschrieben. Er läuft als eigener Systemdienst und nimmt Notifications von Icinga entgegen. Er wandelt sie in ServiceNow-Incidents um, hält den eigenen Zustand in einer SQL-Datenbank (MySQL, PostgreSQL oder SQLite) fest und synchronisiert diesen Zustand regelmäßig mit ServiceNow.
icinga-servicenow-web ist ein Icingaweb2-Modul. Es liefert die grafische Oberfläche, um offene ServiceNow-Incidents direkt am Host oder Service in Icinga Web zu sehen, sowie die CLI (icingacli servicenow), mit der Notifications überhaupt erst an den Daemon geschickt werden.
Voraussetzungen der ServiceNow Integration für Icinga
Diese Integration setzt auf einer bestehenden Icinga-Umgebung auf. Wer noch keine hat, findet in unserer Artikelserie Grundinstallation Icinga die passenden Anleitung.
Für den Daemon
- Der Daemon läuft als eigener systemd-Dienst und braucht dafür keinen separaten Server.
- Go sollte in der Version 1.24.4 installiert sein
- Eine Datenbank (MySQL, MariaDB oder PostgreSQL)
- Zugangsdaten zu einer ServiceNow-Instanz mit einem Benutzer, der Lese-/Schreibrechte auf die Incident-Tabelle hat.
Für das Web-Modul
- Eine laufende Icinga Web 2 Installation
Schritt 1: Datenbank für den Daemon einrichten
Klone zuerst das Repository, es enthält auch die Datenbank-Schemata, die wir gleich brauchen.
git clone https://github.com/NETWAYS/icinga-servicenow.git
cd icinga-servicenowDer Daemon benötigt eine eigene Datenbank, um seinen Incident-Zustand zu speichern. Am Beispiel von MySQL:
mysql -u root -pCREATE DATABASE servicenow CHARACTER SET utf8mb4;
CREATE USER 'servicenow'@'localhost' IDENTIFIED BY 'DeinSuperSicheresPasswort';
GRANT ALL PRIVILEGES ON servicenow.* TO 'servicenow'@'localhost';
EXIT;Importiere anschließend das mitgelieferte Schema.
mysql -u servicenow -p servicenow < schema/mysql/schema.sqlSchritt 2: Daemon installieren und konfigurieren
Zu Beginn bauen wir das Binary.
go build -o icinga-servicenow ./cmd/icinga-servicenowVerwende die mitgelieferte config.example.yml als Basis für die eigene config.yml.
database:
type: mysql
host: 127.0.0.1
port: 3306
user: servicenow
password: DeinSuperSicheresPasswort
name: servicenow
servicenow:
url: "https://deine.service-now-adresse.com"
user: "ServiceNow_Icinga"
password: "SuperSicheresPasswort"
incident_table_endpoint: "/api/now/v2/table/incident"
incident_state_mapping:
Problem: "1"
Acknowledgement: "2"
Recovery: "6"Zum schnellen Testen lässt sich der Daemon direkt so starten:
./icinga-servicenow -config config.ymlFür den Dauerbetrieb erwartet der Daemon die Config standardmäßig unter /etc/icinga-servicenow/config.yml und bringt unter contrib/icinga-servicenow.service ein fertiges systemd-Unit-File mit, das die Binary unter /usr/bin/icinga-servicenow sowie einen Systembenutzer icinga-servicenow voraussetzt:
systemctl enable --now icinga-servicenowMit systemctl status icinga-servicenow lässt sich prüfen, ob der Dienst läuft und Datenbank sowie ServiceNow erfolgreich angepingt wurden.
Schritt 3: Web-Modul installieren
Das web-Modul wird wie ein gewöhnliches Icinga Web Modul eingebunden:
git clone https://github.com/NETWAYS/icinga-servicenow-web.git /usr/share/icingaweb2/modules/servicenow
icingacli module enable servicenowAls nächstes wird das Konfigurationsverzeichnis angelegt:
install -d -m 2770 -o www-data -g icingaweb2 /etc/icingaweb2/modules/servicenowAnschließend wird die config.ini mit der Daemon-Adresse gefüllt:
sudo vim /etc/icingaweb2/modules/servicenow/config.ini[servicenow]
api_url = "https://icinga-servicenow-daemon:5910"
api_timeout = "10"
instance_url = "https://my.service-now.com"
[db]
resource = "servicenow_db"Schritt 5: Icinga 2 mit dem Daemon verbinden
Damit Icinga bei Problemen automatisch eine Notification an den Daemon schickt, wird ein NotificationCommand benötigt. Das ist Icinga 2 eigene Konfigurationssprache, die in eine .conf-Datei gehört, zum Beispiel:
sudo vim /etc/icinga2/conf.d/servicenow-notifications.confArbeitest du mit Zones, liegt die passende Stelle stattdessen unter:
sudo vim /etc/icinga2/zones/deine-zones/Das NotificationCommand für Hosts wird hier nun abgelegt:
object NotificationCommand "servicenow-host-notification" {
command = [ "/usr/bin/icingacli", "servicenow", "send", "notification" ]
arguments += {
"--host" = {
required = true
value = "$notification_hostname$"
}
"--output" = {
required = true
value = "$notification_output$"
}
"--state" = {
required = true
value = "$notification_state$"
}
"--type" = {
required = true
value = "$notification_type$"
}
"--name" = {
required = true
value = "$snow_name$"
}
"--template" = {
value = "$snow_template$"
}
"--extra" = {
value = "$snow_additional_fields$"
}
}
vars += {
notification_type = "$notification.type$"
notification_hostname = "$host.name$"
notification_output = "$host.output$"
notification_state = "$host.state$"
notification_name = "$snow.name$"
notification_template = "$snow.template$"
notification_extra = "$snow_additional_fields$"
}
}Dieses Command braucht noch ein Notification-Template, das festlegt, bei welchen Ereignistypen überhaupt benachrichtigt wird. Einfach im selben Dokument unten anreihen:
template Notification "snow-host-notification" {
command = "servicenow-host-notification"
types = [ Problem, Acknowledgement, Recovery, Custom,
FlappingStart, FlappingEnd,
DowntimeStart, DowntimeEnd, DowntimeRemoved ]
}Das erstellte Template wird ohne einen Host noch nicht verwendet. Hier im Beispiel wird es direkt dem Host-Objekt zugeordnet.
apply Notification "snow-host-notification" to Host {
import "snow-host-notification"
assign where host.vars.snow_name
}Nun speichern, die Konfiguration prüfen und Icinga 2 neu laden:
sudo icinga2 daemon -C
sudo systemctl restart icinga2Praxisbeispiel der ServiceNow Integration für Icinga:
Schritt 1: Template beim Daemon anlegen
Bevor ein Template in einer Notification verwendet werden kann, muss es einmalig beim Daemon angelegt werden. Das Template legt fest, wie icinga-Variablen auf ServiceNow-Feldern abgebildet wird.
curl -X POST -H "Content-Type: application/json" http://localhost:5910/api/v1/template \
-d '{
"display_name": "mytemplate",
"fields": {
"ci_item": "$host.name$.example.localhost",
"short_description": "$notification.output$",
"caller_id": "sys_id_deines_servicenow_benutzers"
}
}'In diesem Beispiel wird $host.name$ beim Erzeugen des Incidents automatisch durch den tatsächlichen Hostnamen ersetzt, $notification.output$ durch den Notification-Text. caller_id muss durch die Sys-ID eines echten Benutzers deiner eigenen ServiceNow-Instanz ersetzt werden.
Schritt 2: Notification unter Verwendung des Templates senden
Jetzt testen wir unser erstelltes Template:
icingacli servicenow send notification --state Critical --type Problem \
--output "This host is on fire!" \
--host Gans --name "generic" --template "mytemplate"In Icinga bekommen wir unter dem Punkt Incidents, dann unser erstellter Incident angezeigt. Gleichzeitig wird automatisch in ServiceNow (Abb 2.) auch ein Incident erstellt.
Fazit zur ServiceNow Integration für Icinga
Mit den beiden Repositories icinga-servicenow und icinga-servicenow-web lässt sich Icinga nahtlos an ServiceNow anbinden: Alarme werden automatisch zu Incidents, und offene Incidents sind direkt in Icinga Web sichtbar.
