Fachbereich Informatik Department of Computer Science. Abschlussarbeit. im Bachelor Studiengang

Transkript

1 Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science Abschlussarbeit im Bachelor Studiengang Evaluierung, Umsetzung und Roll Out einer Open- Source Monitoring-Lösung für die heterogene Serverlandschaft der allesklar.com AG von Erstbetreuer: Prof. Dr. Martin Leischner Zweitbetreuer: Prof. Dr. Kerstin Uhde Eingereicht am:

2 Bachelorarbeit Eidesstattliche Erklärung: Hiermit erkläre ich, dass ich diese Arbeit selbstständig durchgeführt und verfasst habe. Quellen, Literatur und andere Hilfsmittel sind von mir als solche gekennzeichnet. Bonn, den

3 Bachelorarbeit Abstract Als eines der führenden deutschen Internet-Medienunternehmen hängt der wirtschaftliche Erfolg der allesklar.com AG stark von der Verfügbarkeit der betriebenen, unterschiedlichen Internet-Portale und -Dienste ab. Neben der Betreuung der Internet-Portale fällt eine zentrale Bedeutung auch auf die Verfügbarkeit der eingesetzten IT-Infrastruktur. Die internen Geschäftsprozesse, Workflow-Lösungen, Dateiablagen und weiteren nutzbaren Dienste machen es erst möglich, komplexe Projekte zu managen und umfangreiche Aufgaben zu lösen. Gleichzeitig kann nur eine stetige Überwachung der dabei eingesetzten Technologien eine sinnvolle Ressourcenausnutzung sicherstellen und Unregelmäßigkeiten offen legen. Des Weiteren macht das stetige Wachstum, sowohl bei den Internet-Diensten als auch bei der von Mitarbeitern genutzten IT-Infrastruktur, das Zusammenführen bereits eingesetzter, unterschiedlicher Überwachungslösungen notwendig. Nur so kann an einer zentralen Stelle mit geringem, administrativem Einsatz die Verfügbarkeit aller eingesetzten Elemente sichergestellt werden. Ziel der Arbeit ist die Auswahl einer passenden Lösung aus dem Open-Source- Bereich mit anschließender Integration in das Unternehmensnetzwerk der allesklar.com AG.

4 Inhaltsverzeichnis: Bachelorarbeit ABBILDUNGSVERZEICHNIS: EINLEITUNG MOTIVATION AUSGANGSITUATION ZIELSETZUNG AUFBAU DER ARBEIT ANFORDERUNGSANALYSE ALLGEMEINE ANFORDERUNGEN DETAILLIERTE ANFORDERUNGEN ÜBERSICHT OPEN-SOURCE MONITORING-SOFTWARE BIG SISTER OPENSMART OPENNMS ZABBIX NAGIOS ERGEBNIS ENGERE AUSWAHL TESTINSTALLATION OPENNMS TESTINSTALLATION ZABBIX TESTINSTALLATION NAGIOS ENTSCHEIDUNG IMPLEMENTIERUNG VERZEICHNISSTRUKTUR OBJEKT-TEMPLATES BENACHRICHTIGUNGSSYSTEM SMS Benachrichtigung- und Eskalationsmanagement GUI INBETRIEBNAHME FAZIT UND AUSBLICK LITERATURVERZEICHNIS

5 Bachelorarbeit Abbildungsverzeichnis: Abbildung 1: Unternehmensmanagement [HEG99] Abbildung 2: Dimensionen des Managements nach ISO [BIT05] Abbildung 3: Webfrontend Big Sister Abbildung 4: Webfrontend Opensmart Abbildung 5: Funktionsweise Opensmart [OSM08] Abbildung 6: Webfrontend OpenNMS Abbildung 7: Webfrontend Zabbix Abbildung 8: Funktionsweise Zabbix [DTF07] Abbildung 9: Webrontend Nagios Abbildung 10: Architektur von Nagios [BAR08] Abbildung 11: Round Robin Datenbank Abbildung 12: OpenNMS Webfronend - Detailansicht Abbildung 13: OpenNMS Interface Performance Data Report Abbildung 14: Zabbix MySQL Template Abbildung 15: Zabbix Report: incoming/outgoing Traffic eth Abbildung 16: Nagios Status Map Abbildung 17: Nagios Objekt-Referenzierungen [HEI07] Abbildung 18: Nagios Eskalationsmanagement [BAR08] Abbildung 19: Nagios Webfrontend Tactical Overview Abbildung 20: Verzeichnisstruktur - Objektdefinitionen Abbildung 21: NagVis Abbildung 22: NagiosQL

6 Einleitung Bachelorarbeit 1. Einleitung Das Unternehmensmanagement besteht nach [HEG99] aus Service-, Netzwerk- und Komponentenmanagement. Wie in Abbildung 1 zu sehen, nimmt das Netzwerkmanagement dabei die Rolle des Bindeglieds zwischen der Unternehmensplanung und des eigentlichen Betriebs ein. Dazu zählt neben der Überwachung, der Fehlererkennung und -behebung auch die Unterstützung der Benutzer. Das Konfigurationsmanagement ist nach [BOC08] ein Prozess der Planung, Identifizierung, Erfassung, Verwaltung und Kontrolle der IT-Infrastruktur, wird jedoch in dieser Arbeit nicht weiter behandelt. Es sollen viel mehr die Möglichkeiten der Überwachung von Rechnernetzen durchleuchtet werden und dabei der Fokus auf Open-Source Software liegen Motivation Abbildung 1: Unternehmensmanagement [HEG99] Die Verfügbarkeit von Diensten kann auf verschiedene Arten überwacht werden. Eine einfache, jedoch wenig effiziente, Möglichkeit ist eine Überwachung durch die Nutzer selber, d.h. fallen beispielsweise Mailserver und die zugehörigen Dienste aus, wird die Störung erst beim Versuch des Versands oder Empfangs einer auffallen. Sollte der Defekt am Wochenende auftreten, kann die Ausfallzeit schnell mehrere Stunden betragen. Eine sicherlich bessere Möglichkeit ist die regelmäßige Prüfung aller angebotenen Dienste auf Verfügbarkeit und einer zeitnahen Benachrichtigung im Fehlerfall. Zu diesem Zweck sind zahlreiche kommerzielle, aber auch frei verfügbare Überwachungssysteme entwickelt worden, auf Letztere konzentriert sich dabei die vorliegende Arbeit [STR08]

7 Einleitung Bachelorarbeit 1.2. Ausgangsituation Derzeit werden die Dienste, die das Unternehmen bereitstellt, von dem externen Dienstleister Sysformance überwacht. Mögliche Benachrichtigungen über Fehlerzustände beziehen sich dabei ausschließlich auf den fehlerhaften Dienst, nicht jedoch auf den dazugehörigen Rechner. Da beispielsweise der Webservice aus Gründen der Lastverteilung auf mehrere parallel arbeitende Systeme verteilt ist, ist es möglich, dass der Ausfall eines einzelnen Webservers von den restlichen Systemen kompensiert wird und somit für den Nutzer unerkannt bleibt. Zwar werden Daten von Server-Auslastungen sowie Netzwerkverkehr gesammelt und von MRTG [OET08a] grafisch aufbereitet, jedoch ohne eine aktive Benachrichtigung bei Anormalitäten zu versenden. Im Gegensatz dazu erstellt jeder Linux-Server täglich einen Statusbericht und versendet diesen per an die Administratoren. Darin sind alle Aktivitäten des vergangenen Tages wie Einwahlversuche sowie die aktuellen Plattenfüllstände enthalten. Eine Analyse der E- Mails erfolgt nur teilweise automatisch, indem nach auffälligen Schlüsselwörtern geparst wird; der Rest wird manuell untersucht. Abhilfe schafft eine Überwachungsplattform, die alle beschriebenen Einzellösungen zusammenführt, indem sie alle Server und Dienste separat überwacht, das Auslösen von Alarmen durch Schwellenwerte definiert und aktiv Fehler-Meldungen verschickt Zielsetzung Ziel der Arbeit ist die Evaluierung geeigneter Überwachungsplattformen, die Auswahl einer passenden Lösung und anschließende Integration in das Unternehmensnetzwerk der allesklar.com AG. Daneben soll ein Eskalations- und Benachrichtigungsmanagement eingerichtet werden, um in Fehlersituationen die zuständigen Personen zu informieren um damit Ausfallzeiten zu minimieren Aufbau der Arbeit Im folgenden Kapitel werden zunächst einige Aspekte des Netzmanagements dargestellt und die Anforderungen an das Überwachungswerkzeug beschrieben und analysiert. Kapitel 3 stellt einige im Rahmen einer Marktanalyse gefundenen Projekte kurz vor und stellt die Arbeitsweise dar. Anschließend werden drei der Lösungen für weitere Tests in die engere Auswahl genommen. In Kapitel 4 werden die Programme der engeren Auswahl auf einem Testsystem installiert und auf eine mögliche Verwendbarkeit im Unternehmen geprüft. Kapitel 5 befasst sich mit der Integration der im vorherigen Kapitel ausgewählten Überwachungsplattform. Im abschließenden Kapitel wird die Implementierung zusammengefasst und Vorschläge für zusätzliche Erweiterungen gemacht

8 Anforderungsanalyse Bachelorarbeit 2. Anforderungsanalyse Das folgende Kapitel befasst sich mit den Anforderungen, die das in Kapitel 4.4 auszuwählende Überwachungswerkzeug zu erfüllen hat. Dabei beschreibt der erste Abschnitt die generellen Anforderungen in allgemeiner Form. Der zweite Abschnitt geht daraufhin detailliert auf die speziellen Anforderungen des Unternehmens ein Allgemeine Anforderungen Das in der Arbeit von [BIT05] verwendete Funktionsmodell (Abbildung 2) zeigt die verschiedenen Aspekte des Netzmanagements aus der Sicht verschiedener Funktionsbereiche, wobei das Netzwerk-Monitoring in der funktionalen Dimension anzusiedeln ist. Abbildung 2: Dimensionen des Managements nach ISO [BIT05] Die Anforderungen an ein Software-System werden in einem Anforderungskatalog erfasst. Er ist die Basis zwischen Auftraggeber und Auftragnehmer und sollte objektiv überprüfbar sein. Dabei stehen ausschließlich die Forderungen im Vordergrund und nicht deren Umsetzung [BOL98]. Die Hauptaufgabe der Monitoring-Lösung besteht aus der Überwachung der Verfügbarkeit von Diensten, Systemen und Netzkomponenten. Daneben ist die Auswertung der gewonnenen Daten ein bedeutender Bestandteil der Überwachung. Außerdem sollen, in Abhängigkeit zum Zustand des Systems, definierte Maßnahmen eingeleitet werden können. Folgende Fragestellungen sind zur Behebung von auftretenden Fehlerzuständen zu beantworten, wobei mit Ressourcen Dienste, Systeme und Netzkomponenten gemeint sind: [GOS07] Welche Ressource betrifft die Störung? Steht die Ressource in Abhängigkeit zu anderen und wenn ja in welcher? Sind dadurch weitere Ressourcen betroffen? Auf welchem System wird der Dienst bereitgestellt? Sind die Systeme bzw. Netzkomponenten des bereitgestellten Dienstes erreichbar? Ist der Fehler bereits mehrfach aufgetreten? - 8 -

9 Wer muss bei Störungen informiert werden? Wie hoch ist die Verfügbarkeit? Anforderungsanalyse Bachelorarbeit Eine einheitliche Darstellung der Daten wird für alle Ressourcen erwünscht. Außerdem wird ein übersichtliches Webfrontend bevorzugt. Dieses soll die folgenden Darstellungen ermöglichen: Übersicht über alle Zustände und deren Zustand Darstellung von Abhängigkeiten zwischen Systemen als Graph Topologische Darstellung des Netzes Gruppierung von Ressourcen Erstellung von Verfügbarkeitsberichten Ereignishistogramm Benachrichtigungshistogramm Anzeige von Trends bezogen auf Zustandswechsel Planen von Wartungsintervallen Hinzufügen und Löschen von Kommentaren Die zuständigen Mitarbeiter der Fachabteilung müssen bei Zustandswechseln sofort und auf verschiedenen Wegen benachrichtigt werden, wobei beide Richtungen der Zustandswechsel berücksichtigt werden müssen. Die zugehörige Nachricht muss aussagekräftig sein und Angaben zur betroffenen Ressource, Zustand, Zeitpunkt und ggf. vorliegende Leistungsdaten enthalten. Wird die Störung in einem definierbaren Zeitrahmen nicht behoben, sollen ranghöhere Mitarbeiter involviert werden können. Ein mehrstufiges Benachrichtigungsmanagement wird auch Eskalationsmanagement genannt. Weiterhin soll es möglich sein, die Überwachung auf zukünftige Ressourcen zu erweitern. Sollte dabei die Anzahl zu überwachender Objekte die maximal mögliche Anzahl überschreiten, soll das Überwachungssystem auf mehrere Systeme aufteilbar sein. Zusammenfassend muss das zu wählende System folgende Anforderungen erfüllen: Überwachung und Auswertung der Verfügbarkeit Überwachung von Netzkomponenten Übersichtliches Webfrontend Benachrichtigungsmanagement Eskalationsmanagement Erweiterbarkeit Skalierbarkeit 2.2. Detaillierte Anforderungen Die allesklar.com AG unterhält an ihrem Hauptsitz Siegburg eine Serverfarm von ca. 30 Rechnern und in einem nahegelegenen Rechenzentrum ca. weitere 70 Server. Davon fallen die beiden größten Anteile auf Datenbank- und Webserver. Außerdem existieren kleinere Anzahlen an - und Fileservern, teilweise unter Windows. Neben dem generellen Verfügbarkeitstest der vorhandenen Hardware müssen auch die zugehörigen Dienste überwacht werden können. Diese sind im Folgenden: Datenbankdienste (Oracle, MySQL) Webserverkontrolle (Apache) -Dienste (POP, IMAP, SMTP) Dateifreigabedienste (Samba) Domain-Name-Service Weiterhin sollen lokale Ressourcen wie beispielsweise die freie Festplattenkapazität, die Auslastung des Swap-Bereichs sowie die gesamte Systemlast überprüft werden können. Außerdem sollen Abfragen über SNMP möglich sein, da dieses die einzige Möglichkeit ist, Informationen von den vorhandenen Netzwerkgeräten (Router, Switches) zu erlangen. Daneben sind SNMP-Daemons auch für Unix- und Windows- Systeme verfügbar. Als letzten Punkt sollen Änderungen an zu überwachenden Systemen vermieden werden

10 Übersicht Open-Source Monitoring-Software Bachelorarbeit Big Sister 3. Übersicht Open-Source Monitoring-Software Im folgenden Kapitel werden fünf, im Rahmen einer Marktanalyse, ausgesuchte Überwachungswerkzeuge vorgestellt, die Funktionen mit den Anforderungen verglichen und über eine mögliche Verwendbarkeit im Unternehmen entschieden Big Sister Abbildung 3: Webfrontend Big Sister Das erste Tool nennt sich Big Sister [BS08] und wurde 1996 von dem Schweizer Thomas Aeby entwickelt. Das Programm liegt in der Version vor, welche Anfang 2006 veröffentlicht wurde. Da sich die Hardwarevoraussetzungen an den Zeitpunkt der Entwicklung orientieren, fallen diese dementsprechend gering aus. Wie der Name bereits vermuten lässt, ist Big Sister mit dem von der Firma Quest Software vertriebenen Big Brother [BB08] verwandt. Big Brother steht jedoch im Gegensatz zu ihrer kompatiblen großen Schwester nicht unter GNU GPL. Aus diesem Grund kam Big Brother von Anfang an für eine nähere Betrachtung nicht in Frage. Big Sister basiert auf einer Client-Server-Architektur und bietet 3 Wege zur Überwachung von Diensten und Servern an. Bei dem ersten wird ein Agent auf dem überwachten Host installiert, welcher seine Daten in regelmäßigen Abständen über den TCP-Port 1984 an den Server sendet. Der Port wurde von Quests Big Brother in Anlehnung an George Orwells Buch 1984 übernommen. Bei der zweiten Möglichkeit überwacht jeder installierte Agent Netzwerkdienste auf entfernten Host- Systemen, wie z.b. SMTP, HTTP oder NTP, und gibt die Ergebnisse an den Server weiter. Bei der letzten Möglichkeit erfolgt die Datensammlung per SNMP. Die Konfiguration der Agents erfolgt über Textdateien (/etc/bigsister/uxmon-net), in denen SNMP-Parameter wie Version und Community Name eingetragen werden. Außerdem sind dort die IP-Adresse des Servers sowie die zu überwachenden Dienste zu definieren. Ruft man dann mittels eines Webbrowsers die Adresse des Big Sister Servers ( auf, meldet sich das in Abbildung 3 zu sehende Webfrontend

11 Übersicht Open-Source Monitoring-Software Bachelorarbeit Big Sister Zur Visualisierung der Zustände wird ein aus sieben Farben bestehendes Ampelsystem verwendet: Grün OK Gelb Warnung Rot Fehler Violett keine Meldung (z.b. bei Wählleitungen) Blau Offline Weiß Überwachung ausgeschaltet Grau unerreichbar Auch die Alarmkonfiguration erfolgt über eine Textdatei mit dem Namen bb_event_generator.cfg. Sie ist regelbasiert und befindet sich im gleichen Verzeichnis wie uxmon-net. Die verschiedenen Regeln ermöglichen für jeden Host bzw. Dienst ein individuelles Alarmierungskonzept. So kann man eine bestimmte Zeit vergehen lassen, bis ein Alarm ausgelöst wird und ihn verwerfen, wenn das Problem während der Wartezeit verschwunden ist. Im Gegensatz dazu kann die betroffene Person regelmäßig benachrichtigt werden, so lange das Problem weiterbesteht. Außerdem sind Berichte über regelmäßig wiederkehrende Probleme unterdrückbar. Neben Abhängigkeiten zwischen Tageszeit oder Wochentag und dem auslösenden Alarm sind auch Zusammenhänge zwischen den überwachten Teilnetzen darstellbar [AEB03] [AEB04]. Fazit: Big Sister verfügt über ein übersichtliches Webfrontend, jedoch ist der Weg dorthin mit einer umfangreichen Konfiguration verbunden. Die dazu verwendeten Textdateien sind unaufgeräumt und unstrukturiert. Der größte Nachteil ist jedoch das enorme Alter von mehr als zwei Jahren, was darauf schließen lässt, dass die Weiterentwicklung der Software eingestellt wurde. Daher kommt Big Sister für eine tiefere Betrachtung nicht in Frage

12 Übersicht Open-Source Monitoring-Software Bachelorarbeit Opensmart 3.2. Opensmart Abbildung 4: Webfrontend Opensmart Ein weiteres Projekt heißt Opensmart [SCH08], dessen Name sich von Open (Source/System) Monitoring and Reporting Tool ableiten lässt. Sein Entwickler Holger Schultheiß hat die Überwachung der Systeme mittels Agenten realisiert. Für die Kommunikation zwischen den Agenten und dem Opensmart-Server wird XML over HTTP oder HTTPS verwendet. Dabei kann auch ein HTTP(S)-Proxy verwendet werden, sollten sich beispielsweise die überwachten Rechner in einem anderen Subnetz oder einer DMZ befinden. Die Konfigurationsdateien der Agenten werden zentralisiert auf dem so genannten Configuration-Server verwaltet und deren Alter via HTTP-HEAD-Request verglichen. Sollte auf dem Server eine aktuellere Datei vorliegen, wird diese per HTTP-GET angefordert. Für die Kommunikation werden die Funktionen eines Apache-Webservers benötigt, so dass dessen Konfiguration dementsprechend angepasst werden muss. Durch symbolische Links ist es möglich den Pflegeaufwand zu minimieren, da dadurch mehrere Agents auf eine Config-Datei zugreifen können. Das Webfrontend (Abbildung 4), welches sowohl in englischer als auch in deutscher Sprache vorliegt, lässt sich nach erfolgreicher Installation über einen Browser aufrufen ( Dabei ist die Ansicht frei konfigurierbar, so dass man sich beispielsweise nur fehlerhafte Hosts oder alle Hosts nach Gruppen sortiert anzeigen lassen kann. Bei den Zuständen wird zwischen NORMAL, INFO, WARNING, ERROR und FATAL unterschieden. Die Behandlung von Fehlerzuständen kann als Benachrichtigung erfolgen oder bei bekannten Lösungsansätzen vom Agent behoben werden. So kann dieser beispielsweise einen gestoppten Prozess wieder starten. Die Installationsvoraussetzungen sind gering, da der Server neben einem Unix- System, einem Apache-Webserver, einem Perl-Interpreter ab Version nur eine Datenbank benötigt. Hierfür kommen derzeit MySQL, PostgreSQL, Oracle oder DB2 in Frage. Einen zu überwachenden Rechner kann man bereits bei vorhandenem Perl

13 Übersicht Open-Source Monitoring-Software Bachelorarbeit Opensmart Interpreter sowie 1 MByte freiem Festplattenspeicher mit dem Agent ausstatten und überwachen. Dabei sind jedoch auch Rechner mit einem Windows-Betriebssystem möglich. Die Konfiguration des Servers ist in wenigen Schritten erledigt. Es muss eine Datenbank eingerichtet werden und dem Server bekannt gemacht werden. Beispielskripte sind für alle vier unterstützten Datenbanken vorhanden. Anschließend werden noch zwei Cronjobs benötigt. Notifysrv startet bei Statusänderungen in der Datenbank eine Benachrichtigungsregel wie notify_by_mail, notify_by_sms oder auch notify_by_rss. Der zweite Cronjob archive_errors wird aus Performanzgründen gestartet. Wie der Name vermuten lässt archiviert er Inhalte bestimmter Datenbanktabellen. Die Einrichtung des Agenten ist dagegen zeitaufwändiger. In der Konfigurationsdatei, die im XML-Format vorliegt, sind zuerst der Data-Collector und der Configuration- Server anzugeben. Daher müssen diese nicht zwangsläufig auf ein und derselben Maschine laufen, was bei einer großen Anzahl von Agenten auch sinnvoll erscheint. Hier wird neben der IP-Adresse auch das Protokoll eingetragen, so dass HTTPS statt HTTP und, bei entsprechend konfiguriertem Apache-Webserver, auch Basic-Auth möglich sind. Im Anschluss folgen die Tags, die die Überwachungen definieren. So kann man beispielsweise den Füllgrad eines Filesystems kontrollieren und bei Überschreitung von Schwellenwerten den Status wechseln lassen. Außerdem ist es möglich elementare Betriebssystem-Prozesse zu überwachen und einen Befehl zu definieren, der einen hängenden Prozess versucht neu zu starten. Diese Selbstheilungsbefehle werden mit sogenannten FIX-CMD-Tags realisiert. Dabei wird die Fehlerbehebung bei jedem Zustand, der ungleich NORMAL ist, gestartet. Des Weiteren ist es möglich so genannte RUNIF-Tags zu verwenden, um Server und Dienste nur unter bestimmten Bedingungen zu überwachen. Folgende Conditional- Tags bietet Opensmart beispielsweise an: [SCH07] RUNIF_DIR startet den Check nur, wenn das angegebene File oder Directory existiert. RUNIF_CUSTOM macht eine Überprüfung von anderen Befehlen abhängig. RUNIF_TIME definiert Zeitfenster. RUNIF_INTERVAL ermöglicht die Wiederholung eines Tests nach einer definierten Zeit. RUNIF_INTERVAL_FILE speichert den Zeitpunkt der letzten RUNIF_INTERVAL Ausführung Abbildung 5: Funktionsweise Opensmart [OSM08]

14 Fazit: Übersicht Open-Source Monitoring-Software Bachelorarbeit Opensmart Opensmart ist besonders schlank und handlich und aufgrund der geringen Anforderungen auch auf älteren Systemen lauffähig. Die Konfiguration der Agenten ist dagegen sehr zeitaufwendig. Auch bietet Opensmart aktuell keine Möglichkeiten Netzkomponenten über SNMP zu überwachen, was jedoch im Anforderungskatalog gefordert ist. Daher scheidet Opensmart für weiterführende Tests aus

15 Bachelorarbeit OpenNMS 3.3. OpenNMS Abbildung 6: Webfrontend OpenNMS Das Open Network Management System, kurz OpenNMS [ONMS08], ist für die Überwachung von umfangreichen Netzen von Tarus Balog entwickelt worden. Daher ist es recht häufig bei Webhostern und Internetprovidern zu finden. Es legt den Fokus auf die Schwerpunkte Ausfallüberwachung von Servern und Diensten, Datensammeln mittels SNMP und das Alarmierungsmanagement. Als Programmiersprache wurde Java verwendet, die Konfiguration erfolgt über XML- Dateien. Demzufolge ist es auf allen Systemen lauffähig, die SDK ab unterstützen, derzeit sind das folgende Betriebssysteme:[BAL05] Linux o Red Hat Enterprise Linux /CentOS (3, 4, und 5, x86 und x86_64) o Debian Etch and Lenny (x86 und x86_64) o Fedora (2 through 8, x86 und x86_64) o Mandriva 2007 und 2008 o SuSE (9 und 10) Solaris 8, 9, und 10 (SPARC) Solaris 8, 9, und 10 (x86) Mac OS X (10.4+, PowerPC and x86) Microsoft Betriebssysteme ab Windows 2000 Die Ansprüche an die verwendete Hardware fallen gering aus. So ist das Programm bereits auf einem System mit einer 1GHz Pentium III (oder vergleichbarer) CPU installierbar, jedoch werden auch Vorteile mehrerer CPU-Kerne unterstützt. Der Hauptspeicher sollte mindestens 256 (besser 512 MByte) RAM betragen, wobei die OpenNMS Java Virtual Machine mit Speicher von bis zu 2 GByte umgehen kann, bei Betriebssystemen mit 64-bit sogar noch mehr. Weitere Installationsvoraussetzungen sind: Apache Webserver ab Version Tomcat Application Server ab Version 4 Suns JDK ab RRD Tool ab Version PostgreSQL ab Version

16 Bachelorarbeit OpenNMS Nach erfolgter Installation steht dem Administrator ein Feature namens Auto- Discovery zur Verfügung, mit dem man verschiedene Netzbereiche nach Interfaces durchsuchen lassen kann. Dazu trägt man in der zugehörigen XML-Datei Anfangsund Endadresse ein. Nach erfolgtem Neustart sendet OpenNMS in regelmäßigen Abständen ein ICMP-Paket an alle möglichen Adressen des Netzbereichs. Wird das ICMP-Paket beantwortet folgt ein anschließender Portscan, wobei gefundene Dienste sofort in die Überwachung aufgenommen werden. Gleiches gilt für Informationen, die per SNMP bereitgestellt werden, vorausgesetzt die Community-Strings stimmen mit denen der SNMP-Konfigurationsdatei überein. Damit ist der anfängliche Konfigurationsaufwand bereits erledigt, es sei denn es sollen noch zusätzliche zu den bereits definierten Diensten überwacht werden. Dazu müssen Parameter wie der zu überwachende Port, der Zeitraum zwischen zwei Tests und die Anzahl der Wiederholung des Tests definiert werden. Fällt ein Test negativ aus, können Benachrichtigungen versendet werden. Dabei können auch Abhängigkeiten zwischen Servern und Diensten sowie zwischen Servern und Routern abgebildet werden. Stellt beispielsweise ein Server mehrere Dienste bereit und fällt gänzlich aus, wird der Administrator, falls erwünscht, nur über den Ausfall der Server informiert, anstatt eine Nachricht über jeden ausgefallenen Dienst zu erhalten. Selbiges gilt bei Ausfall einer zentralen Netzkomponente und der daran angeschlossenen Rechnern. Zeiten, zu denen keine Tests durchgeführt werden sollen, lassen sich periodisch wiederkehrend oder auch einmalig definieren [KÜH07]. Fazit: Das Webfrontend (Abbildung 6) ist sehr übersichtlich. Die Möglichkeit der automatischen Konfiguration erleichtert die Inbetriebnahme dieses Überwachungssystems. Die insgesamt positiven Eindrücke müssen nähere Untersuchungen bestätigen. OpenNMS wird daher für eine mögliche Verwendung im Unternehmen in einer Testumgebung installiert und genauer analysiert

17 Übersicht Open-Source Monitoring-Software Bachelorarbeit Zabbix 3.4. Zabbix Abbildung 7: Webfrontend Zabbix Als nächstes wird das seit 2001 entwickelte Überwachungswerkzeug Zabbix [ZAB08] vorgestellt. Sein Entwickler Alexei Vladishev ist CEO der Firma SIA, die seit 3 Jahren ihren Sitz in der lettischen Hauptstadt Riga hat und von dort aus professionelle Unterstützung zu dem Produkt anbietet. Das Programm selbst steht unter der GPL (General Public License) und besteht aus den Komponenten Agent, Server und Webfrontend. Das Webfrontend (Abbildung 7) ist wie bei OpenNMS in PHP geschrieben, bei der Überwachung zeigen sich jedoch Unterschiede. So sammelt Zabbix die Überwachungsdaten über Agenten, die auf den zu überwachenden Rechnern laufen müssen. Bei einer großen Anzahl an Servern muss man dadurch anfangs mit hohem Konfigurationsaufwand rechnen. Zabbix selbst hat es mittlerweile in die Standard-Repositories einiger Linux-Distributionen wie Debian, Fedora, Gentoo, Ubuntu, FreeBSD und Network Security Toolkit geschafft. Eine Version für Betriebssysteme von Microsoft existiert nicht. Die Agenten sind dagegen neben den Unix-Betriebssystemen wie AIX, FreeBSD, Linux, Mac OS X, Solaris auch für Windows ab NT4.0 verfügbar. Weitere Voraussetzungen für den Zabbix-Server sind: Apache Webserver ab Version PHP ab 4.3 incl. php-gd und php-bcmath Eine der folgenden Datenbanken o MySQL ab 3.22 incl. phpmysql o Oracle ab incl. php-sqlora8 o PostgreSQL ab incl. php-pgsql o SQLite ab incl. php-sqlite3 Make und C Compiler Optional, jedoch als sinnvoll erachtet werden: NET-SNMP oder UCD-SNMP-Header und Libraries OpenSSL-Header und Libraries Die Wahl des Betriebssystems und der Datenbank hängt von der Anzahl der Hosts ab. Eine Empfehlung der Entwickler ist in der Online-Dokumentation zu finden. Bei der Installation muss die verwendete Datenbanksoftware als Parameter übergeben werden. Falls eine Selbstüberwachung des Zabbix-Servers erwünscht ist, muss natürlich auch der Agent auf dem Server installiert sein. In der Konfigurationsdatei

18 Übersicht Open-Source Monitoring-Software Bachelorarbeit Zabbix des Servers müssen noch die Parameter der Datenbank eingetragen werden, so dass diese zur Lastverteilung auch auf einem entfernten Rechner zu finden sein kann. Tabellen und Initialdaten liegen als Skripte vor und müssen lediglich in die entsprechende Datenbank eingespielt werden. Nachdem das Frontend an eine für den Webserver erreichbare Stelle kopiert wurde, ist der Zabbix-Server über einen beliebigen Browser über erreichbar. Die anschließende Konfiguration erfolgt im Gegensatz zur Installation über die Weboberfläche. Anschließend stehen ungefähr 100 vordefinierte Tests bereit, so dass sich z.b. der freie Festplattenspeicher oder der Netzwerkverkehr überwachen lassen. Die zentrale Datenbank speichert dabei neben den Werten, die der Server Daemon über die verschiedenen Agenten erhält, auch die Konfigurationsdaten, die über das Webfrontend erzeugt werden. Abbildung 8 zeigt die Kommunikation zwischen Agenten, Datenbank und Webfrontend. Zabbix kann Daten für bestimmte Zeiträume grafisch aufbereiten und darstellen. Darüber hinaus ist es möglich, die Netz-Infrastruktur in verschachtelbare Karten abzubilden und damit auch den Ort eines Problems grafisch darzustellen. Die Benachrichtigung dazu kann über , SMS, Pager oder externe Programme erfolgen. Zabbix kann Alarme auch vorbeugend aus Berechnungen abschicken, so dass der Administrator eine Nachricht erhält, wenn die durchschnittliche CPU- Auslastung eines Clusters einen definierten Wert übersteigt. Des Weiteren ist es möglich Beobachtungswerte zu verknüpfen und automatisch mit Eckdaten von Service Level Agreements (SLAs) zu vergleichen. Abhängigkeiten zur Vermeidung von überflüssigen Nachrichten lassen sich ebenso erstellen wie Eskalationsstufen, um bei Nichteinhalten von Fehlerbehebungszeiten weitere Personenkreise einzubeziehen. Ein nützliches Feature ist die Möglichkeit des Im- und Exports von Objekt-Konfigurationen aus bzw. in XML-Dateien, was eine Migration des Zabbix- Servers erleichtert [DTF07]. Abbildung 8: Funktionsweise Zabbix [DTF07]

19 Übersicht Open-Source Monitoring-Software Bachelorarbeit Zabbix Fazit: Der erste Eindruck von Zabbix ist vielversprechend. Die Anforderungen an das Überwachungstool werden erfüllt, mit Ausnahme der Notwendigkeit einen Agenten auf dem überwachten Server einzusetzen. Inwieweit dadurch und durch das weniger übersichtliche Webfrontend die Einsetzbarkeit im Unternehmen beeinträchtigt wird, muss ein Praxistest zeigen. Daher wird Zabbix in einer Testumgebung weitergehend betrachtet

20 Übersicht Open-Source Monitoring-Software Nagios Bachelorarbeit 3.5. Nagios Abbildung 9: Webrontend Nagios Nagios [NAG08] liegt mittlerweile in der Version vor und ist der Nachfolger des 1999 ins Leben gerufenen Projekts Netsaint [NET08]. Der Name lässt sich von Network und Agios (griech. Heiliger) ableiten. Sein Entwickler Ethan Galstad legte bereits von Anfang an einen großen Wert auf Modularität und Erweiterbarkeit. Das ist auch der Grund, weshalb Nagios nach erfolgter Installation nur wenige Funktionen zur Verfügung stellt. Erst bei zusätzlicher Installation der sogenannten Plugins steht dem Benutzer ein vollständiges Überwachungswerkzeug zur Verfügung. Durch die Trennung von Hauptprogramm und Funktionen und den einfachen Schnittstellen wird die Kompatibilität zwischen den verschiedensten Versionen gewährleistet. Mittlerweile bieten viele Konkurrenzsysteme eigene Schnittstellen zu den Nagios- Plugins an, um von der großen Vielfalt zu profitieren. Die Konfiguration erfolgt mittels strukturierter Textdateien, die über einen Editor erstellt bzw. bearbeitet werden können. Es existieren auch Tools, die eine Konfiguration über ein Webfrontend ermöglichen, jedoch setzen diese noch eine Nagios Installation in der Version 2.x voraus. Nagios folgt einem objektorientierten Ansatz. Dadurch ist es möglich, Templates zu definieren, von denen die zu überwachenden Server oder Dienste ihre Parameter erben. Das wesentliche Objekt bei Nagios ist der Host. Er kann z.b. ein Server, ein Drucker oder ein Router sein und wird durch seine IP- oder MAC-Adresse identifiziert. Durch einen Host-Check wird die Erreichbarkeit getestet, die typischerweise mit einem ICMP-Ping realisiert wird. Weiterhin kann man sogenannte Services definieren, wie beispielsweise die korrekte Zuweisung von IP-Adressen per DHCP oder ob ein DNS-Server eine Anfrage richtig auflöst. Neben der Zeit, die zwischen zwei Checks vergehen soll, kann man auch die Anzahl der nötigen Checks definieren, um aus einem Fehler einen Fehlerzustand zu generieren. Die daraus resultierenden Benachrichtigungen werden an die zuständigen Contact-Objekte