Seite wählen

NETWAYS Blog

Benachrichtigung mal einfach

Neulich beim Kunden, sollte folgendes Szenario zur Benachrichtigung umgesetzt werden. Der Weg, also ob Mail, Slack oder Telegram, soll vom Benutzer abhängig sein, je nach dessen Vorliebe. Ist beim Benutzer eine Mailadresse gesetzt, wird er auch per Mail informiert. Soll die Benachrichtigung hingegen via Telegram bzw. Slack erfolgen, muss der notwendige Empfangs-Hook über ein User-Custom-Attribute angegeben werden.

Wer zu benachrichtigen ist, wird am Host-Objekt angegeben. Die zu benachrichtigen Benutzer können hierbei in einer Liste (host.vars.notification.user) oder über die Mitgliedschaft in einer Gruppe, die ebenfalls am Host in einer Liste (host.vars.notification.groups) angegeben werden, zu gewiesen.

Sei ein Benutzer admin Mitglied der Gruppen icingaadmins und linuxadmins. Soll bei folgendem Host

object Host "localhost" {
  import "generic-host"

  address = "127.0.0.1"

  vars.notifiction = {
    groups = [ "icingaadmins", "linuxadmins", "vips" ]
  }
}

für den Benutzer admin, aber keine doppelten Nachrichten versandt werden, kann dies zunächst mit dieser Regel umgesetzt werden:

apply Notification "mail-admin to Host {
  import "mail-host-notification"
  users = [ "admin" ]

  assign where "admin" in host.vars.notification.users || f("admin", host.vars.notification.groups)
}

Über den ersten Teil der assign-Regel wäre das Vorhandensein von admin in der Liste der zu benachrichtigen Benutzer am Host abgehandelt. Der zweite Teil ist eine selbstdefinierte Funktion die ein true zurück liefert, sofern der Benutzer mindestens einer der Gruppen aus der Liste angehört.

function f(user,groups) {
  if (typeof(groups) == Array) {
    for (grp in groups) {
      if (grp in get_user(user).groups) {
        return true
      }
    }
  }
  return false
}

Nun möchte man nicht für jeden Benutzer am Icinga-System eine solche Notification definieren, zumal die Services noch nicht berücksichtigt sind, dann wären deren für jeden Benutzer, immer gleich zwei Notification-Definitionen. Notifications werden vom Config-Compiler immer nach den User- und Usergroup-Objekten ausgewertet, somit kann die Notification zu ein Notification-for, die eine Schleife über alle bekannten Benutzer führt, umgewandelt bzw. erweitert werden:

apply Notification for (user in get_objects(User)) to Host {
  import "mail-host-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Die abschließende ignore-Klausel stellt sich, dass keine Notification für Benutzer erzeugt wird, die keine Mailadresse angegeben haben. Sollen nun die selben Benutzer, nicht nur für den Host, sondern auch über Probleme bei den zum Host gehörigen Services benachrichtigt werden, ist das ganze nur noch eine Fingerübung:

apply Notification for (user in get_objects(User)) to Service {
  import "mail-service-notification"
  users = [ user.name ]

  assign where user.name in host.vars.notification.users || f(user.name, host.vars.notification.groups)
  ignore where ! get_user(user.name).email
}

Äquivalente Notifications lassen sich damit auch für die alternativen Benachrichtigungswege Slack, Telegram und weitere erstellen.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Braintower Gateways erben iSMS Features

braintower_logo Seit vielen Jahren setzen wir im Bereich SMS Alarmierung für Icinga sehr erfolgreich auf das MultiTech iSMS.
Neben der sehr simplen Einrichtung, der Netzwerkanbindungsmöglichkeit und dem Versenden von SMS über die Weboberfläche, bietet das Gerät eine HTTP-Schnittstelle für den Versand von SMS. Dadurch wird eine Integration in Monitoring Lösungen um ein vielfaches einfacher. Als weitere Option bietet das Gerät die Möglichkeit eingehende SMS an einen Webserver weiterzuleiten, was es in unserem Fall erlaubt, Alarmmeldungen von Icinga 2 mit einer simplen Antwort SMS zu Acknowledgen.
Für die Braintower Gateways gibt es seit letzter Woche die neue Firmware Version 3.3.0, welche das Gateway um einige interessante Funktionen erweitert. Eines dieser Features ist das SMS Routing, mit welchem SMS Nachrichten per Mail, SMS oder per Web-Call weitergereicht werden können.
Darüber hinaus wurde die API-Funktion des Gateways erweitert und ist nun vollständig kompatibel zu der MultiTech iSMS API. Wer bisher also ein iSMS sein eigen nennt, kann ohne Probleme auf ein Braintower Gateway umsteigen. Eine Erweiterung der Basis-Funktion (welche die API-Kompatibilität bereits inkludiert), ist über eine Vielzahl von Zusatz-Features möglich. Sofern das Gateway identisch eingerichtet wird (Benutzer, IP, etc.), kann eine nahtlose Alarmierung erfolgen – ohne Anpassungen an Skripten oder Software durchführen zu müssen.
Darüber hinaus ist unser iSMS Notification Plugin mit dem SMS Routing Feature zu 100% kompatibel mit Braintower. Somit ist nun neben einer Alarmierung auch ein Acknowledgen von Alarmmeldungen in Icinga möglich.
Übrigens: Wer bereits ein Braintower-Gateway mit dem SMS-Weiterleitungs-Feature erworben hat, kann ein Upgrade für das SMS Routing direkt nachkaufen.
Da wir auch immer wieder einmal diverse Kunden-Anfragen zum Thema GFI FaxMaker erhalten, ob wir passende Gateways anbieten können, ist die Antwort simpel: Ja!
Offiziell supportet wird seitens des Herstellers das MultiTech iSMS. Mit dem neuen Firmware-Update werden nun auch Braintower Gateways unterstützt.
Anbei noch ein kurzer Überblick zu den Änderungen zu Version 3.3.0:
Verbesserungen
[SMSGW-546] – Es ist möglich, die Scripts sendsms.pl und smsack.cgi aus dem NETWAYS iSMS Nagios / Icinga Plugin zu verwenden.
[SMSGW-606] – Es wurde eine Dokumentation zum Ersetzen von Geräten anderer Hersteller durch das Braintower SMS Gateway hinzugefügt.
[SMSGW-618] – Das Gateway ist zusätzlich auf Port 81 erreichbar.
[SMSGW-597] – Das Nachrichten-Routing kann nun Nachrichten auch an Ziele per HTTP weiterleiten.
[SMSGW-608] – HTTP-Ziele beim Nachrichten-Routing sind nun editierbar.
[SMSGW-612] – Es ist möglich, mehr als ein HTTP-Ziel pro Regel beim Nachrichten-Routing zu konfigurieren.
[SMSGW-624] – HTTP-Ziele sind bei Nachrichten-Routing auch auf eingehende Emails anwendbar.
[SMSGW-627] – Im Nachrichten-Routing wird nun ein Hinweis angezeigt, wenn kein SMTP Server konfiguriert wurde.
[SMSGW-634] – Das Feature Nachrichten-Routing kann nun kostenpflichtig lizenziert werden.
[SMSGW-607] – Das Feature SMS Weiterleitung ist nun Bestandteil des Nachrichten-Routings, jedoch mit verringerter Funktionalität. Kunden, die das Feature SMS Weiterleitung lizenziert haben, können eine Upgrade-Lizenz zur Nutzung des Nachrichten-Routings erwerben.
[SMSGW-619] – Die Gestaltung der Weboberfläche wurde verbessert.
[SMSGW-675] – Es wurden zahlreiche Übersetzungen verbessert.
[SMSGW-623] – Die Regeln zur Überprüfung gültiger Rufnummern bei der HTTP API wurden erweitert.
[SMSGW-641] – Es wurden neuen FAQ Artikel hinzugefügt (Syslog, API per HTTPS, SIM Karten Formfaktor, Einbindung in Centreon, Icinga 2 und WhatsUp Gold, Import und Export des Adressbuchs, Technische Daten).
Fehlerbehebungen
[SMSGW-604] – Beim Nachrichten-Routing wird die konfigurierte Absenderadresse nun korrekt gesetzt.
[SMSGW-614] – Die Whitelist der E-Mail-to-SMS Funktionalität wurde korrigiert.
[SMSGW-616] – Der Suchen und Ersetzen Bereich beim Nachrichten-Routing wird nicht mehr doppelt angezeigt.
[SMSGW-617] – Die E-Mail-Gruppen-Benachrichtigung beim Nachrichten-Routing wurde korrigiert.
[SMSGW-622] – Bei E-Mail-zu-SMS wurde die fehlende Online-Hilfe ergänzt.
[SMSGW-615] – Die Produktbezeichnung in Benachrichtigungs-Emails wurde korrigiert.
[SMSGW-628] – Nachrichten wurden teilweise sowohl über Email-zu-SMS als auch über das Nachrichten-Routing versendet.
Sie haben Interesse an unseren angebotenen Produkten oder wünschen eine Beratung? Nehmen Sie einfach direkt Kontakt mit uns auf oder besuchen Sie unseren Online-Shop für weitere Informationen. Wir stehen Ihnen gerne zur Verfügung!

Christian Stein
Christian Stein
Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

SMS unter Linux versenden – so einfach geht's

CT63_USB_SetEin wichtiger Bestandteil von Monitoringsystemen wie Nagios oder Icinga ist die Alarmierung. Wir bekommen viele Anfragen, wie eine sichere Alarmierung neben der klassischen E-Mail realisierbar ist. Oft bleibt dabei nur noch die SMS übrig, da sie ein kostengünstiges, aber effektives Mittel zur Alarmierung ist.
Heute möchte ich einen kurzen Einblick geben wie man SMS unter Linux verschicken kann – darüber hinaus gibt es einen kurzen Einblick in die Konfiguration vom Monitoring-System zum Versand der SMS.
Ganz wichtig für den SMS-Versand ist ein GSM-Modem. Hier bieten wir unseren Kunden zwei verschiedene Klassen an.
Zum einen gibt es USB-Modems – diese sind kostengünstig aber nur direkt an den Monitoring-Server anzuschließen – die Nutzung ist entsprechend der Signalqualität eingeschränkt. An dieser Stelle empfehlen wir unseren Kunden das CEP-CT63 USB powered – es braucht nur noch eine SIM-Karte – sonst ist alles dabei. Wer gerne auf eine Lösung mit Netzteil zurück greift, sollte sich das CEP CT63 ansehen – dieses eignet sich zusammen mit unserer CAT5/USB Verlängerung.
Auf der anderen Seite bieten wir auch SMS-Gateways mit LAN-Anschlüssen an. Diese eignen sich für Kunden, die Ihre SMS von mehreren Applikationen aus verschicken möchten oder auf gewisse Zusatzdienste nicht verzichten wollen. Diese SMS-Gateways bieten alle eine HTTP-Api – eine SMS wird mittels eines Aufrufs Links verschickt – die parameter werden alle in der URL übergeben. Sie haben die freie Wahl zwischen dem MultiTech iSMS oder dem Braintower SMS Gateway S.
Das Braintower SMS Gateway S Advanced bietet darüber hinaus noch eine Mail2SMS Schnittstelle und Reverse-Nagios Checks. Wenn das Gateway den Monitoring-Server nicht mehr erreicht – so kann es eigenständig eine Alarmierungs-SMS verschicken. Falls Ihre Applikation nur in der Lage ist E-Mails zu versenden – so haben Sie mit diesem Gateway die Möglichkeit auch diese als SMS zu empfangen.
Kommen wir nun wie versprochen zur Einrichtung und dem SMS-Versand mit unserem CEP CT63 USB powered unter Linux.

  • bauen Sie die SIM-Karte wie in der Kurzanleitung beschrieben in das Gerät ein – schließen Sie die Antenne an das Gerät an
  • öffnen Sie Ihre Linux-Shell
  • führen Sie folgendes Kommando aus
  • tail -f /var/log/messages
  • schließen Sie nun das Modem an den Computer an
  • Das Gerät wird ohne weitere Treiber erkannt in unserem Beispiel als „ttyACM0“
  • notieren Sie sich Ihre Ausgabe
  • öffnen Sie die Konfigurationsdatei Ihrer zuvor installierten SMS Server Tools 3 mit einem Texteditor
  • vim /etc/smsd.conf
  • kontrollieren Sie die farblich hervorgehobenen Feld und passen Sie diese ggf. an.

SMS-Servertools-Configblau: Gerätename – muss in der Definition und Konfiguration gleich sein
rot: Devicename: diesem haben wir ein paar Schritte vorher in /var/log/messages ermittelt
orange: keep open auf yes setzen – dies lässt die Verbindung zum Modem geöffnet und vermeidet Probleme

  • Speichern Sie nun Ihre Konfiguration und starten Sie SMS Server Tools neu
  • /etc/init.d/smsd restart
  • Testen Sie die erfolgreiche Konfiguration, geben Sie folgendes Kommando auf der Befehlszeile ein, ersetzen Sie die Telefonnummer durch die, wohin Sie die SMS schicken möchten
  • sendsms +4917185247569 ‚Hello, how are you?‘
  • Wenige Sekunden später bekommen Sie die SMS auf die angegebene Rufnummer zugeschickt – wenn nicht, suchen Sie nach dem Fehler in /var/log/smsd.log

In Nagios oder Icinga lässt sich das Modem mit folgender Konfiguration einbinden:
define command {
command_name    host-notify-by-sms
command_line    /usr/local/bin/sendsms  „$CONTACTPAGER$“ „$HOSTSTATE$ alert for $HOSTALIAS$! Check nagios“
}

define command {
command_name    service-notify-by-sms
command_line    /usr/local/bin/sendsms „$CONTACTPAGER$“ „$HOSTALIAS$n$SERVICEDESC$n$SERVICESTATE$nDate/Time: $DATE$ $TIME$n$SERVICEOUTPUT$“
}
Thats it – die Alarmierung läuft!
Wem die Alarmierung per SMS zu wenig ist – der sollte sich mal bei unseren Voice-Alarmierungen umsehen. Übrigens: für die SMS-Gateways mit LAN-Anschluss bieten wir auch einen Einrichtungsservice vor Ort an.

sms versenden mit Linux

Vor einiger Zeit habe ich eine neue UMTS Karte für mein Notebook bekommen und mich gefreut. Nach dem Anbieterwechsel konnte ich nun endlich die, an vielen Orten vorhandenen, W-Lan Hotspots benutzen – dachte ich.
Im Prinzip war das auch über den Vertrag abgedeckt, jedoch muss man für Aktivierung des Ganzen eine SMS an eine Kurzwahlnummer schicken, um als Antwort die Zugangsdaten zu bekommen. Jedoch passte die SIM-Karte zwar perfekt ins UMTS Modem, jedoch nicht in ein mir zur Verfügung stehendes Handy. Das Problem war Sim <-> MicroSIM.
Als einfachste Lösung habe ich mir gedacht, verschicke ich einfach eine SMS über den Laptop. Als Betriebssystem benutze ich Ubuntu, also konnte ich schon mal nicht mit Hersteller-tools rechnen. Nach kurzem Suchen hat sich allerdings herausgestellt, dass das auch prima mit Linux-Mitteln funktioniert.
Denn genau zu diesem Zweck wurde gammu erfunden, ein CLI-Tool mit dem das versenden und abrufen von SMS möglich ist. Zusätzlich gibt es noch die GUI wammu mit der man das ganze etwas grafischer benutzen kann. Das habe ich allerdings nicht ausprobiert. Denn gerade wegen der Command-line Schnittstelle ist Gammu interessant (z.B. als notification aus Icinga heraus)
Beispielhaft zeige ich kurz die Installation von Gammu auf meinem DELL Laptop.
1.) aptitude install gammu
2.) gammu-detect
3.) gammu –identify
Jetzt müsste unter /home/Mein_USER/.gammurc ein Datei angelegt worden sein mit folgendem Inhalt:
[gammu]
port = /dev/phone
model =
connection = at19200
synchronizetime = yes
logfile =
logformat = nothing
use_locking =
gammuloc =
name=

Das kann bei euch natürlich etwas anders aussehen.
Ich hatte noch ein kleineres Problem mit der Benutzung von gammu ohne root-Rechte. Dafür habe ich einen kurzen fix gefunden den ich euch natürlich auch nicht vorenthalten will. Diese ist auch der Grund, warum in meiner .gammurc /dev/phone steht
Man erstelle einen Symlink vom UMTS-Adaper device zu /dev/phone und sorge anschließend dafür das auch andere dieses beschreiben können
ln -s /dev/ttyACM0 /dev/phone
sudo ln -s /dev/ttyACM0 /dev/phone
chmod 666 /dev/phone
sudo chmod 666 /dev/phone

Als udev rules habe ich folgendes eingetragen, dieses ist allerdings gerätespezifisch
KERNEL=="ttyUSB*", ATTRS{idVendor}=="0421", ATTRS{idProduct}=="006b", NAME="phone", MODE="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="0421", ATTRS{idProduct}=="006b", NAME="phone", MODE="0666"

Als letztes noch ein paar wichtige Kommandos:
SMS abrufen:  gammu getallsms
SMS verschicken:  echo „Hallo! Ich bin ein Gammu-Test.“ | gammu –sendsms TEXT 0123456789  (dieses könnte man auch so als notification command in Icinga eintragen.)

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Voice-Alarmierung für Nagios und Icinga als Rundum-Sorglos-Paket im Online-Shop

nagios-icinga-voicepaket-voip-isdnEine Alarmierung bei kritischen Monitoring-Meldungen ist unverzichtbar. Viele unserer Kunden setzen dabei auf SMS-Lösungen oder E-Mails. In der Regel kann man die zwei genannten Alarmierungstypen relativ einfach priorisieren. E-Mails sind an einem normalen Arbeitstag der ruhigere Typ um auf Probleme aufmerksam zu machen. Die SMS hingegen sind der stressigere Begleiter an einem normalen Büroarbeitstag. In der Nacht nützt eine E-Mail recht wenig, denn wer checkt schon in der Nacht ständig seine E-Mails oder hat einen nervigen E-Mail-Ton am laufen?
Hier kommt die SMS ins Spiel – normalerweise bekommt man auf das Diensthandy nur SMS, wenn es wirklich wichtig ist – diese dürfen dann natürlich auch einen nervigen und lauten Ton haben, um auf sich aufmerksam zu machen. Doch bei aller Sorgfalt des Bereitschaftspersonals passieren auch hier Fehler. Das Handy ist lautlos gestellt oder aus, es liegt im Auto oder in der Wohnung an einem Ort, wo man es nicht direkt hört. Gründe eine SMS zu verpassen gibt es viele, man kann sie halt auch einfach im Schlaf überhören. Übrigens: SMS-Lösungen bieten wir auch an. Wir haben auch eine Lösung mit der Einrichtung bei Ihnen vor Ort.
Genau aus diesem Grund suchen viele Admins nach einer Lösung – die Meldung aus dem Monitoring direkt zu einer Person in das Bewusstsein zu bringen. Klingt nicht einfach – ist es aber.
Der Admin will gerade bei wichtigen Diensten wie Datenbanken, Webservern, User-Logins usw. einen reibungslosen Betrieb garantieren. Doch am Wochenende oder in der Nacht kann es passieren, dass er nicht immer drauf schaut und es somit zu Ausfällen kommt.
Für eine solche Anforderung stellen wir die passende Lösung bereit, damit der Admin nicht wie ein Support-Äffchen rund um die Uhr auf das Monitoring starren muss.
Das Voice-Paket für Nagios und Icinga ist eine komplette kleine Telefonanlage, welche direkt vom Monitoring-System die Meldungen empfängt und in Sprache wandelt. Diese Sprachnachricht wird dann an den angegebenen Kontakt zugestellt.
Damit man es sich einfacher vorstellen kann, haben wir eine Funktionsgrafik erstellt.
Workflow_Anruf1_2_635px
Damit man es sich noch besser vorstellen kann hier ein kleines Beispiel zu dem Bild:
Der Monitoring-Server bemerkt einen Ausfall von einem bedeutsamen Infrastruktur-Bauteil (Server/Switch etc). Sofort wird eine Alarmierung per E-Mail versandt. Zeitgleich geht eine Meldung an die Telefonanlage (wird von NoMa abgearbeitet), welche wiederum den Text in eine Sprachdatei konvertiert. Nun wird der hinterlegte Kontakt angerufen. Sollte dieser nicht an das Telefon gehen, wird der Anruf erneut abgesetzt usw. – bis er dran geht.
Was passiert wenn die Mailbox den Anruf annimmt?
Natürlich hat man bei der Entwicklung einer solchen Alarmierung auch wieder sämtliche Szenarien wie etwa die Mailbox berücksichtigt. Bei der Konfiguration der Alarmierung kann auch eine Tasteneingabe vom User gefordert werden. Somit wird verhindert, dass die Mailbox den Anruf entgegen nimmt und die Meldung dann doch nicht zugestellt wurde. Tritt dieser Fall ein, dass ein Anruf nicht angenommen wird, so kann der nächste in der Eskalationskette benachrichtigt werden oder die Meldung wird beliebig oft an das Telefon vom Bereitschaftsdienst zugestellt.
Können die Meldungen an mehrere bzw. verschiedene User gerichtet werden?
Natürlich kann die Anlage auch mehrere User gleichzeitig oder nacheinander im Fehlerfall benachrichtigen. Die Eskalationskette wird solange abgearbeitet, bis ein User die Meldung als gehört „markiert“ oder die Meldung im Monitoring abgeschaltet wird.
Welche Pakete gibt es?
Wir bieten zwei verschiedene Pakete an. Eine Variante ist nur mit VoIP- die andere mit VoIP und ISDN lauffähig. Zusätzlich empfehlen wir noch unser SMS-Paket inkl. Einrichtung bei Ihnen vor Ort.
Welche Leistungen sind mit im Preis enthalten?
In den jeweiligen Voicepaketen für VoIP oder VoIP/ISDN sind folgende Leistungen bzw. Produkte enthalten

  • Telefonanlage wie gewählt
  • Rackmount-Kit
  • Cepstral Voice-Lizenz (englische Sprache)
  • 1 Termin vor Ort innerhalb Deutschlands mit Einrichtung und Dokumentation
  • Vorab-Versand der Anlage

Gerne passen wir Ihnen die Anlage noch Ihren Wünschen an – fragen Sie doch einfach unverbindlich an.