1. Einleitung

Ursprünglich war es unsere Aufgabe eine genaue Recherche über das Thema Alarmierung via SMS/MMS/Email/Sprachanruf an ein Handy durchzuführen. Im Zuge dieser Recherche bemerkten wir jedoch, dass heutzutage eine Vielzahl von Alarmierungssystemen mit sogenannten Handyapps realisiert werden. So entschieden wir uns, denn Fokus auf die Apps zu legen.

Handyapps, sind Programme die auf Smartphones (modernen Mobiltelefonen) laufen und dabei gehören Macs iOS und Googles Android zu den beliebtesten App Betriebssystemen.

Wir entschieden uns, für einen praktischen Test des Überwachungstools Nagios, um die Möglichkeiten einer solchen Alarmierung näher zu bringen.

2. Überwachung und Alarmierung mit Nagios

2.1 Allgemeines

Nagios ist eine kostenlose Open-Source Software, die entwickelt wurde um Netzwerkgeräte zu überwachen und bei Fehlern oder Änderungen den Anwender oder Administrator zu alarmieren. Die Anwendung kann in kleinen Heimnetzwerken bis zu großen Firmennetzwerken eingesetzt werden. Nagios kann dabei Prozesse auf Servern, die Erreichbarkeit von Diensten (HTTP, FTP, SSH, etc), Performance von Datenbanken, Daten von Netzwerkgeräten wie Switches und Router und noch vieles mehr überwachen.

Nagios überwacht seine Ziele nicht direkt, sondern über Plugins. Diese Plugins werden mit verschiedenen Parametern, wie einer IP, einem Port, oder Ähnlichem aufgerufen und liefern
einen Status zurück („OK“, „Warning“, „Critical“ oder „Unknown“). Viele Plugins werden bereits mit der Nagios Installation mitgeliefert und bieten Möglichkeiten der Überwachung von Systemen über Ping, der Überwachung von Webseiten über einen HTTP Request oder der Überwachung von Systemressourcen. Werden Plug-Ins für speziellere Zwecke benötigt, wird man oft in Plugin Sammlungen im Internet fündig. In dem unwahrscheinlichen Fall, dass es noch keine passenden Plugins gibt, kann man sich sehr leicht in einer beliebigen Programmiersprache sein eigenes Plugin schreiben. Auch die Benachrichtigung über E-Mail, SMS, Telefonanruf, Pager, uvm. geschieht meist über Plugins.
Bei einem Statuswechsel eines Plugins durchläuft ein Ereignis eine Filterkette, die am Ende feststellt, ob eine Benachrichtigung gesendet werden soll oder nicht. Diese Filterkette beinhaltet zum Beispiel die Überprüfung, ob der Host gerade zu Wartungszwecken abgeschaltet wurde, oder ob der Empfänger der Nachricht um diese Uhrzeit benachrichtigt werden soll, oder ob die Benachrichtigungen global deaktiviert wurden und noch vieles mehr. Nagios ist dabei in der Lage Benachrichtigungen über verschiedene Wege an eine Person,  mehrere Personen oder an eine Gruppe von Personen, zu schicken. Dabei können die Wege der Benachrichtigung und die Zeiten wann eine Person oder eine Gruppe benachrichtigt werden soll, angegeben werden. Auch der Text und die enthaltenen Informationen sind frei konfigurierbar.

Quellen: http://www.heise.de/netze/artikel/Netzwerkueberwachung-mit-Nagios-221683.html
Weiterführende Links: http://www.nagiosexchange.org/ http://www.nagios.org/

2.2 Installation von Nagios

Die Installation gestaltet sich im Vergleich zu anderen UNIX Serversystemen relativ einfach, man sollte jedoch Grundkenntnisse im Umgang mit UNIX/Linux besitzen. Nagios ist für alle gängigen UNIX Varianten und somit auch Linux verfügbar. Im Internet finden sich viele ausgezeichnete Anleitungen zur Installation, weshalb dieser Schritt auf den meisten Systemen schnell erledigt ist.

Da Nagios keine grafische Oberfläche benötigt, sollte man aus Performance Gründen auch beim Aufsetzen des Betriebssystems auf eine grafische Oberfläche verzichten. Auch wenn Nagios für einige Linux Systeme in den Repositories enthalten ist, empfiehlt sich die Installation der aktuellsten Version von Nagios.

Nagios benötigt einige Vorraussetzungen um installiert und betrieben werden zu können. Dies sind unter anderem ein Webserver (Apache2) mit PHP, ein „GCC compiler“ mit den dazugehörigen „development libraries“ sowie die „GD development libraries“ für die Bildmanipulation.

Nagios sollte unter einem eigenen Benutzer laufen, um die Sicherheit des Systems nicht zu gefährden. Man sollte sich also einen „nagios“ Benutzer und eine „nagios“ Gruppe anlegen.
Darüber hinaus sollte man eine zweite Gruppe mit dem Namen „nagcmd“ erstellen, der den Benutzer „nagios“ und den Benutzer, unter dem der Webserver läuft, zusammenfasst.

Sind die Benutzer und Gruppen angelegt, kann Nagios von der Projektseite auf sourceforge.net heruntergeladen werden. Die aktuelle Version von Nagios beim Verfassen dieses Dokuments ist 3.2.3. Neben der Kernsoftware Nagios, können auch viele Plugins heruntergeladen werden. Auf Sourceforge lassen sich knapp 300 Projekte mit dem Suchwort “Nagios” finden.

Ist Nagios heruntergeladen und entpackt, kann mit dem Konfigurieren, Kompilieren und Installieren begonnen werden. Näheres dazu findet sich in Betriebssystem spezifischen Anleitungen im Internet oder in der Dokumentation von Nagios (HTML Dateien im Verzeichnis html/docs/). In dieser Dokumentation sind alle Schritte genau beschrieben und dazu auch Hintergrundwissen enthalten.

Einige Anleitungen für die Installation sind in den weiterführenden Links aufgeführt. Mit diesen Anleitungen ist es möglich Nagios auf einem laufenden Linux System zu installieren.

Quellen: http://www.heise.de/netze/artikel/Installation-224088.html

Weiterführende Links:

2.3 Konfiguration von Nagios

Bevor Nagios das erste Mal gestartet werden kann, muss noch die Konfiguration angepasst werden. Bei der Installation werden Standard- bzw. Beispiel-Konfigurationsdateien mitkopiert. Diese Beispielkonfiguration kann man groß teils in das System übernehmen und anschließend Schritt für Schritt an seine Bedürfnisse anpassen. Nagios speichert seine gesamten Einstellungen in einfachen Textdateien, wobei es eine zentrale Konfigurationsdatei gibt, das alle anderen Konfigurationsdateien einbindet. Diese Dateien sind in einem Unterordner der Nagios Installation zu finden. Wurde Nagios beispielsweise unter „/usr/local/nagios“ installiert, so befinden sich die Konfigurationsdateien im Ordner „/usr/local/nagios/etc/objects/.

Die Konfiguration von Nagios teilt sich in folgende Bereiche:

  • Contacts
  • Hosts
  • Services

Contacts sind Personen oder Personengruppen, die Benachrichtigungen erhalten können. Im Bereich Hosts lassen sich alle Systeme konfigurieren, die überwacht werden sollen. Unter Services lassen sich die zu überwachenden Prozesse einrichten.

Nachfolgend ist ein typischer Contacts-Eintrag zu sehen. Bei Ereignissen der überwachten Services oder Hosts wird dieser Kontakt über E-Mail informiert.

define contact{

  • contact_name                                         nagiosadmin
  • use                                                                generic-contact
  • alias                                                              Robert Huber
  • service_notification_period                 24×7
  • host_notification_period                    24×7
  • service_notification_options                w,u,c,r
  • host_notification_options                   d,u,r
  • email                                                             robert.huber@xxx.at

}

Der „contact_name“ bezeichnet den Kontakt und wird von Nagios intern zur Zuordnung verwendet. Daher muss der gewählte Name eindeutig sein. Mit „use“ wird ein Template eingebunden, dass Standardeinstellungen für Kontakte beinhaltet. Damit kann der Administrator gleiche Einstellungen immer zentral verwalten. Der „alias“ beinhaltet meistens den vollen Namen des Kontakts.
Die beiden Einträge „service_notification_period“ und „host_notification_period“ geben die Benachrichtigungszeit an. „24×7“ wurde dabei bereits an einer anderen Stelle in der Konfiguration spezifiziert.

„service_notification_options“ und „host_notification_options“ geben die Fälle an in denen der Kontakt benachrichtigt werden soll. Dabei steht:

  • „w“ für „Warning“
  • „u“ für „Unknown“
  • „c“ für „Critical“
  • „r“ für „Recover“

Bei den Hosts gibt es die Zustände:

  • „d“ für „Down“
  • „u“ für „Unreachable“
  • „r“ für „Recovery“

Die letzte Zeile beinhaltet die E-Mail Adresse des Kontakts.

Hier ist nun ein Eintrag für einen Host zu sehen, wobei es sich um einen Linux Server handelt:

define host{

  • use                                   linux-server
  • host_name                   webspace
  • alias                                webspace
  • address                          78.46.51.253

}

Mit „use“ wird wieder ein Template eingebunden, das für alle Linux Server verwendet werden kann. Der „host_name“ muss wieder eine eindeutige Kennzeichnung für den Host enthalten. Der „alias“ kann der vollständige Name des Servers oder eine Beschreibung sein. Die letzte Zeile „address“ beinhaltet die IP-Adresse über die der Server erreichbar ist.

Um nun die Services des angelegten Hosts überwachen zu können, muss zumindest ein Service Eintrag angelegt werden:

define service{

  • use                                               generic-service
  • host_name                               webspace
  • service_description             webspace FTP check
  • check_command                   check_ftp

}

define service{

  • use                                                local-service
  • host_name                                webspace
  • service_description             HUBAX Homepage Check
  • check_command                   check_http_critical_redirect!hubax.at!/index.php

}

define service{

  • use                                               local-service
  • host_name                               localhost
  • service_description             Root Partition
  • check_command                   check_local_disk!20%!10%!/

}

Der erste Service Eintrag zeigt die Überwachung eines FTP Server auf dem Host „webspace“. Der maßgebliche Befehl „check_ftp“ ist meistens in der commands.cfg definiert.
Der zweite Eintrag zeigt die Überwachung einer Webseite mit dem DNS Namen „hubax.at“ und der Seite „index.php“. Der dritte Eintrag spezifiziert die Überwachung einer lokalen Ressource, die bei Unterschreiten von 20% freiem Speicherplatz eine Warning zurückliefert. Bei weniger als 10% Speicherplatz wird ein Critical Status zurückgeliefert.

Um nun zu wissen was genau hinter den Einträgen steckt, müssen wir uns noch die verwendeten Templates genauer ansehen. Nachfolgend ein Standardtemplates, das mit Nagios mitinstalliert wird:

define contact{

  • name                                                              generic-contact
  • service_notification_period               24×7
  • host_notification_period                     24×7
  • service_notification_options             w,u,c,r,f,s
  • host_notification_options                    d,u,r,f,s
  • service_notification_commands       notify-service-by-email
  • host_notification_commands              notify-host-by-email
  • register                                                           0

}

Dieses Template das von unserem Kontakt benutzt wird, besitzt viele Einstellungen, die wir überschrieben haben. Daneben gibt es aber auch noch den Eintrag service_notification_commands“, der Befehle angibt, die beim Wechsel des Service-Status ausgeführt werden (hier: „notify-service-by-email“, das ein E-Mail beim Status Wechsel verschickt).

define host{

  • name                                              linux-server
  • use                                                  generic-host
  • check_period                             24×7
  • check_interval                           5
  • retry_interval                            1
  • max_check_attempts              10
  • check_command                       check-host-alive
  • notification_period                 workhours
  • notification_interval               120
  • notification_options                d,u,r
  • contact_groups                         admins
  • register                                         0

}

Dieses Template ist für Linux Server gedacht und überwacht die Erreichbarkeit des Hosts und gibt an wie oft der Hosts geprüft wird und welche Personen bei einer Änderung des Status benachrichtigt werden sollen.

Mit den Anleitungen und Ausführungen in den weiterführenden Links ist eine Konfiguration von Nagios zur Überwachung von einfachen Hosts und Services möglich.

Quelle:

Weiterführende Links:

2.4 Weboberfläche von Nagios

Nach einer erfolgreichen Installation und Konfiguration von Nagios kann das umfangreiche Webinterface bestaunt werden. Es bietet nicht nur einen aktuellen Überblick über den Zustand des Netzwerkes, eine Detailansicht der einzelnen Hosts und Services sowie einer History über die geschehenen Ereignisse, sondern auch die Möglichkeit aktiv in Benachrichtigungen und Statusabfragen einzugreifen. Dabei können einzelne Services oder Hosts zu Wartungszwecken deaktiviert oder Abfragen außerhalb des Zeitplans durchgeführt werden. Dabei können zusätzliche Benachrichtigungen versendet oder unversandte als versandt markiert werden.

Dabei bietet das Webinterface viele verschiedene Ansichten an:

  • Übersicht über einzelne Services oder einzelne Hosts,
  • Ansichten über Gruppen von Services oder Hosts, sowie
  • „Tactical Overview“, der den Status und die Probleme des gesamten Netzwerks auf einer Seite zusammenfasst.

NagiosOverview

Bild: Tactical Overview

NagiosServices

Bild: Service Overview

3. Unterschiede zwischen Email/SMS und Handyappbenachrichtigung

3.1            E-Mail Benachrichtigung

Da jedes moderne Mobiltelefon, jeder Computer, und viele andere Geräte bereits E-Mails empfangen können, ist auf Seiten des Clients kaum noch etwas einzurichten. Man benötigt lediglich ein Mailkonto, auf das per POP3 oder IMAP zugegriffen werden kann. Der Vorteil bei dieser Art der Benachrichtigung ist, dass viele Personen bereits E-Mails auf ihren stationären und mobilen Geräten empfangen können.

Auf Seiten des Servers ist meist schon ein E-Mail Programm bei der Installation des Betriebssystems mitinstalliert worden und die Benachrichtigung von Nagios über E-Mail funktioniert out-of-the-box. Es muss lediglich die E-Mail Adresse des Kontakts in Nagios eingetragen werden und der Benutzer erhält eine E-Mail, wenn sich ein Status im überwachten Bereich ändert.

Nachfolgend ist der Standardbefehl aus der Konfigurationsdatei „commands.cfg“ zur Benachrichtigung per E-Mail zu sehen. Der Text in der Mail kann beliebig angepasst werden und mit den Platzhalten zwischen den „$“ Zeichen werden Service spezifische Werte eingebunden.

define command{

  • command_name    notify-service-by-email
  • command_line    /usr/bin/printf „%b“ „***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n“ | /usr/bin/mail -s „** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **“ $CONTACTEMAIL$

}

3.2 SMS Benachrichtigung

SMS Benachrichtigungen benötigen auf einem Endgerät keinerlei Konfiguration. In Nagios muss nur die Telefonnummer des Empfängers konfiguriert werden.
Der Vorteil der SMS Benachrichtigung ist, dass jedes Mobiltelefon SMS empfangen kann und viele Anwender auf eine SMS schneller reagieren als auf eine E-Mail.

Da der Rechner auf dem der der Nagios-Server läuft nur selten SMS senden und empfangen kann, muss diese Möglichkeit erst geschaffen werden. Entweder man meldet sich bei einem “E-Mail to SMS Gateway Service” im Internet an, das zugesandte E-Mails in SMS umwandelt und versendet, oder man schließt ein Mobiltelefon am Computer an, über das SMS versendet werden können.

Der Vorteil bei einem E-Mail to SMS Gateway ist, dass es kostengünstig zu mieten ist und mit jedem Server funktioniert. Der Nachteil liegt daran, dass SMS nur gesendet werden können, wenn auch eine Internetverbindung besteht. Diesen Nachteil besitzt auch die Benachrichtigung über E-Mail, fällt jedoch hier weg, wenn die SMS über ein lokales Mobiltelefon versendet wird. Es verbleibt die Tatsache, dass SMS ein Best-Effort Service ist. Das heißt, dass der Provider eingehende Anfragen im Rahmen seiner Ressourcen schnellstmöglich verarbeitet. Ein garantierter Versand ist nicht gewährleistet. Die Mobilfunkbetreiber versuchen zwar das SMS-Service mit einer Priorität zu versehen, um diese ohne Zeitverzögerung zuzustellen, leider liegt dieser Priority-SMS kein definierter Standard zugrunde, weshalb dieser Ansatz zumeist nur funktioniert, wenn Sender und Empfänger beim selben Provider sind.

Nachfolgend ist die Konfiguration zu sehen, die eine SMS Benachrichtigung über eine “E-Mail to SMS Gateway” sendet und zur Authentifizierung im Betreff einen Benutzernamen und ein Passwort übergibt. Der Empfänger wird hier als E-Mail Empfänger übergeben. Zum Beispiel wird für die Mobiltelefonnummer 06601234567 das E-Mail an 06601234567@smsgateway versandt.

define command{

  • command_name    service-notify-by-epagerSMSat
  • command_line    /usr/bin/printf „%b“ „Type: $NOTIFICATIONTYPE$ — Service: $SERVICEDESC$ — Host: $HOSTALIAS$ — State: $SERVICESTATE$ — Time: $LONGDATETIME$ — Info: $SERVICEOUTPUT$“ | /usr/bin/mail -s „SMSGW-Auth:benutzername:passwort“ $CONTACTEMAIL$

}

Weiterführende Links:

3.3 App Benachrichtigung

Smartphones werden immer beliebter und für die 2 großen Player am Markt, Android und iPhone, gibt es jede Menge Applikationen, die sich sehr einfach installieren lassen. In den jeweiligen App-Stores lassen sich auch Apps für Nagios finden. Wir haben uns Nagroid für Android Mobiltelefone und iNag für iPhones genauer angesehen.

Die Alarmierungsapplikationen pollen dabei den Server und holen sich die aktuellen Informationen und alarmieren den Benutzer zum Beispiel akustisch oder über Vibration. Dabei können in der Applikation Statusinformationen angezeigt und Statistiken abgerufen werden. Einige Apps bieten zusätzlich noch die Möglichkeit Befehle abzusetzen und in die Konfiguration einzugreifen.

Der Vorteil der Alarmierung über Apps liegt wie bei der SMS Alarmierung an der sofortigen Reaktionsmöglichkeit. Das Eintreffen eines E-Mails bemerkt man in der Regel erst sehr viel später. Zusätzlich zur Benachrichtigung erhält man oft noch Zusatzinformationen und muss manchmal zum Eingreifen nicht unbedingt einen Computer aufsuchen.

Der größte Nachteil liegt wie bei der SMS Alarmierung an der Abhängigkeit vom Mobilfunkbetreiber. Wenn kein Empfang verfügbar ist, funktioniert auch die Abfrage des Status nicht. Neben diesem Grundkriterium ist man noch vom Betriebssystem des Smartphones abhängig. Nur die wenigsten Apps sind für mehrere Betriebssysteme verfügbar.

Nagroid – ein inoffzieller Nagios Client für Android

nagios Hier sieht man das Nagroidinterface. Es zeigt alle am Nagroid Webinterface eingestellten Services an. Mehr kann dieses App jedoch nicht.

Von uns getesteten Beispiele:

HubaX Website online check – ist absichtlich deaktiviert worden.

MySQL Service Checks

_

_

_

Quellen: http://code.google.com/p/nagroid/

iNag – Nagios Client für Apples IOs Betriebssystem

iNag

Wir haben den iNAG Client zwar nicht testen können, weil keiner von uns ein IPhone besitzt, jedoch sieht man in der Beschreibung und den Referenzen, das dieses App viel mehr kann als das Nagroid App.

Quellen: http://idevelop.fullnet.com/iapps/modules/apps/inag.php

4. Zusammenfassung & Fazit

Zusammenfassend lässt sich sagen, dass die Alarmierung per App viel komfortabler und besser ist, da man viel mehr Möglichkeiten hat. Man kann Benachrichtigungen empfangen und als gelesen markieren. Somit kann man eine Art Logbuch am Server führen. Heutzutage hat auch fast jeder einen Internetzugang an seinem Smartphone mit einer Internetflatrate, sodass es auch keine wirtschaftlichen Nachteile bei diesem Alarmierungstyp auftreten.

Über Nagios lässt sich fast nur Gutes sagen. Einfache Installation durch eine Menge von Anleitungen, die im Internet zu finden sind. Es besitzt ein gutes und übersichtliches Webinterface, sodass man sofort loslegen kann. Nagios beherrscht auch die Alarmierung per SMS und Email. Das Einzige was uns ein wenig gestört hat, ist die Konfiguration über die Kommandozeile.

Schlussendlich ist man jedoch immer von der Netzqualität des Mobilfunkanbieters abhängig, denn wenn man keinen Empfang hat, kann man gar nicht benachrichtigt werden.