Nagios und Icinga verschicken SMS-Alarme, indem sie bei jeder Benachrichtigung ein Shell-Kommando ausführen, das die HTTP-API eines lokalen SMS-Gateways anspricht. Mit einem SMSEagle im eigenen Netz ist das ohne Cloud-Dienst eingerichtet: Nagios braucht zwei Kommandodefinitionen in der commands.cfg und einen pager-Eintrag im Kontakt, Icinga 2 ein NotificationCommand-Objekt, einen User mit Rufnummer und einen apply-Notification-Block. Dieser Artikel führt durch jeden Schritt für beide Systeme.
Warum reicht kein Cloud-SMS-Dienst als Alarmkanal?
Monitoring funktioniert nur, wenn der Alarmkanal unabhängig von der überwachten Infrastruktur ist. Ein Cloud-SMS-Dienst braucht eine funktionierende Internetleitung, einen laufenden DNS-Resolver und ein aktives Kundenkonto mit Guthaben: genau drei Punkte, die bei einer Infrastrukturstörung alle gleichzeitig fehlen können. Ein Hardware-Gateway wie das SMSEagle sitzt im lokalen Netz und sendet über die eingelegte SIM-Karte direkt ins Mobilfunknetz, ohne Internetpfad und ohne externe Konten. Nagios hält laut 6sense rund 70 Prozent Marktanteil in der Server-Überwachung, viele dieser Installationen laufen in Rechenzentren und Serverräumen, in denen genau diese Unabhängigkeit entscheidend ist.
Was brauchst du?
- Nagios ab Version 3 oder Icinga 2 mit Schreibzugriff auf die Konfigurationsdateien
- SMSEagle-Gateway im lokalen Netz, per HTTP oder HTTPS vom Monitoring-Server aus erreichbar (Geräteübersicht: smsreach.io/geraete)
- Aktive SIM-Karte im Gateway mit ausreichend Netzabdeckung am Aufstellort
- API-Token am SMSEagle, erzeugt unter Einstellungen, API-Zugang, Berechtigung APIv1 aktiviert
- Handynummern der Empfänger im internationalen Format, z. B. +4915112345678
- curl auf dem Monitoring-Server, auf allen aktuellen Linux-Distributionen standardmäßig vorhanden
Wie bereitest du das SMSEagle-Gateway vor?
Am SMSEagle erzeugst du unter Einstellungen, API-Zugang ein Access-Token und aktivierst die Berechtigung APIv1. Danach prüfst du mit einem direkten curl-Aufruf vom Monitoring-Server aus, ob Erreichbarkeit und Token stimmen:
curl "https://IP-DES-SMSEAGLE/http_api/send_sms?access_token=DEIN-TOKEN&to=+4915112345678&message=Testmeldung"
Landet die SMS auf dem Handy, ist die Gateway-Seite abgeschlossen. Erscheint sie im SMSEagle-Log unter Gesendet, trifft aber nicht ein, liegt es meist an der SIM-Karte oder der Netzabdeckung. Taucht die Anfrage gar nicht im Log auf, stimmt IP-Adresse, Token oder das HTTPS-Zertifikat nicht. Das lässt sich mit dem curl-Flag --insecure eingrenzen, in der Produktivkonfiguration sollte das Zertifikat aber korrekt hinterlegt sein.
Wie konfigurierst du Nagios für SMS-Benachrichtigungen?
Nagios trennt zwischen Kommandodefinition und Kontaktkonfiguration. In /usr/local/nagios/etc/objects/commands.cfg legst du zwei Einträge an: einen für Service-Benachrichtigungen, einen für Host-Benachrichtigungen. Der Platzhalter $CONTACTPAGER$ enthält die Rufnummer aus dem Kontakteintrag, die übrigen Nagios-Makros ersetzt Nagios beim Versand automatisch. Der Kern der Kommandozeile sieht für Service-Benachrichtigungen so aus:
/usr/bin/curl -s "https://IP-SMSEAGLE/http_api/send_sms?access_token=TOKEN&to=$CONTACTPAGER$&message=$NOTIFICATIONTYPE$+$SERVICEDESC$+$SERVICESTATE$"
Für Host-Benachrichtigungen ersetzt du $SERVICEDESC$ und $SERVICESTATE$ durch $HOSTALIAS$ und $HOSTSTATE$. In Produktivumgebungen empfiehlt SMSEagle das offizielle Perl-Plugin von Nagios Exchange, das Sonderzeichen und Leerzeichen im Meldungstext korrekt URL-kodiert. Das Prinzip bleibt dasselbe: command_line verweist auf das Skript, Token und $CONTACTPAGER$ werden als Parameter übergeben.
In /usr/local/nagios/etc/objects/contacts.cfg ergänzt du jeden Kontakt, der SMS bekommen soll, um drei Punkte: das Feld pager mit der Rufnummer im internationalen Format, den SMS-Kommandoeintrag in service_notification_commands und den zweiten Eintrag in host_notification_commands. Das Feld pager ist der Nagios-Standard für Textnachrichten und wird vom Makro $CONTACTPAGER$ ausgelesen:
pager +4915112345678
Nach den Änderungen prüfst du die Konfiguration mit nagios -v /usr/local/nagios/etc/nagios.cfg. Meldet der Befehl keine Fehler, lädst du mit systemctl reload nagios nach, und die neuen Kommandos sind aktiv.
Wie konfigurierst du Icinga 2 für SMS-Benachrichtigungen?
Icinga 2 braucht für SMS-Alarme ein Shell-Skript, ein NotificationCommand-Objekt und einen User mit Rufnummer. Das Skript liegt typischerweise unter /etc/icinga2/scripts/ und liest seine Parameter aus Umgebungsvariablen, die das NotificationCommand-Objekt befüllt. Der wesentliche curl-Aufruf im Skript sieht so aus:
curl -s "https://${SMSEAGLE_IP}/http_api/send_sms?access_token=${TOKEN}&to=${USERPAGER}&message=${NOTIFICATIONTYPE}+${HOSTALIAS}+${HOSTSTATE}"
Im NotificationCommand-Objekt in /etc/icinga2/conf.d/commands.conf bindest du das Skript ein und definierst im env-Block, welche Icinga-Variablen als Umgebungsvariablen übergeben werden. $user.pager$ enthält die Rufnummer aus dem User-Objekt, $notification.type$ die Art der Benachrichtigung, $host.state$ den aktuellen Zustand. Das zugehörige User-Objekt in /etc/icinga2/conf.d/users.conf bekommt die Rufnummer im Feld pager:
pager = "+4915112345678"
Damit Icinga 2 weiß, welche Hosts alarmiert werden sollen, nutzt du einen apply-Notification-Block in /etc/icinga2/conf.d/notifications.conf. Das assign-where-Attribut legt die Bedingung fest, etwa eine Custom-Variable am Host. Für reine Host-Alarme bei Down-Ereignissen sieht das so aus:
assign where host.vars.sms_notify == true
Entsprechend kannst du einen zweiten apply-Notification-Block für Services anlegen, der auf Critical und Unknown reagiert. Die Konfiguration prüfst du mit icinga2 daemon -C und lädst sie mit systemctl reload icinga2 nach.
Wie testest du die Alarmierung und was sind typische Fehlerquellen?
In der Icinga-Weboberfläche startest du unter den Aktionen eines Hosts eine Testbenachrichtigung, Nagios bietet dasselbe im Command-Center. Kommt nichts an, hilft dieser Weg zur Eingrenzung:
- curl direkt auf dem Monitoring-Server testen: Landet die SMS, liegt das Problem im Skript oder in der Nagios- bzw. Icinga-Konfiguration, nicht am Gateway
- SMSEagle-Log prüfen: Erscheint der Aufruf unter Gesendet oder gar nicht, das zeigt, ob das Gateway den Aufruf erhalten hat
- Nagios-Log /usr/local/nagios/var/nagios.log oder Icinga-2-Log /var/log/icinga2/icinga2.log auf Fehlermeldungen prüfen
- Dateiberechtigung des Skripts kontrollieren: chmod 755 und passender Eigentümer (nagios bzw. icinga2) müssen gesetzt sein
- Makro $CONTACTPAGER$ prüfen: Ist das pager-Feld im Kontakt leer, bleibt der Parameter to= in der URL leer und die API lehnt den Aufruf ab
Wann reicht die direkte Anbindung nicht mehr?
Zwei Kommandodefinitionen und ein pager-Feld reichen, solange eine Handvoll Empfänger feste Bereitschaft hat und kein Dienstplan rotiert. Sobald mehrere Teams, Eskalationsstufen oder Quittierungspflicht dazukommen, stößt die direkte Anbindung an ihre Grenzen: Nagios und Icinga kennen keine SMS-Quittierung und keinen automatischen Bereitschaftsplan. Dafür schaltet man eine Alarmierungsplattform zwischen Monitoring und Gateway. Die Plattform nimmt die Meldung entgegen, schlägt nach, wer gerade Dienst hat, schickt die SMS über das SMSEagle und eskaliert an die nächste Stufe, wenn die Quittierung ausbleibt.
| Nagios/Icinga direkt an SMSEagle | Nagios/Icinga an smsreach Connect | |
|---|---|---|
| Einrichtung | commands.cfg und pager-Feld, ca. 30 Minuten | Monitoring als Quelle anbinden, Dienstplan anlegen |
| Empfänger | feste Rufnummern in Kontakten | Bereitschaftsplan mit Rotation und Lückenwarnung |
| Quittierung | keine, SMS ist Einbahnstraße | per SMS-Antwort, App oder Web, mit Reaktionszeit |
| Eskalation | weitere Kontaktgruppen, manuell gepflegt | automatisch bei fehlender Quittierung, mehrstufig |
| Nachweis | Versandlog am Gateway | lückenloses Protokoll mit Delivery-Reports, PDF-Export |
| Watchdog | keiner | meldet, wenn Nagios oder das Gateway verstummt |
Wie sich das anfühlt, zeigt die Live-Demo unter smsreach.io/demo: Ein echter Alarm geht aufs eigene Handy, die Quittierung läuft per SMS-Antwort, und die Plattform zeigt den Eingang in Echtzeit. Die passende Hardware, vom einfachen NXS-9700 bis zum redundanten NXS-9750 mit zwei Modems, gibt es mit Beratung vom autorisierten SMSEagle Gold Partner unter smsreach.io/geraete.
Häufig gestellte Fragen
Kann ich dasselbe SMSEagle-Gateway für Nagios und Icinga 2 parallel nutzen?
Ja. Das SMSEagle stellt seine HTTP-API netzweit zur Verfügung, mehrere Systeme können dieselbe Adresse gleichzeitig nutzen. Sinnvoll ist es, für jedes System einen eigenen API-Token zu erzeugen, dann lässt sich im SMSEagle-Log nachvollziehen, welches System welche SMS ausgelöst hat.
Wie gehe ich mit Sonderzeichen und Leerzeichen in Meldungstexten um?
Nagios-Makros wie $SERVICEOUTPUT$ können Leerzeichen und Sonderzeichen enthalten, die in einer HTTP-GET-URL kodiert werden müssen. Bei einfachen Statusmeldungen reicht das Plus-Zeichen als Leerzeichenersatz. Für Produktivumgebungen empfiehlt SMSEagle das offizielle Perl-Plugin von Nagios Exchange, das URL-Kodierung automatisch übernimmt. In Icinga 2 übernimmt das Shell-Skript die Kodierung per python3 oder printf.
Was passiert, wenn das LAN zwischen Monitoring-Server und SMSEagle ausfällt?
Dann kann Nagios oder Icinga das Gateway nicht erreichen und die SMS geht nicht raus. Dieser Fall ist seltener als ein Internet- oder DNS-Ausfall, tritt aber auf, etwa bei einem Core-Switch-Ausfall. Eine Alarmierungsplattform mit Watchdog-Funktion meldet, wenn der Monitoring-Server oder das Gateway verstummt, über einen separaten Weg.
Wie alarmiere ich mehrere Personen gleichzeitig?
In Nagios enthält jeder Kontakt genau eine Rufnummer im pager-Feld. Wer mehrere Personen alarmieren will, legt mehrere Kontakte an und fasst sie in einer Kontaktgruppe zusammen, die dann in der Benachrichtigungskonfiguration des Hosts oder Services eingetragen wird. In Icinga 2 funktioniert das über UserGroup-Objekte, die im apply-Notification-Block als user_groups eingetragen werden.
Welches SMSEagle-Modell passt für Nagios- und Icinga-Alarmierung?
Für typische Monitoring-Umgebungen mit moderatem Alarmaufkommen reicht ein NXS-9700 (4G oder 5G). Wer zwei Mobilfunkwege für höhere Ausfallsicherheit braucht oder SMS und Sprachanrufe kombinieren will, nimmt den NXS-9750 mit zwei Modems. Eine Übersicht mit Preisen und einem Gerätefinder gibt es unter smsreach.io/geraete.