Zenoss als Tool zur Netzwerküberwachungmrick1/mrick1_Zenoss.pdf · 2010. 4. 22. · Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und

Hochschule für Technik, Wirtschaft und Kultur LeipzigFakultät für Informatik,

Mathematik und Naturwissenschaften

Projektarbeit

ZENOSS ALS TOOL ZURNETZWERKÜBERWACHUNG

COMMERCIAL OPEN SOURCE APPLICATION FOR SYSTEM UND NETWORK MONITORING

verfasst und vorgelegt vonB.Sc. Michael Schmidt Mat.Nr 52676

B.Sc. Matthias Rick Mat.Nr 52670

Leipzig, den 22. April 2010

Inhaltsverzeichnis

Einleitung 1

1 Theoretische Grundlagen 31.1 allgemeine Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Das OSI -Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 IP-Adressklassen (IPv4) . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3 Netzwerkmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.4 RRDTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.5 Simple Network Management Protokoll . . . . . . . . . . . . . . . . 71.1.6 Management Information Base . . . . . . . . . . . . . . . . . . . . . 9

1.2 Netzwerkmanagement Systeme . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.1 Cacti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.2 Nagios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Netzwerkmanagement mit Zenoss 142.1 Was ist Zenoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 User Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Collection Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Installation und Konfiguration 193.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Konfiguration der Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 SNMP Installation und Konfiguration unter Linux . . . . . . . . . . . 223.2.2 WMI Installation und Konfiguration unter Windows XP . . . . . . . 24

4 Management 274.1 Überwachung von Servern . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 Serverüberwachung mit SNMP . . . . . . . . . . . . . . . . . . . . 284.1.2 Serverüberwachung mit WMI . . . . . . . . . . . . . . . . . . . . . 29

5 Das Userinterface 305.1 Main Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

I

Inhaltsverzeichnis Inhaltsverzeichnis

5.2 Event Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Monitoring 346.1 CPU Auslastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2 Festplattenüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Speicherüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Management 39

8 Schlusswort 418.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Abbildungsverzeichnis III

Tabellenverzeichnis IV

Glossar V

Abkürzungsverzeichnis VIII

Literaturverzeichnis X

II

Einleitung

Motivation

Netzwerk-Management bekam mit der steigenden Komplexität von Netzwerken immer mehrBedeutung. Um diese Netzwerk-Systeme zu pflegen und die Administratoren bei deren Arbeitzu unterstützen ist es für viele Firmen und Institute unerlässlich, Pakete für das System- undNetzwerkmanagement einzusetzen. Diese sind in der Lage Administratoren bei Problemen mitRechnern, Diensten und Ressourcen umgehend zu benachrichtigen und bei der Fehlersuchezu assistieren. Informationen können dabei häufig verdichtet werden, bei Bedarf aber auchumfassend informieren. Kommerzielle Lösungen stellen beispielsweise Tivoli (IBM), Openview(HP), Unicenter (Computer Associates) und Patrol (BMC) dar, die in der Lage sind, tausendevon Servern zu verwalten und zu überwachen. Der Anschaffungspreis, den ein Unternehmen fürsolch ein umfassendes Schwergewicht zahlen muss, ist jedoch meist nicht rentabel. Deswegenist es vor allem für kleinere Firmen sinnvoll nach Alternativen im Open-Source-Sektor zusuchen. Dabei gibt es neben Werkzeugen wie Nagios, Cacti, Big Sister und Ganglia auch dasNetzwerk-Management-System Zenoss, welches durch eine Vielzahl an Funktionen und nahezubeliebige Erweiterbarkeit durch Plugins besticht.

Inhalte dieser Arbeit

Diese Arbeit betrachtet das System- und Netzwerk-Management-Werkzeug Zenoss. Grundle-gend werden zwei Versionen von Zenoss entwickelt, eine kostenpflichtige Enterprise Versionund eine Open Source Version, welche unter der General Public License (GPL)v2 zum freienDownload zur Verfügung steht. In der vorliegenden Projektarbeit wird lediglich die OpenSource Version betrachtet. Trotzdem kann dabei nicht die gesamte Palette an Funktionen undEinsatzmöglichkeiten beleuchtet werden, wodurch nur Grundkonzepte und spezielle Teilaspektedes Systems zur Sprache kommen werden.

Die Arbeit lässt sich in zwei Teile untergliedern. Der erste Teil beschäftigt sich zunächstmit den theoretischen Grundlagen der Netzwerktechnik und gibt allgemeine Informationenüber die Grundkonzepte von Zenoss. Anschließend folgen dann im Kapitel 3 die Installationund Konfiguration von Zenoss. Dabei stellt sich heraus, dass diese Schritte aufgrund ihrer

1

Einleitung

Komplexität Einsteiger ohne Fachkenntnisse überfordern, sie erlauben aber auch eine hoheFlexibilität und Anpassung an eine Vielzahl von Problemen. Weiterhin wird besonders dieFunktionalität der Weboberfläche beschrieben, welche es dem Administrator ermöglicht, genaudie Informationen angezeigt zu bekommen, die für ihn wichtig sind.

Der zweite Teil, der mit Kapitel 4 beginnt, gibt dann einen umfangreichen Überblick überverschiedene Möglichkeiten der Überwachung von Servern mithilfe von Zenoss. Diese Über-wachung wird hauptsächlich durch Grafiken realisiert. Dabei wird in der vorliegeneden Arbeitzum Beispiel im Abschnitt 6.3 geschildert, wie man anhand dieser Grafiken mögliche Engpässeder zur Verfügung stehenden Hardware erkennen kann. Auch ist eine Optimieriung hinsicht-lich des Zeitmanagements durch geeignetes Rechtemanagement im Kapitel 7 geschildert. AlsAbschluss dieser Arbeit erfolgt dann eine Bewertung sowie ein Vergleich mit anderen Syste-men. Allgemein gültige Empfehlungen für eine Lösung lassen sich dabei nicht treffen. AlsKernaussage gilt, dass die Wahl eines Paketes von der jeweiligen Rechnerumgebung und demEinsatzzweck abhängt und individuell erfolgen muss. Die angegebene Übersicht der Lösungenund die Bewertung geben eine Orientierung und sind bei der Wahl eines Systems behilflich.

2

Kapitel 1

Theoretische Grundlagen

Dieses Kapitel befasst sich mit den Grundlagen aller Themengebiete, welche direkt zur Funktioneines Netzwerk Überwachungs Servers gehören und zu dessen Betrieb nötig sind. Es stelltdie Grundlagen für die nachfolgenden, praktisch bezogenen Kapitel dar. Dabei werden inAbschnitt 1.1 zuerst allgemeine Grundlagen von Netzwerken gegeben. In Abschnitt 1.2 werdenanschließend zwei weitere Netzwerk-Management-Tools vorgestellt.

1.1 allgemeine Grundlagen

1.1.1 Das OSI -Referenzmodell

Das Open System Interconnection (OSI) -Modell ist ein Referenzmodell, welches als Design-grundlage von Kommunikationsprotokollen entwickelt wurde. Dieses Referenzmodell trägtauch die Bezeichnung 7-Schichten-Modell, da es in sieben verschiedene Schichten unterteiltist. Die Schichten werden auch als Ebenen oder Layer bezeichnet. Jeder Schicht ist eine klarumrissene Aufgabe zur Durchführung der Kommunikation zugewiesen. Hierdurch wird daskomplexe Problem der Datenkommunikation innerhalb eines Kommunikationssystems in klei-nere Teilprobleme zerlegt. Die Schichten eins bis vier werden auch als transportorientierteSchichten und die Schichten fünf bis sieben auch als anwendungsorientierte Schichten bezeich-net. Da die Schichten bildhaft als übereinander gestapelt erscheinen, wird ihre Gesamtheit auchhäufig als “Protokoll-Stapel” oder “Protokoll-Stack” bezeichnet (siehe Tabelle 1.1) [Odo05].

Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen TransmissionControl Protocol (TCP) und Internet Protokol (IP) der Netzarchitektur beruht auf den Vorschlä-gen, die bei der Fortentwicklung des Advance Research Projects Agency Networks (ARPANET)gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden,deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI-Standardisierungeingeflossen. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nurvier Schichten: Application Layer, Transport Layer, Internet Layer und Network Layer. Der

3

Kapitel 1 Theoretische Grundlagen 1.1 allgemeine Grundlagen

OSI TCP/IPApplication

ApplicationPresentationSession

Transport TransportNetwork Internet

Data LinkNetwork

Physical

Tabelle 1.1: Vergleich zwischen OSI und TCP/IP

Application Layer des TCP/IP-Modells kann mit den drei Anwendungsschichten des OSI-Referenzmodells verglichen werden. Der Transport Layer ist bei beiden Modellen gleichdefiniert, und der Internet Layer des TCP/IP-Modells entspricht dem Network Layer des OSI-Modells. Die Schichten eins und zwei des OSI-Referenzmodells werden beim TCP/IP-Modellzum Network Layer zusammengefasst.

1.1.2 IP-Adressklassen (IPv4)

Jede IP-Adresse besteht aus einer Netzwerkkennung und einer Hostkennung. Die Netzwerk-kennung (auch Netzwerkadresse genannt) identifiziert die Systeme, die sich im selben Netz-werk befinden. Alle Computer eines logischen Segmentes (Layer 3) müssen über dieselbeNetzwerkkennung verfügen, wobei diese innerhalb eines Verbundnetzes eindeutig sein muss.Die Hostkennung (auch Hostadresse genannt) identifiziert die einzelnen TCP/IP-Hosts inner-halb eines Netzwerks [Odo05].

IP-Adressen sind logische 32-Bit-Zahlenwerte, die in vier 8-Bit-Felder unterteilt werden, diesogenannten Oktette. Nach Request for Comments (RFC) 3330 wurden folgende IP AdressKlassen festgelegt, welche mit den Buchstaben A, B, C, D und E bezeichnet werden. DieAdressklassen definieren, welche Bits für die Hostkennung verwendet werden [win02]. Diedrei Klassen A, B und C werden auch als Hauptklassen bezeichnet. Bei Adressen der Klasse Dhandelt es sich um Multicast-Adressen. Die Adressen der Klasse E sind spezielle, reservierteAdressen.

Anhand der ersten vier Bits wird jeweils die Einordnung in die Adressklassen vorgenommen.In Tabelle 1.2 wird ein Überblick über die Adressklassen A, B und C gegeben.

Die Tabelle 1.3 zeigt die maximal möglichen Anzahlen von Netzen, IP-Adressen sowie dieAdressbereiche der Netze A, B und C

Die schnelle Verknappung der Adressen (vor allem der Klasse B) hat deutlich gemacht, dass dreiprimäre Adressklassen nicht genug sind. Die Klasse A war viel zu groß und die Klasse C viel

4


Class Bit 0-3 4-7 8-15 16-23 24-31A 0... 8-Bit-Netz 24-Bit-HostB 10... 16-Bit-Netz 16-Bit-HostC 110... 24-Bit-Netz 8-Bit-Host

Tabelle 1.2: Adressklassen

KlasseAnzahl

NetzeNetze Adressen

A 27 224 0.0.0.0/8 bis 127.255.255.255B 214 216 128.0.0.0/16 bis 191.255.255.255C 221 28 192.0.0.0/24 bis 223.255.255.255

Tabelle 1.3: Adressbereiche der Klassen A, B und C

zu klein. Um eine Lösung für die daraus resultierende Klasse-B-Adresskrise zu finden, musstedas Modell etwas flexibler gestaltet werden. Da die IP-Adresse aus 32 aufeinanderfolgendenBits besteht, wurde dies durch eine Bitmaske zur flexibleren Interpretation des Netzwerk- undHostteils erreicht. Die Verwendung einer Maske anstelle von Adressklassen zur Bestimmungdes Zielnetzwerkes nennt man Classless Inter-Domain Routing (CIDR)[FL06].

Der Vorteil dabei ist, dass mehrere (Sub-)Netze zusammengefasst werden können, um somitweniger verschiedene Routen auf den Routern zu haben. Dies spart Last und bringt somiteine bessere Performance der Netzkoppelgeräte mit sich. Die Verwendung von Bitmasken zurGenerierung von Netzwerken, deren Größe die Standardmaske überschreitet, bezeichnet manals Supernetting [Hun98].

Das Internet Protokoll Version 6 (IPv6) ist der Nachfolger des gegenwärtig im Internet nochüberwiegend verwendeten Internet Protokolls der Version 4. IPv4 bietet einen Adressraum vonetwas über vier Milliarden IP-Adressen. In den Anfangstagen des Internet, als es nur wenigeRechner gab, die eine IP-Adresse brauchten, galt dies als weit mehr als ausreichend. Aufgrunddes unvorhergesehenen Wachstums des Internet herrscht seit Ende der des 20. JahrhundertsAdressknappheit. Die historische Entwicklung des Internet wirft weitere Probleme auf: Durchdie mit der Zeit mehrmals geänderte Vergabepraxis der IP-Adressen des IPv4-Adressraums istdieser inzwischen auch stark fragmentiert, das heißt häufig gehören mehrere nicht zusammen-hängende Adressbereiche zur gleichen organisatorischen Instanz. Dies führt in Verbindung mitder heutigen Routingstrategie (CIDR) zu langen Routingtabellen. Zudem erfordert IPv4 vonRoutern, Kopfdaten jedes weitergeleiteten Pakets umzuschreiben und entsprechend Prüfsum-men neu zu berechnen, was eine weitere Prozessorlast darstellt.

Um diese Probleme zu beheben begann die Internet Engeneering Task Force (IETF) 1995die Arbeiten an IPv6. Im Dezember 1998 wurde IPv6 mit der Publikation von RFC 2460offiziell zum Nachfolger von IPv4 gekürt. Eine Schätzung, welche die American Registry for

5


Internet Numbers (ARIN) zur Bewertung ihrer Vergabepolitik heranzieht, geht davon aus, dasdie Internet Assigned Numbers Authority (IANA) im Januar 2011 die letzte IPv4-Netze an dieRegional Internet Registries vergeben wird.

1.1.3 Netzwerkmanagement

Unter Netzwerkmanagement versteht man die Verwaltung, Betriebstechnik und Überwa-chung von IT-Netzwerken und Telekommunikationsnetzen. Der englische Fachbegriff fürdiese Tätigkeiten lautet Operation, Administration and Maintenance (OAM). Die InternationalOrganisation of Standardization (ISO) hat das Fault, Configuration, Accounting, Performance,Security Management (FCAPS) Modell entwickelt welches die funktionalen Aufgaben vonNetzwerkmanagement beschreibt. Die Tabelle 1.4 gibt einen Überblick über die fünf Schichtendes FCAPS Modells.

Definition Übersetzung BeschreibungFault Management Fehlermanagement Erkennen, protokollieren, mel-

den und beheben von auftreten-den Fehlerzuständen

Configuration Management Konfigurationsmanagement Erfassung aller Komponen-ten (Configuration Items), dieüberwacht werden müssen

Accounting Management Abrechnungsmanagement Erfassen der Benutzung desNetzes, so dass Rechnungengestellt werden können

Performance Management Leistungsmanagement Verkehrswerte/Leistungsdatensammeln und Statistikenführen, Grenzwerte festlegen

Security Management Sicherheitsmanagement Authentifizierung von Benut-zern, Autorisierung von Zu-griff und Nutzung

Tabelle 1.4: Überblick über die Schichten des FCAPS

Ein großer Teil dieser Aufgaben wird von rechnerbasierten Netzmanagementsystemen unter-stützt. Reale Netzmanagementsysteme unterstützen in der Regel jedoch nur einen Teil dieserAufgaben. IP-Netze werden häufig mittels Simple Netzwork Management Protocol (SNMP)und/oder Windows Management Instrumentations (WMI) verwaltet und überwacht. In grö-ßeren Netzen werden auch andere Protokolle wie z. B. SAA oder Netflow verwendet. In dennationalen und internationalen Telekommunikationsnetzen werden proprietäre Protokolle mithöherer Leistungsfähigkeit verwendet, in Deutschland z. B. QD2, in den USA TL1. Wegen derim Vergleich mit privaten Heimnetzen wesentlich höheren Anzahl von Netzelementen können

6


keine Protokolle verwendet werden, die wie SNMP auf Polling basieren. In Europa werdenauch OSI-Protokolle verwendet.

Unter Netzwerk-Monitoring versteht man die Überwachung und regelmäßige Kontrolle vonNetzwerken, deren Hardware (z. B. Server, Router, Switches) und Diensten (z. B. Webserver,DNS-Dienste, E-Mail-Dienste). Man unterscheidet hierbei zwischen externem und internemMonitoring. Beim externen Monitoring wird ein zusätzliches Monitoring-Gerät an das Netzangeschlossen, beim internen Monitoring nicht. Eine weitere Charakterisierung wird mit denBegriffen aktiv und passiv getroffen. Beim aktiven Monitoring werden zusätzliche Pakete indas Netz gesendet, beim passiven wird lediglich “mitgehört”.

1.1.4 RRDTool

RRDtool ist ein open source Programm, mit dem zeitbezogene Messdaten gespeichert, zusammen-gefasst und visualisiert werden können. Dieses Programm ist unter der GNU lizensiert. DieAbkürzung Round-Robin-Database (RRD) bezieht sich auf die Art und Weise, in der Daten vonRRDtool gespeichert werden. Beim Anlegen einer Datenbank, einer so genannten “RRD-Datei”,wird ein Speicherbereich mit einer festen Größe reserviert. Die Größe des Speicherbereichswird dabei so gewählt, dass die in der fest definierten Zeitspanne anfallenden Daten in dieserDatei gespeichert werden können. Nach dieser Zeitspanne ist der reservierte Speicherbereichaufgebraucht, jedoch wird die Datenbank nicht erweitert (die Datei wird nicht vergrößert),sondern die ältesten Daten werden überschrieben. Dieses “Reihum-Verfahren” wird in derInformatik häufig mit Round-Robin bezeichnet.

Die Benutzer-Schnittstelle von RRDtool besteht aus Kommandozeilen-Programmen. DamitRRDtool von anderen Programmen zum Speichern von Daten und Erstellen von Graphenverwendet werden kann, stehen Programmierschnittstellen (APIs) für mehrere Programmier-sprachen bereit, unter anderem C und Perl.

Üblicherweise wird RRDtool nicht direkt über die Kommandozeile verwendet, sondern dientanderen Programmen als Datenspeicher bzw. -quelle. Beispiele von Free Open Source Software(FOSS)-Programmen, die RRDtool verwenden, sind Cacti und Multi Router Traffic Grapher(MRTG)[cac09].

1.1.5 Simple Network Management Protokoll

Das SNMP ist ein Netzwerkprotokoll, das von der IETF definiert wurde. Es wurde entwickelt,um Netzwerkelemente1 von einer zentralen Managementstation aus überwachen und steuernzu können. Dabei wird die Kommunikation zwischen den überwachten Geräten und der Über-wachungsstation geregelt. SNMP beschreibt hierbei den Aufbau der Datenpakete, die zwischen

1zum Beispiel Router, Server, Switches, Drucker, Computer

7


den überwachten Stationen und der Managementkonsole übertragen werden und den Kommu-nikationsablauf. Durch seine Einfachheit hat sich SNMP zum Standard entwickelt, der von denmeisten Managementtools unterstützt wird. Zu den Aufgaben des Netzwerkmanagements, diemit SNMP möglich sind, zählen:

• Überwachen von Netzwerkkomponenten

• Fernsteuerung und Fernkonfiguration von Netzwerkkomponenten

• Fehlererkennung und Fehlerbenachrichtigung

Funktion

Auf den überwachten Netzwerkelementen muss ein so genannter Agent laufen. Dabei handeltes sich um ein Programm, das die jeweilige Station überwacht und dessen Eigenschaftenim Netz verfügbar macht. Managerprogramme können über diese Agenten auf die Stationenzugreifen um Daten abzufragen, Einstellungen vorzunehmen und Aktionen auszulösen. Fürdie Kommunikation zwischen den Agenten und den Managern gibt es sechs verschiedeneSNMP-Pakete. Diese sechs Pakete sowie die Funktion der einzelnen Pakete wird in Tabelle 1.5aufgezeigt.

Name AufgabeGET zum Anfordern eines Management DatensatzesGETNEXT um den nachfolgenden Datensatz abzurufen (um Tabellen zu durchlaufen)GETBULK um mehrere Datensätze auf einmal abzurufen, wie zum Beispiel mehrere

Reihen einer Tabelle (verfügbar ab SNMPv2)SET um einen Datensatz eines Netzelementes zu verändernRESPONSE Antwort auf eines der vorherigen PaketeTRAP unaufgeforderte Nachricht von einem Agenten an den Manager, dass ein

Ereignis eingetreten ist

Tabelle 1.5: SNMP-Pakate und deren Aufgaben

Abbildung 1.1 gibt einen Überblick über die Kommunikation zwischen einem SNMP-Managerund einem Agent. Bei dem Agent kann es sich sowohl um einen einzelnen Agent handeln,als auch um einen Masteragent. Ein Masteragent fungiert als Schnittstelle zwischen mehrerenAgents und einem SNMP-Manager. Der Manager sendet an die einzelnen Agents GET - oderSET - Requests um Datensätze anzufordern oder zu verändern. Daraufhin sendet der AgentRESPONSE - Pakete als Antwort auf einen solchen Request. Beim Eintreten eines Ereignisseswird von dem jeweiligen Agent ein TRAP - Paket an den Manager gesandt. Damit dieses PaketEmpfangen und Ausgewertet werden kann, beinhaltet der SNMP-Manager einen sogenannten“Trap-Empfänger”.

8


Abbildung 1.1: Simple Network Management Protokoll

Die drei Get-Pakete (Get, GetNext, GetBulk) können vom Manager zu einem Agenten ge-sendet werden um Daten über die jeweilige Station anzufordern. Dieser antwortet mit einemResponse-Paket, das entweder die angeforderten Daten enthält oder eine Fehlermeldung. Mitdem Set-Paket kann ein Manager Werte beim Agenten verändern. Damit ist es möglich Ein-stellungen vorzunehmen oder Aktionen auszulösen. Der Agent bestätigt die Übernahme derWerte ebenfalls mit einem Response-Paket. Wenn der Agent bei der Überwachung des Sys-tems einen Fehler erkennt, kann er diesen mit Hilfe eines Trap-Paketes unaufgefordert andie Management-Station melden. Diese Pakete werden nicht vom Manager bestätigt. DerAgent kann damit nicht feststellen, ob der Trap beim Manager angekommen ist. Damit dieNetzwerkbelastung gering bleibt wird zum Versenden der Nachrichten das verbindungsloseUser Datagramm Protocol (UDP)-Protokoll verwendet. Der Agent empfängt dabei die Requestsauf dem Port 161, während für den Manager der Port 162 zum Empfangen der Trap-Meldungenvorgeschrieben ist[CFSD90].

1.1.6 Management Information Base

Welche Informationen ein Agent sammeln und ein Verwaltungssystem von einem Agentenanfordern kann, ist in der Management Information Base (MIB) festgelegt. Eine MIB ist einSatz verwaltbarer Objekte, die verschiedene Arten von Informationen über ein Netzwerk-gerät darstellen können (zum Beispiel die Anzahl der aktiven Sitzungen oder die Version derNetzwerkbetriebssystem-Software, die auf dem Host ausgeführt wird). SNMP-Verwaltungs-systeme und SNMP-Agenten interpretieren MIB-Objekte gleich. Informationen über die Ob-jekte einer bestimmten MIB werden vom Agent gespeichert, und das Verwaltungssystem ruftdie Informationen aus der MIB über den Agenten ab.

Die Informationen der MIB sind in einer Art Baumstruktur organisiert, deren einzelne Zweige

9


entweder durch Nummern oder alternativ durch alphanumerische Bezeichnungen dargestelltwerden können. Die MIB-2 ist zum Beispiel unter “iso.org.dod.internet.mgmt.MIB-2” zufinden, das ebenso durch die Zahlenreihe 1.3.6.1.2.1 eindeutig bestimmt ist (1 steht für “iso”, 3für “org” ). Diese aus Punkten und Zahlen bestehende Zeichenkette nennt man Object Identifier(OID). In den MIBs wird dann weiter verzweigt bis zu den einzelnen Daten, die jeweils aucheine eigene OID besitzen und somit eindeutig identifiziert werden können.

Neben den in den RFCs definierten MIBs kann jeder Hersteller von Soft- oder Hardware eigeneMIBs, so genannte private MIBs, definieren, die die speziellen Eigenschaften seines Produkteswiedergeben. Unter der OID iso(1).org(3).dod(6).internet(1).private(4).enterprises(1) werdendiese bei der IANA registriert. Mittlerweile sind unter dieser OID mehrere tausend Firmenregistriert. Ist einer OID einmal ein Objekt zugeordnet, so darf sich die Bedeutung dieser OID -sofern vom Gerät (dem SNMP-Agenten) unterstützt - nicht wieder ändern. Es darf auch keineÜberschneidungen geben.

Mit Hilfe der MIB-Dateien sind die Managementprogramme in der Lage den hierarchischenAufbau der Daten beim Agenten darzustellen und sie abzufragen, ohne dass der Benutzer dieOID selber kennen muss.

SNMP Paketaufbau

Die meisten SNMP-Pakete sind identisch aufgebaut. Lediglich bei Trap-Meldungen werden imProtocol Data Unit (PDU)-Header teilweise andere Informationen versendet.

SNMP-Paket Header

Im Header wird die Angabe über die Gesamtgröße des Pakets, die Versionsnummer (SNMPv1,SNMPv2 oder SNMPv3) und der Community Name übermittelt. Durch Zuweisen von Commu-nities sollten Zugriffsrechte vergeben werden. In den meisten Fällen wurde aber als CommunityName “public” gewählt für Lesezugriff und „private“ für Lese und Schreibzugriff. Sicherheitkann aber auch durch andere Namen nicht erreicht werden, da der Community Name imKlartext übertragen wird und von jedem im Netz mitgehört werden kann.

PDU-Header (Nicht-Trap-Pakete)

Der erste Teil des PDU-Headers beinhaltet die Angabe über die Art des SNMP-Paketes und dieAngabe über die Größe der PDU.

Der Aufbau des zweiten Teils hängt von der Art des SNMP-Paketes ab. Damit Antwortpaketeden vorherigen Anfragen zugeordnet werden können, gibt es die Request ID. Diese Request

10


ID ist im Anfrage- und Antwortpaket identisch. Damit ist es möglich mehrere Anfragen zuverschicken und die Antworten wieder richtig zu sortieren. Der Fehlerstatus und - index wirddazu verwendet, um in den Antwortpaketen mitzuteilen, warum eine Anfrage nicht bearbeitetwerden konnte. Solange kein Fehler auftritt, sind die beiden Felder mit dem Wert Null belegt.Im Fehlerfall gibt der Fehlerindex an, beim wievielten Datensatz der Fehler auftrat. Mit demFehlerstatus wird der Grund des Fehlers angegeben. Der Fehlerstatus kann bei SNMPv1 einenvon 6 möglichen Werten haben:

• Kein Fehler

• Paket ist zu groß um versendet zu werden

• Die OID wird nicht unterstützt

• Falscher Datentyp oder Werte

• Nur Lesezugriff

• Unbekannter Generierungsfehler

PDU-Header (Trap-Pakete)

Die ersten beiden Felder des PDU-Header sind bei Traps identisch zu anderen SNMP-Paketen.Das Feld Pakettyp gibt an, dass es sich um einen Trap handelt. Ebenfalls wird hier die Größe derPDU angegeben. Im zweiten Teil werden andere Werte übertragen, die nur bei Traps benötigtwerden. Zum Erkennen von wem die Nachricht kommt wird eine OID des Gerätes mitgeschickt,dass den Trap generiert hat und die IP-Adresse des Absenders. Die OID gibt an um was für einGerät es sich handelt. Das ist wichtig zu wissen, wenn es sich um einen firmenspezifischenTrap handelt, die nur für diesen Gerätetyp gilt.

Danach folgt die allgemeine TrapID. Es gibt sieben mögliche allgemeine TrapIDs:

• Kaltstart

• Warmstart

• Link Down

• Link Up

• Authentifizierungsfehler

• EGP-Nachbar verloren

• Firmenspezifisch

11

Kapitel 1 Theoretische Grundlagen 1.2 Netzwerkmanagement Systeme

Wird in diesem Feld angegeben, dass es sich um einen firmenspezifischen Trap handelt, wirddessen ID im nachfolgenden Feld übertragen.

Da es möglich ist, dass Trap-Pakete nicht in der Reihenfolge eintreffen wie sie versendetwurden, gibt es zusätzlich noch eine Zeitangabe, die auf hundertstel Sekunden genau angibt,wie lang der SNMP-Agent gelaufen ist, bis das Trap-Ereignis auftrat. Dadurch ist es möglich,die Trap-Ereignisse in die zeitlich richtige Reihenfolge zu bringen.

PDU-Body

Im PDU-Body werden die eigentlichen Werte übertragen. Jeder Wert wird in einer Variablebinding übertragen: Zu einer Variable binding gehören deren OID, der Datentyp und derWert an sich. Es gibt keine Vorgabe wie viele Variablen binding im PDU-Body mitgeschicktwerden dürfen. Es ist also möglich mehrere Werte mit einem Get-Befehl abzufragen. Wenn aberdas Antwortpaket dabei zu groß wird, kann es passieren, dass die entsprechende Fehlermeldungim Antwortpaket zurückgeschickt wird.Bei Traps ist es auch möglich, dass keine Variablen binding mitgeschickt werden. In demFall wird die TrapID als ausreichende Information angesehen.Im SNMP-Paket ist keine Angabe vorgesehen, welche die Anzahl an mitgeschickten Variablenbinding angibt. Das lässt sich nur über die Größenangabe des PDU-Bodys und der Größen-angabe der einzelnen Variablen binding heraus finden.

1.2 Netzwerkmanagement Systeme

1.2.1 Cacti

Cacti ist eine Open Source Software, mit welcher sich Messwerte periodisch sammeln undgrafisch darstellen lassen. Diese Daten können via SNMP oder über eigene Skripte von Cactiausgelesen werden. Die Daten werden in einer RRD gespeichert. Dadurch ist Cacti in derLage, praktisch alle maschinenlesbaren Datenquellen zu lesen. Es kann zur Überwachungaktiver Netzwerkkomponenten oder anderer IT-Systeme innerhalb eines autonomes Systembenutzt werden. Es kann unter anderem für die Beaufsichtigung der Auslastung verschiedenerKomponenten genutzt werden. Zudem ist eine Darstellung von Umweltbedingungen, wie zumBeispiel Temperatur, Luftfeuchtigkeit und vielen anderen, möglich. Für die Installation vonCacti wird folgende Software benötigt:

• PHP

• Webserver

• MySQL

12

Kapitel 1 Theoretische Grundlagen 1.2 Netzwerkmanagement Systeme

• RRDTool

• SNMP

1.2.2 Nagios

Auch Nagios (dieses Wort setzt sich zusammen aus “Network” und “Hagios”) dient zurÜberwachung von komplexen IT-Infrastrukturen. Nagios bietet dazu eine Sammlung vonModulen zur Überwachung von Netzwerken, Hosts und speziell Diensten sowie einer Web-Schnittstelle zum Abfragen der gesammelten Daten. Es steht unter der GPL, ist also auch eineFreie Software, und läuft unter zahlreichen Unix-ähnlichen Betriebssystemen.

Am 9. November 2007 wurde die Nagios Enterprises LLC von Ethan Galstad gegründet,welche Consulting und technische Unterstützung rund um das Thema Nagios als kommerzielleDienstleistung anbietet. Die Software selber bleibt aber weiterhin unter einer freien Lizenz.

13

Kapitel 2

Netzwerkmanagement mit Zenoss

Ungeachtet der Größe eines Unternehmens spielt die IT im 20.Jahrhundert eine große undweiter anwachsende Rolle des täglichen Geschäftes. Nicht nur aus diesem Grunde ist es immerwichtiger die verschiedenen Server, Klienten und Netzwerkkoppelgeräte zu verwalten. Zenossist eines von vielen Netzwerk- und System-Managementtools, welche derzeit auf dem Marktvertreten sind. Nagios oder auch Cacti sind 2 weitere Open Source Lösungen, welche zumZwecke der Netzwerküberwachung entwickelt wurden. Die Abschnitte 2.1 bis 2.2.3 gebeneinen Überblick über die Strunktur und die Funktionalität von Zenoss.

2.1 Was ist Zenoss

Zenoss ist ein Enterprise open source Netzwerk Management System (NMS), welches inPython/Z Object Publishing Environment (ZOPE) entwickelt wurde. Zenoss stellt ein ganzheit-liches Produkt zur Überwachung von Verfügbarkeit, Performance, Events und Konfigurationenquer durch das Netzwerk bereit. Zudem bietet es eine auf Asynchronous JavaScript and XML(AJAX)-basierende Weboberfläche, welche es dem Administrator ermöglicht die Überwachungder Geräte zu überprüfen und zu konfigurieren. Egal ob fünf oder 5000 Geräte überwachtwerden, Zenoss bietet eine Skalierbare Lösung zum jeweiligen Zweck.

2.2 Architektur

Zenoss hat alles, was benötigt wird, um eine IT-Infrastruktur auf Fehler zu untersuchen, zuwarten oder um Konfigurationen vorzunehmen. Zu diesem Zweck kann Zenoss in drei Schichtenunterteilt werden:

• User

• Data

14

Kapitel 2 Netzwerkmanagement mit Zenoss 2.2 Architektur

• Collection

In Abbildung 2.1 wird ein Überblick über die Architektur von Zenoss gegeben. Diese Ab-bildung zeigt, dass der User Layer auf den Data und Collection Layer zugreift. Der Data Layerinteragiert mit dem Collection Layer und dieser ist der einzige welcher auf das Netzwerkzugreift.

User Layer

Data Layer

Netzwerk

Collection Layer

Abbildung 2.1: Überblick über die Systemarchitektur von Zenoss

Die Anwenderschicht (auch User-Layer genannt) erlaubt es von einem Webbrowser aus auf denZenoss-Server zuzugreifen und mit diesem zu arbeiten. Offiziell wird hierbei nur die aktuelleVersion von Mozilla Firefox1 oder des Microsoft Internet Explorers unterstützt. Die Anwender-schicht erlaubt es, die angeschlossenen Ressourcen des Zenoss-Servers zu konfigurieren oderdie aufgezeichneten Daten abzurufen. Die Schnittstelle stellt dabei das Webinterface des Serversdar. Zenoss arbeitet auf der Basis von verschiedenen Open Source Werkzeugen. Die wichtigstendavon sind ZOPE, Python, MySQL und RRDTool. In den Abschnitten 2.2.1, 2.2.2 und 2.2.3werden die einzelnen Schichten genauer erläutert.

2.2.1 User Layer

Zenoss ist flexibel genug, um komplett über die Kommandozeile bedient zu werden. Allerdingskann ein Großteil der Arbeit auch über das auf AJAX basierende Webinterface erledigt werden.Aus diesem Grund wurde die Arbeit auf der Kommandozeile in diesem Projekt lediglich aufdie Fehlersuche und Installation begrenzt.

Mit Hilfe des Webinterfaces können sowohl der Data Layer als auch der Collection Layerbedient werden. Folgende Aufgabenbereiche werden dabei abgedeckt:

1Bei der Erstellung dieser Ausarbeitung wurde die Version 3.5.3 verwendet

15


• Navigation und Organisation

• Devicemanagement

• Verfügbarkeits- und Performanceüberwachung

• Systemberichte

• Eventmanagement

• Einstellungen und Administration

2.2.2 Data Layer

Das Herzstück des Data Layers sind Datenbanken. Der Data Layer von Zenoss besteht grund-sätzlich aus drei verschiedenen Datenbanken, in welche die Daten gespeichert werden. ImCollection Layer (siehe Abschnitt 2.2.3) werden die Daten selektiert und anschließend durchden ZenHub in der entsprechenden Datenbank abgespeichert (vergleiche Abbildung 2.2).

ConfigurationCMDB

PerformanceZenRRD

EventsZenEvents

CollectionZenHub

Abbildung 2.2: Überblick über den Data Layer von Zenoss

Ereignisse werden in einer MySQL-Datenbank abgespeichert.Es wird immer dann vom Zenoss-Daemon ein Ereignis generiert, wenn ein bestimmter Grenzwert über- oder unterschrittenwird. Beispiele für solche Grenzwerte sind unter anderem eine hohe Hauptspeicherauslastungeines Servers oder Stromausfall eines Servers. Solche Ereignisse können eine Aktion wie zumBeispiel das Senden einer Email oder einer SMS an den Administrator erzwingen.

Zeitbezogene Messreihen oder Logfiles werden in einer RRD gespeichert. Der Vorteil einersolchen Datenbank besteht darin, dass die Speichergröße dieser Datenbank nur bis zu einem

16


festgelegten Wert ansteigt. Falls dieser Wert erreicht wird, werden die ältesten Daten über-schrieben. In Zenoss gibt es zudem die Möglichkeit solche Daten graphisch darzustellen,beispielsweise in einem Diagramm.

Die dritte Datenbank von Zenoss ist eine Configuration Management Database (CMDB).CMDB ist ein Information Technology Infrastructure Library (ITIL) Standard zum verwaltenvon Konfigurationen, Abhängigkeiten und zur Speicherung von Änderungender überwach-ten Netzwerkgeräte. Anhand dieser Daten kann mittels Zenoss ein detailliertes Modell desNetzwerkes erstellt werden. Die CMDB ist unter Zenoss in einer ZOPE eingebettet.

2.2.3 Collection Layer

Der Collection Layer besteht aus mehreren Daemons, die Informationen über Geräte, Ver-fügbarkeiten, Dienste und Ereignisse (siehe Abbildung 2.3) sammeln und speichern. DieseInformationen werden an ZenHub geschickt und mit Hilfe dieses Dienstes in der entsprechendenDatenbank gespeichert.

CollectionZenHub

GeräteManagement

Verfügbarkeitund Funktion

Ereignisse

Abbildung 2.3: Überblick über den Collection Layer

Über die Weboberfläche kann eine Auswahl getroffen werden, welche Daemons mitgespeichertwerden sollen. Alle Daemons, welche standardmäßig von Zenoss bereitgestellt werden, beginnenmit dem Präfix “zen”.

Der Status gibt an, ob ein bestimmter Daemon aktiv (grün) oder inaktiv (rot) ist. Anhandvon “view config” oder “edit config” kann die jeweilige Konfiguration des Dienstes angezeigtoder verändert werden. Zudem kann über die Weboberfläche ein Dienst angehalten oder(neu) gestartet werden. In den Logfiles werden jeweils die Meldungen mit Verweisen auf dieEreignisse der einzelnen Dienste gespeichert.

17


Abbildung 2.4 zeigt die Ansicht einer Übersicht mit den standardmäßig installierten Daemonsvon Zenoss. In der ersten Spalte steht Name des Daemons. Die zweite Spalte beinhaltet dieAngabe über die Prozess ID (PID) des jeweiligen Daemons. In der dritten und vierten Spaltesteht eine Verlinkung zu den Logfiles und den Konfigurationsdateien der Daemons. DieseDateien können dabei betrachtet und die Konfigurationsdatei zusätzlich bearbeitet werden. Inder fünften Spalte wird der aktuelle Status dargestellt. Die sechste Spalte bietet die Möglichkeitdie einzelnen Daemons über einen Button neuzustarten beziehungsweise zu stoppen.

Abbildung 2.4: Standardmäßig installierte Daemons von Zenoss

18

Kapitel 3

Installation und Konfiguration

In diesem Kapitel wird die Installation und Konfiguration eines Zenoss-Servers beschrieben. Diefolgenden Rechner dienten bei der Erstellung dieser Arbeit als Hosts. Der Zenoss-Server wurdeauf einem handelsüblichen Notebook installiert. Mit diesem wurden anschließend die anderenHosts überwacht. Auf den zu überwachenden Hosts wurden verschiedene Softwarepakete undProgramme installiert, welche für die fehlerfreie Funktion von SNMP benötigt werden.

Zenoss Server Host 1 Host 2Hardware IBM Think Pad T41 Think Pad X60s Bluechip S14YCPU Intel Centrino Intel Core Duo Intel Centrino Duo

@ 1,7 GHz @ 1,66GHz @ 1,6 GHzRAM 1GB 2GB 2GBBS Ubuntu 9.10 Server Ubuntu 9.10 Windows XP SP3Software Zenoss Core SNMP WMI

Tabelle 3.1: Verwendete Hosts

Die Tabelle 3.1 gibt einen Überblick über die Hardwarezusammenstellung der verwendetenGeräte. Bei allen drei Geräten handelt es sich um handelsübliche Notebooks, welche nichtausschließlich für dieses Projekt genutzt wurden, sondern täglich zusätzlich für verschiedeneAufgaben genutzt wurden. Aus diesem Grund war auf beiden Host-Notebooks zusätzlicheSoftware installiert, welche allerdings keinen Einfluss auf die Durchführung dieses Projekteshat.

3.1 Installation

Wie in Tabelle 3.1 aufgezeigt, diente ein handelsübliches Notebook als Hardwaregrundlage fürden Zenoss-Server. Als Betriebssystem dient in diesem Projekt Ubuntu 9.10 Server. Bei derInstallation wurde der Linux, Apache, MySQL and PHP (LAMP) Server mit ausgewählt. Da

19

Kapitel 3 Installation und Konfiguration 3.1 Installation

auf die Installation des X-Servers verzichtet wurde, wurde auf dem Zenoss-Server zusätzlichder Secure Shell (SSH)-Daemon installiert.

In Tabelle 3.2 wird ein Überblick über die Softwarepakete (Programme oder Bibliotheken)gegeben, welche für die fehlerfreie Installation von Zenoss zusätzlich benötigt werden. Zudemwird zu jedem Paket eine Beschreibung gegeben, für was die Pakete benötigt werden.

Paketname Beschreibungbuild-essential Paket zum Erzeugen von Debian-Paketenlibmysqlclient15-dev Entwicklungsbibliotheken und Header Files für MySQLpython-dev Header-Dateien, statische Bibliotheken und eine Entwicklungsum-

gebung für Python

Tabelle 3.2: Zusätzlich benötigte Pakete

Diese Softwarepakete wurden mit Hilfe des Paketmanagers apt-get auf dem Server installiert.Das build-essential Paket wird zum erzeugen von Debian-Paketen benötigt. Das Paketlibmysqlclient15-dev stellt Entwicklungsbibliotheken und Headerfiles für MySQL zurVerfügung. Im Paket python-dev werden zusätzliche Headerfiles, statische Bibliothekenund eine Entwicklungsumgebung für Python bereitgestellt.

Für die Installation von Zenoss stehen drei Varianten zur Verfügung. Die erste ist eine Instal-lation als virtuelle Applikation. Da in diesem Projekt ein dedizierter Server für Zenoss zurVerfügung steht, wurde diese Methode nicht ausgewählt. Bei den anderen beiden Methoden han-delt es sich um die Installation der aus den Binaries oder von den Sources. Auf der Homepagevon Zenoss1 steht bereits ein Debian-Paket (*.deb) zur Installation auf einem Ubuntu Serverzur Verfügung. Des weiteren kann Zenoss unter Ubuntu bereits über die Repositories installiertwerden. Der Vorteil hierbei ist, dass apt2 alle Abhängigkeiten automatisch erkennt und allebenötigten Pakete automatisch nachinstalliert. Aus diesem Grund wurde die Installation ausden Repositories gewählt. Zudem kann diese Installation komplett ohne graphische Oberflä-che ausgeführt werden. Dies ist nötig, da auf dem Server kein X Window System installiertwurde.

Um Zenoss aus den Repositories installieren zu können, muss zunächst die Liste der Quell-dateien angepasst werden. Dabei muss lediglich die Homepage von Zenoss bekannt gemachtwerden. Dies wird durch folgenden Eintrag in die /etc/apt/sources.list realisiert:

1 # Zenoss repository2 deb http://dev.zenoss.org/deb main stable

Anschließend müssen die Quellen aktualisiert werden. Die Aktualisierung der Quellen wirdmit folgendem Befehl ausgeführt:

1http://www.zenoss.com2Das Advanced Packaging Tool (APT) ist ein Paketverwaltungssystem, das im Bereich des Betriebssystems

Debian GNU/Linux entstanden ist.

20

http://www.zenoss.com

http://www.zenoss.com

Kapitel 3 Installation und Konfiguration 3.2 Konfiguration der Server

1 apt-get update

Durch diesen Befehl wird zunächst die Datei /etc/apt/sources.list eingelesen unddanach werden die Informationen über alle verfügbaren Softwarepakete und Aktualisierungengeladen und gespeichert .Nachdem die Quellen aktualisiert wurden, kann mit folgendem geprüftwerden, ob das Zenoss-Paket verfügbar ist:

1 apt-cache search zenoss-stack

Die Rückgabe der folgenden Meldung besagt dabei, dass das gesuchte Paket zenoss-stackmit allen Abhängigkeiten in den aktuell verfügbaren Quellen vorhanden ist und installiertwerden kann.

1 zenoss-stack - Zenoss Stack with all requirements.

Da das gewünschte Paket in den Quellen verfügbar ist, kann dieses mit dem folgenden Befehlüber apt installiert werden.

1 sudo apt-get install zenoss-stack

Nach erfolgreicher Installation kann Zenoss mit dem Befehl1 /etc/init.d/zenoss-stack start

gestartet werden. Der entsprechende Eintrag in der /etc/init.d, damit der Server beijedem Neustart automatisch startet, ist bereits während der Installation aus den Repositoriesgesetzt wurden.

3.2 Konfiguration der Server

In diesem Abschnitt wird beschrieben, wie zu überwachende Server konfiguriert werden können.Zenoss bietet eine Vielzahl von Möglichkeiten, um verschiedene Server mit unterschiedlichenBetriebssystemen zu überwachen. All diese Möglichkeiten zu betrachten sprengt den Rahmendieses Projektes. Aus diesem Grund wird hier lediglich auf die Grundkonfiguration eingegangen.Als Protokoll für die Überwachung wurde hierbei SNMP und WMI gewählt. Die Betriebs-systeme der zu überwachenden Server sind Ubuntu 9.10 und Windows XP SP3 (siehe Tabelle3.1 ). Beide Hosts werden dabei mit SNMP überwacht. Zusätzlich wird der Windows-Host mitWMI überwacht.

21


3.2.1 SNMP Installation und Konfiguration unter Linux

Um ein Linux-System mit SNMP überwachen zu können, muss der SNMP-Daemon snmpdinstalliert werden. Dieser Daemon liegt bei den meisten Distributionen bereits in den Reposi-tories, sodass er bequem installiert werden kann.

Auch die Installation unter Ubuntu kann aus den Repositories erfolgen. Dieser Weg ist auch zuempfehlen, da auf diesem Weg alle Abhängigkeiten geprüft werden und eventuell benötigteSoftwarepakete automatisch nachinstalliert werden. Mit dem Befehl

1 apt-get install snmpd

wird dieser Daemon unter Debian/Ubuntu mit Hilfe des Paketmanagers apt-get installiert.Die Konfiguration dieses Daemons findet im Anschluss an die Installation durch bearbeiten derKonfigurationsdatei /etc/snmp/snmpd.conf statt. Im Zuge dieses Projektes wurde unterUbuntu 9.10 die Version 5.4.1 des snmpd gewählt.

Zuerst muss die Konfigurationsdatei /etc/snmp/snmpd.conf angepasst werden. In dervorliegenden Projektarbeit wird lediglich die Grundkonfiguration von SNMP erläutert. Anhanddieser Grundkonfiguration ist es möglich, vom Zenoss-Server auf den zu überwachendenUbuntu-Host mit SNMP-V1 zugreifen zu können und verschiedene Werte abzufragen. DasListing 3.1 zeigt eine minimale /etc/snmp/snmpd.conf um dieses Ziel verfolgen zukönnen.

1 com2sec readonly 192.168.56.2 mycomm2 #com2sec readwrite 192.168.56.2 mycomm3

4 group MyROGroup v1 readonly5 #group MyRWGroup v1 readwrite6

7 view all included .1 808 #view system included .iso.org.dod.internet.mgmt.mib-2.system9

10 # context sec.model sec.level match read write notif11 access MyROGroup "" any noauth exact all none none12 #access MyRWGroup "" any noauth exact all all none13

14 syslocation worldwide15 syscontact Root <root@localhost> (configure /etc/snmp/snmpd.local.conf)

Listing 3.1: "Minimalkonfiguration der snmpd.conf Datei"

In der ersten Zeile wird dabei festgelegt, dass vom der IP 192.168.56.2 und der Communitymycomm lediglich gelesen werden kann. Um Schreibzugriff zu bekommen, muss der Wertreadonly in readwrite geändert werden(siehe Zeile 2). Die vierte Zeile legt fest, zu wel-cher Gruppe readonly gehört. In dieser Gruppe werden dann die Lese- und Schreibberechti-gungen festgelegt (siehe Zeile 10). Eine Beispielkonfiguration der Gruppe mit Schreibberechti-gungen wird in Zeile 11 aufgezeigt. In den Zeilen 14 und 15 werden variablen gesetzt, welche

22


Über SNMP abgefragt werden können. Diese beiden Zeilen sind für eine Grundkonfigurationjedoch nicht notwendig.

Im nächsten Schritt müssen die Startparameter für SNMP gesetzt werden. Hierfür wird dieDatei /etc/default/snmpd, wie in Listing 3.2 aufgezeigt, bearbeitet.

1 # This file controls the activity of snmpd and snmptrapd2

3 # MIB directories. /usr/share/snmp/mibs is the default, but4 # including it here avoids some strange problems.5 export MIBDIRS=/usr/share/snmp/mibs6

7 # snmpd control (yes means start daemon).8 SNMPDRUN=yes9

10 # snmpd options (use syslog, close stdin/out/err).11 #SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid

127.0.0.1’12 SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid13 -c /etc/snmp/snmpd.conf’14

15

16 # snmptrapd control (yes means start daemon). As of net-snmp version17 # 5.0, master agentx support must be enabled in snmpd before snmptrapd18 # can be run. See snmpd.conf(5) for how to do this.19 TRAPDRUN=no20

21 # snmptrapd options (use syslog).22 TRAPDOPTS=’-Lsd -p /var/run/snmptrapd.pid’23

24 # create symlink on Debian legacy location to official RFC path25 SNMPDCOMPAT=yes

Listing 3.2: "Minimalkonfiguration der snmpd Datei"

Zeile 12 des Listings 3.2 zeigt die standardmäßige Konfiguration. Bei dieser wird lediglich aufdem Loop-Interface 127.0.0.1 eine SNMP-Abfrage beantwortet. Damit auch von anderenInterfaces SNMP-Anfragen beantwortet werden können, wird aus dieser Zeile die Loop-Adresseentfernt und dafür die entsprechende Konfigurationsdatei /etc/snmp/snmpd.conf mitdem Schalter -c aufgerufen.

Nachdem diese Änderungen vorgenommen wurden, muss der SNMP Daemon (neu-) gestartetwerden. Ein Neustart wird mit dem Befehl

1 /etc/init.d/snmpd restart

ausgeführt. Für den Fall, dass der Daemon noch nicht läuft, muss er mit dem Befehl1 /etc/init.d/snmpd start

23


gestartet werden.

3.2.2 WMI Installation und Konfiguration unter Windows XP

Unter Windows gibt es ein weiteres Protokoll, um Hosts überwachen zu können. Das WMIist bei den meisten Windows Versionen bereits in den Komponenten vorhanden. Lediglichdie Auswahl des Protokolls sowie die anschließende Installation und Konfiguration mussdurchgeführt werden.

Um WMI unter Windows XP zu installieren, muss in der Systemsteuerung der Menüpunkt“Software” ausgewählt werden. Dabei öffnet sich ein Fenster (siehe Abbildung 3.1), in welchemalle zusätzlich installierten Programme angezeigt werden.

Abbildung 3.1: Systemsteuerung: Software

In der Menüleiste auf der Linken Seite des Fensters steht der Punkt “Windows-Komponentenhinzufügen/entfernen”. nachdem dieser ausgewählt wurde, öffnet sich ein weiteres Fenster. Indiesem Fenster (“Assistent für Windows-Komponenten”, siehe Abbildung 3.2) muss der Punkt“Verwaltungs- und Überwachungsprogramme” markiert werden.

24


Abbildung 3.2: Assistent für Windowskomponenten

Anschließend wird der Button “Details” ausgewählt. Dabei öffnet sich ein weiteres Fenster mitdem Namen “Verwaltungs- und Überwachungsprogramme” (siehe Abbildung 3.3).

25


Abbildung 3.3: Detailansicht der Verwaltungs- und Überwachungsprogramme

In diesem können die Protokolle SNMP beziehungsweise WMI ausgewählt werden. Im Zugedieses Projektes wurden beide Pakete ausgewählt, auch wenn explizit nur auf die Konfigurationvon WMI eingegangen wird.

26

Kapitel 4

Management

In diesem Kapitel wird ein Überblick darüber gegeben, wie verschiedene Server mittels Zenossüberwacht werden können. Da es den Rahmen des Projektes sprengt, wenn alle Funktionenbeschrieben würden, liegt das Hauptaugenmerk hierbei auf einer Default-Konfiguration. Wiebereits in Kapitel 3 erwähnt, wird ein Ubuntu- und ein Windows-Server überwacht.

4.1 Überwachung von Servern

Nach erfolgreicher Installation von Zenoss kann das Webfrontend über einen Browser aufge-rufen werden. Wie bereits in Kapitel 2.2 beschrieben, werden offiziell von Zenoss nicht alleBrowser unterstützt. Eine vollständige Liste der unterstützten Browser ist auf der Homepagevon Zenoss einzusehen. Um das Webfrontend aufzurufen muss die IP-Adresse beziehungs-weise der DNS-Name des Zenoss-Servers in die Adressleiste des Browsers eingefügt werden.Standardmäßig lauscht der Zenoss-Server auf Port 8080. Da der Standard HTTP-Port aufPort 80 liegt, muss dieser mit übergeben werden. Bei der Erstanmeldung wird der Benutzeraufgefordert ein Konto anzulegen. Die Konfigurationsroutine dabei ist sehr einfach und nüch-tern gehalten. Nachdem diese zwei Schritte durchgeführt wurden, können vom Benutzer dieverschiedenen Server hinzugefügt werden. Im Zuge dieses Projektes wurden diese Schrittejedoch übersprungen. Wie die verschiedenen Server später hinzugefügt werden können ist inden Abschnitten 4.1.1 (Serverüberwachung mit SNMP) und 4.1.2 (Serverüberwachung mitWMI) beschrieben.

27

http://www.zenoss.org

http://www.zenoss.org

Kapitel 4 Management 4.1 Überwachung von Servern

4.1.1 Serverüberwachung mit SNMP

Um einen neuen Server in Zenoss hinzuzufügen, muss im Zenoss-Webinterface in der Menü-leiste der Punkt “Add Device” ausgewählt werden (diese Menüleiste ist nicht in Abbildung4.1 abgebildet). Danach öffnet sich eine Seite, auf der Eigenschaften des zu überwachendenServers, sowie Abhängigkeiten und Attribute eingegeben werden können.

Abbildung 4.1: Hinzufügen von Servern

In Abbildung 4.1 ist diese Seite dargestellt. Im Feld “Device Name” wird die IP-Adresseoder der DNS-Name des zu überwachenden Servers eingegeben. Im Feld “Device ClassPath” kann die Klasse des Gerätes1 eingetragen werden. Das Feld “Collector” definiert dieNetzwerkkarte, über welche der Server erreichbar ist. Unter dem Punkt “Attributes” kön-nen verschiedene SNMP-Einstellungen vorgenommen werden. Falls die Geräte nicht aufden Default-SNMP-Port 161 eingestellt sind, kann auch dies hier geändert werden. Unterdem Punkt “Production State” kann eingestellt werden, in welchem Status sich der Serverbefindet. Dies ist insbesondere dann sinnvoll, wenn neue Server, welche noch nicht im Pro-duktivbetrieb sind, hinzugefügt werden. Diese können auf den Status “Test” gesetzt wer-den. Im Abschnitt “Relations” können Hardware-Eigenschaften der Geräte beziehungswei-se Betriebssystem-Eigenschaften hinzugefügt werden. Nachdem alle Einstellungen vorge-nommen wurden, wird mit Betätigung des “Add Device” -Buttons das neue Gerät hinzu-gefügt. Zudem öffnet sich die Statusseite, auf welcher der Status des neuen Gerätes angezeigtwird.

1Im vorliegenden Szenario handelt es sich jeweils um Server, alternativ können auch andere Geräte wie Router,unterbrechungsfreie Stromversorgung (USV)s oder Switches mit Zenoss überwacht werden.

28

Kapitel 4 Management 4.1 Überwachung von Servern

4.1.2 Serverüberwachung mit WMI

Die Konfiguration und Installation von WMI wurde bereits in Abschnitt 3.2.2 beschrieben.In diesem Abschnitt wird die Konfiguration der zProperties des Zenoss-Servers aufgezeigt,welche nötig ist, um einen Windowsserver via WMI überwachen zu können.

Zuerst muss ein neuer Host (Device) hinzugefügt werden. Dieser Schritt ist bei allen Gerätengleich, egal ob das Gerät mit SNMP oder mit WMI überwacht wird. Wie bereits in Abschnitt4.1.1 beschrieben, muss dafür im Frontend des Zenoss-Servers auf der linken Seite der Punkt“Add Device” ausgewählt werden. Daraufhin öffnet sich ein Eingabefenster, in diesem müssenmindestens der Device Name2, und die SNMP-Community eingegeben werden. Die Bestätigungund Speicherung des neuen Gerätes erfolgt durch die Betätigung des “Add Device” - Buttons.Nachdem Das Gerät vom Server gefunden wurde, erfolgt die WMI-Konfiguration. Dazu wirddas Gerät markiert und im Menü unter more der Punkt zProperties ausgewählt. Am Ende derSeite (siehe Abbildung 4.2) müssen folgende Angaben vorgenommen werden:

• zWinEventLog auf true setzen

• Das Windows-Benutzerpasswort in das Feld zWinPassword eintragen

• Benutzername (Dieser benötigt Administrative Rechte auf dem Windowsserver) in dasFeld zWinUser eintragen

– .\user bei lokalen Useraccounts

– DOMAIN\user für Domain Useraccounts

• zWMIMonitorIgnore auf false setzen

Abbildung 4.2: Konfiguration von WMI

Nachdem alle Änderungen vorgenommen wurden, müssen diese bestätigt und gespeichertwerden. Um diese wirksam zu machen, muss die Konfigurationsdatei vom Zenoss-Serverneu eingelesen werden. Dafür wird unter dem Menüpunkt Manage der Punkt Model Deviceausgewählt.

2Als Device Name kann entweder der DNS-Name oder die IP-Adresse des zu überwachenden Servers eingegebenwerden.

29

Kapitel 5

Das Userinterface

Dieser Abschnitt gibt einen Überblick über ein paar ausgewählte Funktionen, welche mitZenoss ausgeführt werden können. Bei diesen Funktionen handelt es sich um Standardtools,welche von Zenoss mitgeliefert werden. Diese Auswahl dient dabei nur als Überblick. Jedeeinzelne dieser ausgewählten Funktion genau zu erläutern sprengt den Rahmen dieses Projektes.Als Gliederung dieses Kapitels wurde zur besseren Übersicht teilweise die Gliederung desMenüs von Zenoss gewählt.

5.1 Main Views

Unter dem Abschnitt Main Views im Webfrontend von Zenoss gibt es die folgenden vierEinträge:

• Dashboard

• Event Console

• Device List

• Network Map

Das Dashboard ist dabei standardmäßig der Startbildschirm von Zenoss. Auf diesen kann eineKarte (ein Google Maps Plugin) eingerichtet werden, worauf der Standort der zu überwachendenGeräte eingetragen werden kann. Dies ist vor allem bei Dienstleistern sinnvoll, die ein Gebietbetreuen, welches sich beispielsweise über einen Stadtteil oder eine ganze Stadt streckt.

Falls ein Gerät oder Dienst ausfällt oder nicht mehr verfügbar ist wird von Zenoss ein Ereignis(Event) generiert. Diese Events können auch für die Über oder Unterschreitung definierterGrenzwerte generiert werden. Ein Weg, ein solches Ereignis anzuzeigen ist die Darstellungin der Event Console. Abbildung 5.1 zeigt einen Ausschnitt, in dem vier Meldungen überaufgetretene Ereignisse aufgezeigt werden. Da die Skripte zum Abfragen der Stati der Geräte ineinem bestimmten Zeitintervall ausgeführt werden, wird diese Tabelle in unangemessen kurzer

30

Kapitel 5 Das Userinterface 5.1 Main Views

Abbildung 5.1: Event Konsole

Zeit voll werden, falls beispielsweise ein Gerät komplett ausfällt. Aus diesem Grund gibt esfür jedes Ereignis nur einen Eintrag. In der achten Spalte wird die Anzahl der Vorfälle diesesEreignisses angezeigt. Die siebente Spalte zeigt die Zeit, in welcher das Ereignis als letztesaufgetreten ist. Zudem ist es möglich, das Zenoss benutzerdefinierte Befehle oder Skripteausführt. Die Benachrichtigung über ein Ereignis kann auch via Mail, über einen Pager oderüber SMS geschehen.

Abbildung 5.2 zeigt eine Ausgabe unter dem Abschnitt Device List. In dieser Ausgabe werdenalle zu überwachenden Geräte, sowie ein paar grundlegende Daten zu diesen, wie zum Beispieldie IP-Adresse und die Geräteklasse zu der das jeweilige Gerät hinzugefügt wurde, angezeigt.In dieser Ansicht können einzelne Geräte oder mehrere Geräte gleichzeitig ausgewählt werden,um bestimmte Aktionen durchzuführen. In der letzten Spalte dieser Tabelle wird eine Zusam-menfassung über die Ereignismeldungen aufgezeigt. Diese Zusammenfassung erinnert stark andas Ampelprinzip von Nagios, ist aber bei genauer Betrachtung bedeutend umfangreicher. Indieser Zusammenfassung wird farblich und durch Ziffern darauf aufmerksam gemacht, ob esFehlermeldungen am System gibt oder nicht.

Abbildung 5.2: Device List

Den letzten Punkt unter der Main View stellt die Network Map dar. In dieser Ansicht könneneinzelne Netze grafisch dargestellt werden. Abbildung 5.3 zeigt diese grafische Darstellung fürdas Subnetz dieses Projektes. In dieser Ausgabe kann zusätzlich zum Subnetz ein Filter fürbestimmte Geräte gesetzt werden. Diese Ansicht ist besonders hilfreich, um zum Beispiel zusehen welche Server von einem Ausfall eines Netzkoppelelements betroffen sind.

31

Kapitel 5 Das Userinterface 5.2 Event Classes

Abbildung 5.3: Netzwerkkarte

5.2 Event Classes

In Zenoss werden Events in Klassen (sogenannte Event Classes) unterteilt. Beim Eintreten ei-nes Ereignisses wird der sogenannte “event class key” abgefragt. Anhand von diesem Schlüsselwird die Einteilung des Ereignisses in die verschiedenen Klassen vorgenommen.

Event Classes können durch den Administrator angelegt oder gelöscht werden. Zudem könnendie verschiedenen “event class keys” durch den Administrator verändert werden. Dadurch istes möglich, dass bei einem Ereignis mehrere Events gesetzt ausgelöst werden. Die Strukturdieser Klassen ist hierarchisch aufgebaut.

Abbildung 5.4: Die Event Klassen

In Abbildung 5.4 ist ein Beispiel für diese Klassen aufgezeigt. In der ersten Spalte steht jeweilsder Name der Klasse und die Spalte “SubClasses” zeigt auf, wie viele Klassen sich unter derKlasse befinden. In der letzten Spalte steht die Anzahl der Ereignisse der jeweiligen Klasseinklusive all ihrer Unterklassen.

32

Kapitel 5 Das Userinterface 5.2 Event Classes

Auch alle zu überwachenden Geräte werden in verschiedene, hierarchisch aufgebaute Klassenunterteilt. Abbildung 5.5 zeigt die Geräteklassen auf oberster Ebene. Wie bereits beschriebenwurden in diesem Projekt zwei Geräte überwacht. Zum einen ein Windows-Server und zumanderen ein auf Ubuntu basierender Server. In Abbildung 5.5 ist zu erkennen, dass in der Zeile“Server” bei der Anzahl der Geräte dieser Klasse in der dritten Spalte eine zwei steht. Dies istdarauf zurückzuführen, dass bei der Konfiguration dieser beiden Geräte der Windows-Server indie Klasse “/Server/Windows” und der Ubuntu-Server in die Klasse “/Server/Linux” verschobenwurde.

Abbildung 5.5: Ansicht der Geräteklassen des Zenoss-Servers

Sowohl die Prozesse als auch die zu überwachenden Dienste können auf diese Art und Weisedargestellt werden. Der Vorteil dieses Systems ist zum einen, das sofort klar ist, wo beziehungs-weise wie die verschiedenen Daten auf dem Server gespeichert werden und zum anderen, dassdie Darstellung übersichtlich ist. Die Benutzung dieser Struktur ist sinnvoll, da die Ordnerstruk-turen der meisten Betriebssysteme ähnlich sind.

33

Kapitel 6

Monitoring

Neben den in den Abschnitten 5.1 und 5.2 aufgezeigten Möglichkeiten Ereignisse aufzeigenzu lassen oder Fehlerbehandlungen beziehungsweise Alarmmeldungen generieren zu lassen,bietet Zenoss die Möglichkeit der grafischen Hardwareüberwachung der Server. Inhalt diesesAbschnittes ist es, die verschiedenen Monitore aufzuzeigen und deren Inhalte zu erläutern. DieUnterteilung der Zeitachse ist bei allen Monitoren gleich und wird global vorgenommen. DieDaten der einzelnen Monitore werden mittels SNMP oder WMI von dem zu überwachendenServern auf den Zenoss-Server übertragen. Zenoss speichert diese Daten anschließend in einerRRD-Datenbank. Da die Daten in einer RRD-Datenbank gespeichert werden, ist eine grafischeDarstellung danach in einem Diagramm problemlos möglich.

6.1 CPU Auslastung

Abbildung 6.1: Statistische Anzeige der CPU Auslastung

Abbildung 6.1 zeigt ein Beispiel der CPU-Überwachung. Im oberen Teil der Abbildung wirddie CPU-Auslastung der letzten 16 Stunden grafisch dargestellt. Zu sehen ist, dass der Serverzwischen 0 und 7 Uhr eine CPU-Auslastung von rund 60 % hatte und die restliche Zeit lediglich10 % der maximal verfügbaren CPU-Zeit in Anspruch genommen wurden.

34

Kapitel 6 Monitoring 6.2 Festplattenüberwachung

Im unteren Teil der Abbildung wird zusätzlich angezeigt, wie viele Prozesse die verschiedenenBenutzer derzeit, durchschnittlich und maximal haben. Die 90 % Markierung wird hierbeidurch eine rote gerade in der Grafik dargestellt.

6.2 Festplattenüberwachung

Für die Überwachung der Festplatten bietet Zenoss standardmäßig zwei Monitore. Zumeinen wird die Auslastung der Festplatte aufgezeigt und zum anderen die Input Output (IO)-Aktivitäten. Abbildung 6.2 zeigt die grafische Ausgabe einer Festplattenauslastung. Im oberenTeil wird dabei prozentual die Auslastung der Festplatte grafisch dargestellt. In der Zeit von 2bis 5 Uhr wurde der Grenzwert von 90 % überschritten. Zudem wurde die Festplatte zwischen8 und 12 Uhr benutzt. In der restlichen Zeit fanden Zugriffe statt, welche die Festplatte zu mehrals 5 % ausgelastet haben.

Abbildung 6.2: Grafische Darstellung der Festplattenauslastung

Im Unteren Teil der Abbildung wird die durchschnittliche Auslastung, die derzeitige und diemaximale Auslastung in Prozent angezeigt.

Zusätzlich zur Festplattenauslastung wird die IO-Aktivität angezeigt. Abbildung 6.3 zeigt dieseIO-Aktivitäten, welche synchron zu der Festplattenauslastung aus Abbildung 6.2 aufgezeichnetwurden. In dieser Grafik wird die Anzahl der IO-Operationen pro Sekunde aufgezeigt. ImVergleich zur Abbildung 6.2 ist zu erkennen, dass in der Zeit, wo die Festplattenauslastung beiüber 70 % lag circa 200 Leseoperationen ausgeführt wurden.

Neben der grafischen Aufbereitung der IO-Aktivitäten der Festplatte wird im unteren Teilder Abbildung die Anzahl der derzeitigen, der maximalen und der durchschnittlichen Lese-beziehungsweise Schreiboperationen aufgezeigt. Zudem wird jeweils die Summe aus diesenbeiden aufgezeigt.

In Abbildung 6.4 wird die Anzahl der Prozesse aufgezeigt, welche sich in der Disk Queue(Warteschlange) befinden. Bei dieser handelt es sich um eine Warteschlange, in der sich

35

Kapitel 6 Monitoring 6.3 Speicherüberwachung

Abbildung 6.3: Grafische Darstellung der Festplatten IO Aktivitäten

Prozesse befinden, welche auf Festplattenzugriff warten. Werte, die größer als zwei sind, sinddabei problematisch.

Abbildung 6.4: Grafische Darstellung der Festplatten Queue

Im unteren Teil der Abbildung wird wieder die durchschnittliche, die aktuelle und die maximaleAnzahl der wartenden Anfragen aufgezeigt. Dabei ist zu erkennen, dass maximal zwei Lese-anfragen in einer Queue standen.

6.3 Speicherüberwachung

Bei fast allen Servern ist neben der CPU-Auslastung die Speicherauslastung ein wichtigesKriterium für einen fehlerfreien Betrieb. Falls es zu einem Speicherüberlauf kommt brichtdie Performance zusammen, da ein Großteil der Zeit damit verbraucht wird, einzelne Pa-ges1 beispielsweise von einer SWAP-Partition in den Hauptspeicher zu kopieren und zurück.Falls ein solches Ereignis nur zu bestimmten Tages oder Nachtzeiten auftritt, ist es für einen

1Mit Pages sind einzelne Speicherbereiche gemeint, welche im Arbeitsspeicher vorgehalten werden. Wenn derCache ausgelastet ist, werden einzelne Pages ausgelagert.

36


Administrator nicht möglich die Ursache des Problems einzugrenzen, beziehungsweise aufzu-decken. Aus diesem Grund bietet Zenoss auch eine ausführliche Überwachung der Speicher-auslastung der einzelnen Server.

Abbildung 6.5: Darstellung der Anzahl der Speicher Pages im Bezug auf die Zeit

Abbildung 6.5 zeigt im oberen Teil eine grafische Darstellung der Anzahl der benutztenSpeicherpages zu den jeweiligen Uhrzeiten. Es ist zu erkennen, dass in der Zeit von 8 bis 12Uhr 150 bis 200 Pages benutzt wurden. Ein Vergleich mit den Ergebnissen der Abbildungen6.2 und 6.3 ist zu sehen, dass zur gleichen Zeit eine große Anzahl IO-Operationen und eineFestplattenauslastung von über 60 % stattgefunden hat. Dieser Fakt lässt in erster Linie daraufschließen, dass der Server zu dieser Zeit allgemein ausgelastet war. In Abbildung 6.1 istallerdings zu dieser Zeit kein Ausschlag des Graphen zu verzeichnen. Wie zu erkennen ist,können anhand solcher Grafiken Engpässe der zu Verfügung stehenden Hardware erkannt undgegebenenfalls beseitigt werden.

Wie auch bei den vorherigen Grafiken ist auch bei dieser im unteren Teil eine Tabelle welcheAufschluss über die Eckdaten wie durchschnittliche, maximale und derzeitige Auslastung derPages. In dieser Tabelle sind die Pages zusätzlich in Output, Input und die Summe aus beidenunterteilt.

Abbildung 6.6 zeigt eine weitere Grafik zur Darstellung der Speicherauslastung. In dieserGrafik werden allerdings nicht wie in Abbildung 6.5 die Speicherpages dargestellt, sonderndie Auslastung des kompletten Speichers. Eine solche Grafik ist Administratoren schon vomTaskmanager aus Windows oder der grafischen Systemüberwachung2 unter Linux bekannt.

In Abbildung 6.6 ist der gesamte verfügbare Arbeitsspeicher hellgrün dargestellt. Zudem wirddurch eine schwarze Linie, welche bei vier GByte parallel zur X-Achse eingezeichnet ist, diephysikalische Obergrenze dargestellt. Der durchgängig etwas dunkler eingefärbte Bereich imunteren Teil der Grafik zeigt ein Abbild des benutzten Speichers auf. Anhand dieser Grafik

2Beispielsweise das “Systemüberwachungstool” der gnome bietet dem Anwender eine solche grafische Darstel-lung

37


ist zu erkennen, dass bis 9 Uhr lediglich ein viertel des verfügbaren Arbeitsspeichers benutztwurde (circa ein GByte). Ab neun Uhr wurden dann etwa 500 MByte mehr, insgesamt circa 1,5GByte benutzt.

Abbildung 6.6: grafische Darstellung der Speicherauslastung

Im unteren Teil von Abbildung 6.6 ist der verfügbare, der durchschnittliche und der aktuelleWert des verfügbaren, des benutzten und des physikalischen Arbeitsspeichers angegeben.

38

Kapitel 7

Management

Wie bereits in den den Vorherigen Kapiteln beschrieben bietet Zenoss eine Vielzahl vonMöglichkeiten zur Überwachung beziehungsweise zum Monitoring von Servern und anderenGeräten. Eine Vielzahl dieser Funktionen erleichtert nicht nur die Fehlersuche und somit denArbeitsalltag von Administratoren, sondern auch die Arbeit von anderen Mitarbeitern oder An-wendern1. Aus diesem Grund ist es notwendig Benutzer2 mit unterschiedlichen Zugriffsrechtenanlegen zu können. Zenoss bietet auch diese Möglichkeit.

Abbildung 7.1: Ansicht der Anwenderverwaltung

Abbildung 7.1 zeigt das Fenster, in welchem Zugriffsrechte beziehungsweise unterschiedlicheRollen zu Anwendern hinzugefügt oder entfernt werden können. Standardmäßig gibt es dreivordefinierte Benutzer in Zenoss. Tabelle 7.1 zeigt einen Überblick über diese drei Benutzerund deren Aufgaben und Rechte.

1Mit Anwendern sind hier Benutzer gemeint, welche bestimmte Dienste von verschiedenen Geräten benutzen,allerdings nicht für die Administration zuständig sind

2Hier: Anwender die das Zenoss-Management-Tool benutzen

39

Kapitel 7 Management Kapitel 7 Management

Rolle Aufgaben RechteManager managed den Zenoss-Server als Administrative des Servers, ver-

gleichbar mit einem Serveradminis-trator

ZenManager administriert einzelne überwachteServer

volle Rechte auf “seine” Server

ZenUser überwacht Server nur Leserechte auf einzelne Server

Tabelle 7.1: Überblick vordefinierter Zenoss-Benutzer

Es ist unter anderem möglich einen Benutzer anzulegen, der lediglich die Rechte hat, umeinen bestimmten Server zu überwachen. Dies erlaubt diesem zum Beispiel ProzessorlastigeAnwendungen in einem Zeitfenster auszuführen, in dem der jeweilige Server keine anderenAnwendungen ausführt. Zudem ist es dadurch möglich beispielsweise ein Update oder einBackup zu einer Zeit vorzunehmen, in der kein User die betreffende Anwendung nutzt.

Zudem können auf diese Art verschiedene ZenManager angelegt werden. Das bedeutet, dassmit einem einzigen Zenoss-Server mehrere Serverfarms überwacht werden, es jedoch zu jederFarm einen anderen Administrator gibt. Dies spart zum einen Hardware, da nicht für jede Farmein dedizierter Server benötigt wird und zum anderen werden dadurch, dass jeder Zenmanagernur seine eigene Farm sieht und administrieren kann, die Rechte des jeweiligen gewahrt.

40

Kapitel 8

Schlusswort

8.1 Zusammenfassung

Die Installation und Konfiguration eines auf einer Open Source Software basierendes Manage-menttools zum überwachen verschiedener Geräte war Ziel dieses Projektes. In Kapitel 1 wurdenallgemeingültige Grundlagen erläutert, welche zum besseren Verständnis dieses Projektes not-wendig waren.

Kapitel 2 beschäftigt sich mit dem Netzwerkmanagementtool Zenoss. Dabei wurde insbesondereauf den Aufbau dieser Software eingegangen. Im Abschnitt 2.2 wurde dabei die Architekturvon Zenoss näher beleuchtet und insbesondere auf die drei Schichten der Grundstruktur diesesNetzwerkmanagementtools eingegangen.

Die Installation und eine Grundkonfiguration zum Überwachen eines Linux- und eines Windows-servers wurden im Kapitel 3 erklärt. Zudem wurde dabei auf die verschiedenen Protokolle,SNMP unter Linux und WMI unter Windows eingegangen. Ein weiterer Schwerpunkt dieses Ka-pitels stellt die Serverkonfiguration dar, welche benötigt wird, um mittels eines Zenoss-Serversdie unterschiedlichen Geräte überwachen zu können.

In Kapitel 7 wurden Grundlagen der Konfiguration des Zenoss-Servers erläutert, um verschie-dene Geräte mit Hilfe des SNMP oder WMI zu überwachen beziehungsweise zu managen.

Kapitel 5 beschäftigt sich insbesondere mit den verschiedenen Überwachungs- und Konfigurati-onsmethoden, welche vom Web-basierenden Frontend von Zenoss bereitgestellt werden. Zudemwurde dabei auf die verschiedenen Klassen dieses Netzwerkmanagementtools eingegangen undgrundlegende Ansichten genauer erläutert.

Die grafische Hardwareüberwachung mit Zenoss ist Bestandteil von Kapitel 6. Die unterschied-lichen Sichten auf einen Server, welcher mittels WMI überwacht wurde, wurden im Detailerläutert. Einige Vorteile einer solchen Überwachung von Hardware wurden dabei genauererläutert.

41

Kapitel 8 Schlusswort 8.2 Fazit

8.2 Fazit

Zenoss ist ein Netzwerkmanagementtool, welches auf verschiedenen Plattformen wie zumBeispiel Linux oder Windows läuft. Zudem ist es möglich Zenoss als Virtuelle Maschine zuinstallieren. Zenoss bietet eine Netzwerküberwachung über das WMI-Protokoll von Microsoftund über das plattformübergreifende SNMP-Protokoll.

Im Zuge dieses Projektes wurde Zenoss auf einem Laptop installiert. Dabei ist aufgefallen, dasswenn ein Systemadministrator bei den Basisfunktionen bleibt, er innerhalb weniger Stundenohne Vorkenntnisse ein Netzwerk mit verschiedenen Geräten durch Zenoss überwachen kann.Um jedoch die zahlreichen Zusatzfunktionen nutzen zu können, muss der Administrator How-To’s und Dokumentationen durcharbeiten und studieren. Die geringe Population von Zenossund die Tatsache, dass Zenoss in der Literatur bisher nur mit einem Werk vertreten ist, ist dabeiwenig hilfreich.

Zudem ist der strukturierte Aufbau des Webfrontend hilfreich und die Bedienung ist aufgrunddessen intuitiv. Die komplexen Einstellungs-, Template- und Plug-in-Funktionen machenZenoss zu einem Management-Tool, welches allerdings, um dessen kompletten Umfang nutzenzu können, einen geschulten Systemverwalter erfordert.

Im Vergleich zu Nagios bietet Zenoss die Möglichkeit nicht nur zu prüfen ob verschiedeneDienste oder Server aktiv sind, sondern mit Hilfe von Zenoss kann zusätzlich eine Performance-Messung oder eine Statistik zur Auswertung verschiedener Kenngrößen wie zum Beispiel derFestplattenauslastung oder der CPU-Auslastung erstellt werden.

Mit Zenoss ist ein weiteres Netzwerkmanagementtool auf dem Markt, welches sich nichthinter anderen Tools verstecken muss. Falls die Dokumentationen umfangreicher und leichterverständlich werden, ist es möglich, dass in Zukunft Zenoss ein ernstzunehmender Gegner fürandere Netzwerkmanagementtools wie Nagios oder Cacti sein wird.

42

Abbildungsverzeichnis

1.1 Simple Network Management Protokoll . . . . . . . . . . . . . . . . . . . . 9

2.1 Überblick über die Systemarchitektur von Zenoss . . . . . . . . . . . . . . . 152.2 Überblick über den Data Layer von Zenoss . . . . . . . . . . . . . . . . . . 162.3 Überblick über den Collection Layer . . . . . . . . . . . . . . . . . . . . . . 172.4 Standardmäßig installierte Daemons von Zenoss . . . . . . . . . . . . . . . . 18

3.1 Systemsteuerung: Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 Assistent für Windowskomponenten . . . . . . . . . . . . . . . . . . . . . . 253.3 Detailansicht der Verwaltungs- und Überwachungsprogramme . . . . . . . . 26

4.1 Hinzufügen von Servern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Konfiguration von WMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Event Konsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Device List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Netzwerkkarte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Die Event Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.5 Ansicht der Geräteklassen des Zenoss-Servers . . . . . . . . . . . . . . . . . 33

6.1 Statistische Anzeige der CPU Auslastung . . . . . . . . . . . . . . . . . . . 346.2 Grafische Darstellung der Festplattenauslastung . . . . . . . . . . . . . . . . 356.3 Grafische Darstellung der Festplatten IO Aktivitäten . . . . . . . . . . . . . . 366.4 Grafische Darstellung der Festplatten Queue . . . . . . . . . . . . . . . . . . 366.5 Darstellung der Anzahl der Speicher Pages im Bezug auf die Zeit . . . . . . . 376.6 grafische Darstellung der Speicherauslastung . . . . . . . . . . . . . . . . . 38

7.1 Ansicht der Anwenderverwaltung . . . . . . . . . . . . . . . . . . . . . . . 39

III

Tabellenverzeichnis

1.1 Vergleich zwischen OSI und TCP/IP . . . . . . . . . . . . . . . . . . . . . . 41.2 Adressklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Adressbereiche der Klassen A, B und C . . . . . . . . . . . . . . . . . . . . 51.4 Überblick über die Schichten des FCAPS . . . . . . . . . . . . . . . . . . . 61.5 SNMP-Pakate und deren Aufgaben . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Verwendete Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Zusätzlich benötigte Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.1 Überblick vordefinierter Zenoss-Benutzer . . . . . . . . . . . . . . . . . . . 40

IV

Glossar

Advance Research Projects Agency Networks

Es wurde ab 1962 unter Leitung der US-Luftwaffe entwickelt und ist der Vorläufer desheutigen Internets.VIII, 2

Asynchronous JavaScript and XML

Ajax (Asynchronous JavaScript and XML) bezeichnet ein Konzept der asynchronenDatenübertragung zwischen einem Browser und dem Server. Dieses ermöglicht es,HTTP-Anfragen durchzuführen während eine HTML-Seite angezeigt wird und die Seitezu verändern ohne sie komplett neu zu laden. Viele Anwendungen von AJAX werdendazu eingesetzt, im Webbrowser ein desktopähnliches Verhalten zu simulieren, wiebeispielsweise Popup-Fenster.VIII, 13

autonomes System

Ein autonomes System ist eine Ansammlung von IP-Netzen, welche als Einheit verwaltetwerden. Ein AS steht unter einer gemeinsamen Verwaltung, typischerweise von einemInternet Service Provider (ISP), einer Firma oder einer Universität.11

Host

Deutsch: Gastgeber - wird ein in einem Rechnernetz eingebundenes Betriebssystembezeichnet, das Server oder Clients beherbergt.3

IP-Adresse

Eine 32-Bit Adresse, die Hosts zugeordnet ist, welche TCP/IP verwenden. Jede Adressebesteht aus einem Netzwerkanteil, optional einer Subnetznummer und einem Hostanteil.Der Netzweranteil und Subnetzanteil werden zum Routen des Paketes genutzt. DerHostanteil wird genutzt, um einen individuellen Host im Netz oder Subnetz eindeutig zu

V

Glossar

bestimmen1.3, 4

MySQL

Der MySQL Server ist ein relationales Datenbankverwaltungssystem. Es ist als Open-Source-Software sowie als kommerzielle Enterpriseversion für verschiedene Betriebs-systeme verfügbar und bildet die Grundlage für viele dynamische Webauftritte.VIII, 14, 15, 18

Netzwerkmanagement

Das Netzwerkmanagement befasst sich mit der Verwaltung von Netzdiensten und Netz-komponenten. Es wird daher auch manchmal als Komponentenmanagement bezeichnet.Objekte des Netzwerkmanagements sind z.B. Leitungen, Übertragungs- und Vermittungs-einrichtungen (Switch, Bridges, Router) sowie Protokollinstanzen.5

Python

Python ist eine universelle höhere Programmiersprache. Python beansprucht bemerkens-werte Leistung mit sehr klarer Syntax und ihre standardmäßig enthaltene Bibliothekist groß und umfangreich. Es werden objektorientierte, aspektorientierte und funktiona-le Programmierung unterstützt. Wie andere dynamische Sprachen, wird Python oft alsSkriptsprache genutzt. Die Sprache hat ein offenes, gemeinschaftsbasiertes Entwicklungs-modell, gestützt durch die gemeinnützige Python Software Foundation, die de facto dieDefinition der Sprache in CPython, der Referenzumsetzung pflegt.13, 14

RRDTool

RRDtool ist ein Programm, mit dem zeitbezogene Messdaten gespeichert, zusammen-gefasst und visualisiert werden können. Das Programm wurde ursprünglich von TobiasOetiker entwickelt und unter der GNU GPL lizenziert. Durch die Veröffentlichung alsFreie Software haben inzwischen viele weitere Autoren neue Funktionalität und Feh-lerbehebungen beigesteuert. RRDtool ist als Quelltext und als ausführbares Programmfür viele Betriebssysteme verfügbar. Der Name RRD bezieht sich dabei auf die Artund Weise, in der Daten gespeichert werden. Beim Anlegen einer Datenbank, einer sogenannten „RRD-Datei“, wird genug Speicher für eine angegebene Zeitspanne angelegt.Nach dieser Zeitspanne wird die Datenbank nicht erweitert (die Datei wird nicht ver-größert), sondern die ältesten Daten werden überschrieben. Dieses „Reihum-Verfahren“

1Hier werden nur IPv4 Adressen betrachtet.

VI

Glossar

wird in der Informatik häufig mit Round-Robin bezeichnet.14

Server

Ein Computer, der den Netzwerkbenutzern im Rahmen eines Client-Server-ModellsDienste und Ressourcen zur gemeinsamen Nutzung zur Verfügung stellt.VII

Switch

Deutsch: Schalter, Weiche - ist ein Netzwerkgerät, welches Frames filtert, weiterleitetund Flutet. Dieses findet anhand der Ziel-Media-Access-Control (MAC)-Adresse jedesFrames statt. Der Switch arbeitet auf Layer 2 des Osi-Referenzmodells (siehe Abschnitt1.1).VI

unterbrechungsfreie Stromversorgung

Diese werden eingesetzt, um bei Störungen im Stromnetz die Stromversorgung kritischerelektrischer Lasten, in diesem Fall der Server, sicherzustellen.VIII, 27

X Window System

Das X Window System (auch: X Version 11, X11, X) ist ein Netzwerkprotokoll undeine Software, die Fenster auf Bitmap-Displays auf den meisten unixoiden Betriebs-systemen und OpenVMS ermöglicht. X11 wurde auf allen gebräuchlichen Betriebs-systemen implementiert.19

Z Object Publishing Environment

Zope ist ein objektorientierter, in der Programmiersprache Python geschriebener, frei-er Webanwendungs-Server mit offenem Quelltext. Zope stellt eine Plattform für dieRealisierung von Webanwendungen dar und eignet sich sehr gut zum Erstellen vondynamischen Webauftritten, da es prinzipiell darauf ausgerichtet ist, den Inhalt von derGestaltung der Website zu trennen. Der Quellcode von Zope wurde in Teilen 1996, diegesamte Applikation 1998 Open Source.VIII, 13

VII

Abkürzungsverzeichnis

AJAX Asynchronous JavaScript and XMLARIN American Registry for Internet NumbersARPANET Advance Research Projects Agency Networks

CIDR Classless Inter-Domain RoutingCMDB Configuration Management Database

FCAPS Fault, Configuration, Accounting, Performance, SecurityManagement

FOSS Free Open Source Software

GPL General Public License

IANA Internet Assigned Numbers AuthorityIETF Internet Engeneering Task ForceIO Input OutputIP Internet ProtokolISO International Organisation of StandardizationISP Internet Service ProviderITIL Information Technology Infrastructure Library

LAMP Linux, Apache, MySQL and PHP

MAC Media-Access-ControlMIB Management Information BaseMRTG Multi Router Traffic Grapher

NMS Netzwerk Management System

OAM Operation, Administration and MaintenanceOID Object IdentifierOSI Open System Interconnection

VIII

Abkürzungsverzeichnis

PDU Protocol Data UnitPID Prozess ID

RFC Request for CommentsRRD Round-Robin-Database

SNMP Simple Netzwork Management ProtocolSSH Secure Shell

TCP Transmission Control Protocol

UDP User Datagramm ProtocolUSV unterbrechungsfreie Stromversorgung

WMI Windows Management Instrumentations

ZOPE Z Object Publishing Environment

IX

Literaturverzeichnis

[Bad08] Michael Badger. Zenoss Core Network and System Monitoring. Packt Publishing,June 2008.

[Bar08] Wolfgang Barth. Nagios - System und Netzwerkmonitoring. Open source Press, 2.aktualisierte und erweiterte auflage edition, 2008.

[cac09] Cacti: The complete rrdtool-based graphig solution, December 2009.

[CFSD90] J. Case, M. Fedor, M. Schoffstall, and J. Davin. RFC1157 - Simple NetworkManagement Protocol (SNMP). RFC. Internet Engeneering Task Force, http://www.ietf.org/rfc, May 1990.

[FHLS01] W. Frisch, H.-J. Hölzel, F.-J. Lintermann, and U. Schaefer. Vernetzte IT-Systeme.Basiswissen IT-Berufe. H. Stam GmbH, 2001.

[FL06] V. Fuller and T. Li. RFC 4632 - Classless Inter-domain Routing (CIDR). RFC.Internet Engeneering Task Force, http://www.ietf.org/rfc, August 2006.(23.08.2009).

[Hun98] Craig Hunt. TCP/IP Netzwerk Administration. O’Reilly & Associates Inc., 1998.

[Odo05] Wendell Odom. CCNA INTRO Self-Study Exam Certification Guide. Cisco Press,January 2005.

[win02] Microsoft Windows XP Professional. Original Microsoft Training. Microsoft PressDeutschland, 2002.

[zen09a] zenoss. Getting Started with Zenoss, 2009.

[zen09b] zenoss. Zenoss Administration Guide, 2009.

[zen09c] zenoss. Zenoss Installation Guide, 2009.

X

http://www.ietf.org/rfc



Documents

Zenoss als Tool zur Netzwerküberwachungmrick1/mrick1_Zenoss.pdf · 2010. 4. 22. · Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät für Informatik, Mathematik und