kann die Diplomarbeit heruntergeladen werden. - bei BS-NetSolutions

Fachhochschule Braunschweig/Wolfenbüttel
Fachbereich Informatik
Heterogenes Server-Monitoring unter Einsatz des
OpenSource-Tools Nagios®
Diplomarbeit
von
Sven Schaffranneck
Studiengang: Praktische Informatik
Matrikelnr.: 20066338
Datum: 18.08.2004
Betreuer:
Fachhochschule Braunschweig/Wolfenbüttel
Fachbereich Informatik
Prof. Dr. U. Klages
Volkswagen AG
K-DOI-5/4
Systems Management
Dipl.-Ing. Hans-Werner Buske
Dipl.-Ing. (FH) Hans Fricke

- II -
Kurzfassung
Diese Diplomarbeit zeigt systematisch den Aufbau einer Enterprise Server-Überwachung mit
Hilfe des OpenSource-Tools Nagios. Dabei wird im Wesentlichen auf die vorgegebenen
Eckdaten seitens des betreuenden Unternehmens eingegegangen. Gerade die heterogene IT-
Landschaft sowie die grosse Anzahl der zu überwachenen Services stellen hohe
Anforderungen an das einzusetzende Tool.
Die zentrale, Plugin-basierte Architektur von Nagios überzeugt durch Transparenz und
geringe Komplextität. Die praxisnahen Features reichen von Event-Unterdrückung bis zu
intelligentem Scheduling.
Anhand eines Proof of Concepts wird der Einsatz einer Nagios-Überwachung in der IT-
Umgebung der Volkswagen AG evaluiert. Die verwendeten Server und Betriebssysteme
repräsentieren die strategischen Plattformen des Unternehmens. Neben der generellen
Verfügbarkeit der Plugins auf den spezifischen Plattformen zeigen Performance-Messungen
die zu erwartende Last des Nagios-Servers im praktischen Einsatz.
Nagios zeigt im Laufe des Proof of Concepts hohe Stabilität und Zuverlässigkeit. Der offene
Quelltext bietet Flexibilität und ermöglicht schnelle Fehlerkorrekturen. Nagios bringt eigene
Konzepte für ausfallsicheres sowie verteiltes Monitoring mit und kann mit Hilfe
unterschiedlicher Vorgehensweisen auch in Firewall-Umgebungen agieren.
In Summe lässt dies den Autor zu dem Schluss kommen, den Einsatz von Nagios in der IT-
Umgebung der Volkswagen AG Wolfsburg zu befürworten.

- III -
Danksagung
Die vorliegende Diplomarbeit wurde in der Zeit von Mai bis August 2004 bei der
Volkswagen AG Wolfsburg in der Unterabteilung K-DOI-5/4 Systems Management
angefertigt.
Für die freundliche Aufnahme und vielfältige Unterstützung möchte ich mich bei allen
Mitarbeitern der Unterabteilung K-DOI-5/4 bedanken.
Besonderer Dank gilt meinen Betreuern Herrn Buske und Herrn Fricke, die stets ein offenes
Ohr für meine Probleme und Anregungen hatten. Dieser Dank gebührt ebenso Herrn Meister
(K-DOI-1/1) sowie den Mitarbeitern der Firmen Pluralis AG, gedas deutschland GmbH und
IBM, namentlich Andreas Schmutzler, Dirk Lammers und Martin Adamiak.
Für die Betreuung und Unterstützung seitens der Fachhochschule Braunschweig/Wolfenbüttel
möchte ich mich bei Herrn Klages bedanken.
Ebenso bedanke ich mich bei Claudia Sturm und Carsten Poels für die konstruktiven
Diskussionen, Vorschläge und Anregungen bei der Erstellung der Diplomarbeit.
Sven Schaffranneck, August 2004

- IV -
Inhaltsverzeichnis
Inhaltsverzeichnis................................................................................................................... IV
Abkürzungsverzeichnis.......................................................................................................VIII
Abbildungsverzeichnis..........................................................................................................XII
1. Einleitung.............................................................................................................................13
1.1 Aufgabe und Struktur des Rechenzentrums................................................................... 13
1.2 Kenndaten der IT-Infrastruktur.......................................................................................14
1.3 Relevanz des Server-Monitorings.................................................................................. 15
1.4 Gliederung der Arbeit.....................................................................................................15
2. IT Infrastructure Library (ITIL)...................................................................................... 16
2.1 Vorteile des IT Service Managements............................................................................16
2.2 Umfang der IT Infrastructure Library.............................................................................17
2.3 Service Support.............................................................................................................. 19
2.4 Service Delivery............................................................................................................. 21
3. Incident Management in der Praxis.................................................................................. 23
3.1 Incident Management Prozess........................................................................................23
3.2 Incident- und Event-Management bei der Volkswagen AG...........................................24
3.3 Server-Monitoring.......................................................................................................... 25
3.3.1 Manuelle Überwachung..........................................................................................25
3.3.2 Automatisierte Überwachung................................................................................. 26
3.3.3 IBM/Tivoli im Einsatz bei der Volkswagen AG.................................................... 27
4. Konzept von Nagios.............................................................................................................31
4.1 Architekturbedingte Unterschiede zu IBM/Tivoli..........................................................32
4.1.1 zentraler Ansatz...................................................................................................... 33
4.1.2 dezentraler Ansatz.................................................................................................. 33
4.1.3 Gegenüberstellung IBM/Tivoli und Nagios............................................................34
4.2 Überwachung lokaler Ressourcen mit Nagios................................................................35
4.3 Überwachung entfernter, öffentlicher Ressourcen......................................................... 38
4.4 Überwachung entfernter, privater Ressourcen............................................................... 39
4.4.1 Nagios Remote Plugin Executor (NRPE)...............................................................39
4.4.1.1 Konzept und Implementierung........................................................................39
4.4.1.2 Sicherheitsmerkmale.......................................................................................40
4.4.1.3 Konfiguration................................................................................................. 41

- V -
4.4.1.4 Aufruf des check_nrpe.................................................................................... 43
4.4.1.5 Zusammenfassung...........................................................................................44
4.4.2 Nagios Service Check Acceptor (NSCA)...............................................................45
4.4.2.1 Konzept und Implementierung........................................................................45
4.4.2.2 Sicherheitsmerkmale.......................................................................................47
4.4.2.3 Konfiguration des NSCA-Daemons................................................................48
4.4.2.4 Konfiguration des NSCA-Clients (send_nsca)............................................... 51
4.4.2.5 Aufruf des send_nsca......................................................................................51
4.4.2.6 Zusammenfassung...........................................................................................53
4.4.3 Plugin check_by_ssh...............................................................................................54
4.4.3.1 Konzept und Implementierung........................................................................54
4.4.3.2 Sicherheitsmerkmale.......................................................................................55
4.4.3.3 Konfiguration der Secure Shell (SSH)............................................................55
4.4.3.4 Aufruf des check_by_ssh Plugins................................................................... 56
4.4.3.5 Zusammenfassung ..........................................................................................58
4.4.4 Fazit........................................................................................................................ 59
4.5 Distributed Monitoring...................................................................................................60
4.5.1 Architektur..............................................................................................................61
4.5.2 Konfiguration..........................................................................................................62
4.6 Failover Monitoring........................................................................................................64
4.6.1 Architektur..............................................................................................................64
4.6.2 Konfiguration und Voraussetzungen...................................................................... 65
5. Funktionale Details............................................................................................................. 68
5.1 Service- und Host-Abhängigkeiten................................................................................ 68
5.1.1 Architektur..............................................................................................................68
5.1.2 Konfiguration..........................................................................................................71
5.2 Soft und Hard States.......................................................................................................73
5.2.1 Soft States............................................................................................................... 73
5.2.2 Hard State............................................................................................................... 74
5.3 State Flapping.................................................................................................................75
5.3.1 Implementierung.....................................................................................................75
5.3.2 Konfiguration..........................................................................................................77
5.3.3 Auswirkungen.........................................................................................................77
5.4 Freshness-Check.............................................................................................................78

- VI -
5.5 Scheduling mit Interleaving............................................................................................79
5.5.1 Konfiguration..........................................................................................................79
5.5.2 Funktionsweise des Interleaving.............................................................................81
6. Plugins.................................................................................................................................. 84
6.1 Standard Plugins.............................................................................................................85
6.2 Contributed Plugins........................................................................................................91
7. Proof of Concept (PoC).......................................................................................................92
7.1 Zielsetzung..................................................................................................................... 92
7.2 Anforderungen an das Server-Monitoring......................................................................93
7.2.1 Plattformen............................................................................................................. 93
7.2.2 Service-Überwachung.............................................................................................93
7.2.2.1 Filesystem-Überwachung............................................................................... 93
7.2.2.2 Prozess-Überwachung....................................................................................94
7.2.2.3 Auslagerungsspeicher-Überwachung.............................................................96
7.3 Beschreibung des PoC....................................................................................................97
7.4 Installation des Nagios Servers.......................................................................................98
7.4.1 Voraussetzung.........................................................................................................98
7.4.2 Installation............................................................................................................ 100
7.4.2.1 Apache Installation.......................................................................................101
7.4.2.2 Nagios Installation....................................................................................... 103
7.4.2.3 Installation der Plugins................................................................................ 104
7.4.2.4 Installation des check_nrpe.......................................................................... 104
7.4.2.5 Installation des NSCA...................................................................................105
7.4.3 Konfiguration von Nagios.................................................................................... 106
7.4.3.1 Modifikationen an cgi.cfg.............................................................................106
7.4.3.2 Modifikationen an checkcommands.cfg........................................................108
7.4.3.3 Modifikationen an contactgroups.cfg...........................................................109
7.4.3.4 Modifikationen an contacts.cfg.....................................................................110
7.4.3.5 Modifikationen an dependencies.cfg............................................................ 111
7.4.3.6 Modifikationen an escalations.cfg................................................................111
7.4.3.7 Modifikationen an hostgroups.cfg................................................................ 111
7.4.3.8 Modifikationen an hosts.cfg..........................................................................112
7.4.3.9 Modifikationen an misccommands.cfg......................................................... 113
7.4.3.10 Modifikationen an nagios.cfg..................................................................... 114

- VII -
7.4.3.11 Modifikationen an ressource.cfg................................................................ 115
7.4.3.12 Modifikationen an services.cfg................................................................... 115
7.4.3.13 Modifikationen an timeperiods.cfg.............................................................116
7.4.4 Start des Nagios Servers....................................................................................... 117
7.5 Vorbereitung der Agenten für die remote Hosts.......................................................... 120
7.6 Installation der Agenten auf den remote Hosts............................................................ 124
7.6.1 Voraussetzung und Vorbereitung......................................................................... 124
7.6.2 Installation............................................................................................................ 124
7.6.3 Einsatz von send_nsca.......................................................................................... 126
7.6.4 Einsatz von check_by_ssh.................................................................................... 127
7.7 Besonderheiten und Hinweise für AIX........................................................................ 129
7.8 Besonderheiten und Hinweise für HP-UX................................................................... 131
7.9 Besonderheiten und Hinweise für Linux (Intel/s390).................................................. 132
7.10 Remote Hosts hinter einer Firewall............................................................................133
7.11 Performance................................................................................................................134
7.11.1 Systemauslastung bei 980 Checks/Minute......................................................... 135
7.11.2 Systemauslastung bei 490 Checks/Minute......................................................... 137
7.11.3 Skalierbarkeit durch Veränderung der Prozessoranzahl.....................................138
8. Ergebnis............................................................................................................................. 140
9. Ausblick..............................................................................................................................140
Anhang................................................................................................................................... 141
Literaturverzeichnis..............................................................................................................156
Verzeichniss der relevanten Internet Links........................................................................158
Eidesstattliche Erklärung

- VIII -
Abkürzungsverzeichnis
• CPU
Central Processing Unit: Ein Prozessor ist für die Verarbeitung der Daten in einem
Rechnersystem verantwortlich.
• CVS
Concurrent Versions System: bezeichnet eine Software zur Versionsverwaltung von
Quellcode.
• Daemon
Als Daemon wird unter Unix ein Prozess bezeichnet, welcher im Hintergrund läuft. Einmal
gestartet, wartet er auf bestimmte Ereignisse und tritt dann in Aktion. Daemons haben
meistens keine direkte Ausgabe auf die Systemkonsole. Sie schreiben ihre Meldungen in
die Log-Dateien des Unix-Systems.
• DES
Der Data Encryption Standard ist einer der bekanntesten Algorithmen für symmetrische
Verschlüsselung. Beim 3DES (Tripple DES) wird dieser dreifach hintereinander
angewendet, um eine höhere Sicherheit zu erreichen.
• DHCP
Dynamic Host Configuration Protocol: Dient zur dynamischen Vergabe von IP-Adressen
an Client-Rechnern. Der zu konfigurierende Client muß keine IP-Adresse kennen. Er
sendet einen Broadcast, um DHCP Server zu finden. Aus den Rückmeldungen der DHCP-
Server wählt der Client einen Server aus und erhält von diesem dann die geleaste IP-
Adresse, sowie die Netmask, default Gateway und die IP-Adressen der DNS-Server. Nach
dem Ende der Lease-Time erhält der Client eine neue IP-Adresse.
• DNS
Domain Name Service: Ein Dienst zum Auflösen von symbolischen Internet-Adressen in
IP-Adressen.
• FTP
File Transfer Protocol: Ein Protokoll zum Übertragen von Dateien von einem Rechner auf
einen anderen. FTP setzt auf TCP/IP auf.

- IX -
• GNU
GNU ist eine rekursive Abkürzung von GNU's Not Unix. Das GNU-Projekt wurde 1984
begonnen, um ein vollständiges, Unix-artiges Betriebssystem zu entwickeln, das freie
Software ist.
• GPL
Die GNU General Public Licenses erlaubt legales kopieren, verbreiten und/oder
Veränderungen der Quellen.
Einzusehen unter http://www.gnu.org/copyleft/gpl.html
• GUI
Graphical User Interface: Grafische Nutzeroberfläche.
• HTTP
Hyper Text Transfer Protocol: Protokoll zur Übertragung von Dokumenten im Internet.
• iLinux
Das „i“ steht für Intel und beschreibt ein Linux, welches auf Intel-basierender Hardware
läuft.
• IPv4
Internet Protocol, Version 4
• IPv6
Internet Protocol, Version 6: Es wurde der Adressumfang gegenüber IPv4 erweitert und
Teile des IP-Headers verändert, um weniger Overhead bei den Paketen mitzuführen.
• ITIL
Die IT Infrastructure Library ist ein IT Service Management Leitfaden, welcher Ende der
80er Jahre von der britischen Behörde CCTA (Central Computer and
Telecommunications Agency) für die Regierung entwickelt wurde.
• Kernel
Eine Binärdatei, welche die Ressourcen der Hardware verwaltet.
• LDAP
Lightwight Directory Access Protocol: Protokoll zur Kommunikation mit einem LDAP-
Server. LDAP bietet auf einer Protokollschicht Zugriff auf einen Verzeichnisdienst.
• NFS
Mit dem Network File System können Verzeichnisse über das Netzwerk freigegeben
werden.

- X -
• NIS
Network Information Service: Bei NIS handelt es sich um Sun Microsystems YP (yellow
pages) Client-Server-Protokoll für die Verteilung von Systemkonfigurationen wie
Benutzer, Passwörter und Hostnames.
• Pipe
Pipes ermöglichen den Transport von Daten zwischen Prozessen nach der First In, First
Out (FIFO) Methode.
• POP
Post Office Protocol: Ein Protokoll zum Empfangen von eMails von einem POP-
Mailserver.
• RPM
Red Hat Package Manager: Paketformat der installierbaren Software unter Red Hat Linux
und z. T. auch anderen Distributionen sowie Unices.
• SAMBA
Ein Softwarepaket bestehend aus zwei Services und mehreren Anwendungen für folgende
Möglichkeiten: Nachbilden eines NT-File-Servers, Zugriff auf Windows-SMB-Dienste wie
freigegebene Verzeichnisse oder NT-Drucker-Server.
• SLA
Service Level Agreements sind Vereinbarungen zwischen Anbieter und Kunden. Sie
definieren exakt den Umfang der Leistungen des Anbieters.
• SMB
Server Message Block: Das Protokoll dient im Microsoft Windows Umfeld der
Kommunikation mit den Shares.
• SMTP
Das Simple Mail Transfer Protocol dient dazu, ausgehende eMails an den eMail-Server zu
transportieren.
• SNMP
Abkürzung für Simple Network Management Protocol und ein Teil der Internet Protokolle,
die von der Internet Enginieering Task Force definiert wurden. Das Protokoll dient der
Verwaltung und Überwachung von Netzelementen, die überwiegend aus dem LAN Bereich
stammen (z.B. Router, Server, etc). SNMP überträgt und verändert
Managementinformationen und Alarme.

- XI -
• SQL
Stuctured Query Language: Sprache zur Kommunikation mit einer SQL-fähigen
Datenbank.
• TCP
Transmission Control Protocol: Überwacht den Weg und die Reihenfolge, in der
Datenpakete übertragen werden.
• TCP/IP
Transmission Control Protocol / Internet Protocol: Mittels der Verbindung dieser beiden
Protokolle werden Daten in IP-basierenden Umgebungen übertragen.
• WWW
World Wide Web: ein Synonym für das Internet.
• zLinux
Bezeichnet die Implementierung des freien Betriebssystems Linux auf IBM zSeries
Hardware (S/390).
• Zombie
Ein Zombie ist ein beendeter Kindprozess, dessen Vaterprozess es versäumt hat, den
Exitstatus des Kindprozesses mit einem wait()-Call abzufragen. Bis dieses geschehen ist
(oder der Vaterprozess beendet wurde), bleibt der Prozess in der Prozesstabelle als Zombie
bestehen.

Abbildungsverzeichnis
- XII -
Abbildung 1 Organisatorische Eingliederung........................................................................... 15
Abbildung 2 ITSM Disziplinen.................................................................................................19
Abbildung 3 Incident Management Prozesse............................................................................24
Abbildung 4 Tivoli Managed Region........................................................................................29
Abbildung 5 zentraler/dezentraler Ansatz.................................................................................33
Abbildung 6 Überwachung lokaler Ressourcen........................................................................36
Abbildung 7 Nagios Webinterface Service Details...................................................................38
Abbildung 8 Überwachung entfernter, öffentlicher Ressourcen...............................................39
Abbildung 9 Indirekter Service-Check mit NRPE....................................................................40
Abbildung 10 Passiver Service-Check mit NSCA....................................................................47
Abbildung 11 Longrunner mit NSCA und NRPE.....................................................................48
Abbildung 12 Passiver Service-Check im Webfrontend...........................................................53
Abbildung 13 Indirekter Service-Check mit check_by_ssh......................................................55
Abbildung 14 Distributed Monitoring...................................................................................... 62
Abbildung 15 Failover Monitoring........................................................................................... 65
Abbildung 16 Beispiel von Service-Abhängigkeiten................................................................70
Abbildung 17 Beispiel von Host-Abhängigkeiten.................................................................... 73
Abbildung 18 Service State Transitions....................................................................................76
Abbildung 19 Weighted State Transitions................................................................................ 77
Abbildung 20 Scheduling ohne Interleaving 1..........................................................................82
Abbildung 21 Scheduling ohne Interleaving 2..........................................................................82
Abbildung 22 Scheduling mit Interleaving, Anfang................................................................. 83
Abbildung 23 Scheduling mit Interleaving, erste Durchgang...................................................83
Abbildung 24 Scheduling mit Interleaving, dritter Durchgang.................................................84
Abbildung 25 Nagios Webfrontend: Tacticel Overview nach erstem Start............................120
Abbildung 26 PAP zur Installation eines remote Hosts..........................................................126
Abbildung 27 Nagios Performance Info................................................................................. 135
Abbildung 28 CPU-Usage bei 980 Checks/Minute................................................................ 136
Abbildung 29 CPU Load bei 980 Checks/Minute.................................................................. 137
Abbildung 30 CPU-Usage bei 490 Checks/Minute................................................................ 138
Abbildung 31 CPU-Load bei 490 Checks/Minute.................................................................. 138
Abbildung 32 CPU-Load bei 490 Checks/Minute (1 Prozessor)............................................139
Abbildung 33 CPU-Load bei 490 Checks/Minute (1 Prozessor)............................................140

1. Einleitung
- 13 -
Aufbauend auf der Studienarbeit Schaffranneck, Sven, (2004) „Analyse ausgewählter Event-
Management-Tools auf Basis der Anforderungen der Volkswagen AG unter Berücksichtigung
von OpenSource“ soll diese Arbeit anhand eines Proof of Concepts (PoC) den möglichen
Einsatz von Nagios bei der Volkswagen AG praktisch evaluieren. Dabei sollen die
Möglichkeiten und Grenzen in praktischen Versuchen dargelegt werden. Das Ziel ist die
Überwachung einer hohen Anzahl von Servern auf verschiedensten Unix-Plattformen.
1.1 Aufgabe und Struktur des Rechenzentrums
Unsere heutige Gesellschaft wird auch als Informationsgesellschaft bezeichnet. Gestützt durch
Computer und Netzwerke werden die Informationen in Form von Daten gespeichert und
verwaltet. Die Technik trägt damit maßgeblich zum Erfolg eines Unternehmens bei.
Entscheidend ist dabei neben dem schnellen und flexiblen Zugriff auf Informationen die
ständige Verfügbarkeit.
Erreicht werden kann dies nur durch ein optimales Zusammenspiel einzelner Komponenten
der Computer-Infrastruktur, primär in Form eines Netzwerkes. Der Trend geht zu immer
größeren Netzen und verteilten Anwendungen, die einer immer größeren Anzahl von
Anwendern den Zugriff auf Applikationen und Daten ermöglichen.
In Anbetracht der gesteigerten Anforderungen und der Größe des Volkswagen Konzerns,
erweiterten sich die Aufgaben und Tätigkeiten des Rechenzentrums von einfachen
Rechentätigkeiten zu einem komplexen Zentrum für Informationsverarbeitung.
Aus diesem Grund wir das Rechenzentrum bei der Volkswagen AG „Informationssysteme
Technik und Betrieb“ genannt und ist dem Ressort „Führungsorganisation und Systeme“
eingegliedert. 1
1 Vgl: Twele, Horst (2000), S. 10ff

- 14 -
Unterteilt wird der Bereich „Informationssysteme Technik und Betrieb“ (K-DOI) in
Serversysteme (K-DOI-1), Middleware (K-DOI-2), Kommunikationssysteme (K-DOI-3),
Betriebssteuerung (K-DOI-4), Betrieb Rechner & Netzwerke (K-DOI-5),
Client Services (K-DOI-6), Projekt Global Client Services (K-DOI-7) und IT Infrastruktur
Konzern/Markengruppe Volkswagen (K-DOI-8). Abbildung 1 verdeutlicht die
Gliederungsstruktur.
Abbildung 1 Organisatorische Eingliederung
eigene Darstellung
1.2 Kenndaten der IT-Infrastruktur
Das Rechenzentrum der Volkswagen AG Wolfsburg umfasst laut der Präsentation
„Ihr IT-Powershop“ von Dirk Pollmeier (2003) eine (Rechner-) Fläche von 3600qm. Die
Leistungsaufnahme wird mit ca. 20.000.000 kWh/Jahr angegeben, was dem
durchschnittlichen Bedarf von 4000 Einfamilienhäusern entspricht.
Die 2200 Server besitzen zusammen eine Speicherkapazität von ca. 1500 Terabyte
(1,5 Petabyte) und werden von 220 Mitarbeitern (RZ Betrieb) betreut.
Um den Anspruch an hohe Verfügbarkeit gerecht zu werden, teilt sich das Rechenzentrum auf
4 Standorte auf und besitzt vielfältige Redundanz. Darunter fallen nicht nur redundante
Hardware, sondern auch redundante Stromversorgungen und Klimaanlagen.

- 15 -
1.3 Relevanz des Server-Monitorings
Mit steigender Komplexität der Systeme steigt auch die Anzahl der potenziellen Fehlerquellen
und Sicherheitslücken. Eine umfassende Überwachung wird zunehmend problematischer.
Abhilfe schaffen hier automatisierte Systems-Management-Werkzeuge, die qualitative
Aussagen über den Systemzustand geben können. Darunter fallen unter anderem die
Leistungsdaten (Performance) von Netzwerken, Servern und den darauf laufenden
Applikationen. Das Ziel, Fehler und Leistungsengpässe frühzeitig zu erkennen und darauf
reagieren zu können, ist die Hauptaufgabe des Server-Monitorings.
1.4 Gliederung der Arbeit
In Kapitel 2 wird zunächst auf die Theorie und Hintergründe des IT-Managements nach ITIL
eingegangen. Im Anschluss daran stellt das Kapitel 3 den Einsatz des Incident Managements
in Theorie und Praxis dar. Anhand dieser Grundlagen wird das Konzept und die wesentliche
Funktionalität von Nagios in den Kapiteln 4 bis 6 verdeutlicht, um als Fundament für das
Proof of Concept (Kapitel 7) zu dienen.

- 16 -
2. IT Infrastructure Library (ITIL)
ITIL, die IT Infrastructure Library, ist ein IT Service Management Leitfaden, welcher Ende
der 80er Jahre von der britischen Behörde CCTA (Central Computer and
Telecommunications Agency) für die Regierung entwickelt wurde. ITIL umfasst eine
Ansammlung von Literatur und ist als Baukasten mit Best Practice Prozessen 1 zum
IT Service Management zu verstehen. Dadurch, dass alle Vorgehensweisen im Rahmen des
IT Service Managements beschrieben werden und die Prozesse kundenorientiert ausgeprägt
sind, kann ITIL als vollständiges Referenzsystem dienen.
Mittlerweile gilt ITIL als „de Facto“-Standard und erfährt eine zunehmende, weltweite
Verbreitung.
Die in dieser Arbeit verwendete Terminologie lehnt sich eng an den innerhalb der
IT Infrastructure Library verwendeten Fachjargon.
2.1 Vorteile des IT Service Managements
In der Vergangenheit war die IT-Organisation eines Unternehmens oftmals nicht klar messbar.
Die Kosten für IT-Services waren weitestgehend unbekannt, die Dokumentation der IT-
Komponenten unvollständig oder inkonsistent und es fehlte eine klare Aussage über die von
der IT-Organisation zu erbringenden Leistungen.
Mit dem Einsatz des IT Service Managements werden IT-Prozesse messbar. Die IT-
Organisation kann als Service-Dienstleister innerhalb des Unternehmens auftreten und seine
Dienste intern verkaufen. Daraus resultiert eine geschäftsmäßige Beziehung zwischen der IT-
Organisation und ihren Kunden, was eine verbesserte Kommunikation zwischen IT-Kunden,
IT-Anwendern und der IT-Organisation zur Folge hat. (vgl. MASTERS Consulting GmbH
(2004), S. 4ff)
Mit der Definition von IT Services, der Festlegung der auszuliefernden Service Levels sowie
deren Kosten wird IT messbar. Durch Transparenz in Kosten und Leistungen wird die IT zu
einer Steuerungsgröße innerhalb der Wertschöpfungskette des Unternehmens und stellt nicht
mehr nur einen kaum beeinflussbaren Kostenblock dar. 2
1 Ein Prozess gilt als eine zeitliche und logische Verkettung von Einzelaktivitäten mit definierter Eingabe,
definiertem Ergebnis sowie definierten Mess- und Steuerungsgrössen. (vgl. MASTERS Consulting GmbH
(2004), S. 10)
2 Vgl: MASTERS Consulting GmbH (2004), S. 4

- 17 -
2.2 Umfang der IT Infrastructure Library
Während der letzten 3 Jahre wurde das vorhandene Wissen aktualisiert und neu
zusammengestellt. Aus den ehemals 10 Büchern entstanden 7 neue Exemplare, welche die
grundlegende Basis der ITIL darstellen.
• Service Support
siehe Kapitel 2.3
• Service Delivery
siehe Kapitel 2.4
• Planning to Implement Service Management
Das Ziel dieses Buches ist es, dem Leser die wesentlichen Punkte beim Planen eines
erfolgreichen Service Managements zu vermitteln. Es beschreibt die einzelnen Schritte, IT-
Services einzuführen oder vorhandene zu verbessern.
• ICT Infrastructure Management
In dieser Publikation werden neben Network Service Management (Netzwerk-
Management) und Computer Installation auch Bereiche wie Operations Management
(Betriebs-Management) behandelt.
• Application Management
Dieses Buch deckt den Lebenszyklus der Softwareentwicklung ab und betont hierbei die
klare Anforderungsdefinition und ihre Implementierung.
• Security Management
In der Informations-Technik gilt die Information als das Kerngeschäft. Jeder Faktor, der
diese Information oder deren Verarbeitung gefährdet, gefährdet auch direkt die Leistung
der IT-Organisation. Dabei ist die Sicherheit ein strukturelles Problem. ITIL stellt mit
Security Management eine Grundlage für das Management von IT-Infrastrukturen zur
Verfügung, die aus dem Gesichtspunkt eines Managers die Sicherheit in der IT-
Infrastruktur organisiert und beibehält.
• Software Asset Management
Ein wirkungsvolles Management von Software ermöglicht eine gezielte Kontrolle und
Schutz vorhandener Software innerhalb einer Organisation. Diese Publikation beinhaltet
einen Leitfaden, welcher die wesentlichen Punkte des Software Asset Managements
darlegt.

- 18 -
Die englischsprachigen Werke können bei dem britischen
OGC (Office of Government Commerce), welches auch die Rechte an dem Wissen hält,
bestellt werden.
Die für diese Arbeit wesentlichen Begriffsdefinitionen stammen aus den Werken
Service Support und Service Delivery, welche zusammen 11 Disziplinen umfassen
(siehe Abbildung 2) und in den nachfolgenden Kapiteln 2.3 und 2.4 kurz zusammengefasst
werden.
ITSM
Service / Help Desk
Incident Management
Problem Management
Change Management
Release Management
Configuration Management
Service Level Management
Capacity Management
Continuity Management
Availability Management
IT Financial Management
Service Support
Service Delivery
Abbildung 2 ITSM Disziplinen
modifiziert nach iETSolutions GmbH (2003)
Der in Abbildung 2 auftretende Oberbegriff ITSM beschreibt hier das
Information Technologie Service Management und gilt als eine Untermenge von ITIL.

- 19 -
2.3 Service Support
Der Service Support umfasst die Service-Leistungen, welche notwendig sind, die IT-Services
instandzuhalten und effektiv anbieten zu können. Dabei wird zwischen 5 bzw. 6 Gebieten
unterschieden. Der Service-Desk ist zwar als ein eigener Punkt aufgeführt, wird jedoch durch
das Incident Management impliziert.
• Service-Desk
• Schnittstelle zwischen Kunde bzw. Benutzer und Anbieter
• Funktion des Incident-Managements
• Incident-Management
• Impliziert den Service-Desk
• Primäre Aufgabe ist, dem Kunden schnellstmöglich das ausgefallene System (oder
Ersatz) wieder zur Verfügung zu stellen
• Problem-Management
• Fehler erkennen, beheben und aufzeichnen
• Verhindern von Ereignissen, welche das normale Betriebsgeschäft unterbrechen
können
Der wesentliche Unterschied zwischen dem Incident-Management und dem Problem-
Management ist die Zielsetzung. Das Incident-Management hat die primäre Aufgabe, dem
Kunden schnellstmöglich eine Problemlösung zu bieten. Dabei kann es sich auch um ein
einfachen Workaround handeln. Das Problem-Management hingegen setzt an der Wurzel des
Problems an, analysiert dieses und sucht nach einer Lösung. Dieser Prozess dauert i.d.R.
länger und entspricht damit nicht dem Ziel des Incident-Managements.

- 20 -
• Change-Management
• Stellt sicher, dass alle Konfigurationsänderungen geplant und authorisiert sind
• Bewertet und überwacht die Änderung
• Jede Änderung wird getestet und ein Plan zum Rücksetzen der Änderung erstellt
• Release-Management
• Organisiert die kontrollierte Softwarehaltung und -verteilung
• Halten einer Software-/Hardware-Bibliothek
• Configuration-Management
• Informationssammlung über Hardware, Software, Dokumentation und
Ansprechpartner
• Identifikation von IT-Komponenten
• Warten und Anpassen von Informationen bei Änderungen
• Verifikation der vorhanden Daten (IST) mit dem SOLL-Zustand
• Pflege der Configuration Management Database (CMDB), welche ein logisches
Modell der IT-Infrastruktur abbildet und die zentrale Informationsbasis für alle am
IT-Service-Management beteiligten Prozesse und Funktionen darstellt

- 21 -
2.4 Service Delivery
Das Service Delivery umfasst die Service-Leistungen an sich und stellt sicher, dass die
angebotenen Leistungen den Vereinbarungen zwischen Anbieter und Kunde entsprechen.
• Service-Level-Management
• Primäres Management für angebotene IT-Dienstleistungen
• Stellt sicher, das vereinbarte Dienstleistungen eingehalten werden
• Überprüfen vorhandener Dienstleistungen
• Verhandlungen mit den Kunden
• Erstellen und überwachen von Service-Level-Agreements (SLA) 1
• Implementieren von Verbesserungs-Regeln und -Prozessen
• Erstellen von Prioritäten
• Planung von Angebotswachstum
• Zusammenarbeit mit den Buchhaltungsprozessen, um entstandene Kosten
zurückzugewinnen
• Capacity-Management
• Leistungskontrolle (Performance Monitoring)
• Auslastungskontrolle
• Anwendungsauslastung
• Vorhersage von Ressourcenauslastungsentwicklung
• Vorhersage von Nachfrage
1 SLA's sind Vereinbarungen zwischen Anbieter und Kunden. Sie definieren exakt den Umfang der Leistungen
des Anbieters.

- 22 -
• Continuity-Management
• Stellt sicher, dass die IT-Services wiederhergestellt und fortlaufen können, wenn
ein schwerwiegendes, unerwartetes Ereignis eintrifft
• Reduktion der Risiken in erster Instanz
• Risikobeurteilung der einzelnen IT-Services
• Wiederherstellungsrichtlinien erstellen
• Erstellen eines Katastrophenplanes
• Testen, überprüfen und verbessern des Katastrophenplanes
• Availability-Management
• Grundlage für SLA
• Zuverlässigkeit als die Zeit einer Komponente, in der erwartet werden kann, sie
ohne Ausfälle nutzen zu können
• Regenerierbarkeit als den Zeitraum der Wiederherstellung einer Komponente nach
einem Ausfall
• Wartbarkeit, vorbeugend und fehlerbehebend
• Sicherheit und Auswirkungen von Sicherheitslöchern
• IT Financial-Management
• Kalkulieren der Kosten für die angebotenen Dienstleistungen
• Stellt sicher, das die IT-Infrastruktur kosteneffektiv aufgebaut wird

- 23 -
3. Incident Management in der Praxis
Nach der ITIL-Terminologie wird der Begriff Incident wie folgt definiert:
Any event that is not part of the standard operation of a service and that causes, or may
cause, an interruption to, or a reduction in, the quality of that service. 1
Ein Incident ist demnach ein Ereignis, welches nicht dem üblichen Betriebsablauf entspricht
und die Qualität der angebotenen Dienste gefährdet, bis hin zu einem Totalausfall.
3.1 Incident Management Prozess
Die Aufgabe des Incident Managements ist es, das Auftreten dieser „gefährlichen“ Ereignisse
abzufangen und negative Auswirkungen für den Betrieb einzuschränken oder im besten Fall
zu verhindern.
Ein Beispiel für die Prozessabläufe beim Incident Management zeigt ITIL:
Abbildung 3 Incident Management Prozesse
Quelle: Office of Government Commerce, (2000): ITIL Service Support CD-ROM Version 1.3
1 Vgl: Office of Government Commerce, (2000)

- 24 -
Die Zentrale Komponente ist hier der Incident Management process. Als Quelle für
auftretende Incidents gelten unter anderem Server, Anwendungen, Netzwerke oder der
Service-Desk. Die Incidents werden vom Incident Management process erkannt und
analysiert. Dieser hat Zugriff auf die Problem Database (Problem/error database) und die
CMDB. Über die CMDB können Informationen bezüglich der betroffenen Systeme abgefragt
werden, darunter auch administrative Ansprechpartner. Die Problem Database wird vom
Problem-Management gepflegt. Sie enthält Informationen über bekannte Fehler und Probleme
mit Workarounds und Fehlerbehebungen. Anhand dieser Daten kann der Incident
Management process dem Anwender schnellstmöglich helfen. Handelt es sich bei dem Fehler
jedoch um ein generelles Problem, welches eine Änderung am Server (oder den
Anwendungen, Datenbanken, etc.) erfordert, so wird ein Request for Change (RFC) an das
Change-Management weitergeleitet. Dieses bewertet und authorisiert die
Konfigurationsänderung.
Über die Service Request procedures werden die Incident-Tickets gegebenenfalls an die
Fachabteilungen weitergeleitet und dort gelöst. Probleme, welche nicht direkt durch das
Incident Management gelöst werden können, werden an das Problem Management übergeben.
3.2 Incident- und Event-Management bei der Volkswagen AG
Der Begriff Incident-Management wurde bei VW noch um den Begriff Event, bzw. Event-
Management erweitert. Während nach ITIL jegliches Auftreten eines Ereignisses über die
Incident-Quellen als Incident bezeichnet wird, unterscheidet VW zwischen Ereignissen, die
über den Service-Desk (Incidents) eintreffen, und denen, die von den Systemen (Events)
ausgelöst werden.
Mit dieser Unterscheidung wird sichergestellt, das nicht jede Anfrage eines Anwenders über
den Service-Desk als ein Incident (nach ITIL) gewertet wird. So tauchen in der Praxis auch
Fragen über den alltäglichen Umgang mit Standard-Produkten am Service-Desk auf, die nicht
die Qualität oder Funktionalität des Betriebes stören.
Um die Konformität beizubehalten, wird im weiteren Verlauf nicht zwischen Events und
Incidents unterschieden.

- 25 -
3.3 Server-Monitoring
Diese Arbeit bezieht sich speziell auf Server-Monitoring als Incident-Quelle. Server-
Monitoring beschreibt eine automatisierte Überwachung von Servern und den darauf
laufenden Anwendungen. Erst dadurch wird das Handling von vielen hundert zu
überwachenden Systemen effizient.
Eine IT-Organisation, welche Service Level Agreements mit Fachabteilungen des
Unternehmens ausgehandelt hat, bietet, abhängig vom Inhalt der SLA's, garantierte
Leistungen an. Diese Leistungen können beispielsweise eine maximale Ausfallzeit des HTTP-
Dienstes von 30 Minuten am Tag enthalten. Um solch einer Anforderung gerecht zu werden,
ist die ständige Überwachung dieses Dienstes notwendig. In den folgenden Ansätzen wird
eine Arbeitswoche von 40 Stunden angenommen:
3.3.1 Manuelle Überwachung
Die Woche wird in 8 Stunden-Blöcke zerteilt, was einem Arbeitstag entspricht. Zu jedem
dieser Blöcke müssen zwei Mitarbeiter anwesend sein, damit zu den gesetzlich
vorgeschriebenen Pausen mindestens einer die Überwachung fortführen kann. Jedes
Mitarbeiter-Paar kann anhand der 40-Stunden-Woche fünf 8-Stunden-Blöcke absolvieren. Da
eine Woche jedoch 168 Stunden hat und somit 21 Arbeits-Blöcke darstellt, werden insgesamt
10 Mitarbeiter benötigt, um die vorgegebene Überwachung zu realisieren.
24 Std. * 7 Tage = 168 Std.
168 Std. / 8 Std. = 21 Arbeits-Blöcke
21 Blöcke / 5 Blöcke_pro_Paar = 4,2 Mitarbeiter-Paare
Um den Ausfall eines Mitarbeiters, durch Krankheit, Unfall, Urlaub oder Pause, zu
kompensieren, müssen weitere Mitarbeiter als Redundanz abgestellt oder Überstunden
geleistet werden. Damit sind mindestens 10 Mitarbeiter zum Einhalten des SLA's notwendig.
4,2 Mitarbeiter-Paare = 8,4 Mitarbeiter (aufgerundet 9)
9 Mitarbeiter + 1 Mitarbeiter (Redundanz) = 10 Mitarbeiter

- 26 -
3.3.2 Automatisierte Überwachung
Ein Tool übernimmt die ständige Überwachung des Dienstes. In regelmäßigen Abständen
untersucht das Tool die erwartete Funktionalität des Dienstes und meldet Probleme umgehend
an den oder die zuständigen Mitarbeiter. Zusätzlich kann das Tool schon erste
Eskalationsmaßnahmen, wie z.B. Neustarten von Prozessen oder Löschen von temporären
Dateien, durchführen, um den gefährdeten oder ausgefallenen Dienst wiederherzustellen. Über
Rufbereitschaft können die informierten Mitarbeiter direkt vom Arbeitsplatz aus, oder von zu
Hause mit Hilfe eines Laptops, das Problem analysieren und beheben. Dieses Szenario ließe
sich schon mit 3 oder 4 Mitarbeitern realisieren. Damit können in diesem Falle mehr als 50%
der Mitarbeiter eingespart werden, was eine erhebliche Kostensenkung zur Folge hat.
Insbesondere im großflächigen Einsatz macht sich die Automatisierung bemerkbar. Soll ein
Szenario mit mehr als 1000 Servern mit Anwendungen überwacht werden, und jeder Server
benötigt nur 5 Minuten eines Administrators zur Überprüfung, so werden 5000 Minuten
benötigt, alle Server innerhalb eines Arbeitstages einmal zu überprüfen. Das entspricht mehr
als 83 Arbeitsstunden und damit 11 Mitarbeitern.
Sollte jeder Server mindestens einmal alle 30 Minuten überprüft werden, und das 24 Stunden
am Tag, sind mindestens 167 Mitarbeiter notwendig (vereinfachtes Szenario ohne Redundanz,
Pausen, etc.).
30 Minuten / 5 Minute_pro_Server = 6 Server_pro_Mitarbeiter (in 30 Minuten)
1000 Server / 6 Server_pro_Mitarbeiter ≈ 167 Mitarbeiter
Diese Überlegungen sollen Aufschluss darüber geben, wie wichtig eine automatisierte
Überwachung von Servern und Anwendungen ist, um als IT-Organisation kostengünstig und
effektiv Dienstleistungen anbieten zu können. Die genannten Beispiele berücksichtigen nicht
alle denkbaren Permutationen. So kann ein Mitarbeiter im Urlaub sein und der zweite
aufgrund von Krankheit ausfallen. Sie sind jedoch für eine Abschätzung der Dimensionen
ausreichend präzise.

- 27 -
3.3.3 IBM/Tivoli im Einsatz bei der Volkswagen AG
Tivoli Software wurde im Jahre 1989 von zwei ehemaligen IBM-Angestellten gegründet und
im Jahre 1996 von IBM akquiriert. Noch immer kämpft IBM mit Integrationsproblemen und
der Vereinfachung des Produktfolios. Dadurch wird die Innovationskraft gebremst und den
Mitbewerbern ermöglicht, sich auf dem Markt zu positionieren 1 .
Hinweis: Die in der Arbeit verwendete Bezeichnung IBM/Tivoli bezieht sich ausschliesslich
auf die Produktsparte Systems-Management und entspricht thematisch den von der Firma
Tivoli Software ursprünglich entwickelten Produkten.
Das bei der Volkswagen AG bereits seit 1998 etablierte IBM/Tivoli umfasst nicht nur das hier
betrachtete Incident-Management und Server-Monitoring, sondern implementiert viele weitere
Systems-Management Disziplinen, welche im ITSM zu finden sind.
IBM/Tivoli basiert auf einer Kommunikationsplattform (Framework) mit dezentralen
Komponenten. Diese Komponenten sind „intelligente“ Agenten, welche auf den zu
überwachenden Hosts installiert werden. Die Eskalation von Incidents erfolgt primär vom
Agenten aus, weitere Eskalationsmöglichkeiten sind über die TEC gegeben. Die in
Abbildung 4 gezeigte Architektur lehnt sich eng an den bei der Volkswagen AG
implementierten Aufbau.
1 Vgl: Inverso, John (2003), S. 4

- 28 -
"TMR"
managed Node
TEC
managed Node
TMR-Server
oserv
oserv
managed Node
Gateway
oserv
GW
Endpoint
lcfd - ITM
Endpoint
lcfd - ITM
. . .
Endpoint
lcfd - ITM
Abbildung 4 Tivoli Managed Region
modifiziert nach Meister, Stefan (2001), S. 90
Zusammen bilden die managed Node's und Endpoints die TMR. Der primäre Tivoli-Server
wird daher TMR-Server genannt. Die Begrifflichkeiten werden wie folgt definiert 1 :
• Framework
Als Framework wird das grundlegende Kommunikationsgerüst der Tivoli-Software
bezeichnet. Alle Aktionen, die zum Management der zu verwaltenden Systeme in der
Tivoli-Managed-Region (TMR) verwendet werden, stützen sich auf das Framework.
• Tools
Auf das Framework können einzelne Tools mit speziellen Aufgaben aufgesetzt werden.
Tivoli bietet eine Vielzahl von Tools wie Inventory 2 und Software Distribution 3 . Auch das
Event-Management wird im Framework als eigenes Tool bereitgestellt.
1 Vgl. Meister, Stefan (2001), S. 89ff
2 automatische Datenerfassung der Hardwarekomponenten zur Laufzeit
3 Software kann von zentraler Stelle im Betrieb auf ausgewählte Endpoints installiert werden

- 29 -
• Endpoint
Als Endpoint gilt der zu überwachende Host, welcher seinerseits keine weiteren Rechner in
der Tivoli-Managed-Region verwaltet.
• Gateway
Dieser managed Node dient zur logischen oder physikalischen Strukturierung einer TMR.
Das Gateway steht in Verbindung mit einem TMR-Server und übernimmt die
Kommunikation mit den Endpoints. Fällt ein Gateway aus, können die angeschlossenen
Endpoints mit ihren lcfd's die Verbindung zu einem anderen Gateway aufnehmen. Somit ist
eine Software-basierte Redundanz möglich.
• GW
Dieses Gateway-Objekt ist die Schnittstelle, über welche die bidirektionale
Kommunikation der Endpoints mit den managed Nodes ermöglicht wird.
• ITM
Das IBM Tivoli Monitoring ist die Produktbezeichnung für die Überwachungssoftware. Die
ITM-Engine fragt über zugewiesene Monitore Systemzustände ab und bewertet diese
Information anhand vorgegebener Thresholds 1 , um bei Bedarf einen Event zu generieren.
Diese Events werden über den lcfd und das Tivoli Framework an das zugeordnete Gateway
gesendet, welcher die Tivoli Enterprise Console informiert. Hat der lcfd eine Fehlfunktion,
so läuft die ITM-Engine zwar weiter, eine Kommunikation zum Tivoli Framework ist
jedoch nicht mehr möglich. Eine eigene SMTP 2 -Engine bringt das ITM nicht mit, jedoch
kann eine lokale Aktion oder auch ein Task 3 ausgeführt werden.
• lcfd (lightweight client framework daemon)
Dieser Daemon 4 bildet mit den oserv-Prozessen das Tivoli Framework. Über den lcfd wird
die Verbindung des Endpoints mit dem zugeordneten TMR-Server oder managed Node
aufrecht erhalten. Fällt dieser aus, kann der lcfd zu einem anderen Gateway Kontakt
aufnehmen, sofern dieser bekannt und dem selben TMR-Server zugeteilt ist. Ausserdem
kümmert sich der lcfd um das dynamische Nachladen von Software-Komponenten, welche
auf dem Endpoint benötigt werden.
1 [engl.]: der Grenzwert
2 Das Simple Mail Transfer Protokoll (SMTP) dient dem Austausch von eMails.
3 hier: Ein auf dem TMR-Server hinterlegtes Programm oder Script, welches bei Bedarf lokal auf dem
Endpoint ausgeführt wird.
4 Als Daemon wird unter Unix ein Prozess bezeichnet, welcher im Hintergrund läuft. Einmal gestartet, wartet er
auf bestimmte Ereignisse und tritt dann in Aktion.

- 30 -
• managed Node
Als managed Node wird ein Rechner bezeichnet, auf welchem der oserv-Prozess läuft.
Abhängig von den definierten Objekten und installierten Software-Komponenten ist ein
managed Node fähig, verschiedene Aufgaben innerhalb der TMR zu übernehmen.
• oserv (Tivoli Object Dispatcher)
Der oserv stellt (mit den lcfd’s) das grundlegende Kommunikationsgerüst für das Tivoli
Framework bereit. Es handelt sich dabei um eine Softwarekomponente, die auf den
managed Nodes installiert wird.
• TEC (Tivoli Enterprise Console)
Die TEC nimmt die Events entgegen, legt diese in einer Datenbank ab und zeigt sie mit
Hilfe eines GUI's 1 an.
• TMR (Tivoli-Managed-Region)
Die logische Zusammenfassung von TMR-Server, managed-Node(s) und Endpoints.
Aktuell sind pro TMR genau ein TMR-Server und maximal eine TEC möglich.
Die Erfahrung zeigt, das kommerzielle Lösungen wie IBM/Tivoli ein hohes Maß an
individueller Anpassung benötigen, um in einer so komplexen Umgebung wie der
Volkswagen AG eingesetzt werden zu können. Zwar mag dies durch die Unterstützung des
Herstellers anfangs einfacher erscheinen, jedoch ist man gerade dadurch an das Unternehmen
gebunden. Weiterhin hat die Erfahrung gezeigt, daß sich der scheinbare Vorteil des Hersteller-
Supports in der Realität auch als nachteilig herausstellen kann. Bei notwendigen Anpassungen
und Fehlerkorrekturen muss auf das Handeln des Herstellers gehofft werden, welcher oft nicht
in angemessener Zeit reagiert. OpenSource-Produkte mit offenem Quellcode hingegen, lassen
schnelle Reaktionen bei Fehlerbereinigung, Erweiterbarkeit und Wartbarkeit im eigenen
Unternehmen zu.
In der Studienarbeit Schaffranneck, Sven, (2004, S. 34ff) wurde festgestellt, dass der Einsatz
des OpenSource-Tools Nagios, unter Berücksichtigung der gegebenen Anforderungen,
sinnvoll erscheint. Darauf aufbauend wird diese Folgearbeit ein Proof of Concept vorstellen,
welches die Möglichkeiten und Grenzen von Nagios kritisch aufzeigt.
1 Graphical User Interface (grafische Nutzeroberfläche)

4. Konzept von Nagios
- 31 -
Der von dem Entwickler Ethan Galstad geschützte Begriff Nagios setzt sich aus „network“
und „hagios 1 “ zusammen. Vielen ist Nagios noch unter dem Namen „Netsaint“ geläufig.
Aufgrund der Namenskollision mit einem Security-Scanner nannte Galstad sein Projekt
jedoch im Jahre 2002 um. Seit der Beta Version 1.0b ist Netsaint unter dem neuen Namen
bekannt.
Nagios basiert auf einem zentralen, Plugin-gestützten Ansatz und differenziert sich damit
grundlegend von vielen kommerziellen Mitbewerbern, auch von IBM/Tivoli.
Generell lässt sich zwischen drei Komponenten unterscheiden:
• Der Nagios Process (auch als Core Logic bezeichnet) ist die zentrale Komponente. Hier
werden die Informationen der zu überwachenden Systeme gesammelt, aufbereitet und in
Log-Dateien festgehalten. Erkennt der Nagios Process ein Problem, wird die dafür
festgelegte Eskalationsmethode ausgeführt.
• Das Webinterface und dessen CGI-Skripte lesen die Konfigurations- und Log-Dateien
aus und stellen die Informationen übersichtlich dar. Mit Hilfe einer Named-Pipe 2
können zusätzliche Kommandos aus dem Webinterface an den Nagios Prozess
übergeben werden.
• Plugins werden vom Nagios Prozess aufgerufen, um Informationen über den Status von
Hosts und Services zu sammeln. Diese Plugins können neben beliebigen Scripten auch
kompilierte Programme sein, sofern sie die Nagios-Konventionen berücksichtigen. Perl-
Scripts erfahren durch den Embedded Perl Nagios (EPN) - Interpreter einen
zusätzlichen Geschwindigkeitsschub. Hier wird anstatt dem vollständigen Nachladen
eines Perl-Interpreters beim Aufruf des Perl-Scriptes nur ein Bibliotheksaufruf
verwendet. Zusätzlich lassen sich dann die kompilierten Perl-Scripte für den nächsten
Aufruf zwischenspeichern (perl-cache). Leider funktioniert nicht jedes Perl-Plugin mit
EPN, ein manuelles Kompilieren mit perlcc 3 kann in diesem Fall helfen.
1 griechisch: heilig
2 Pipes ermöglichen den Transport von Daten zwischen Prozessen nach der First In First Out (FIFO) Methode
3 Werkzeug, Bestandteil der Standard Perl Distribution

push
- 32 -
4.1 Architekturbedingte Unterschiede zu IBM/Tivoli
Während IBM/Tivoli mit seinem Framework eher einen dezentralen Ansatz verfolgt, agiert
Nagios von einer zentralen Instanz aus. Eine allgemeingültige Unterscheidung stellt
Abbildung 5 dar:
zentraler / dezentraler
Ansatz
Operator (SMS,
Konsole, eMail)
DEZENTRAL
poll
Zentrale Engine
poll
- erfassen
- bewerten
- eskalieren
ZENTRAL
push
push
- erfassen
- bewerten
- eskalieren
Abbildung 5 zentraler/dezentraler Ansatz
eigene Darstellung

- 33 -
4.1.1 zentraler Ansatz
Ein zentraler Server fragt die zu überwachenden Hosts in einem definierten Intervall ab.
Dienste, die extern sichtbar und überprüfbar sind, können somit leicht erfasst werden.
Dadurch entfällt neben der Installation, Konfiguration und Wartung eines Agenten auf dem zu
überwachenden Host auch der resultierende Ressourcenverbrauch, da die gesamte
„Intelligenz“ 1 des Incident-Management Tools auf einem zentralen Server läuft. Müssen
jedoch Systemdaten erfasst werden, welche nicht auf einem öffentlich zugänglichen Port (wie
HTTP, FTP, TELNET, ...) erfragt werden können, muss der zentrale Ansatz um dezentrale
Komponenten erweitert werden. Die Installation eines simplen Agenten auf dem Host oder
das Ausführen von Befehlen über einen Remote-Zugang verbindet den Komfort des zentralen
mit den vielseitigen Möglichkeiten des dezentralen Ansatzes.
4.1.2 dezentraler Ansatz
Beim dezentralen Ansatz wird auf dem zu überwachenden Host (Endpoint) eine „intelligente“
Software (Agent) installiert. Dieser sammelt autark Informationen über die zu überwachenden
Dienste, Prozesse oder Systemdaten. Die Agenten werden zentral konfiguriert und bekommen
diese Konfiguration danach mitgeteilt. Anhand der nun lokal vorliegenden Konfiguration wird
bei einer Überschreitung der festgelegten Grenzwerte einer Messung der Alarm (Incident)
generiert und entweder als SMS, eMail oder an eine Konsole eskaliert. Die Daten-Erfassung,
-Bewertung und auch die Eskalation geschieht somit dezentral auf den Endpoints. Dadurch ist
nahezu die gesamte „Intelligenz“ dezentral verteilt. Durch die installierten Agenten wird eine
komplexe, lokale Datenerfassung möglich, da ein lokaler Zugriff auf dem Host stattfindet.
Auch lassen sich, abhängig von den Rechten des Agenten, beliebig komplexe Automationen
ausführen.
1 In diesem Falle die Daten-Erfassung, -Bewertung und -Eskalation

- 34 -
4.1.3 Gegenüberstellung IBM/Tivoli und Nagios
Weder IBM/Tivoli noch Nagios halten sich strikt an einen der beiden Ansätze. Vielmehr
versuchen sie die grundlegenden Techniken mit gezielten Veränderungen sowie
Erweiterungen zu vermischen. Die folgende Tabelle stellt die wesentlichen,
architekturbedingten Vor- bzw. Nachteile der beiden Tools im Bezug auf Incident-
Management dar.
Nagios
Tivoli
+
Konfigurationsänderungen lassen sich Konfigurationsänderungen können über das
+
größtenteils zentral durchführen
Framework zentral durchgeführt werden
+
zentrales, „intelligentes“ Scheduling
minimiert die Last auf den Remote-Hosts
- nur lokales Scheduling möglich
+
Aktualität der Zustände abhängig von der
direkte Statusabfrage sämtlicher Systeme
- Zuverlässigkeit der Monitore und des
von zentraler Instanz möglich
Heartbeats
+
Heartbeat-Funktionalität architekturbedingt zusätzliche Heartbeat-Implementierung
-
implementiert
notwendig
+ geringerer Wartungsaufwand -
erhöhter Wartungsaufwand durch verteilte
Komplexität
+ simple Agenten sind robust - komplexe Agenten sind fehleranfällig
-
Änderungen an der Konfiguration benötigt Die meisten Änderungen können on-thy-fly
+
einen Neustart des Prozesses
ohne Neustart durchgeführt werden
- erhöhte Last auf dem Netzwerk +
Entlastung des Netzwerkes durch autarke
Agenten
-
Zugriff auf lokale Ressourcen und lokale
Automation nur mit zusätzlichem Agent
+ Lokale Automation über Agenten möglich
- Hohe Last auf dem Server - Erhöhte Last auf den Remote-Hosts

- 35 -
4.2 Überwachung lokaler Ressourcen mit Nagios
Nach der erfolgreichen Installation von Nagios und seiner Plugins können lokale Ressourcen
sofort konfiguriert und überwacht werden. Der schematische Ablauf der Überwachung sieht
wie folgt aus:
Abbildung 6 Überwachung lokaler Ressourcen
eigene Darstellung
Der Nagios Prozess ruft das Plugin auf (1) und übergibt diesem (i. d. R.) Threshold-Werte.
Das Plugin ermittelt die erforderlichen Daten (2 und 3), bereitet diese auf und vergleicht sie
mit den übergebenen Thresholds. Das resultierende, bewertete Ergebnis wird dem Nagios
Prozess zurückgeliefert (4).
Zusätzlich besteht die Möglichkeit, Perfomance-Daten abzufangen, welche die Plugins seit
der Version 1.4 ergänzend liefern. Die Plugins können auch manuell ausgeführt werden. Um
z.B. den belegten Auslagerungsspeicher zu prüfen, kann ein Aufruf folgendermaßen lauten:
nagios@host-n# check_swap -w50% -c25%
SWAP OK: 68% free (2485 MB out of 3658 MB)|swap=2485MB;1829;914;0,3658
Dem Plugin check_swap werden zwei Thresholds übergeben, eines mit 50%, eines mit 25%.
Die Option -w gibt hierbei den Schwellwert für WARNING, das -c den Schwellwert für
CRITICAL an.

- 36 -
Abhängig von der Architektur liest dieses Plugin die erforderlichen Informationen aus dem
ProcFS 1 (/proc/meminfo) oder ruft spezielle Kommandos auf, welche Daten über den Swap-
Speicher preisgeben. Das Script vergleicht die Daten anhand der WARNING- und CRITICAL-
Thresholds und liefert ein bewertetes Ergebnis zurück. Dabei handelt es sich einerseits um
Informationen in Textform, andererseits um einen Return-Code. Folgende Return-Codes sind
in den Entwicklungs-Richtlinien 2 festgelegt:
0: OK
1: WARNING
2: CRITICAL
3: UNKOWN
Anhand dieser Return-Codes kann der Nagios Prozess das Ergebnis weiter verarbeiten.
nagios@local# echo $?
0
Der Return-Code des hier genannten Beispiels entspricht erwartungsgemäß dem OK.
Erhält der Nagios Prozess das Ergebnis vom Plugin, wird die Status-Datei status.log
aktualisiert und bei einer Status-Änderung sowie für alle kritischen Meldungen ein Eintrag in
die Log-Datei nagios.log geschrieben.
Abhängig von der Konfiguration wird zusätzlich der Event-Handler aufgerufen und
Eskalationsmaßnahmen eingeleitet. Auf diese wird im weiteren Verlauf detaillierter
eingegangen.
1 Das ProcFS ist eine Schnittstelle zu Kernel- und Prozess-Informationen, um diese zur Laufzeit auszulesen
oder zu verändern.
2 Vgl. Nagios Plugins Development Team (2004)

- 37 -
Das Webinterface wertet die status.log aus und bereitet die enthaltenen Status-Informationen
grafisch auf. Abbildung 7 zeigt beispielhaft das Webinterface im Einsatz. Die hinterlegten
Farben repräsentieren den Status des Services.
Abbildung 7 Nagios Webinterface Service Details
Quelle: Screenshot Nagios

- 38 -
4.3 Überwachung entfernter, öffentlicher Ressourcen
Der Zugriff auf entfernte, öffentliche Ressourcen geschieht analog zu den lokalen Ressourcen.
Abbildung 8 verdeutlicht den Vorgang.
Abbildung 8 Überwachung entfernter, öffentlicher Ressourcen
eigene Darstellung
Für den Nagios Prozess macht es keinen Unterschied, ob der zu überwachende Dienst entfernt
oder lokal ist. Er ruft nur ein Plugin auf, welches die Aufgabe hat, einen Return-Code
zurückzuliefern. Um jedoch auf Dienste und Ressourcen zuzugreifen, die nicht über einen
Port am Remote-Host ansprechbar sind, bedarf es einer anderen Lösung.

- 39 -
4.4 Überwachung entfernter, privater Ressourcen
Private Ressourcen unterscheiden sich von öffentlichen Ressourcen insofern, dass sie nicht
direkt von einem entfernten Host abrufbar sind, sondern eine vermittelnde Instanz benötigen.
Für diese vermittelnde Instanz haben sich im Wesentlichen drei unterschiedliche Ansätze
etabliert.
4.4.1 Nagios Remote Plugin Executor (NRPE)
Die verbreitestete Möglichkeit, Plugins auf entfernten Hosts auszuführen, ist der NRPE.
Ebenso wie die Server-Software Nagios, wird NRPE von Ethan Galstad entwickelt und
gepflegt. Zum Zeitpunkt dieser Arbeit hat der Daemon den Versionsstand 2.0 und ist auf der
Nagios-Webseite (http://www.nagios.org/download/extras.php) zu finden.
4.4.1.1 Konzept und Implementierung
Der NRPE kommt der Idee einer vermittelnden Instanz am nahsten.
Abbildung 9 Indirekter Service-Check mit NRPE
eigene Darstellung

- 40 -
Der Nagios Prozess ruft, wie gewohnt, ein lokales Plugin auf; in diesem Fall check_nrpe.
Dieses Plugin fragt jedoch nicht direkt eine Ressource ab, sondern bildet mit dem NRPE-
Daemon eine, für den Nagios Prozess nicht sichtbare, Vermittlungsschicht. Über Optionen,
die check_nrpe übergeben werden, ruft der NRPE-Daemon ein lokales Plugin auf dem
entfernten Host auf. Das Ergebnis wird daraufhin dem check_nrpe zurückgegeben, welcher es
an den Nagios Prozess durchreicht.
4.4.1.2 Sicherheitsmerkmale
Der NRPE unterstützt SSL sowie IP-Restriction als Sicherheitsmerkmale. Um SSL nutzen zu
können, muss beim Kompilieren die Option --enable-ssl angegeben werden. Weiterhin muss
das OpenSSL 1 -Paket installiert sein. In dieser Arbeit wurde auf OpenSSL 0.9.7
zurückgegriffen.
Zur Authentifikation des Nagios-Servers muss dessen IP explizit in der NRPE-Konfiguration
angeben werden. Diese Authentifizierung ist nicht sehr sicher, da IP's leicht zu fälschen sind.
Des Weiteren muss die Konfiguration auf sämtlichen entfernten Hosts modifiziert werden,
wenn sich die IP des Nagios-Servers ändert. Diese Art der Authentifizierung ist jedoch in den
meisten Fällen ausreichend (im Bezug auf den NRPE).
Der NRPE läuft per Default unter Benutzer:Gruppe nagios:nagios. Somit werden auch die
Plugins mit diesem Benutzer aufgerufen und ausgeführt. Werden für spezielle Anforderungen
andere Nutzerrechte verlangt, kann entweder auf die SUDO 2 -Funktionalität zurückgegriffen
werden, oder es wird ein Binary verwendet, welches mit dem SUID 3 -Flag versehen ist.
Letzteres ist unter Sicherheitsaspekten jedoch als kritisch anzusehen und sollte in der Praxis
vermieden werden.
1 Das OpenSSL-Projekt, stellt eine freie SSL (v2/v3) und TLS (v1) Protokoll-Implementierung bereit und ist
unter http://www.openssl.org zu finden.
2 SUDO (von „Superuser DO“) erlaubt benannten Benutzern oder Gruppen Root-Level Befehle auszuführen,
ohne das Root-Passwort zu verwenden. SUDO zeichnet auch sämtliche Befehle und Argumente detailliert in
einer Log-Datei auf und ermöglicht so, seine Verwendung nachzuvollziehen.
3 Ein spezielles Bit in den Permissions einer Datei ermöglicht das Ausführen dieser Datei unter dem Benutzer,
welchem die Datei gehört. Gerade solche Dateien sind jedoch beliebte Angriffsziele für böswillige Nutzer,
welche über Buffer-Overflows an fremde Rechte gelangen können.

- 41 -
4.4.1.3 Konfiguration
Die Konfiguration des NRPE-Daemons erfolgt in erster Linie dezentral. Folgende Optionen
sind vorhanden:
• server_port=
Nummer des Ports auf welchem der Daemon auf Verbindungen wartet.
• server_address=
Lokale IP-Adresse, an die sich der NRPE binden soll. Gerade in Cluster-Umgebungen ist
diese Funktion von Vorteil. Ist diese Option nicht angegeben, bindet sich der NRPE an alle
Interfaces.
• allowed_hosts=
Eine mit Kommas getrennte Liste von Hosts, die eine Verbindung zum NRPE aufnehmen
dürfen. Da diese Überprüfung intern nur rudimentär stattfindet, wird die Verwendung von
inetd 1 bzw. xinetd 2 empfohlen, um nur speziellen Hosts den Zugriff auf den Port des NRPE
zu erlauben.
Wird NRPE mit inetd oder xinetd verwendet, ist diese Option ohne Bedeutung.
• nrpe_user=
Der Benutzername oder die ID, unter welcher der NRPE laufen soll.
Wird NRPE mit inetd oder xinetd verwendet, ist diese Option ohne Bedeutung.
• nrpe_group=
Der Gruppenname oder die ID, unter welcher der NRPE laufen soll.
Wird NRPE mit inetd oder xinetd verwendet, ist diese Option ohne Bedeutung.
• dont_blame_nrpe=
Anhand dieser Option wird entschieden, ob dem NRPE-Daemon zusätzliche Argumente
übergeben werden dürfen. Diese Argumente können beim Ausführen von lokalen Plugins
berücksichtigt werden. Es wird jedoch explizit darauf hingewiesen, dass das Aktivieren
dieser Option ein Sicherheitsrisiko darstellt.
1 Der inetd ist ein „Superserver“, welcher auf ankommende Verbindungen wartet, diese annimmt und den
passenden Serverprozess startet, für welchen die Verbindung bestimmt ist. Daraus ergibt sich der Vorteil, das
nicht jeder Netzwerkdienst permanent laufen und System-Ressourcen belegen muss, sondern automatisch bei
Bedarf gestartet werden kann.
2 Das „x“ vor dem inetd steht für „extended“. Die Erweiterungen beziehen sich primär auf unterschiedliche
Sicherheitstechniken.

- 42 -
• debug=
Diese Option bestimmt, ob Debug-Meldungen in die Syslog 1 geschrieben werden, oder
nicht.
• command_timeout=
Hiermit wird die maximale Sekundenanzahl festgelegt, die der NRPE-Daemon auf das
Beenden eines Plugins wartet, bevor dieses aktiv beendet wird.
• include=
Diese Option erlaubt das Einlesen von weiteren Konfigurationsdateien.
• include_dir=
Jede Datei mit der Endung .cfg wird in dem hier angegebenen Verzeichnis oder
Unterverzeichnis eingelesen und verarbeitet.
• command[]=
Diese Option erlaubt Kommando-Definitionen, welche der NRPE-Daemon ausführen
kann. Innerhalb dieser Definitionen können Variablen verwendet werden, welche dem
NRPE-Daemon beim Aufruf übergeben werden. Hierzu muss der NRPE-Daemon jedoch
mit --enable-command-args kompiliert und in der Konfiguration die Option
dont_blame_nrpe aktiviert werden. Ein Beispiel zur Überwachung des Swap-Spaces könnte
wie folgt aussehen:
command[check_swap]=../libexec/check_swap -w 50% -c 25%
Wurde der NRPE-Daemon vollständig konfiguriert, kann er gestartet werden.
nagios@host-a: ./nrpe -c nrpe.cfg -d
nagios@host-a: pidof nrpe
7451
Die Option -c ermöglicht das Übergeben einer Konfigurationsdatei und die Option -d startet
den NRPE als Daemon. Mit pidof 2 wird überprüft, ob der Daemon-Prozess tatsächlich
gestartet wurde.
1 Unter Unix dient das Konzept des Syslog-Dämons dazu, Logging-Nachrichten wie Warnungen oder
bemerkenswerte Ereignisse aufzufangen und in einer Datei abzuspeichern.
2 pidof ist ein Linux Standardtool um die ID eines Prozesses anzeigen zu lassen.

- 43 -
4.4.1.4 Aufruf des check_nrpe
Über das check_nrpe Plugin kann der Nagios-Server eine Verbindung mit dem entfernten
NRPE-Daemon aufnehmen. Folgende Optionen sind möglich:
• -H
Adresse des entfernten Hosts, auf welchem der NRPE-Daemon läuft.
• [-p ] [default=5666]
Portnummer des NRPE-Daemon.
• [-t ] [default=10]
Maximale Anzahl der Sekunden die check_nrpe auf ein Ergebnis warten soll.
• [-c ]
Der Name des Kommandos, welches aufgerufen werden soll. Dieses muss einem
definierten Kommando aus der nrpe.cfg entsprechen.
• [-a ]
Eine Liste von Argumenten, welche dem Kommando übergeben werden sollen. Diese
Option wird nur ausgewertet, wenn der NRPE mit --enable-command-args kompiliert und
in der nrpe.cfg die Option dont_blame_nrpe aktiviert wurde.
• [-n]
Dieser undokumentierte Switch zwingt das check_nrpe eine Verbindung ohne SSL
aufzubauen. Wenn der NRPE-Daemon ohne, das Plugin check_nrpe jedoch mit
SSL-Support kompiliert wurde, ist die Verwendung dieser Option notwendig.

- 44 -
Im Folgenden wird von dem Nagios-Server über das check_nrpe Plugin eine Verbindung zum
NRPE-Daemon aufgebaut.
nagios@host-n: ./check_nrpe -H host-a
NRPE v2.0
Da keine weiteren Argumente übergeben wurden, antwortet der NRPE-Daemon nur mit seiner
Versionsnummer. Der Verbindungstest war erfolgreich.
Wurde der NRPE mit --enable-command-args kompiliert, besteht die Möglichkeit, die Plugins
nahezu komplett zentral zu konfigurieren. Hierzu kann ein Template-Command wie folgt
konfiguriert werden:
command[check_args]=../libexec/check_$ARG1$ $ARG2$
Über den Aufruf des check_nrpe lässt sich nun neben den Thresholds auch das Plugin selbst
variieren.
nagios@host-n# ./check_nrpe -H host-a -c check_template -a "swap -w50% -c25%"
In diesem Falle wird auf host-a das Plugin ../libexec/check_swap mit den Argumenten
-w50% -c25% aufgerufen.
4.4.1.5 Zusammenfassung
Die Features des NRPE sind in der nachfolgenden Tabelle noch einmal zusammengefasst.
Features
NRPE
sichere Authentifikation -
IP-Restriction
X
Verschlüsselung
X
Remote-Plugins ausführbar
X
Software Distribution -
Plugins Ausführung unter anderem User z.T. / -
Asynchrone Funktionalität -
Externes Scheduling -
Scheduling über Nagios
X
Zentrale Konfiguration
X
Lokale Konfiguration
X
In der Praxis zeigt sich der Einsatz des NRPE als robust und effektiv. Selbst bei der
Verwendung von SSL ergeben sich keine kritischen Performance-Einbußen. Der wesentliche
Nachteil des NRPE besteht in der begrenzten Authentifikationsmöglichkeit.

- 45 -
4.4.2 Nagios Service Check Acceptor (NSCA)
Der zweite von Galstad gepflegte Daemon ist der Nagios Service Check Acceptor (NSCA).
Mit Hilfe des Clients send_nsca ermöglicht der NSCA das Übermitteln von Service-Check
Ergebnissen an den Nagios Prozess. Zum Zeitpunkt dieser Arbeit ist der NSCA in der Version
2.4 aktuell und ebenso wie der NRPE auf der Nagios-Homepage
(http://www.nagios.org/download/extras.php) zu finden.
4.4.2.1 Konzept und Implementierung
Bei der Verwendung des NRPE kann Nagios auf seine übliche Funktionalität, das Aufrufen
von Plugins, zurückgreifen. Der NSCA kommt immer dann zum Einsatz, wenn auf das
Nagios-interne Scheduling verzichtet werden kann oder muss. Das kann der Fall sein, wenn
Statusmeldungen von lokalen Maintenance-Tools übermittelt werden sollen, die auf dem
lokalen Rechner über cron 1 gestartet werden. Eine zweite Einsatzmöglichkeit bietet NSCA für
den Fall, dass das auszuführende Plugin eine hohe Laufzeit aufweist und die üblichen Nagios-
Timeouts überschreitet. Solche Plugins oder Scripte werden in dieser Arbeit als Longrunner
bezeichnet.
1 Cron ist ein Programm, welches Unix-Benutzern automatisches Ausführen von Scripts und Programmen zu
einem, auf die Minute konfigurierbaren, Zeitpunkt erlaubt

- 46 -
In Abbildung 10 ist die primäre Verwendung des NSCA zu sehen.
Abbildung 10 Passiver Service-Check mit NSCA
eigene Darstellung
Der externe Scheduler stößt ein Script an, welches entweder selbst oder mit Hilfe eines
weiteren Plugins die gewünschen Daten sammelt, bewertet und das Ergebnis über den NSCA-
Client send_nsca an den NSCA-Daemon sendet. Dieser schreibt die empfangenen
Informationen in das External Command File des Nagios Prozesses, welches zyklisch
ausgelesen und abgearbeitet wird.
Wird als externer Scheduler beispielsweise cron verwendet, so lassen sich genaue Startzeiten
definieren, zu welchen der lokale Longrunner gestartet werden soll. Dieser Komfort erhöht
jedoch den Aufwand für Wartung und Pflege, da hierzu Einstellungen am entfernten Host
vorgenommen werden müssen. Eine Lösung bietet die Kombination des NSCA mit dem
NRPE. Hierzu wird der externe Scheduler durch den NRPE ersetzt, welcher durch das
Scheduling des Nagios Prozesses angestossen wird.

- 47 -
Abbildung 11 Longrunner mit NSCA und NRPE
eigene Darstellung
Im Nagios wird ein zusätzlicher Service konfiguriert, der das Script auf Host A mit Hilfe des
check_nrpe Plugins aufruft. Im ersten Schritt bedient das gestartete Script den NRPE und
übergibt diesem ein Rückgabewert mit der Information, erfolgreich gestartet worden zu sein.
Diese Daten werden über das check_nrpe Plugin an den Nagios Prozess geliefert, welcher den
gestarteten Service als OK anerkennt.
Im zweiten Schritt startet das Script seine eigentliche Funktion und sammelt die gewünschten
Daten. Der Übertragungsweg des Ergebnisses ist analog zum vorherigen Beispiel.
4.4.2.2 Sicherheitsmerkmale
Der NSCA erfüllt die wichtigsten Sicherheitsmerkmale. Wie der NRPE unterstützt der NSCA
auch die Beschränkung auf festgelegte IP-Adressen. Jedoch muss in diesem Falle jede IP
sämtlicher entfernter Hosts in der Konfigurationsdatei des NSCA eingetragen werden, was
den Konfigurationsaufwand erheblich steigert.

- 48 -
Weiterhin kann die Kommunikation zwischen dem NSCA-Client und -Daemon über
verschiedene Verfahren verschlüsselt werden, darunter auch XOR. Gerade auf Plattformen,
auf denen sich die OpenSSL-Unterstützung als problematisch herausstellt, ist dies von
Interesse, da für die XOR „Verschleierung“ 1 keine SSL-Library benötigt wird und sie
bedeutend schneller als 3DES 2 oder Blowfish 3 arbeitet.
Der NSCA-Daemon kann unter einem beliebigen Benutzer laufen. Als einzige Voraussetzung
benötigt er den schreibenden Zugriff auf das External Command File des Nagios Prozesses.
Der Aufruf von send_nsca ist ebenso benutzerunabhängig, lediglich der lesende Zugriff auf
die Konfigurationsdatei wird benötigt. Damit ist es möglich, Befehle unter verschiedenen
Benutzern aufzurufen und resultierende Ergebnisse mit send_nsca zu verschicken.
4.4.2.3 Konfiguration des NSCA-Daemons
Im Gegensatz zum NRPE ist der NSCA eine zentrale Instanz, zu welcher die Clients ihre
Daten liefern. Daher ist auch die Konfiguration des Daemons an einer einzigen, zentralen
Stelle möglich.
Folgende Optionen enthält die nsca.cfg:
• server_port=
Nummer des Ports, auf welchem der Daemon auf Verbindungen horcht.
• server_address=
Lokale IP-Adresse, an die sich der NSCA binden soll. Ist diese Option nicht angegeben,
bindet sich NSCA an alle Interfaces.
• allowed_hosts=
Eine mit Kommas getrennte Liste von Hosts, die eine Verbindung zum NSCA aufnehmen
dürfen. Da diese Überprüfung intern nur rudimentär stattfindet, wird die Verwendung des
inetd empfohlen, um nur speziellen Hosts den Zugriff auf den NSCA zu erlauben.
• nsca_user=
Der Benutzername oder die ID, unter welcher der NSCA laufen soll.
Wird NSCA mit inetd oder xinetd verwendet, ist diese Option ohne Bedeutung.
1 Vgl: Galstad, Ethan (2002), Sample NSCA Daemon Config File
2 Der DES (Data Encryption Standard) ist einer der bekanntesten Algorithmen für symmetrische
Verschlüsselung. Beim 3DES (Tripple DES) wird dieser dreifach hintereinander angewendet, um eine höhere
Sicherheit zu erreichen.
3 Blowfish ist ebenso wie DES eine Blockchiffrierung, jedoch wesentlich schneller als DES.

- 49 -
• nsca_group=
Der Gruppenname oder die ID, unter welcher der NSCA laufen soll.
Wird NSCA mit inetd oder xinetd verwendet, ist diese Option ohne Bedeutung.
• debug=
Diese Option bestimmt, ob Debug-Meldungen in die Syslog geschrieben werden.
• command_file=
Vollständiger Pfad zu dem Nagios External Command File.
• alternate_dump_file=
Sollte der Nagios Prozess einmal nicht laufen, so kann der NSCA keine Daten in das
External Command File schreiben. Die Option alternate_dump_file gibt eine alternative
Datei an, in welcher die zwischenzeitlich auftretenden Ergebnisse gespeichert werden
können. Es empfiehlt sich das Start-Script des Nagios Prozesses dahingehend abzuändern,
dass nach dem Start von Nagios der Inhalt des alternate_dump_file in das External
Command File geschrieben wird.
• aggregate_writes=
Diese Option erhöht die Effizienz beim Schreiben von Ergebnissen, indem mehrere
Ergebnisse in einem Paket geschrieben werden, anstatt jedes einzelne für sich in das
External Command File abzulegen. Es können jedoch nur Ergebnisse zusammengefasst
werden, welche zuvor von einem Client gesammelt und in einem Durchgang übertragen
wurden.
• append_to_file=
Diese Option steuert den Zugriff auf das External Command File und sollte „absolut
immer“ 1 auf den Wert 0 gesetzt werden (das External Command File wird schreibend
geöffnet). Im Falle des Wertes 1 wird die Named Pipe 2 anhängend (appending) geöffnet.
1 Vgl: Galstad, Ethan (2002), Sample NSCA Daemon Config File
2 Als Named Pipe (oder FIFO) wird unter Unix eine virtuelle Datei bezeichnet, die nur im Speicher existiert
und als eine Schnittstelle zwischen Prozessen dienen kann. Daten können nach dem First-In/First-Out Prinzip
in die Named Pipe geschrieben und ausgelesen werden.

- 50 -
• max_packet_age=
Mit Hilfe dieser Option wird die Verfallszeit von Ergebnissen definiert, welche von den
entfernten Hosts übertragen werden. Der Wert sollte möglichst klein gehalten werden, um
möglichen „replay“-Attacken 1 vorzubeugen. Er entspricht der Zeit, die der entfernte Host
benötigt, seine Daten zum NSCA-Daemon zu schicken. Ein Wert über 900 (Sekunden) ist
nicht möglich.
• password=
Hier wird das Passwort angegeben, welches zum Entschlüsseln der empfangenen Pakete
verwendet werden soll. In Verbindung mit dem richtigen Verschlüsselungsverfahren lassen
sich die übermittelten Daten wiederherstellen.
• decryption_method=
Die Entschlüsselungsmethode, welche verwendet werden soll. Die Liste der möglichen
Varianten ist der Konfigurationsdatei (Vgl: Galstad, Ethan (2002), Sample NSCA Daemon
Config File) zu entnehmen. Bei der Auswahl sollte auf eine gute Balance zwischen
Sicherheit und Performance geachtet werden. Die hier angegebene
Entschlüsselungsmethode muss mit der Verschlüsselungsmethode der NSCA-Clients
übereinstimmen.
Wurde der NSCA-Daemon vollständig konfiguriert, kann er gestartet werden.
nagios@host-n: ./nsca -c nsca.cfg
nagios@host-n: pidof nsca
844
Die Option -c ermöglicht das Übergeben einer Konfigurationsdatei. Mit pidof wird überprüft,
ob der Daemon-Prozess tatsächlich gestartet wurde.
1 Als replay-Attacken werden Angriffe bezeichnet, welche ein gültiges Paket aus dem Netzwerkverkehr
herrausfiltern und erneut übermitteln. Anhand der darauf folgenden Antworten lassen sich nähere
Informationen über das Ziel-System ermitteln oder einfache Denial-of-Service Attacken durchführen.

- 51 -
4.4.2.4 Konfiguration des NSCA-Clients (send_nsca)
Die Konfiguration von send_nsca beinhaltet zwei Parameter:
• password=
Hier wird das Passwort angegeben, welches zum Verschlüsseln der zu versendenden
Pakete verwendet werden soll. Dieses Passwort muss dem des NSCA-Daemons
entsprechen.
• encryption_method=
Diese Option gibt die Verschlüsselungsmethode an, welche verwendet werden soll. Die
Liste der möglichen Varianten ist der Konfigurationsdatei (Vgl: Galstad, Ethan (2002),
Sample NSCA Client Config File) zu entnehmen. Bei der Auswahl sollte auf eine gute
Balance zwischen Sicherheit und Performance geachtet werden. Die hier angegebene
Verschlüsselungsmethode muss mit der Entschlüsselungsmethode des NSCA-Daemons
übereinstimmen.
4.4.2.5 Aufruf des send_nsca
Der NSCA-Client send_nsca übermittelt beliebige Service-/Host-Check Ergebnisse an den
NSCA-Daemon. Dieses Ergebnis muss einem definierten Format entsprechen. Als
Trennzeichen werden Tabulatoren verwendet, hier als [tab] gekennzeichnet. Mehrere
Ergebnisse können zeilenweise übertragen werden.
• Service-Checks:
[tab][tab][tab][newline]
• Host-Checks:
[tab][tab][newline]
Die Schlüsselwörter werden wie folgt definiert:
• hostname
Bei Service-Check: Kurzname des Hosts, mit welchem der Service assoziiert ist.
Bei Host-Check: Kurzname des Hosts.
• descr
Beschreibung des Services.
• ret_code
Der Return-Code des Ergebnisses (siehe Seite 36).
• plugin_out
Ausgabe des Plugins im ASCII-Format.

- 52 -
Diese Check Ergebnisse werden dem send_nsca über stdin 1 übergeben. Weiterhin sind
folgende Optionen beim Aufruf von send_nsca möglich.
• -H
Adresse des entfernten Hosts, auf welchem der NSCA-Daemon läuft.
• [-p ] [default=5667]
Portnummer des NSCA-Daemon.
• [-to ] [default=10]
Maximale Anzahl der Sekunden, bevor die Verbindung abgebrochen wird.
• [-d ] [default=tab]
Trennzeichen für das Check Ergebnis.
• [-c config_file]
Name und Pfad der Konfigurationsdatei.
Im folgenden Beispiel wird ein Service-Check Ergebnis von dem Host debian zu dem Nagios-
Server mit der IP 10.101.202.101 übertragen. Zur klaren Erkennung des Trennzeichens wurde
der Tabulator durch die Zeichenfolge [tab] substituiert.
nagios@debian# echo “debian[tab]passive[tab]0[tab]OK Übertragung mit NSCA\
erfolgreich am `date`“ | ./send_nsca -H 10.101.202.101 -c\
send_nsca.cfg
1 data packet(s) sent to host successfully.
Zuletzt bestätigt send_nsca das erfolgreiche Übertragen eines Ergebnisses an den NSCA-
Daemon, welches sich daraufhin im Webfrontend des Nagios Prozesses präsentiert:
Abbildung 12 Passiver Service-Check im Webfrontend
Quelle: Screenshot
1 Der Stream „stdin“ entspricht der Standardeingabe unter Unix/Linux-Derivaten

- 53 -
In der letzten Zeile der Abbildung 12 ist der soeben übertragene Service-Check mit der
Bezeichnung „passiv“ wiederzufinden. Das rote „P“ neben der Bezeichnung gibt an, das es
sich um einen passiven Check handelt und Nagios keine aktiven Checks für diesen Service
von sich aus startet.
4.4.2.6 Zusammenfassung
Die nachfolgende Tabelle stellt die Features des NSCA noch einmal zusammengefasst dar.
Features
NSCA
sichere Authentifikation
X
IP-Restriction
X
Verschlüsselung
X
Remote-Plugins ausführbar
X
Software Distribution -
Plugins Ausführung unter anderem User X
Asynchrone Funktionalität
X
Externes Scheduling
X
Scheduling über Nagios -
Zentrale Konfiguration -
Lokale Konfiguration
X
Der NSCA fällt insbesondere durch seine Sicherheitsmechanismen positiv auf. Bezüglich der
Flexibilität nimmt der Nagios Service-Check Acceptor die oberste Position ein.
Aufwändig erscheint jedoch die Pflege der freigegebenen IPs in der nsca.cfg. Zwar bietet die
allowed_hosts-Direktive Schutz vor gefälschten Ergebnissen von unbekannten Hosts.
Dadurch das einige Server mehrere IPs besitzen und sich ihre IPs ändern können, besteht die
Gefahr, das Artefakte zurück bleiben.
Ein wichtiges Merkmal ist die Abhängigkeit zu einem externen Scheduler. Der
Nagios Prozess kann zwar ebenso als Scheduler für send_nsca verwendet werden, dieses
Szenario bringt jedoch erhöhten Konfigurationsaufwand mit sich.

- 54 -
4.4.3 Plugin check_by_ssh
Die dritte Möglichkeit an private Ressourcen entfernter Hosts zu gelangen, bietet das
check_by_ssh Plugin. Das Prinzip entspricht dem des NRPE, mit dem Unterschied, das auf
den zumeist vorhandenen SSH-Daemon zurückgegriffen wird. Damit kann die Installation,
Konfiguration und Wartung eines zusätzlichen Daemons vermieden werden. Insbesondere für
entmilitarisierte Zonen (DMZ 1 ) ist diese Methode interessant, da kein weiterer Port geöffnet
werden muss, sofern bereits SSH erlaubt wird.
4.4.3.1 Konzept und Implementierung
Wie beim NRPE ruft der Nagios Prozess ein Plugin auf, welches ihm ein Ergebnis
zurückliefert. Zuvor baut es eine SSH-Verbindung zum entfernten Host auf und führt dort das
gewünschte Plugin aus.
Abbildung 13 Indirekter Service-Check mit check_by_ssh
eigene Darstellung
Die Information, auf welchem Host welches Plugin auszuführen ist, wird dem Plugin vom
Nagios Prozess über die Kommandozeile mitgeteilt.
1 Bei einer DMZ (Demilitarized Zone) handelt es sich um einen geschützten Rechnerverbund, der sich
zwischen zwei Netzwerken befindet. Der Rechnerverbund wird jeweils durch eine Firewall gegen das
dahinterstehende Netzwerk abgeschirmt.

- 55 -
4.4.3.2 Sicherheitsmerkmale
Bei SSH handelt es sich um ein sicheres Verfahren, das sich weltweit bewährt hat. Die
Verwendung des SSH-Protokolls erlaubt eine sichere Authentifkation und Verschlüsselung
mittels Public-Key-Verfahren. Der hohe Sicherheitsstandard hat jedoch eine schlechte
Performance als Preis.
Das für diese Arbeit verwendete OpenSSH ist eine freie Implementierung der SSH
Protokollsammlung und ist für viele Plattformen verfügbar. Die aktuelle Version 3.8 wurde
am 24. Februar 2004 freigegeben und ist unter http://www.openssh.org zu finden.
4.4.3.3 Konfiguration der Secure Shell (SSH)
Zur Authentifikation wird das Public-Key-Verfahren verwendet. Host N hält den privaten
Schlüssel vor, sämtliche entfernten Hosts haben den Public Key des Benutzers nagios in ihrer
~/.ssh/authorized_keys eingetragen. Zusätzlich müssen die öffentlichen Host-Schlüssel
sämtlicher entfernter Hosts in der ~/.ssh/know_hosts auf dem Nagios-Server stehen 1 . Sind
diese Voraussetzungen erfüllt, ist ein passwortloser Zugriff vom Nagios Host auf die
entfernten Hosts möglich.
Die Default-Optionen der sshd.conf sind für den Betrieb dieser Lösung bereits ausreichend.
Sollten diese verändert werden, so ist darauf zu achten, folgende Einstellungen beizubehalten:
• RSAAuthentication yes
Erlaubt die RSA-Authentifikation. Diese Option muss aktiviert sein, wird das alte SSH-
Protokoll 1 verwendet. Für Version 2 hat diese Option keine Bedeutung.
• PubkeyAuthentication yes
Gibt an, ob eine Authentifikation mit dem Public-Key-Verfahren erlaubt wird.
1 Durch die Deaktivierung des StrictHostKeyChecking kann die umständliche Pflege der Host-Keys umgangen
werden, s. Seite 127.

- 56 -
4.4.3.4 Aufruf des check_by_ssh Plugins
Das aktive, indirekte Service-Check-Verfahren mit check_by_ssh wird über die vielseitigen
Optionen des Plugins gesteuert.
• [-f]
Zwingt den SSH-Prozess in den Hintergrund, kurz bevor das übergebene Kommando
ausgeführt wird.
• [-4], [--use-ipv4]
Gibt an, das Internet Protokoll in der Version 4 zu verwenden.
• [-6], [--use-ipv6]
Gibt an, das Internet Protokoll in der Version 6 zu verwenden.
• [-t timeout ]
Maximale Anzahl der Sekunden, die check_by_ssh auf ein Ergebnis warten soll.
• [-l user], [--logname=USERNAME]
SSH Benutzername auf dem entfernten Host.
• -H , --hostname=ADDRESS
Hostname oder IP-Adresse des entfernten Hosts.
• -C , --command='COMMAND STRING'
Kommando, welches auf dem entfernten Host ausgeführt werden soll.
• [-n name], [--name=NAME]
Name des Hosts aus der Nagios Konfiguration. Sinnvoll beim Einsatz des check_by_ssh
Plugins für passive Service-Checks.
• [-s servicelist], [--services=LIST]
Eine Liste der Nagios Service-Bezeichnungen, durch „:“ getrennt. Sinnvoll beim Einsatz
des check_by_ssh Plugins für passive Service-Checks.
• [-O outputfile], [--output=FILE]
Pfad zum External Command File von Nagios. Sinnvoll beim Einsatz des check_by_ssh
Plugins für passive Service-Checks.

- 57 -
• [-p port], [--port=INTEGER]
Port des SSH-Daemons, zu welchem die Verbindung aufgebaut werden soll.
• [-h], [--help]
Aufruf der ausführlichen Hilfe von check_by_ssh.
• [-V], [--version]
Information über die Version von check_by_ssh.
• [-1], [--proto1]
Zwingt SSH, die Protokoll-Version 1 zu verwenden.
• [-2], [--proto1]
Zwingt SSH, die Protokoll-Version 2 zu verwenden.
• [-w], [--warning=DOUBLE]
Anzahl der Sekunden, bevor der WARNING-Status zurückgegeben wird.
• [-c], [--critical=DOUBLE]
Anzahl der Sekunden, bevor der CRITICAL-Status zurückgegeben wird.
Soll check_by_ssh im passiv-Modus verwendet werden, so können mehrere „-C“ Optionen
angegeben werden. Dies setzt die Verwendung der Optionen „-O“, „-s“ und „-n“ voraus. Die
Liste der Services muss der Reihenfolge der „-C“-Optionen entsprechen 1 .
Ein typischer Aufruf zur Überprüfung des Auslagerungsspeichers auf dem entfernten Host A
mit Hilfe des check_by_ssh Plugins sieht wie folgt aus:
nagios@host-n# ./check_by_ssh -H host-a -C "./check_swap -w50% -c25%"
SWAP OK: 51% free (1806 MB out of 3549 MB)|swap=1806MB;1774;887;0;3549
Der Rückgabewert entspricht dem des check_swap Plugins, welchen der Nagios Prozess weiter
verarbeiten kann.
1 Vgl: Nagios Plugin Development Team (2003), check_by_ssh detailed help

- 58 -
4.4.3.5 Zusammenfassung
Zusammenfassend ergibt sich folgende Übersicht der Features:
Features
check_by_ssh
sichere Authentifikation
X
IP-Restriction
X
Verschlüsselung
X
Remote-Plugins ausführbar
X
Software Distribution
X
Plugins Ausführung unter anderem User X
Asynchrone Funktionalität -
Externes Scheduling -
Scheduling über Nagios
X
Zentrale Konfiguration
X
Lokale Konfiguration -
Zwar ist das check_by_ssh Plugin sehr flexibel, jedoch bringt es einen entscheidenden
Nachteil mit sich. Für jeden Check muss der SSH-Client aufgerufen werden. Dieser ist, im
Vergleich zum NRPE oder NSCA, sehr ressourcenlastig. Insbesondere bei einer großen
Anzahl von Service-Checks/Minute ist von dem Einsatz dieses Plugin's abzuraten. Für den
gezielte Einsatz in Firewallumgebungen können die Vorteile von check_by_ssh jedoch
überwiegen.

- 59 -
4.4.4 Fazit
Der Einsatz eines „Agenten“ (vermittelnde Instanz) ist zwingend notwendig, sollen private
Ressourcen in die Überwachung aufgenommen werden. Sinnvoll ist eine Kombination der
verschiedenen Möglichkeiten, um sämtliche Benefits auszunutzen. Die nachfolgende Tabelle
stellt die wesentlichen Eigenschaften der einzelnen Tools dar.
Features NRPE NSCA check_by_ssh
sichere Authentifikation - X X
IP-Restriction X X X
Verschlüsselung X X X
Remote-Plugins ausführbar X X X
Software Distribution - - X
Plugins Ausführung unter anderem User z.T. / - X X
Asynchrone Funktionalität - X -
Externes Scheduling - X -
Scheduling über Nagios X - X
Zentrale Konfiguration X - X
Lokale Konfiguration X X -
Da der NRPE die geringste Komplexität aufweist, empfiehlt er sich als Agent für die breite
Masse. Einmal auf sämtlichen entfernten Hosts installiert, lassen sich die Schwellwerte und
weitere Optionen der vorhandenen Plugins zentral auf dem Nagios Server verändern. Der
NRPE ist selbst mit Verschlüsselung sehr performant. Leider ist keine ausreichende
Authentifizierungsmethode vorhanden. Hier bietet der NSCA mehr Schutz.
Der Einsatz von NSCA bietet sich immer dann an, wenn Longrunner ausgeführt werden
müssen. Das Ergebnis kann, unabhängig von Timeouts, zu jeder Zeit übermittelt werden.
Dieses Feature bieten der NRPE sowie das check_by_ssh Plugin nur über Umwege.
Letzteres bietet die größte Sicherheit bei schwächster Performance. In sicherheitsrelevanten
Umgebungen jedoch, wie DMZ, ist das check_by_ssh Plugin das Mittel der Wahl.

- 60 -
4.5 Distributed Monitoring
Soll eine hohe Anzahl von Servern überwacht werden, summiert sich die Last auf dem
Nagios-Server drastisch. Ein Beispiel aus der Praxis ist die IT-Umgebung der
Volkswagen AG. Betriebsinterne Kalkulationen haben ergeben, dass das derzeit eingesetzte
System Management Tool IBM/Tivoli etwa 1280 Service-Checks pro Minute dezentral
durchführt. Dabei wurden sämtliche Service-Checks mit einer Cycle-Time von 60 bis 604800
Sekunden berücksichtigt.
Um mit Nagios diese Umgebung zu überwachen, müssten 1280 Checks in der Minute
angestoßen, auf die Rückgabewerte gewartet, verarbeitet und eventuell eskaliert werden. Um
die auftretende Last auf mehrere Server zu verteilen, empfiehlt sich das Distributed
Monitoring.

- 61 -
4.5.1 Architektur
Nagios bietet mit eigenen Mitteln eine Lastverteilung und präsentiert in der Dokumentation
folgenden Lösungsvorschlag.
Abbildung 14 Distributed Monitoring
Quelle: Galstad, Ethan (2003): Nagios Documentation Version 1.0

- 62 -
Die wesentliche Last wird durch die Vielzahl der lokalen Plugin-Aufrufe des Nagios
Prozesses erzeugt. Diese Last lässt sich durch eine 2-stufige Server-Architektur auf insgesamt
n Nagios-Server verteilen (wobei n >= 2 Server entspricht).
• Central Monitoring Server
Dieser primäre Monitoring Server erhält die Ergebnisse sämtlicher Checks über den
NSCA-Daemon direkt in sein External Command File. Er kennt sämtliche Hosts mit ihren
Services und eskaliert bei Bedarf auftretende Fehler. Der Central Monitoring Server führt
keine aktiven Service-Checks aus, ausgenommen Freshness-Checks (siehe Kapitel 5.4).
• Distributed Monitoring Server #n
Die Distributed Monitoring Server kennen jeweils eine Untermenge der gesamten Hosts
mit ihren Services und sind für diese direkt zuständig. Sie führen aktive Service-Checks
durch und übergeben die Ergebnisse an den Central Monitoring Server. Für das Distributed
Monitoring ist mindestens 1 Distributed Monitoring Server notwendig.
4.5.2 Konfiguration
Folgende Konfigurationsoptionen in der nagios.cfg sind für das Distributed Monitoring
relevant:
Central Monitoring Server:
• enable_notifications = 1
• active_service_checks = 0
• exernal_command_checks = 1
• passive_service_checks = 1
Distributed Monitoring Server #n:
• enable_notifications = 0
• obsess_over_service = 1
• ocsp_command =

- 63 -
Ein beispielhaftes ocsp_command zeigt die Nagios-Dokumentation:
#!/bin/sh
# Arguments:
# $1 = host_name (Short name of host that the service is
# associated with)
# $2 = svc_description (Description of the service)
# $3 = state_string (A string representing the status of
# the given service - "OK", "WARNING", "CRITICAL"
# or "UNKNOWN")
# $4 = plugin_output (A text string that should be used
# as the plugin output for the Service-Checks)
#
# Convert the state string to the corresponding return code
return_code=-1
case "$3" in
OK)
return_code=0
;;
WARNING)
return_code=1
;;
CRITICAL)
return_code=2
;;
UNKNOWN)
return_code=-1
;;
esac
# pipe the service check info into the send_nsca program, which
# in turn transmits the data to the nsca daemon on the central
# monitoring server
/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" |
send_nsca central_monitoring_server -c send_nsca.cfg
Nach jedem Service-Check ruft der Distributed Monitoring Server dieses Script mit folgenden
Optionen auf:
define command {
command_name
command_line
}
submit_check_result
submit_check_result $HOSTNAME$ '$SERVICEDESC$'
$SERVICESTATE$ '$OUTPUT$'
Die Makro-Definitionen, welche als Optionen übergeben werden, sind wie folgt definiert:
• $HOSTNAME$: Der Name des Hosts, zu welchem das Ergebnis gehört.
• $SERVICEDESC$: Kurzbeschreibung des Service-Checks, wie er in services.cfg
definiert ist.
• $SERVICESTATE$: Ein String des bewerteten Ergebnisses, „OK“, „WARNING“,
„CRITICAL“ oder „UNKNOWN“.
• $OUTPUT$: Die Ausgabe des Service-Checks als String.

- 64 -
4.6 Failover Monitoring
Um eine höchstmögliche Verfügbarkeit der Überwachung zu gewährleisten, kann der Nagios
Server redundant aufgebaut werden. Wird Distributed Monitoring verwendet, ist das in
diesem Kapitel beschriebene Szenario auf die einzelnen Distributed Monitoring Server zu
übertragen.
4.6.1 Architektur
Zur Redundanz werden zwei Nagios-Server benötigt, der Master-Host und ein Slave-Host.
Beide Hosts verwenden dieselbe Konfiguration, mit dem Unterschied, dass der Slave-Host die
aktiven Service-Checks und Notifications deaktiviert hat. Dies wird durch die Befehle
STOP_EXECUTING_SERVICE_CHECKS und DISABLE_NOTIFICATIONS erreicht, welche in das External
Command File zu schreiben sind. Wichtig ist hierbei die korrekte Syntax.
Scheduler
Ext. Command File
start/stop
Nagios Prozess
Slave Host
check-nrpe
nsca
Plugin
nrpe
Nagios Prozess
check-nagios
Master Host
send-nsca
ocsp
Plugin
Abbildung 15 Failover Monitoring
eigene Darstellung
Der Master-Host überwacht sämtliche Services. Nach jedem Service-Check wird über die
Funktion Obsessive Compulsive Service Processor Command (ocsp) ein Script aufgerufen,
welches das Ergebnis des Service-Checks mit Hilfe des NSCA an den Slave-Host überträgt.
Damit wird bei einem Ausfall des Master-Hosts garantiert, dass der Slave-Host über die
Status sämtlicher Services informiert ist.

- 65 -
Überwacht wird der Master-Host über das Plugin check-nagios. Da auf dem Slave-Host die
aktiven Service-Checks deaktiviert sind, muss in diesem Falle auf einen externen Scheduler
wie cron zurückgegriffen werden. Dieser stößt in regelmäßigen Abständen ein
Überwachungsscript an, welches mit Hilfe des check_nrpe und dem NRPE-Daemon den
Zustand des Master-Hosts überprüft. Wird festgestellt, dass der Nagios Prozess nicht mehr
läuft, oder der gesamte Host down ist, aktiviert das Script die Notifications und aktiven
Service-Checks auf dem Slave-Host. Diese bleiben solange aktiv, bis der Master-Host wieder
erreichbar ist und das check_nagios Plugin einen OK-Status liefert. Dann übernimmt dieser
die Service-Checks und der Slave-Host wird mit den genannten Methoden in einen passiven
Zustand versetzt.
4.6.2 Konfiguration und Voraussetzungen
Das ocsp-Kommando wird in der nagios.cfg konfiguriert. Folgende Optionen sind hierfür
relevant:
• obsess_over_services=1
Diese Option aktiviert die Obsess Over Service Funktion und veranlasst den Nagios
Prozess nach jedem Service-Check das ocsp_command auszuführen.
• ocsp_command=ocsp_cmd
Das hier angegebene Kommando wird nach jedem Service-Check ausgeführt, sofern
obsess_over_service aktiviert wurde. Das Kommando muss vorher definiert worden sein.
Wird der NSCA für die Übertragung zum Slave-Host verwendet, kann das ocsp_command mit
folgenden Macros 1 aufgerufen werden:
define command {
command_name ocsp_cmd
command_line submit_result_via_nsca $HOSTNAME$ $SERVICEDESC$ \
$SERVICESTATE$ $OUTPUT$
}
Da das Macro $SERVICESTATE$ die ASCII-Variante des Service-States substituiert, muss in
dem Script submit_result_via_nsca vor der Übermittlung per send_nsca eine Konvertierung
stattfinden. Das folgende Beispiel verwendet die Quellen von Ethan Galstad aus den Dateien
obsessive_svc_handler und submit_check_result_via_nsca, welche dem Nagios-Archiv
beiliegen.
1 Vgl: Galstad, Ethan (2003): Nagios Documentation 1.0: Using Macros in Commands

- 66 -
# SUBMIT_RESULT_VIA_NSCA
# Sven Schaffranneck (2004.06.11)
# Original from Ethan Galstad, 07-19-2001
#
# Arguments:
# $1 = host_name (Short name of host that the service is associated with)
# $2 = svc_description (Description of the service)
# $3 = return_code (An integer that determines the state of the service
# check, 0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN).
# $4 = plugin_output (A text string that should be used as the plugin output
# for the service check)
case "$3" in
OK)
return_code=0
;;
WARNING)
return_code=1
;;
esac
CRITICAL)
return_code=2
;;
UNKNOWN)
return_code=3
;;
echocmd="/bin/echo -e"
NscaBin="/usr/local/nagios/libexec/send_nsca"
NscaCfg="/usr/local/nagios/etc/send_nsca.cfg"
NagiosHost="nagioshost"
# create the command line to add to the command file
cmdline="$1;$2;$3;$4"
$echocmd "$1\t$2\t$3\t$4\n" | $NscaBin $NagiosHost -c $NscaCfg
# EOF

- 67 -
Die Verwendung des NRPE geschieht analog zu der Beschreibung aus Kapitel 4.4.1. Der
wesentliche Unterschied liegt im Aufruf des check_nrpe, der in diesem Fall indirekt durch
cron getriggert wird. Das folgende Script kann in einem kurzen Intervall vom Slave-Server
aufgerufen werden:
#!/bin/sh
# Only take action on hard service states...
case "$2" in
HARD)
case "$1" in
CRITICAL)
# The master Nagios process is not running!
# We should now become the master host and
# take over the responsibility of monitoring
# the network, so enable notifications...
/usr/local/nagios/eventhandlers/enable_notifications
/usr/local/nagios/eventhandlers/enable_active_service_checks
;;
WARNING)
UNKNOWN)
# The master Nagios process may or may not
# be running.. We won't do anything here, but
# to be on the safe side you may decide you
# want the slave host to become the master in
# these situations...
;;
OK)
# The master Nagios process running again!
# We should go back to being the slave host,
# so disable notifications...
/usr/local/nagios/eventhandlers/disable_notifications
/usr/local/nagios/eventhandlers/disable_active_service_checks
;;
esac
;;
esac
exit 0
Die hierbei verwendeten Scripte enable_notifications, disable_notifications,
enable_active_service_checks und disable_active_service_checks liegen dem Nagios-
Paket bei und können nach Anpassung der Pfade verwendet werden. Gemäß ihrer
Beschreibung aktivieren oder deaktivieren sie über das External Command File die
Notifications und Service-Checks. Folgende Kommando-Zeilen werden verwendet:
• [`date +%s`] ENABLE_NOTIFICATIONS;`date +%s`
• [`date +%s`] DISABLE_NOTIFICATIONS;`date +%s`
• [`date +%s`] START_EXECUTING_SERVICE_CHECKS
• [`date +%s`] STOP_EXECUTING_SERVICE_CHECKS

5. Funktionale Details
- 68 -
Zur „intelligenten“ Überwachung von Servern gehört nicht nur die starre Überprüfung
einzelner Services und das Benachrichtigen bei Problemen. In komplexen Umgebungen gibt
es eine Vielzahl von dynamischen Komponenten, die nur mit Hilfe von flexiblen
Überwachungsmechanismen sinnvoll gehandhabt werden können. Nagios bringt Features mit,
welche die Überwachung von einer großen Anzahl an Servern erst möglich machen.
5.1 Service- und Host-Abhängigkeiten
Service- sowie Host-Abhängigkeiten (Service and Host Dependency) sind für komplexe
Monitoring-Umgebungen vorgesehen. Sie ermöglichen eine statusbasierende Korrelation
zwischen Services und Hosts.
5.1.1 Architektur
Die folgende Grafik zeigt beispielhaft das logische Layout von Service-Abhängigkeiten und
stammt aus der Nagios Online-Dokumentation. Es sind folgende Punkte zu beachten 1 :
• Ein Service kann von einem oder mehreren anderen Services abhängig sein.
• Ein Service kann von Services abhängig sein, die nicht mit dem gleichen Host verknüpft
sind.
• Service-Abhängigkeiten sind nicht vererbbar .
• Service-Abhängigkeiten können genutzt werden, um die Ausführung von Service-Checks,
Event Handlern und Benachrichtigungen unter bestimmten Umständen (bei OK-,
WARNING-, UNKNOWN- und/oder CRITICAL-Status) zu unterdrücken.
1 Vgl: Galstad, Ethan (2003): Nagios Documentation 1.0: Host and Service Dependencies

- 69 -
Abbildung 16 Beispiel von Service-Abhängigkeiten
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Host and Service Dependencies
Bevor Nagios einen Service-Check oder eine Benachrichtigung durchführt, überprüft das
Programm, ob für diesen Service Abhängigkeiten bestehen. Ist dies der Fall, wird Nagios
folgende Schritte durchführen (vgl: Galstad, Ethan (2003): Nagios Documentation 1.0):
• Nagios erhält den aktuellen Status 1 des Services, von dem der definierte Service abhängt.
• Nagios vergleicht den aktuellen Status des Services von dem er abhängig ist, mit den in der
Abhängigkeits-Definition angegebenen Status-Optionen (ob der aktuelle Status relevant ist,
oder nicht).
1 Nagios benutzt den aktuellsten „harten“ Status des Service auf den sich der Service bezieht. Falls Nagios den
aktuellsten Status des Services (egal ob harter oder weicher Status) benutzen soll, muss man die
soft_service_dependencies-Option aktivieren.

- 70 -
• Falls der aktuelle Status des Services von dem er abhängt mit einem der in der
Abhängigkeits-Definition angegebenen Status-Optionen übereinstimmt, ist die
Abhängigkeit fehlgeschlagen und Nagios beendet die Schleife zur Abhängigkeits-
Überprüfung.
• Falls der aktuelle Status des Dienstes, von dem er abhängt, nicht mit einem der in der
Abhängigkeits-Definition angegebenen Status-Optionen übereinstimmt, hat die
Abhängigkeit bestanden und Nagios wird den nächsten Abhängigkeits-Eintrag überprüfen.
Dieser Zyklus wiederholt sich, bis entweder alle Abhängigkeiten für diesen Dienst überprüft
wurden, oder bis eine der Abhängigkeits-Überprüfungen fehlschlägt. In diesem Fall wird die
Ausführung des Service-Checks oder Event-Handlers/Benachrichtigung unterdrückt.
Die Abhängigkeit für den Service F aus der Abbildung 16 liest sich wie folgt.
• Abhängigkeit für die Ausführung des Service F:
Nagios wird den Check für Service F nicht durchführen, wenn
• Service C im State WARNING ist, und/oder
• Service D im State OK ist.
• Abhängigkeit für die Benachrichtigungen des Service F:
Nagios wird die Benachrichtigungen für Service F nicht durchführen, wenn
• Service C im Status CRITICAL ist, und/oder
• Service D im Status WARNING oder UNKNOWN ist, und/oder
• Service E im Status WARNING, UNKNOWN oder CRITICAL ist.
Die Abhängigkeiten zwischen Hosts entsprechen den Regeln der Service-Abhängigkeiten, mit
dem Unterschied, dass sie für Hosts und nicht für Services gelten und nur
Benachrichtigungen, nicht jedoch die Host-Checks, unterdrücken.

- 71 -
5.1.2 Konfiguration
Das unter 5.1.1 genannte Beispiel für Service F wird mit folgenden Einstellungen
konfiguriert:
define servicedependency{
host_name
service_description
dependent_host_name
dependent_service_description
execution_failure_criteria
notification_failure_criteria
}
define servicedependency{
host_name
service_description
dependent_host_name
dependent_service_description
execution_failure_criteria
notification_failure_criteria
}
define servicedependency{
host_name
service_description
dependent_host_name
dependent_service_description
execution_failure_criteria
notification_failure_criteria
}
Host B
Service D
Host C
Service F
o
w,u
Host B
Service E
Host C
Service F
n
w,u,c
Host B
Service C
Host C
Service F
w
c

- 72 -
Die Konfiguration für Host-Abhängigkeiten geschieht analog zu den Service-Abhängigkeiten.
Für den Host C im folgenden Layout ergeben sich somit diese Definitionen:
define hostdependency{
host_name
dependent_host_name
notification_failure_criteria
}
define hostdependency{
host_name
dependent_host_name
notification_failure_criteria
}
Host A
Host C
d
Host B
Host C
d,u
Abbildung 17 Beispiel von Host-Abhängigkeiten
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Host and Service Dependencies

- 73 -
5.2 Soft und Hard States
Nagios unterscheidet nicht nur zwischen den vier auf Seite 36 genannten Service-States,
sondern kennt zudem „weiche“ und „harte“ Status. Diese sind elementarer Bestandteil der
Nagios Überwachungslogik.
In order to prevent false alarms, Nagios allows you to define how many times a service or
host check will be retried before the service or host is considered to have a real problem. 1
Geregelt wird die maximale Anzahl der Wiederholungen über die max_check_attempts
Direktive in der Host- bzw. Service-Check Definition.
5.2.1 Soft States
Laut der Nagios Dokumentation tritt ein Soft State immer dann auf, wenn:
• die Überprüfung eines Dienstes oder Hosts in einem nicht-OK-Status endet und die
Überprüfung noch nicht so oft wie in der max_check_attempts-Option angegeben,
wiederholt wurde.
Wenn ein Dienst oder Host aus einem Soft State wiederhergestellt wurde, wird dies
soft recovery genannt. Beim Auftreten eines Soft State oder soft recovery werden folgende
Aktionen durchgeführt:
• Der Fehler oder die Wiederherstellung wird in die Logdatei geschrieben, sofern die
log_service_retries oder log_host_retries Optionen in der Nagios Konfiguration
aktiviert wurden.
• Event Handler werden ausgeführt, sofern welche definiert wurden, um die Fehler oder
Wiederherstellungen für einen Service oder Host zu bearbeiten. Zuvor wird das
$STATETYPE$-Macro auf "SOFT" gesetzt.
• Nagios sendet keine Benachrichtigungen an die Kontaktpersonen, da noch kein ernsthaftes
Problem für den Service oder Host erkannt wurde.
Zusammenfassend ist zu erkennen, dass primär der Eventhandler aufgerufen wird, um z.B.
pro-aktive Korrekturmaßnahmen durchzuführen.
1 Galstad, Ethan (2003): Nagios Documentation 1.0: State Types

- 74 -
5.2.2 Hard State
Ein Hard State für ein Service bzw. Host tritt laut der Nagios Dokumentation in folgenden
Situationen auf:
• Wenn das Ergebnis eines Service oder Host-Checks einen nicht-OK-Status zurückgibt und
der Service/Host-Check bereits so oft wiederholt wurde, wie durch die max_check_attempts
Option in der Service/Host Definition angegeben.
• Wenn das Ergebnis eines Service-Checks einen nicht-OK-Status zurückgibt und der zu
dem Service korrespondierende Host entweder DOWN oder UNREACHABLE ist.
Wird ein Service oder ein Host aus einem Hard State wiederhergestellt, so handelt es sich um
ein hard recovery. Als Hard State Change wird ein Status-Wechsel in folgenden Situationen
bezeichnet:
• Der Status wechselt von einem harten OK-Status in einen harten nicht-OK-Status.
• Der Status wechselt von einem harten nicht-OK-Status in einen harten OK-Status.
• Der Status wechselt von einem harten nicht-OK-Status in einen anderen harten nicht-OK-
Status.
Bei einem Hard State Change wird ein Log-Eintrag erzeugt, der Event-Handler ausgeführt und
die Kontaktpersonen über den Fehler oder die Wiederherstellung informiert, sofern es die
Konfiguration zulässt.

- 75 -
5.3 State Flapping
Nagios erkennt optional Status-Schwankungen (flapping), die unter Umständen auf eine
Fehlkonfiguration oder Netzwerkprobleme hindeuten können.
Flapping occurs when a service or host changes state too frequently, resulting in a storm of
problem and recovery notifications. 1
Das State Flapping tritt also immer dann auf, wenn sich der Status eines Services oder Hosts
zu oft ändert und somit eine Flut an Problem- und Recovery-Benachrichtigungen auslöst.
5.3.1 Implementierung
Nagios speichert für jeden Service/Host das Ergebnis der letzten 21 Checks in einem Array.
Bei jedem neuen Check wird der Inhalt des Arrays analysiert und festgestellt, ob der Service
oder Host flappt. Dazu wird die prozentuale Anzahl von State-Changes ermittelt. Da genau 21
States im Array stehen, können bis zu 20 State Changes auftreten.
Abbildung 18 zeigt beispielhaft den Inhalt des Arrays für einen Service. OK States sind grün
markiert, WARNING States in gelb dargestellt, CRITICAL States in rot und UNKNOWN States
in orange. Blaue Pfeile zeigen die aufgetretenden State Changes an.
Abbildung 18 Service State Transitions
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Detection and Handling of State Flapping
1 Galstad, Ethan (2003): Nagios Documentation 1.0: Detection and Handling of State Flapping

- 76 -
Die Anzahl der Statusänderungen zu summieren und in Prozenten auszudrücken ist jedoch
nicht aussagekräftig genug. Daher gewichtet Nagios die auftretenden State Changes
unterschiedlich. Der neueste Statuswechsel wird bis zu 50% schwerer gewichtet als der
älteste. Abbildung 19 zeigt die Verteilung der Gewichtung über die Zeitpunkte t1 bis t20, wobei
t1 den ältesten und t20 den neuesten Status darstellt.
Abbildung 19 Weighted State Transitions
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Detection and Handling of State Flapping
Zu den Zeitpunkten t3, t4, t5, t9, t12, t16 und t19 sind Statuswechsel aufgetreten. Ohne die
zusätzliche Gewichtung ergibt sich ein State Flapping von 35%. Bei einer gewichteten
Bewertung wird ein State Flapping von 31% erreicht. Dieser geringere Wert macht Sinn, da
die gehäuften Statusänderungen am Anfang der Zeitperiode auftraten und für die Aussage
über das aktuelle Flapping-Verhalten weniger relevant sind.

- 77 -
5.3.2 Konfiguration
Es gibt drei relevante Optionen, welche die Flapping-Logik von Nagios beeinflussen:
• low_flap_threshold
Unterer Threshold, ab wann ein Service/Host nicht mehr als Flapping erkannt wird.
• high_flap_threshold
Oberer Threshold, ab wann ein Service/Host als Flapping erkannt wird.
• enable_flap_detection
Aktiviert oder deaktiviert die Flap Detection.
Jede der drei Optionen können zum einen in der nagios.cfg systemweit gesetzt werden, zum
anderen in den Objektdefinitionen für Services und Hosts individuell festgelegt werden, was
das Überschreiben der systemweiten Defaults ermöglicht.
5.3.3 Auswirkungen
Wenn ein Service oder Host als Flapping erkannt wird, unternimmt Nagios folgendes:
• Eintrag in die Log-Datei über das Flapping schreiben.
• Einen Hinweis als Kommentar zum aktuellen Service- oder Host-Eintrag erstellen.
• Unterdrücken der Benachrichtigungen für diesen Service oder Host.
Erkennt Nagios, dass ein Service oder Host den Flapping Status verlässt, werden die
entgegengesetzten Aktionen unternommen:
• Eintrag in die Log-Datei über das stoppen des Flapping schreiben.
• Der Kommentar zum Service oder Host über das Flapping wird entfernt.
• Benachrichtigungen für den Service oder Host werden wieder freigegeben.

- 78 -
5.4 Freshness-Check
Nagios bietet ein Feature, welches veraltete Ergebnisse erkennt und bei Bedarf aktive Checks
anstößt. Veraltete Ergebnisse können beispielsweise bei passiv deklarierten Service-Checks
auftreten, wenn das externe Tool zum Übertragen des Ergebnisses nicht erwartungskonform
funktioniert oder ausgefallen ist. Mit dem Freshness-Check wird sichergestellt, dass Nagios
regelmäßig die Ergebnisse von passiven Service-Checks übermittelt bekommt, bzw. ein
Hinweis erzeugt wird, dass ein Ergebnis veraltet ist.
Folgende globale Optionen müssen in der nagios.cfg konfiguriert werden, um Freshness-
Checks zu verwenden:
• check_service_freshness
Bei einem Wert von 1 kann die Freshness-Überprüfung verwendet werden. Bei
einer 0 werden die Freshness-Checks systemweit deaktiviert.
• freshness_check_interval
Diese Option gibt an, wie oft Nagios die Aktualität von Service-Überprüfungen
kontrollieren soll. Falls die Freshness Checks global deaktiviert sind (siehe
check_service_freshness), hat diese Option keine Bedeutung.
Zu diesen globalen Konfigurationsoptionen gibt es noch einige objektbasierten Optionen.
Hierzu werden zu den Service-Definitionen folgende Direktiven hinzugefügt:
• check_freshness
Muss den Wert 1 haben, um für den aktuellen Service die Freshness-Checks zu aktivieren.
• freshness_threshold
Das Anzahl der Sekunden (abhängig von der globalen Option interval_length aus der
nagios.cfg), die das Ergebnis des Service alt sein darf.
• check_command
Ein gültiger Befehl, welcher ausgeführt werden soll, wenn das mit der Option
freshness_threshold angegebene Alter überschritten wird.
Hinweis: Selbst wenn für den gewählten Service die aktiven Checks deaktiviert sind, wird
Nagios den Befehl hinter check_command bei Bedarf ausführen, sollte der Freshness-Check für
ihn aktiviert sein.

- 79 -
5.5 Scheduling mit Interleaving
Ein wesentlicher Vorteil der zentralen Architektur, wie sie Nagios implementiert, ist die
übergreifende Steuerung des Schedulings. Dabei verteilt Nagios die konfigurierten Service-
Checks anhand zweier Werte, die in der nagios.cfg festgelegt werden.
5.5.1 Konfiguration
Folgende Optionen sind für die Konfiguration des Interleaving relevant:
• inter_check_delay_method=
Die inter_check_delay Direktive dient dem Load-Balancing auf dem zentralen Nagios
Server. Sie steuert, in welchen Abständen die Service-Checks in der Queue verteilt werden.
Wird die „smart delay calculation“ durch den Wert „s“ verwendet, errechnet Nagios einen
durschnittlichen Check-Intervall und kann anhand dessen selbstständig einen Delay
wählen. Gültige Werte sind:
n: Es wird keine Verzögerung verwendet.
d: Verwendung eines festen Delays von einer Sekunde.
s: „Intelligente“ Berechnung eines sinnvollen Wertes durch Nagios.
x.xx: Benutzung eines individuellen inter-check Delays von x.xx Sekunden.
Die Berechnung für die „smart delay calculation“ erfolgt nach dieser Gleichung:
inter_check_delay = (check interval for all services) / (# of all services) 2
Die automatische Berechnung des Verzögerungs-Intervalls kann in manchen Fällen jedoch
problematisch sein. Bei der Verwendung von extrem unterschiedlichen Check-Zyklen kann es
durchaus auftreten, dass die berechnete Verzögerung zu lang ausfällt. Folgende Situation
erörtert das Problem:
Definition:
5 Services mit je 3 Minuten Check-Cycle
5 Services mit je 60 Minuten Check-Cycle
[(5*180) + (5*3600)] / 10² = inter_check_delay
18900 / 100 = 189
Ein inter_check_delay von 189 entspricht 3,15 Minuten. In diesem Falle wird also zwischen
jedem Service-Check genau 189 Sekunden gewartet. Das wiederspricht jedoch der
Anforderung, einige der Services alle 3 Minuten zu überprüfen.
Diese Situation tritt jedoch nur in vereinzelten Extremfällen auf, wenn sehr wenige Service-
Checks definiert wurden und diese zudem eine hohe Cycle-Time Differenz aufweisen.

- 80 -
• service_interleave_factor=
Mit Hilfe des Interleaving-Faktors werden die Service-Checks über sämtliche Hosts
„gefächert“ (verteilt), um eine Lastverteilung auf den remote Hosts und schnellere
Erkennung von Host-Problemen zu erreichen.
Dadurch, das Nagios parallele Ausführung von Service-Checks beherrscht, kann es ohne
Interleaving passieren, dass ein Host viele Service-Checks gleichzeitig beantworten muss
und dadurch unter hoher Last steht. Das Kapitel 5.5.2 erläutert die Technik des
Interleavings im Detail.
Gültige Werte sind:
x: Eine Zahl größer oder gleich 1 gibt die Anzahl der auszulassenden
Service-Checks an. Der Faktor 1 bedeutet, das kein Service ausgelassen wird.
s: Benutzung eines „intelligenten“, durch Nagios berechneten Interleaving-Faktor.
Die „intelligente“ Berechnung für den Interleaving-Faktor geschieht nach folgender
Gleichung 1 :
interleave factor = ceil ( # of services / # of hosts )
1 Die Funktion ceil rundet den Wert in der Klammer auf, die Raute steht für „Gesamtsumme“.

- 81 -
5.5.2 Funktionsweise des Interleaving
Ohne Interleaving werden sämtliche Service-Checks der Reihe nach in die Queue einsortiert.
Dieses Verhalten lässt sich über das Webfrontend beobachten und ist in den nachfolgenden
Abbildungen dargestellt.
Abbildung 20 Scheduling ohne Interleaving 1
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Service Check Scheduling
Abbildung 20 zeigt die Service Details aus dem Webfrontend nach dem Start von Nagios
ohne Interleaving (service_interleave_factor=1). Sämtliche Service-Checks sind
hintereinander in die Queue eingereiht. Abbildung 21 zeigt die Auswirkung.
Abbildung 21 Scheduling ohne Interleaving 2
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Service Check Scheduling
Deutlich zu erkennen ist die sequenzielle Bearbeitung der Checks. Jeder Host wird innerhalb
kürzester Zeit mit sämtlichen Service-Checks beauftragt, was eine erhebliche Lastspitze auf
den remote Hosts erzeugen kann.

- 82 -
Im Vergleich dazu die Verwendung von Interleaving. Die folgenden drei Grafiken zeigen den
gefächerten Verlauf der Service-Checks. Zu Demonstrationszwecken wurde der
service_interleave_factor manuell auf den Wert 4 gesetzt.
Abbildung 22 Scheduling mit Interleaving, Anfang
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Service Check Scheduling
Nach dem Start von Nagios werden die Service-Checks so in die Queue einsortiert, dass
immer genau 4 Service-Checks ausgelassen werden. In Abbildung 22 sind die mit einem roten
Strich markierten Service-Checks der Reihe nach einsortiert. Erwartungsgemäß werden diese
als erstes überprüft und es ergibt sich die Abbildung 23.
Abbildung 23 Scheduling mit Interleaving, erste Durchgang
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Service Check Scheduling

- 83 -
Die Abbildung 24 zeigt das Ergebnis nach drei Durchläufen. Jedes Mal werden 4 Checks
ausgelassen. Dadurch ergibt sich eine bessere Verteilung über die einzelnen remote Hosts.
Abbildung 24 Scheduling mit Interleaving, dritter Durchgang
Quelle: Galstad, Ethan: Nagios Documentation 1.0: Service Check Scheduling
Anzumerken ist hierbei, das die Verteilung umso besser ist, je ähnlicher die Anzahl der
Service-Checks pro Hosts sind. Existieren einige Hosts mit vielen Checks und einige mit
wenigen oder nur einem Check, kann es unter Umständen wieder dazu kommen, das einige
Services auf dem selben Host gleichzeitig überprüft werden.

6. Plugins
- 84 -
Die Nagios Distribution enthält primär die Nagios Quellen, jedoch keine Plugins. Diese
werden unter der Plugin Project Page http://nagiosplug.sourceforge.net/ von einem
eigenständigen Entwicklerteam gepflegt. Die 6 eingetragenen Kernentwickler sind:
• Ethan Galstad
• Karl DeBisschop
• Subhendu Ghosh
• Stanley Hopcroft
• Ton Voon
• Jeremy T. Bouse
Neben diesen Kernentwicklern gibt es eine Reihe weiterer, aktiver Programmierer, die
Verbesserungen oder neue Plugins beitragen. Eine vollständige Liste findet sich in dem
Quellpaket der Nagios-Plugins in der Datei AUTHORS. Auch der Verfasser dieser Arbeit ist
darin wiederzufinden. Derzeit sind 116 Autoren eingetragen.
Weiterhin gibt es drei Mailinglisten die sich mit dem Thema der Plugins beschäftigen:
• nagiosplug-help@lists.sourceforge.net
Allgemeine Anfragen und Hilfe zu den Plugins.
• nagiosplug-devel@lists.sourceforge.net
Hier tauschen Entwickler untereinander Informationen zu neuen und vorhandenen Plugins
aus.
• nagiosplug-checkins@lists.sourceforge.net
In diese Mailingliste werden neue CVS 1 -Checkins bekannt gegeben. Nur die Kern-
Entwickler haben Schreibrechte.
Aktuell ist die Version 1.4.0alpha1. Die letzte stabile Version ist die 1.3.1.
1 CVS steht für Concurrent Versions System. Es bezeichnet ein Software-Programm zur Versionsverwaltung
von Quellcode.

- 85 -
6.1 Standard Plugins
Folgende Standard-Plugins liegen dem Nagios Plugin Projekt bei:
• check_breeze
Dieses Plugin überwacht die Signalstärke von Breezecom Funk-Hardware.
Weiterführende Informationen: check_breeze --help
• check_by_ssh
Ruft über eine SSH-Verbindung beliebige Plugins auf entfernten Hosts auf.
Weiterführende Informationen: Kapitel 4.4.3 und check_by_ssh --help
• check_dig
Testet den DNS-Service des angegebenen Hosts mit Hilfe von dig 1 .
Weiterführende Informationen: check_dig --help
• check_disk
Kontrolliert den verbrauchten Speicherplatz eines eingebundenen Filesystems.
Weiterführende Informationen: check_disk --help
• check_disk_smb
Kontrolliert den verbrauchten Speicherplatz von entfernen SMB 2 Netzlaufwerken.
Weiterführende Informationen: check_disk_smb --help
• check_dns
Überwacht die korrekte Auflösung einer Domain zu seiner IP mit Hilfe von nslookup 3 .
Weiterführende Informationen: check_dns --help
• check_dummy
Ein Dummy-Plugin, welches nur den übergeben Status zurückgibt.
Weiterführende Informationen: check_dummy --help
• check_file_age
Kontrolliert ob die übergebene Datei nicht älter als n Sekunden und mindestes m Bytes
lang ist.
Weiterführende Informationen: check_file_age --help
1 dig (domain information groper) ist ein flexibles Tool um DNS-Anfragen zu erstellen und auszuwerten.
2 SMB (Server Message Block) werden von Windows für Datei- und Drucker-Freigaben verwendet. Unter
Unix bietet das Programm Samba diese Funktionalität an.
3 Mit Hilfe des Tools nslookup können Hostnamen aufgelöst werden. Durch Verwendung von
unterschiedlichen Optionen (z.B. set type=CNAME) lassen sich weitere DNS-Spezifische Daten abfragen.

- 86 -
• check_flexlm
Überwacht die Erreichbarkeit des FLEXlm 1 .
Weiterführende Informationen: check_flexlm --help
• check_fping
Ein schnelles Host-Check Plugin, welches auf fping von SAINT 2 basiert.
Weiterführende Informationen: check_fping --help
• check_game
Unter Verwendung des Programms QStat 3 überwacht dieses Plugin Verbindungen zu
aktiven Spieleservern auf angegebenen Hosts.
Weiterführende Informationen: check_game --help
• check_hpjd
Dieses Plugin testet den Status eines HP Druckers mit einer JetDirect Karte. Zur Abfrage
muss net-snmp 4 installiert sein.
Weiterführende Informationen: check_hpjd --help
• check_http
Dieses Plugin testet den HTTP- oder HTTPS-Service eines Hosts. Es kann redirects
folgen, Verbindungszeiten testen, das Auslaufen von Zertifikaten feststellen und nach
Strings oder regulären Ausdrücken suchen.
Weiterführende Informationen: check_http --help
• check_ifoperstatus
Kontrolliert den Status von speziellen Netzwerkintefaces des Zielhosts mit Hilfe von
SNMP.
Weiterführende Informationen: check_ifoperstatus --help
• check_ifstatus
Kontrolliert den Status von jedem Netzwerkintefaces des Zielhosts mit Hilfe von SNMP.
Weiterführende Informationen: check_ifstatus--help
1 FLEXlm ist ein kommerzieller Lizenz-Manager, siehe
http://www.macrovision.com/products/legacy_products/flexlm/index.shtml
2 SAINT ist ein Kommerzieller Security-Scanner, siehe http://www.saintcorporation.com/
3 QStat ist ein Kommdozeilen-Tool welches Echtzeitinformationen von einer vielzahl von Spieleservern
abfragen kann. Primär unterstützt sind hierbei geläufige Quake Half-Life und ähnliche First-Person-Shooter.
4 Dieses Paket umfasst verschiedene Tools für das Simple Network Management Protocol

- 87 -
• check_ircd
Überwacht den IRC 1 -Daemon anhand der eingewählten Benutzer eines angegebenen Hosts.
Weiterführende Informationen: check_ircd --help
• check_load
Dieses Plugin überwacht die lokale, durchschnittliche Load.
Weiterführende Informationen: check_load --help
• check_log
Durchsucht eine Log-Datei nach einem bestimmten String.
Weiterführende Informationen: check_log --help
Hinweis: Das Plugin check_log2 (aus dem contrib-Verzeichnis) erlaubt auch reguläre
Ausdrücke als Suchbegriff. Beide Plugins betrachten jedoch die Log-Dateien nur
zeilenweise und greifen nicht auf rotierte Log-Dateien zurück. Mit Hilfe des Plugins
check_logsurfer 2 können rotated-Logfiles mehrzeilig (also Kontext-Abhängig) mit
regulären Ausdrücken überprüft werden.
• check_mailq
Überprüft die Anzahl der in der Mail-Queue wartenden eMails. Bei Verwendung von
Postfix 3 als MTA 4 zeigt dieses Plugin jedoch eine schwache Performance und wird vom
Autor dieser Arbeit nicht empfohlen.
Weiterführende Informationen: check_mailq --help
• check_mrtg
Dieses Plugin überprüft entweder den durchschnittlichen oder maximalen Wert einer der
beiden Variablen, die in der MRTG 5 Log-Datei stehen.
Weiterführende Informationen: check_mrtg --help
• check_mrtgtraf
Dieses Plugin überprüft den eingehenden/ausgehenden Traffic eines Routers, Switches,
etc., dessen Daten in einer MRTG Log-Datei gespeichert sind.
Weiterführende Informationen: check_mrtgtraf --help
1 Das IRC (Internet Relay Chat) dient der Online-Kommunikation als Plattform
2 Die Nagios Plugins and Extensions: http://naplax.sourceforge.net/check_logsurfer.html
3 Postfix ist ein MTA, welcher den bekannten Sendmail MTA ersetzt. Postfix ist schneller, sicherer und
bedeutend leichter zu konfigurieren, bewahrt aber die Kompatiblität zu Sendmail.
4 Ein MTA (Mail Transfer Agent) ist ein Programm, welches den Transport und die Verteilung von eMails
erledigt.
5 Der Multi Router-Traffic-Grapher (MRTG) stellt den Traffic von Routern graphisch dar. Da MRTG auf
SNMP basiert, lassen sich eine Vielzahl von SNMP Daten verarbeiten.

- 88 -
• check_nagios
Erlaubt die Überwachung des Nagios Prozesses auf dem lokalen Rechner. Da dieses Plugin
auch auf das ps-Kommando zurückgreift, wird der Einsatz auf zLinux vom Autor dieser
Arbeit nicht empfohlen (siehe Kapitel 7.2.2.2).
Weiterführende Informationen: check_nagios --help
• check_nt
Sammelt Daten von dem NSClient 1 , welcher auf Windows NT/2000/XP Servern als
Service installiert werden kann.
Weiterführende Informationen: http://support.tsmgsoftware.com/ und
check_nt --help
• check_ntp
Vergleicht die lokale Zeit mit der eines entfernten Hosts. Basiert auf ntpdate 2 .
Weiterführende Informationen: check_ntp --help
• check_nwstat
Dieses Plugin kontaktiert den auf einem Novell-Server installierten MRTGEXT NLM 3
Weiterführende Informationen: check_nwstat --help
• check_oracle
Überprüft den Status einer Oracle-Datenbank.
Weiterführende Informationen: check_oracle --help
• check_overcr
Dieses Plugin kontaktiert einen entfernten Over-CR 4 Daemon und sammelt über diesen
lokale, private Daten.
Weiterführende Informationen: check_overcr --help
• check_ping
Überprüft die Verbindung zu einem entfernten Host mittels ping.
Weiterführende Informationen: check_ping --help
1 Der NetsaintClient (NSClient) ist ein Windows Service, welcher verschiedene Systemdaten über einen Port
zur Abfrage bereit stellt. Homepage: http://support.tsmgsoftware.com/
2 ntpdate ist ein Standard Unix-Tool zur Zeit-Synchronisation über das Netzwerk.
3 Der MRTGEXT ist ein Modul, welches MRTG und Nagios auf Novell Netware-Basis unterstützt.
4 Over-CR ist ein alternativer Datensammler von privaten Ressourcen, dessen Weiterentwicklung jedoch
eingestellt wurde. Siehe http://www.molitor.org/overcr/.

- 89 -
• check_procs
Dieses komplexe Plugin überprüft eine Vielzahl von Prozess-Informationen anhand von
angegebenen Metriken und Threshold-Wertebereichen. Da es jedoch auf der Ausgabe des
ps-Kommandos basiert, ist der Einsatz unter zLinux nicht empfehlenswert (siehe
Kapitel 7.2.2.2).
Weiterführende Informationen: check_procs --help
• check_real
Überprüft den REAL Streaming-Service auf dem angegeben Host.
Weiterführende Informationen: check_real --help
• check_rpc
Überprüft, ob der angebene RPC 1 auf dem remote Host registriert und funktionsfähig ist.
Weiterführende Informationen: check_rpc --help
• check_sensors
Dieses Plugin überprüft den lokalen Hardware-Status mit Hilfe des lm_sensors 2 Paketes.
Nur unter Linux funktionsfähig.
Weiterführende Informationen: check_sensors --help
• check_smtp
Dieses Plugin versucht eine SMTP-Verbindung zum angegebenen Host aufzubauen.
Weiterführende Informationen: check_smtp --help
• check_snmp
Überprüft den Status eines entfernten Hosts mit Hilfe der System-Informationen des
SNMP. Es verwendet das Kommando snmpget aus dem net-snmp Paket, welches installiert
sein muss.
Weiterführende Informationen: check_snmp --help
• check_ssh
Überprüft die Verbindung zu einem SSH-Daemon auf dem angegeben Host und Port.
Weiterführende Informationen: check_ssh --help
1 Remote Procedure Call, oder kurz RPC, ist ein Protokoll auf der fünften und sechsten Schicht des ISO/OSI-
Modells. Mit der Hilfe von RPC können über ein Netzwerk Funktionsaufrufe auf entfernten Rechnern
durchgeführt werden.
2 Das lm_sensors Paket ermöglicht unter Linux auf unterschiedliche Überwachungs-Hardware wie z.B.
Temperatur-Überwachung zuzugreifen.

- 90 -
• check_swap
Überprüft den verwendeten Swap-Speicher auf dem lokalen Host.
Weiterführende Informationen: check_swap --help
• check_tcp
Dieses Plugin testet TCP-Verbindungen zum angegeben Host.
Weiterführende Informationen: check_tcp --help
• check_time
Überprüft die Zeit auf dem angegebene Host. check_time verwendet hierzu kein ntpdate,
sondern verbindet sich direkt auf den Port 37 (time-service) des entfernten Hosts.
Weiterführende Informationen: check_time --help
• check_udp
Dieses Plugin testet UDP-Verbindungen zum angegeben Host.
Weiterführende Informationen: check_udp --help
• check_ups
Dieses Plugin testet den UPS 1 -Services des angegebenen Hosts. Die Network UPS Tools
von http://ww.exploits.org werden vorausgesetzt.
Weiterführende Informationen: check_ups --help
• check_users
Überprüft die Anzahl der aktuell angemeldeten Benutzer.
Weiterführende Informationen: check_users --help
• check_wave
Undokumentiert: Überprüft mit Hilfe von SNMP die Signalstärke von WaveLAN.
Weiterführende Informationen: check_wave --help
1 UPS steht in diesem Zusammenhang für Uninterruptible Power Supplies

- 91 -
6.2 Contributed Plugins
Neben den Standard-Plugins existieren eine Reihe weiterer Plugins, die es teilweise (noch)
nicht in die offizielle Distribution geschafft haben oder nicht vom offiziellen Entwicklerteam
gepflegt werden.
Allein dem Nagios Plugin Projekt liegen bereits mehr als 60 weiterere (als contrib
gekennzeichnete) Plugins bei, die Überwachungsmechanismen für Apache-Server, Citrix-
Umgebungen, Raid-Systeme, MS-SQL, ORACLE oder Sockets bereitstellen.
Einige interessante Plugins lassen sich auf folgenden Webseiten finden.
• http://sourceforge.net/projects/nrpe/
NRPE (Nagios Remote Plugin Executor) dient zum Ausführen von Plugins auf entfernten
Hosts.
• http://sourceforge.net/projects/nrpent/
NRPE_NT, der Nagios Remote Plugin Executor für Windows-Umgebungen.
• http://sourceforge.net/projects/naplax/
Nagios Plugins and Extensions. Einige Addons und Plugins für Nagios, jedoch wurde nicht
auf die Verwendung des embedded Perl Nagios Rücksicht genommen. Eine Nachfrage bei
dem Autor Martin Schmitz zur Anpassung an ePN ergab folgendes:
„nein, dazu gibt es momentan keine Pläne.
Da ich noch nie mit embedded Perl gearbeitet habe, habe ich auch keine Vorstellung davon,
wie lange eine Anpassung dauern würde.“ 1
• http://support.tsmgsoftware.com/index.php?c=2
Der Nagios NSClient ist ein Windows-Service, welcher verschiedene Systemdaten über
einen Port zur Abfrage bereit stellt. Die offiziellen Nagios Plugins beinhalten bereits das
check_nt Plugin, welches zur Abfrage dieser Daten dient.
1 Vgl: Schmitz, Martin (2004): eMail-Korrespondenz Schmitz, Martin, 03.05.2004

7. Proof of Concept (PoC)
- 92 -
Als Aufgabe wurde die Implementierung eines heterogenen Server-Monitorings mit Nagios
gestellt. In erster Linie soll die generelle Realisierbarkeit mit Standard-Monitoring-Plugins
evaluiert werden. Eine wesentliche Herausforderung hierbei ist die breite Masse an Servern,
welche es performant zu handhaben gilt.
7.1 Zielsetzung
Schon das Ergebnis der vorangegangenen Studienarbeit 1 hielt den Einsatz von Nagios im
Unternehmen Volkswagen theoretisch für möglich, doch wurde eine nähere Evaluierung
empfohlen.
Dieses Proof of Concept soll den praxisnahen Einsatz des Server-Monitoring-Tools Nagios im
Unternehmen Volkswagen darlegen. Dabei sollen konkrete Fragen beantwortet werden:
• Lassen sich die geforderten Standard-Ressourcen überwachen? (siehe Kapitel 7.2)
• In welchem Verhältnis steht der Ressourcenverbrauch von Nagios in Bezug auf die Anzahl
der zu überwachenden Services?
Nach der Aussage von Hans-Werner Buske stellt sich eine weitere Anforderung:
„Um unseren Kunden eine Low-Cost Alternative anbieten zu können, ist es unser Ziel, ein
OpenSource Betriebssystem mit einem OpenSource Server-Monitoring Tool zu überwachen.“
Zitat Hans-Werner Buske (2004), Volkswagen AG, Systems Management
Da für jeden überwachten Server bei dem Einsatz von IBM/Tivoli Lizenzgebühren fällig
werden, stellen grosse Linux-Cluster-Installationen einen hohen Kostenfaktor dar. Sollte
Nagios ausreichende oder sogar bessere Überwachungsmechanismen für Linux bereitstellen,
stellt sich die Plattform Linux im produktiven Betrieb als noch attraktiver, da günstiger, dar.
1 Vgl: Schaffranneck, Sven (2004): Studienarbeit

- 93 -
7.2 Anforderungen an das Server-Monitoring
Die Realisierbarkeit soll anhand der folgenden Eckdaten aufgezeigt werden. Diese spiegeln
die bei der Volkswagen AG eingesetzte IT-Umgebung wieder.
7.2.1 Plattformen
Um eine möglichst praxisnahe Umgebung zu realisieren, wurden folgende, mit der
betreuenden Fachabteilung abgestimmten, Plattformen für das PoC gewählt.
• Sun Solaris 8
• HP-UX 11.11
• IBM AIX 5.1 und 5.2
• iLinux 1 2.2 und 2.4 (GNU/Debian Woody und Sid)
• zLinux 2 2.4 (SuSE SLES 7.0)
Als Windows-Plattformen kommen Windows NT4, 2000 und 2003 zum Einsatz. Das hier
vorgestellte PoC beschränkt sich jedoch aus Zeitgründen auf die Unix-Plattformen.
7.2.2 Service-Überwachung
Die Basis des großflächigen Server-Monitorings bezieht sich auf eine Untermenge der zur
Verfügung stehenden Plugins. Dem Autor dieser Arbeit wurden folgende Vorgaben zur
Überwachung gemacht:
7.2.2.1 Filesystem-Überwachung
Verzeichnisse und Mountpoints sollen anhand von prozentualen Grenzwerten überwacht
werden.
Diese Anforderung lässt sich mit dem check_disk Plugin aus dem Nagios Plugin Projekt in
der Version 1.3.1 erfüllen. Der Einsatz des check_disk Plugins aus dem Nagios Plugin Projekt
Release 1.4.0alpha1 ist hierbei problematisch, denn es überprüft nur reelle Mountpoints. Dazu
kontrolliert es anhand der /etc/mtab, ob das angegebene Verzeichnis ein Mountpoint ist. Ist
dies nicht der Fall, beendet das Plugin seinen Aufruf mit der Fehlermeldung, dass der
angegebene Mountpoint nicht existiert, obwohl das Verzeichnis als ein Unterverzeichnis eines
anderen Mountpoints sehr wohl bestehen kann.
1 Das „i“ steht für Intel und beschreibt ein Linux, welches auf Intel-basierender Hardware läuft.
2 zLinux bezeichnet die Implementierung des freien Betriebssystems Linux auf IBM zSeries Hardware.

- 94 -
Beispiel:
Host A:
/dev/hda1 /
/dev/hda2 /boot
Ausgabe des Plugins aus dem Release 1.3.1:
nagios@host-a: ./check_disk -w15% -c10% -p /usr
DISK OK [464372 kB (16%) free on /dev/hda1]
nagios@host-a: ./check_disk -w15% -c10% -p /usr
DISK OK [464372 kB (16%) free on /dev/hda1]
Ausgabe des Plugins aus dem Release 1.4.0alpha1:
nagios@host-a: ./check_disk -w15% -c10% -p /
DISK OK - free space: / 453 MB (16%);| /=453MB;1689;1971;0;2816
nagios@host-a: ./check_disk -w15% -c10% -p /usr
DISK CRITICAL - free space:| [/usr not found]
Obwohl /usr als Verzeichnis, jedoch nicht als Mountpoint, existiert, wird der Status
CRITICAL zurückgegeben.
Ist man auf Performance-Daten angewiesen, steht derzeit jedoch nur das check_disk Plugin
aus dem Release 1.4.0alpha1 zur Verfügung.
7.2.2.2 Prozess-Überwachung
Die Überwachung der Prozesse ist eine weitere Anforderung. Folgende Aspekte sind zu
berücksichtigen:
• Minimale und maximale Anzahl eines Prozesses.
Es werden sämtliche Prozesse gezählt, die dem übergebenen Prozessnamen (mit oder ohne
Argumente) entspricht.
• Anzahl der Zombie 1 -Prozesse.
• CPU-Last einzelner Prozesse.
Gelöst werden diese Anforderungen mit dem check_procs Plugin. Es verwendet das ps
Systemkommando, um die relevanten Prozessinformationen zu sammeln und auszuwerten.
Leider stellt der Aufruf von ps in der Version 2.0.7 der eingesetzten
SuSE Linux Enterprise Server Distribution 7 unter zLinux ein Performance-Problem dar.
1 Ein Zombie ist ein beendeter Kindprozess, dessen Vaterprozess es versäumt hat, den Exitstatus des
Kindprozesses mit einem wait()-Call abzufragen. Bis dieses geschehen ist (oder der Vaterprozess beendet
wurde), bleibt der Zombie-Prozess in der Prozesstabelle bestehen.

- 95 -
Das Kommando ps greift auf das proc-Filesystem zu, um Prozessinformationen zu ermitteln.
Dabei wird (bezogen auf die genannte Version) für jeden Prozess auch die „Datei“
/proc//meminfo geöffnet und ausgelesen, auch wenn die darin enthaltene Information
von dem (durch Optionen erweiterten) ps-Aufruf nicht benötigt wird.
Gerade dieser Aufruf verbraucht jedoch erhebliche CPU-Zeit, was insbesondere bei hoher
Prozessanzahl auffällig wird. Die mit time 1 gemessene Zeit eines ps Aufrufes bei 340 aktiven
Prozessen dauert mehr als 3 Sekunden:
root@lnx12: time /bin/ps -weo 'stat uid ppid vsz rss pcpu comm args' |wc -l
340
real 0m3.268s
user 0m0.040s
sys 0m3.190s
Zu diesem Zweck wurde im Rahmen dieser Arbeit ein auf Perl basierendes ps-Kommando
entwickelt, welches im Anhang auf Seite 153 zu finden ist.
root@lnx12: time ./ps.pl | wc -l
340
real 0m0.279s
user 0m0.160s
sys 0m0.090s
Dieses Plugin benötigt nur einen Bruchteil der CPU-Zeit des ursprünglichen ps-Kommandos,
stellt jedoch alle (mit Ausnahme der verwendeten, prozentualen CPU-Last, s. Seite 153) für
das check_procs notwendigen Informationen bereit.
Auf HP-UX-Plattformen (HP-UX 11.11) gab es ebenfalls ein Problem im check_proc-Plugin
(1.4.0alpha1), welches jedoch mittlerweile im CVS behoben wurde. 2 Hierbei handelte es sich
um eine fehlerhafte Auswertung des ps-Kommandos. Berichtet wurde der Fehler vom Autor
dieser Arbeit am 29.04.2004 in der nagios-user Mailingliste 3 . Einen Tag später wurde der
Fehler durch den Entwickler Von Toon beseitigt.
1 time misst unter Linux die Laufzeit eines einfachen Kommandos.
2 Vgl: Voon, Ton (2004): eMail-Korrespondenz Voon, Ton, 30.04.2004
3 Vgl: Mailingliste nagios-users, Message-ID: 8138925, 29.04.2004

- 96 -
7.2.2.3 Auslagerungsspeicher-Überwachung
Der Verbrauch des Auslagerungsspeichers kann mit Hilfe des check_swap Plugins überwacht
werden. Hierzu kann das Plugin mit der Option --allswaps die angegebenen Thresholds
gegen den gesamten, zur Verfügung stehenden Auslagerungsspeicher (oder jede einzelne
Swap-Partition) testen. Der Aufruf von check_swap --help erläutert dies wie folgt:
-a, --allswaps
Conduct comparisons for all swap partitions, one by one
Auf den HP-UX-Plattformen ist die Erkennung des swap-Befehls jedoch fehlerhaft. Das
Problem liegt in der Datei configure.in und wurde nach einem Bugfix durch den Autor dieser
Arbeit am 10.05.2004 korrigiert. Die neue Revision >=1.110 der configure.in kann im
WebCVS unter http://cvs.sourceforge.net/viewcvs.py/nagiosplug/nagiosplug/configure.in
eingesehen werden. Weitreichender sind die Modifikationen an dem Quellcode von
check_swap.c, welcher im Anhang auf Seite 146 einzusehen ist.
Erst die Verwendung des configure.in ab der Revision 1.110 und dem angehängten
check_swap.c ermöglicht den Einsatz des check_swap-Plugins auf HP-UX Plattformen.

- 97 -
7.3 Beschreibung des PoC
Es soll ein möglichst einfaches Szenario aufgebaut werden, welches die in Kapitel 4.5
genannten ~1280 Service-Checks/Minute bewältigt. Dazu stellt VW teils dedizierte Test-
Server, teils Server aus dem Produktionsumfeld zur Verfügung, um ein realistisches Testfeld
zu ermöglichen.
Der (alleinige) Nagios-Server wird auf einer Sun-Fire-280R installiert.
• Prozessoren: 2x UltraSPARC-III CPU 750MHz
• Arbeitsspeicher: 2GB RAM
• Betriebssystem: Sun Solaris 8
Um die hohe Anzahl von Checks/Minute zu erreichen, werden 49 Hosts mit je 20 minütlich
zu überprüfende Services in die Überwachung genommen. Damit ergeben sich
980 Checks/Minute. Folgende Plattformen werden auf den remote Hosts eingesetzt.
• 1x AIX 5.1
• 1x AIX 5.2
• 1x HP-UX 11.11
• 1x iLinux 2.4 (Debian Sarge)
• 2x zLinux 2.4 (Suse Linux Enterprise Server 7)
• 43x Sun Solaris 8
Von den 49 Hosts stehen 47 (inkl. Nagios-Server) direkt im Intranet und 2 in einer DMZ
(hinter einer „weichen“ Firewall 1 ), um auch den Zugriff durch eine Firwall experimentell zu
demonstrieren.
Die verbleibenden 47 Hosts stehen zum einen in Wolfsburg, wo auch der Nagios-Server
präsent ist, zum anderen in Emden (3), Kassel (3), Braunschweig (1) und Salzgitter (1). Damit
kann die Funktionalität auch über WAN-Strecken getestet werden.
Um die Komplexität der Konfiguration für den PoC gering zu halten, werden bei sämtlichen
Hosts identische Services mit identischen Tresholds überwacht.
1 Zugriffe vom Intranet in die DMZ sind erlaubt, entgegengesetzt nur bestehende Verbindungen,
s. Kapitel 7.10.

- 98 -
7.4 Installation des Nagios Servers
Der Kern des PoC besteht aus dem Nagios-Server. Um die hohe, zu erwartende Last
verarbeiten zu können, wird ein Doppelprozessor Sun-Server eingesetzt. Als Betriebssystem
kommt Solaris 8 zum Einsatz.
Vor der Installation müssen die Pre-Requirements festgestellt und erfüllt werden. Danach
können die Quellen kompiliert und installiert, sowie die Konfiguration für das PoC angepasst
werden.
7.4.1 Voraussetzung
Folgende zusätzlichen Systempakete werden für die Installation des Nagios Servers benötigt.
Als Quelle wird die kostenlose Software-Sammlung http://www.sunfreeware.com gewählt.:
• OpenSSH 3.7.1p2 (openssh-3.7.1p2-sol8-sparc-local.gz)
Freie Implementierung des Secure Shell Systems. Wird unter anderem für das
check_by_ssh Plugin verwendet.
Prereq-Check erfolgreich: pkginfo -l SMCossh ergibt Version 3.7.1.p2
• gd 2.0.12 (gd-2.0.12-sol8-sparc-local)
Die GD Graphics Library dient dem dynamischen Erstellen von JPEG, PNG sowie anderen
Bildern und wird von dem Nagios Webinterfache verwendet.
Prereq-Check erfolgreich: pkginfo -l SMCgd ergibt Version 2.0.12
• xpm 3.4k (xpm-3.4k-sol8-sparc-local)
XPM Graphic Library, wird von GD benötigt.
Prereq-Check erfolgreich: pkginfo -l SMCxpm ergibt Version 3.4k
• libpng 1.2.4 (libpng-1.2.4-sol8-sparc-local)
PNG Graphic Labrary, wird von GD benötigt.
Prereq-Check erfolgreich: pkginfo -l SMClpng ergibt Version 1.2.4
• libiconv 1.8 (libiconv-1.8-sol8-sparc-local)
GNU iconv() Implementierung, wird von GD benötigt.
Prereq-Check erfolgreich: pkginfo -l SMCliconv ergibt Version 1.8
• libgcc 3.3 (libgcc-3.3-sol8-sparc-local.gz)
Dieses Paket enthält die wesentlichen gcc-Librarys, welche zur Laufzeit von GD
notwendig sind.
Prereq-Check: libgcc wird nicht benötigt, da gcc zum kompilieren installiert wird.

• jpeg 6b (jpeg-6b-sol8-sparc-local)
- 99 -
JPEG Graphics Library, wird von GD benötigt.
Prereq-Check erfolgreich: pkginfo -l SMCjpeg ergibt Version 6b
• freetype 2.1.2 (freetype-2.1.2-sol8-sparc-local)
Software Font Engine, wird von GD benötigt.
Prereq-Check erfolgreich: pkginfo -l SMCfreetp ergibt Version 2.1.2
• gcc 3.3.2 (gcc-3.3.2-sol8-sparc-local.gz)
Der GNU C Compiler wird zum Kompilieren, jedoch nicht zur Laufzeit, von Nagios und
dessen Plugins verwendet. Wird das gcc-Paket installiert, sind die gcc-Libraries implizit
enthalten und es kann auf die Installation des libgcc verzichtet werden.
Prereq-Check erfolgreich: pkginfo -l SMCgcc ergibt Version 3.3.2
Hinweis: Das gcc-Paket benötigt zum Entpacken temporär etwa 350MB in /var/tmp und
nach erfolgreicher Installation dauerhaft etwa 350MB in /usr/local. Es ist darauf zu
achten, ausreichend Speicherplatz bereit zu halten.
• mcrypt library 2.4.11 (libmcyrpt-2.4.11)
Die mcrypt-Library wird zum Übersetzen und zur Laufzeit des NSCA benötigt. Sie kann
unter http://mcrypt.hellug.gr/ herunter geladen werden.
Prereq-Check FEHLER: find / | grep libmcrypt ergibt 0 Dateien
Daraus folgt, das die mcrypt-Library installiert werden muss, bevor der NSCA-Daemon
kompiliert werden kann. Dieser Vorgang wird in Kapitel 7.4.2.5 beschrieben.
Mit dem Befehl pkgadd -d können die einzelnen Pakete über den Solaris
Paketmanager installiert werden.
pkgadd -d gcc-3.3.2-sol8-sparc-local.gz
Sollte es bei der Installation der Pakete zu Komplikationen kommen, ist eventuell bereits eine
(ältere) Version installiert. Diese kann mit pkgrm deinstalliert werden.
pkgrm SMCgcc
Für den Einsatz des Webfrontends von Nagios wird ein Apache (Version 1.3.29) Web-Server 1
installiert.
Hinweis: Für die Verwendung von SSH und SSL wird ein SunOS Patch (ID: 112438)
benötigt, welcher /dev/random und /dev/urandom bereitstellt. 2
1 Der Apache Webserver ist einer der verbreitesten Webserver weltweit und kann von
http://httpd.apache.org/download.cgi herunter geladen werden.
2 Der SunOS Patch 112438-03 kann unter
http://sunsolve.sun.com/pub-cgi/retrieve.pl?type=0&doc=fpatches%2F112438&display=plain gefunden

- 100 -
7.4.2 Installation
Damit der Aufwand für die evtl. Portierung der Installation in ein HA-Cluster zu einem
späteren Zeitpunkt geringer ausfällt, wird das ursprüngliche Installationsverzeichnis
/usr/local/nagios auf /global/nagios abgeändert. Der Mountpoint /global entspricht den in
dem Cluster gespiegelten Festplatten.
Folgende Verzeichnisstruktur wird verwendet:
/global/nagios/
/global/nagios/client/
/global/nagios/nagios/
/global/nagios/nagios/bin/
/global/nagios/nagios/etc/
/global/nagios/nagios/lib/
/global/nagios/nagios/libexec/
/global/nagios/nagios/sbin/
/global/nagios/nagios/share/
/global/nagios/nagios/var/
/global/nagios/nagios/var/rw/
/global/nagios/nsca/
/global/nagios/src/
/global/nagios/src/apache_1.3.29
/global/nagios/src/libmcrypt-2.5.7
/global/nagios/src/nagios-1.2
/global/nagios/src/nagios-plugins-1.4.0aplha1
/global/nagios/src/nrpe-2.0
/global/nagios/src/nsca-2.4
/global/nagios/apache/
/global/nagios/local/
Wurzelverzeichnis der Nagios-Umgebung
Wurzel der Client-Binaries und -Quellen
Nagios Server Installation
Nagios Binaries
Nagios Konfigurationen
Für Nagios benötigte Libraries
Plugin-Sammlung
CGI-Verzeichnis
Basis der Stylsheets, Dokumentation, etc.
Wurzel für die Log-Daten und
Statusinformationen
Basis für das External Command File
Basis des NSCA-Daemons
Wurzelverzeichnis der Quellen
Wurzelverzeichnis für die dedizierte
Apache-Installation
Wurzelverzeichnis für sonstige Programme
und Libraries
Der Benutzername sowie Gruppe heisst nagios und muss zuvor manuell angelegt werden.
root@tivoli-1: groupadd nagios
root@tivoli-1: useradd -g nagios nagios
Die nachfolgenden Schritte werden weitestgehend als User nagios durchgeführt.
werden

- 101 -
7.4.2.1 Apache Installation
Die verwendete Apache-Version stammt von http://httpd.apache.org und wird nach dem
Entpacken mit nachfolgenden Befehlen für Nagios vorbereitet.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < apache_1.3.29.tar.gz | tar xf -
nagios@tivoli-1: cd apache_1.3.29
nagios@tivoli-1: ./configure --prefix=/global/nagios/apache\
--server-uid=nagios --server-gid=nagios
nagios@tivoli-1: make; make install
Hierbei wird dem Apache schon beim Kompilieren seine UID und GID mitgeteilt.
Die Standardkonfiguration muss um einige Direktiven erweitert werden. Um die
Übersichtlichkeit zu waren, werden sämtliche Nagios-spezifischen Konfigurationsmerkmale
in nagios.conf ausgelagert. Die Datei httpd.conf wird um eine Include-Anweisung erweitert:
nagios@tivoli-1: echo „Include /global/nagios/apache/conf/nagios.conf“ >>\
/global/nagios/apache/conf/httpd.conf
Die Datei /global/nagios/apache/conf/nagios.conf enthält folgende Daten:
# BEGIN
ScriptAlias /cgi-bin/nagios /global/nagios/nagios/sbin
ScriptAlias /nagios/cgi-bin /global/nagios/nagios/sbin
Options ExecCGI
AllowOverride AuthConfig
Order Allow,Deny
Allow From All
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /global/nagios/nagios/etc/htpasswd.users
require valid-user
# Where the stylesheets (config files) reside
Alias /nagios/stylesheets /global/nagios/nagios/share/stylesheets
# Where the HTML pages live(d)
Alias /nagios /global/nagios/nagios/share

- 102 -
Options FollowSymLinks
AllowOverride AuthConfig
Order Allow,Deny
Allow From
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /global/nagios/nagios/etc/htpasswd.users
require valid-user
# EOF
Nachdem daraufhin die Benutzer in die angegebene htpasswd.users eingetragen wurden, kann
der Apache gestartet werden.
nagios@tivoli-1: cd /global/nagios/apache/bin
nagios@tivoli-1: ./htpasswd -c /global/nagios/nagios/etc/htpasswd.users nagios
nagios@tivoli-1: ./htpasswd -c /global/nagios/nagios/etc/htpasswd.users hansi
nagios@tivoli-1: ./htpasswd -c /global/nagios/nagios/etc/htpasswd.users sven
nagios@tivoli-1: ./apachectl start
./apachectl start: httpd started
Damit der Apache auch bei einem Reboot des Servers wieder gestartet wird, kann das im
Anhang auf Seite 145 dokumentierte init-Script nach /etc/init.d/nag-apache installiert
werden. Daraufhin sollte noch ein passender Symlink in den Runlevel 3 (Multiuser) und
Runlevel 0 (Shutdown) gesetzt.
nagios@tivoli-1: ln -s /etc/init.d/nag-apache /etc/rc3.d/S99nag-apache
nagios@tivoli-1: ln -s /etc/init.d/nag-apache /etc/rc0.d/K50nag-apache

- 103 -
7.4.2.2 Nagios Installation
Wurde das benötigte Installationspaket von
http://prdownloads.sourceforge.net/nagios/nagios-1.2.tar.gz?download herunter geladen, kann
es wie folgt installiert werden.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < nagios-1.2.tar.gz | tar xf -
nagios@tivoli-1: cd nagios-1.2
nagios@tivoli-1: ./configure --enable-embedded-perl\
--with-perlcache\
--prefix=/global/nagios/nagios
Durch die Optionen --enable-embedded-perl und --with-perlcache profitiert Nagios von den
Vorteilen seines embedded Perl-Interpreters (siehe S. 31) sowie Perl-Caches.
nagios@tivoli-1: make all
nagios@tivoli-1: make install
nagios@tivoli-1: make install-commandmode
nagios@tivoli-1: make install-config
Die Installation der Init-Scripte erfolgt im nächsten Schritt als User root, da nur dieser
schreibenden Zugriff auf das systemweite init-Verzeichnis hat.
root@tivoli-1: make install-init
Hinweis: Wird Nagios über das init-Script aufgerufen, müssen die zusätzlichen Library-Pfade
bekannt gemacht werden. Dies geschieht durch Hinzufügen der folgenden beiden Zeilen
in /etc/init.d/nagios.
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/ssl/lib:/global/nagios/local/lib
export LD_LIBRARY_PATH
Auf die Konfiguration von Nagios wird im Kapitel 7.4.3 eingegangen.

- 104 -
7.4.2.3 Installation der Plugins
Da das Nagios Quellpaket keine Plugins enthält, müssen diese zusätzlich nachinstalliert
werden. Wurden die Plugins von
http://sourceforge.net/project/showfiles.php?group_id=29880 herunter geladen, können diese
wie gewohnt installiert werden.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < nagios-plugins-1.4.0alpha1.tar.gz | tar xf -
nagios@tivoli-1: cd nagios-plugins-1.4.0alpha1.tar
nagios@tivoli-1: ./configure --prefix=/global/nagios/nagios
nagios@tivoli-1: make; make install
Daraufhin sind die Plugins einsatzbereit und in dem Verzeichnis
/global/nagios/nagios/libexec zu finden.
7.4.2.4 Installation des check_nrpe
Das Plugin check_nrpe ist unabhängig von dem Nagios Plugin Projekt und kann über die
Nagios Homepage bezogen werden (http://www.nagios.org/download/extras.php). Um von
der Komfortabilität der variablen Parameter profitieren zu können, wird der NRPE mit
--enable-command-args kompiliert. Mit der Option --enable-ssl werden die SSL-
Verschlüsselungsmechanismen berücksichtigt.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < nrpe-2.0.tar.gz | tar xf -
nagios@tivoli-1: cd nrpe-2.0.tar
nagios@tivoli-1: ./configure --enable-ssl --enable-command-args
nagios@tivoli-1: make all
Nach dem Kompilieren liegt der NRPE-Daemon und der check_nrpe im Unterverzeichnis
./src. Von dort aus können sie manuell in das Zielverzeichniss kopiert werden. Da für diese
Nagios-Server-Installation nur das check_nrpe Plugin von Interesse ist, wird dieses in das
libexec-Verzeichnis der Nagios-Installation kopiert.
nagios@tivoli-1: cp -p src/check_nrpe /global/nagios/nagios/libexec
Der check_nrpe kann jetzt verwendet werden.

- 105 -
7.4.2.5 Installation des NSCA
Der NSCA soll auf dem Nagios Server als Daemon laufen und seine empfangenen Check-
Results in das External Command File schreiben. Bevor jedoch der NSCA kompiliert werden
kann, muss die mcrypt-Library installiert werden.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < libmcrypt-2.5.7.tar.gz | tar xf -
nagios@tivoli-1: cd libmcrypt-2.5.7
nagios@tivoli-1: ./configure --prefix=/global/nagios/local
nagios@tivoli-1: make; make install
Damit das configure-Script des NSCA die mcrypt-Installation findet, werden manuell die
Umgebungsvariablen verändert.
nagios@tivoli-1: export PATH=$PATH:/global/nagios/local/bin
nagios@tivoli-1: export LD_LIBRARY_PATH=/global/nagios/local/lib
Jetzt kann das NSCA Paket entpackt und kompiliert werden. Als Prefix wird in diesem Fall
der Installationspfad der Nagios-Installation angegeben.
nagios@tivoli-1: cd /global/nagios/src
nagios@tivoli-1: gunzip < nsca-2.4.tar.gz | tar xf -
nagios@tivoli-1: cd nsca-2.4
nagios@tivoli-1: ./configure --prefix=/global/nagios/nagios
nagios@tivoli-1: make all
Die Installation des NSCA-Daemons erfolgt manuell durch kopieren.
nagios@tivoli-1: cp nsca.cfg ./src/nsca /global/nagios/nsca
Die generierte Konfiguration ist bereits lauffähig. Einzig die Option password wird auf den
Wert tivnag gesetzt. Nach dem Starten des NSCA-Daemons erscheint dieser
erwartungsgemäß in der Prozessliste.
nagios@tivoli-1: cd /global/nagios/nsca
nagios@tivoli-1: ./nsca -c nsca.cfg
nagios@tivoli-1: ps -Af|grep nsca
nagios 12266 1 0 15:13:59 ? 0:00 ./nsca -c nsca.cfg
Zu diesem Zeitpunkt sind nur Verbindungen von der IP 127.0.0.1 (localhost) erlaubt. Im
Verlauf des PoC werden weitere IPs für jeden Host, welcher send_nsca nutzt, hinzugefügt.

- 106 -
Um nach einem Reboot des Servers den Start des NSCA-Daemons zu gewährleisten, wird das
init-Script (s. Anhang, Seite 144) manuell in /etc/init.d/nsca erstellt und mit folgenden
Befehlen eingebunden.
nagios@tivoli-1: ln -s /etc/init.d/nsca /etc/rc3.d/S99nsca
nagios@tivoli-1: ln -s /etc/init.d/nsca /etc/rc0.d/K50nsca
7.4.3 Konfiguration von Nagios
Das Konfigurationsverzeichnis /global/nagios/nagios/etc beinhaltet bereits Beispiele.
Sämtliche Dateien wurden bei der Installation automatisch im Namen durch -sample erweitert,
um auf notwendige Anpassungen hinzuweisen. Die einzelnen Konfigurationsoptionen können
der Nagios-Dokumentation 1 entnommen werden. In dieser Arbeit wird auf sämtliche
modifizierten Optionen eingegangen. Zu Formatierungszwecken wurden in dieser Arbeit zum
Teil Zeilenumbrüche hinzugefügt. Diese sind durch Backslashs „\“ gekennzeichnet und
müssen vor Übernahme in die Konfigurationsdateien entfernt werden.
7.4.3.1 Modifikationen an cgi.cfg
Die Datei cgi.cfg beinhaltet Konfigurationsmerkmale für das Webinterface. Es ermöglicht,
Statusinformationen der Service-Checks abzurufen und Einfluss auf den Nagios Prozess zu
nehmen. Um zu erkennen, ob der Nagios Prozess noch läuft, wird folgende Option
auskommentiert.
• nagios_check_command=/global/nagios/nagios/libexec/check_nagios\
/global/nagios/nagios/var/status.log 5 '/global/nagios/nagios/bin/nagios'
Hauptsächlich werden die authorisierten Benutzer mit ihren globalen Berechtigungen in
cgi.cfg definiert.
• authorized_for_system_information=nagios,hansi,sven
Zugriff auf die Nagios Prozess-Informationen über das Webinterfache für die User nagios,
hansi und sven.
• authorized_for_configuration_information=nagios,hansi,sven
Lesenden Zugriff auf Konfigurationsinformationen (Hosts, Services, Check-Befehle, ...)
über das Webinterface für die angegebenen Benutzer erlauben.
• authorized_for_system_commands=nagios
Der angegebene Benutzer darf über das Webinterface den Nagios Prozess starten und
stoppen.
1 Vgl: Galstad Ethan (2003): Nagios Documentation Version 1.0: Template-Based Object Data Configuration
File Options

- 107 -
• authorized_for_all_services=nagios
Der angegebene Benutzer kann die Information sämtlicher Services abrufen. Alle anderen
Benutzer sehen nur die Services, zu denen sie als Kontaktperson eingetragen sind.
• authorized_for_all_hosts=nagios
Der angegebene Benutzer kann die Information sämtlicher Hosts abrufen. Alle anderen
Benutzer sehen nur die Hosts, zu denen sie als Kontaktperson eingetragen sind.
• authorized_for_all_service_commands=nagios
Der angegebene Benutzer kann Service-Kommandos für sämtliche Services über das
Webinterface ausführen. Alle anderen Benutzer haben nur Zugriff auf die Service-
Kommandos, zu deren Service sie als Kontaktperson eingetragen sind.
• authorized_for_all_host_commands=nagios
Der angegebene Benutzer kann Host-Kommandos für sämtliche Hosts über das
Webinterface ausführen. Alle anderen Benutzer haben nur Zugriff auf die Host-
Kommandos, zu deren Hosts sie als Kontaktperson eingetragen sind.
Wurden die Änderungen vorgenommen, kann cgi.cfg-sample in cgi.cfg umbenannt werden.
nagios@tivoli-1: mv cgi.cfg-sample cgi.cfg

- 108 -
7.4.3.2 Modifikationen an checkcommands.cfg
In checkcommands.cfg werden sämtliche vom Nagios Prozess aufzurufenden Plugins mit
einem beschreibenden Namen und der Kommandozeile festgelegt. Um die in diesem PoC
verwendeten Plugins verwenden zu können, muss die Datei um folgende Einträge erweitert
werden.
define command {
command_name check_nrpe_ssl_args
command_line $USER1$/check_nrpe -t 120 -H $HOSTADDRESS$ -c check_args\
-a „$ARG1$ $ARG2$“
}
define command {
command_name check_nrpe_ssl_alive
command_line $USER1$/check_nrpe -t 120 -H $HOSTADDRESS$
}
define command {
command_name check_nrpe_args
command_line $USER1$/check_nrpe -n -t 120 -H $HOSTADDRESS$\
-c check_args -a „$ARG1$ $ARG2$“
}
define command {
command_name check_nrpe_alive
command_line $USER1$/check_nrpe -n -t 120 -H $HOSTADDRESS$
}
Diese vier Einträge für den NRPE gelten für Hosts, auf denen der NRPE-Daemon mit oder
ohne SSL kompiliert wurde (erkennbar an der Option -n). Zusätzlich wurde der Timeout auf
120 Sekunden erhöht, um die in der Praxis auftretenden Performanceschwankungen des
Netzwerkes oder remote Hosts zu kompensieren.
Wurden die Änderungen durchgeführt, lässt sich die Beispielkonfiguration durch umbenennen
aktivieren.
nagios@tivoli-1: mv checkcommands.cfg-sample checkcommands.cfg

- 109 -
7.4.3.3 Modifikationen an contactgroups.cfg
Die in contactgroups.cfg definierten Objekte fassen die in contact.cfg angelegten Benutzer
zu Gruppen zusammen. Da die vorgegebenen Beispiele nicht auf das PoC übertragbar sind,
wird die bestehende Konfiguration aus contactgroups.cfg-sample verworfen und stattdessen
mit nachfolgenden Objekten neu erstellt.
define contactgroup{
contactgroup_name
alias
members
}
define contactgroup{
contactgroup_name
alias
members
}
unix-admins
Unix Administratoren
hansi
linux-admins
Linux Administratoren
hansi,sven

- 110 -
7.4.3.4 Modifikationen an contacts.cfg
Die vorgegeben Benutzer in contact.cfg-sample werden verworfen und durch folgende
Objektdefinitionen ersetzt.
define contact{
contact_name
alias
service_notification_period
host_notification_period
service_notification_options
host_notification_options
service_notification_commands
host_notification_commands
email
pager
}
nagios
Nagios Admin
none
none
n
n
notify-by-email
host-notify-by-email
sven.schaffranneck@volkswagen.de
sven.schaffranneck@volkswagen.de
Der Kontakt Nagios Admin wird aufgrund des n (none) hinter den Optionen
host_notification_options und service_notification_options keine Meldungen von
Nagios erhalten. Er dient lediglich administrativen Zwecken.
define contact{
contact_name
alias
service_notification_period
host_notification_period
service_notification_options
host_notification_options
service_notification_commands
host_notification_commands
email
pager
}
define contact{
contact_name
alias
service_notification_period
host_notification_period
service_notification_options
host_notification_options
service_notification_commands
host_notification_commands
email
pager
}
hansi
Hans Fricke
workhours
workhours
c,r
d,r
notify-by-email
host-notify-by-email
hans.fricke@volkswagen.de
hans.fricke@volkswagen.de
sven
Sven Schaffranneck
24x7
24x7
c,w,r
d,r
notify-by-email
host-notify-by-email
sven.schaffranneck@volkswagen.de
sven.schaffranneck@volkswagen.de

- 111 -
7.4.3.5 Modifikationen an dependencies.cfg
Service- und Host-Abhängigkeiten sind in komplexen Umgebungen sinnvoll einsetzbar. Von
ihrer Verwendung wird in diesem PoC jedoch abgesehen, da sie für großflächige Lasttests
keinen aussagekräftigen Mehrwert sondern nur zusätzlichen Konfigurationsaufwand mit sich
bringen.
Die Datei dependencies.cfg-sample wird gelöscht und in die entsprechende
cfg_file-Direktive aus der nagios.cfg entfernt (s. Kapitel 7.4.3.10).
nagios@tivoli-1: rm dependencies.cfg-sample
7.4.3.6 Modifikationen an escalations.cfg
Laut der Nagios Dokumentation sind die Host,- Hostgroup-, Service- und Servicegroup- (erst
ab Nagios Version 2.0) Escalations „completely optional“. Mit ihnen lassen sich
Benachrichtigungen für spezifische Hosts oder Services (oder Gruppen) regeln. In diesem
PoC werden diese optionalen Direktiven nicht verwendet.
nagios@tivoli-1: rm escalations.cfg-sample
7.4.3.7 Modifikationen an hostgroups.cfg
Die Objekte dieser Konfigurationsdatei fassen die Hosts aus hosts.cfg in Gruppen
zusammen. Für die Unix-Hosts wird in diesem PoC zwischen SSL-fähigen und nicht-SSLfähigen
NRPE-Hosts unterschieden.
define hostgroup{
hostgroup_name
alias
contact_groups
members
}
define hostgroup{
hostgroup_name
alias
contact_groups
members
}
define hostgroup{
hostgroup_name
alias
contact_groups
members
}
unix-nrpe-ssl-servers
Unix-Server mit NRPE-SSL
unix-admins
tivoli-40
unix-nrpe-servers
Unix Server mit NRPE
unix-admins
l11tiv01m,l11tiv03m
linux-nrpe-ssl-servers
Linux Server mit NRPE-SSL
linux-admins
s390linux07,lnx5

- 112 -
Zusätzlich gibt es noch eine Hostgroup unix, welche sämtliche Unix und Linux Hosts enthält.
Die in hostgroups.cfg-sample vordefinierten Objekte sind für die verwendete Konfiguration
überflüssig und werden entfernt.
7.4.3.8 Modifikationen an hosts.cfg
In hosts.cfg werden sämtliche zu überwachenden Hosts definiert. Durch die Verwendung
von Templates lassen sich viele Optionen zusammenfassen. Zuerst wird ein generisches Host-
Objekt für Unix-Server definiert.
define host {
name
generic-unix-host
register 0
max_check_attempts 3
process_perf_data 0
notification_interval 0
notification_period 24x7
notification_options d,r
check_command
check-host-alive
}
Mit dem Wert 0 (Null) der Option register wird die Host-Definition als generisch deklariert.
Andere Host-Definition können nun mit der Direktive use von generic-unix-host erben.
define host{
use
generic-unix-host
host_name
tivoli-40
alias Tivoli 40
address 10.115.215.115
}
define host{
use
generic-unix-host
host_name
s390linux07
alias
s390linux07
address 10.113.213.113
}
Sämtliche weiteren Hosts werden analog zu diesen beiden Beispielen angelegt. Die vorhande
hosts.cfg-sample wird verworfen.

- 113 -
7.4.3.9 Modifikationen an misccommands.cfg
Kommandodefinitionen für die Notifications und Performance-Processing sind typischer
Inhalt der Datei misccommands.cfg. Unter SunOS 5.8 besteht ein Problem mit dem
vorgegebenen mail-Kommando. Die Option -s für das Subjekt ist nicht mit /usr/bin/mail
kompatibel. Abhilfe schafft hier das Programm /usr/bin/mailx. Die korrekte Zeile für das
Kommando notify-by-email lautet demnach:
define command{
command_name notify-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\n \
Notification Type: $NOTIFICATIONTYPE$\n\n \
Service: $SERVICEDESC$\nHost: $HOSTALIAS$\n \
Address: $HOSTADDRESS$\nState: $SERVICESTATE$\n\n \
Date/Time: $DATETIME$\n\nAdditional Info:\n\n \
$OUTPUT$" | \
/usr/bin/mailx -s "** $NOTIFICATIONTYPE$ alert - \
$HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" \
$CONTACTEMAIL$
}
Die Kommandodefinition für host-notify-by-email wird dementsprechend angepasst.
Besteht die Anforderung, weitere Macros zu verwenden, können diese in der Nagios-
Dokumentation unter dem Abschnitt „Using Macros In Commands“ 1 nachgelesen werden. In
misccommands.cfg existieren noch weitere, beispielhafte Objektdefinitionen, die jedoch für
dieses PoC nicht relevant sind und entfernt werden können.
nagios@tivoli-1: mv misccommands.cfg-sample misccommands.cfg
1 Vgl: Galstad Ethan (2003): Nagios Documentation Version 1.0: Using Macros In Commands

- 114 -
7.4.3.10 Modifikationen an nagios.cfg
Zuerst werden die nicht benutzten cfg_file-Direktiven zum Einbinden von dependencies.cfg
und escalations.cfg auskommentiert.
#cfg_file=/global/nagios/nagios/etc/dependencies.cfg
#cfg_file=/global/nagios/nagios/etc/escalations.cfg
Als nächstes wird die Verarbeitung von externen Befehlen aktiviert. Erst dadurch lassen sich
über das Webinterface Kommandos an den Nagios Prozess übergeben. Auch für passive
Service-Checks ist diese Option notwendig.
check_external_commands=1
Um später die Möglichkeit offen zu halten, die von Nagios produzierten Logdateien mit
anderen Programm zu verarbeiten, empfiehlt es sich, die initialen Service-States zu sichern.
Folgende Option ist hierfür relevant.
log_initial_states=1
Damit Nagios nach einem Neustart die alten (zuletzt gespeicherten) Service-States aus der
status.sav einliest, wird die nachfolgende Option aktiviert. Sie verhindert, das vorhande
Probleme nach dem Neustart fälschlicherweise als neu erkannt und eskaliert werden.
use_retained_program_state=1
Die Standart-Timeouts von Nagios sind für die Praxis zu restriktiv definiert. Um Fehlalarme
zu minimieren, werden die vorgegebenen Werte verdoppelt.
service_check_timeout=120
host_check_timeout=60
event_handler_timeout=60
notification_timeout=60
ocsp_timeout=10
perfdata_timeout=10
Das Feature Flap Detection muss explizit aktiviert werden. Da es sich dabei um ein als
experimentell ausgewiesenes Feature handelt, ist es in der Default-Konfiguration deaktiviert.
enable_flap_detection=1

- 115 -
Zuletzt wird noch die eMail- und Pager-Adresse des Administrators definiert. Diese lassen
sich über die Macros $ADMINEMAIL$ und $ADMINPAGER$ weiterverwenden.
admin_email=sven.schaffranneck@volkswagen.de
admin_pager=sven.schaffranneck@volkswagen.de
Damit sind die Modifikationen an nagios.cfg bzw. nagios.cfg-sample abgeschlossen.
nagios@tivoli-1: mv nagios.cfg-sample nagios.cfg
7.4.3.11 Modifikationen an ressource.cfg
Die Datei ressource.cfg beinhaltet die frei definierbaren Macros und Datenbank-spezifischen
Konfigurationsoptionen. Letztere werden in diesem PoC jedoch nicht eingesetzt, da die DB-
Unterstützung in zukünftigen Nagios-Versionen ohnehin entfernt wird 1 .
Das vorhandene Macro $USER1$ ist bereits korrekt definiert, die weiteren 31 zur Verfügung
stehenden Macrodefinitionen werden nicht genutzt.
nagios@tivoli-1: mv ressource.cfg-sample ressource.cfg
7.4.3.12 Modifikationen an services.cfg
Die Konfiguration der Services profitieren stark von festgelegten Templates. Die existierende
services.cfg-sample beinhaltet Beispieldefinitionen, welche in dieser Arbeit jedoch neu
definiert werden. Damit kann die Beispiel-Datei verworfen werden.
nagios@tivoli-1: rm service.cfg-sample
Zuerst wird ein globales Template-Objekt definiert.
define service {
name
generic-unix
register 0
contact_groups
unix-admins,linux-admins
check_period
24x7
max_check_attempts 3
normal_check_interval 1
retry_check_interval 1
notification_interval 0
notification_period 24x7
notification_options c,r
}
Anzumerken ist hierbei, das normal_check_interval sowie retry_check_interval auf den
Wert 1 gesetzt sind. In Kombination mit der Option interval_length=60 aus der nagios.cfg
bedeutet dies, das jeder Service-Check jede Minute ausgeführt wird. In der Regel werden
diese zwar nur alle 5 bis 15 Minuten notwendig werden. Um jedoch die geforderten ~1280
Service-Checks/Minute zu simulieren, wird diese sehr kurze Intervallzeit gewählt.
1 Vgl: Galstad, Ethan (2004): Upcoming Version Information

- 116 -
Es folgen die einzelnen Servicedefinitionen. Der Aufbau der Objekte sind ähnlich. Wichtig ist
die Direktive use, um von generic-unix zu erben.
define service {
name
use
service_description
hostgroup_name
check_command
}
define service {
name
use
service_description
hostgroup_name
check_command
}
define service {
name
use
hostgroup_name
check_command
}
telnet
generic-unix
TCP Telnet
unix-servers
check_tcp_telnet
nrpe_disk_var
generic-unix
Disk /var
unix-nrpe-servers
check_nrpe_args!disk!-w5% -c2% -p/var
nrpe_ssl_disk_var
nrpe_disk_var
unix-nrpe-ssl-servers,linux-nrpe-ssl-servers
check_nrpe_ssl_args!disk!-w5% -c2% -p/var
Die Servicedefinitionen nrpe_ssl_disk_var erbt in diesem Fall nicht von generic-unix,
sondern von nrpe_disk_var. Dabei werden hostgroup_name und check_command überschrieben.
7.4.3.13 Modifikationen an timeperiods.cfg
Die vorgegebenenZeiträume sind für diese PoC bereits optimal gewählt, daher werden keine
Änderungen an timeperiods.cfg vorgenommen, sondern die Beispieldatei übernommen.
nagios@tivoli-1: mv timeperiods.cfg-sample timeperiods.cfg

- 117 -
7.4.4 Start des Nagios Servers
Nachdem die Konfiguration abgeschlossen ist, müssen noch die Umgebungvariablen für den
Benutzer nagios angepasst werden, damit sämtliche notwendigen Bibliotheken und
Programme gefunden werden. Dazu sind folgende Zeilen zu ~/.profile hinzuzufügen.
PATH=$PATH:/usr/local/bin:/global/nagios/local/bin
LD_LIBRARY_PATH=/global/nagios/local/lib:/usr/local/lib:/usr/local/ssl/lib
export LD_LIBRARY_PATH
Jetzt kann der Nagios Server gestartet werden. Zuvor sollte jedoch unbedingt ein Check der
Konfiguration vorgenommen werden. Dieser sogenannte „pre-flight check“ lässt sich mit der
Option -v beim Aufruf von Nagios erreichen.
nagios@tivoli-1: # pwd
/global/nagios/nagios/etc

- 118 -
nagios@tivoli-1: # ../bin/nagios -v nagios.cfg
Nagios 1.2
Copyright (c) 1999-2004 Ethan Galstad (nagios@nagios.org)
Last Modified: 02-02-2004
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 640 services.
Checking hosts...
Checked 49 hosts.
Checking host groups...
Checked 3 host groups.
Checking contacts...
Warning: Contact 'nagios' is not a member of any contact groups!
Checked 3 contacts.
Checking contact groups...
Checked 2 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking host group escalations...
Checked 0 host group escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 22 commands.
Checking time periods...
Checked 4 time periods.
Checking for circular paths between hosts...
Checking for circular service execution dependencies...
Checking global event handlers...
Checking obsessive compulsive service processor command...
Checking misc settings...
Total Warnings: 1
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
Das der Benutzer nagios keiner Gruppe angehört, ist beabsichtigt. Die aufgetretene Warnung
kann somit ignoriert werden.

- 119 -
Über das installierte init-Script /etc/init.d/nagios kann Nagios gestartet werden. Dazu ist es
die Berechtigung des Users root erforderlich.
root@tivoli-1: # /etc/init.d/nagios start
Starting network monitor: nagios
PID TTY TIME CMD
3629 ? 0:00 nagios
Nagios wurde erfolgreich gestartet. Ein Blick auf die Tactical Overview des Nagios
Webfrontends unter http://tivoli-1:8080/nagios bestätigt dieses (Abbildung 25).
Abbildung 25 Nagios Webfrontend: Tacticel Overview nach erstem Start
Quelle: Screenshot

- 120 -
7.5 Vorbereitung der Agenten für die remote Hosts
Um die remote Hosts einzubinden, werden für sämtliche Plattformen kompilierte Binaries der
Plugins, des NRPE-Daemons sowie send_nsca benötigt. Um eine semi-automatische
Softwareverteilung vorzubereiten, werden die Quellen der einzelnen Plugins und Daemons in
definierte Verzeichnisse kopiert:
/global/nagios/client//
[...]/src
[...]/distrib
[...]/distrib/ssh
Wurzelverzeichnis der Client-Files (im weiteren
Verlauf durch [...] substituiert)
Verzeichnis der Quellen für die remote Hosts
Distributionsverzeichnis für die remote Hosts
Public Keys (für check_by_ssh)
Die Unterverzeichnisse distrib sowie src unterteilen sich identisch nach Plattformen und
Versionen. Für jede Software existiert ein symbolischer Link latest, welcher auf die
aktuellste Version zeigt. Der Vorteil dieser Struktur liegt in der automatischen Verarbeitung.
So lässt sich in dem folgenden Beispiel „SunOS“ automatisch mit uname ermitteln und die
Version 5.8 mit uname -r. Anhand der symbolischen Links latest wird immer die neuste
Version erreicht.
[...]/src/SunOS/5.8/nrpe/nrpe-2.0
[...]/src/SunOS/5.8/nrpe/latest -> nrpe-2.0
[...]/distrib/SunOS/5.8/plugins/nagios-plugins-1.4.0alpha1
[...]/distrib/SunOS/5.8/plugins/latest -> nagios-plugins-1.4.0alpha1

- 121 -
Nachdem die benötigte Verzeichnisstruktur angelegt wurde, werden die Quellen an die
entsprechenden Orte kopiert. Für die Plattform SunOS 5.8 besteht demnach folgende
Verzeichnisstruktur.
SunOS/
SunOS/5.8
SunOS/5.8/src
SunOS/5.8/src/plugins
SunOS/5.8/src/plugins/latest -> nagios-plugins-1.4.0alpha1
SunOS/5.8/src/plugins/nagios-plugins-1.4.0alpha1
SunOS/5.8/src/libmcrypt
SunOS/5.8/src/libmcrypt/latest -> libmcrypt-2.5.7
SunOS/5.8/src/libmcrypt/libmcrypt-2.5.7
SunOS/5.8/src/nrpe
SunOS/5.8/src/nrpe/latest -> nrpe-2.0
SunOS/5.8/src/nrpe/nrpe-2.0
SunOS/5.8/src/nsca
SunOS/5.8/src/nsca/latest -> nsca-2.4
SunOS/5.8/src/nsca/nsca-2.4
SunOS/5.8/distrib
SunOS/5.8/distrib/plugins
SunOS/5.8/distrib/plugins/latest -> nagios-plugins-1.4.0alpha1
SunOS/5.8/distrib/plugins/nagios-plugins-1.4.0alpha1
SunOS/5.8/distrib/nsca
SunOS/5.8/distrib/nsca/latest -> nsca-2.4
SunOS/5.8/distrib/nsca/nsca-2.4
SunOS/5.8/distrib/nrpe
SunOS/5.8/distrib/nrpe/latest -> nrpe-2.0
SunOS/5.8/distrib/nrpe/nrpe-2.0
SunOS/5.8/distrib/lib
Nach dem Kompilieren, welches analog zum Kapitel 7.4.2 geschieht, können die einzelnen
Binaries in die vorbereiteten Distributionsverzeichnisse kopiert werden.
nagios@tivoli-1: # cd plugins/latest/plugins
nagios@tivoli-1: # find ./ -perm 755 -name "check_*" -exec\
cp '{}' /global/nagios/client/SunOS/5.8/distrib/plugins/latest \;
nagios@tivoli-1: # cd /global/nagios/client/SunOS/5.8/src/nrpe/latest
nagios@tivoli-1: # cp nrpe.cfg /global/nagios/client/sunOS/5.8/distrib/nrpe/latest
nagios@tivoli-1: # cp src/nrpe /global/nagios/client/sunOS/5.8/distrib/nrpe/latest

- 122 -
Der NRPE-Daemon wird anhand der Datei nrpe.cfg wie folgt konfiguriert:
server_port=5666
allowed_hosts=127.0.0.1,10.153.253.153,10.101.202.101
nrpe_user=tivadmin
nrpe_group=tivadmin
dont_blame_nrpe=1
debug=0
command_timeout=120
command[check_args]=/opt/Tivoli/nagios/libexec/check_$ARG1$ $ARG2$
Zusätzlich empfiehlt es sich, ein init-Script hinzuzufügen, welches im Anhang auf Seite 143
zu finden ist. Dieses wird als nrpe.sh im NRPE-Distributionsverzeichnis abgelegt.
Die Konfiguration des send_nsca beschränkt sich auf das Festlegen des Passwortes. Die
encryption_method wird belassen.
password=tivnag
encryption_method=1
Daraufhin kann auch send_nsca mit seiner Konfiguration ins Distributionsverzeichnis kopiert
werden.
nagios@tivoli-1: # cd /global/nagios/client/SunOS/5.8/src/nsca/latest
nagios@tivoli-1: # cp -p send_nsca.cfg\
/global/nagios/client/sunOS/5.8/distrib/nsca/latest
nagios@tivoli-1: # cp -p src/send_nsca\
/global/nagios/client/sunOS/5.8/distrib/nsca/latest
Um den nrpe mit SSL-Unterstützung auch auf remote Hosts nutzen zu können, die kein SSH
und SSL installiert haben, werden die SSL-Libraries mit in das Distributionsverzeichnis
aufgenommen. Zusätzlich werden noch von einigen Plugins die iconv-Libraries benötigt.
nagios@tivoli-1: # mkdir -p /global/nagios/client/SunOS/5.8/distrib/lib
nagios@tivoli-1: # cp -p /usr/local/ssl/lib/libssl.so.0.9.7\
/usr/local/ssl/lib/libcrypto.so.0.9.7\
/usr/local/lib/libiconv.so.2
/global/nagios/client/SunOS/5.8/distrib/lib

- 123 -
Mit Hilfe des folgenden Installationsscriptes install.sh, welches von der festgelegten
Verzeichnisstruktur gebrauch macht, können die Binärpakete später komfortabel auf den
remote Hosts installiert werden.
#!/bin/sh
nfs_dir="/net/tivoli-1/global/nagios/client"
nfs_distrib="$nfs_dir/`uname`/`uname -r`/distrib"
local_dir="/opt/Tivoli/nagios"
echo "lege verzeichnisse an"
mkdir -p $local_dir/nrpe
mkdir -p $local_dir/nsca
mkdir -p $local_dir/libexec
mkdir -p $local_dir/lib
echo "setze rechte auf tivadmin:tivadmin"
chown -R tivadmin:tivadmin $local_dir
echo "installiere distribution `uname`/`uname -r`"
su - tivadmin -c "cp $nfs_distrib/nrpe/latest/* $local_dir/nrpe"
su - tivadmin -c "cp $nfs_distrib/nsca/latest/* $local_dir/nsca"
su - tivadmin -c "cp $nfs_distrib/plugins/latest/* $local_dir/libexec"
su - tivadmin -c "cp $nfs_distrib/lib/* $local_dir/lib"
su - tivadmin -c "mkdir .ssh"
su - tivadmin -c "cp $nfs_dir/ssh/* .ssh"
ln -s $local_dir/nrpe/nrpe.sh /etc/rc3.d/S99nrpe
ln -s $local_dir/nrpe/nrpe.sh /etc/rc0.d/K50nrpe
Dieses Script wird, leicht angepasst, auch für die anderen Architekturen verwendet und setzt
den Einsatz von NFS 1 voraus.
Als Wurzelverzeichnis wird plattformübergreifend /opt/Tivoli/nagios gewählt. Diese
Bezeichnung hat betriebsinterne Gründe und ist für die Funktionalität irrelevant. Es sollte
lediglich darauf geachtet werden, auf sämtlichen Hosts das gleiche Verzeichnis zu nutzen.
Dies erleichtert die Konfiguration und Pflege enorm. Neben dem gleichlautenden
Verzeichnisnamen wird auch ein gleichlautender Benutzer sowie Gruppe verwendet. In der
Regel ist dies der Benutzer nagios mit der Gruppe nagios. In dieser Arbeit wird jedoch der
Benutzer tivadmin mit der Gruppe tivadmin genutzt, was wiederum betriebsinterne
Hintergründe hat.
1 Mit dem NFS (Network File System) können Verzeichnisse über das Netzwerk freigegeben werden.

- 124 -
7.6 Installation der Agenten auf den remote Hosts
Ein Grossteil der zu überwachenden Server laufen unter dem Betriebssystem Solaris 8. Dieser
Artikel beschreibt die notwendigen Prerequirements, die Installation sowie Konfiguration der
Überwachungsmechanismen.
7.6.1 Voraussetzung und Vorbereitung
Auf dem remote Host muss anhand folgender Tabelle sichergestellt sein, das die notwendigen
Voraussetzungen erfüllt sind (Patch 112438 nur für Solaris 8):
Voraussetzung NRPE (SSL) NRPE NSCA NSCA (XOR) check_by_SSH
Solaris-Patch 112438 X - X - -
SSH 3.7.1p2 - - - - X
Soll der NRPE ohne SSL oder der NSCA ohne mcrypt-Unterstützung verwendet werden,
muss der NRPE ohne die configure-Option --enable-ssl kompiliert werden und das
configure-Script des NSCA darf die mcrypt-Library nicht im Pfad finden.
7.6.2 Installation
Wurde die Installation gemäß Kapitel 7.5 vorbereitet, können die Binaries an die
entsprechenden Stellen kopiert werden. Der verwendete Benutzer tivadmin ist im NIS 1 -
Verzeichnis eingetragen und somit auf vielen der remote Hosts bereits bekannt. Sollte ein
Server keinen NIS-Client besitzen, muss die Gruppe sowie Benutzer tivadmin angelegt
werden:
root@tivoli-40 # groupadd tivadmin
root@tivoli-40 # useradd -g tivadmin -d /opt/Tivoli/nagios tivadmin
1 Network Information Service: Bei NIS handelt es sich um Sun Microsystems YP (yellow pages) client-server
Protokoll für die Verteilung von Systemkonfigurationen wie Benutzer und Hostnames.

- 125 -
Anhand des PAP (Programmablaufplan / flow chart) aus Abbildung 26 lässt sich die
Installation der Agenten nachvollziehen.
Abbildung 26 PAP zur Installation eines remote Hosts
Quelle: Eigene Darstellung
Soll der NRPE-Daemon nach einem Neustart des Servers automatisch mitgestartet werden, so
muss das korrespondierende init-Script nrpe.sh als root installiert werden.
root@tivoli-40 # ln -s /opt/Tivoli/nagios/nrpe/nrpe.sh /etc/rc3.d/S99nrpe
root@tivoli-40 # ln -s /opt/Tivoli/nagios/nrpe/nrpe.sh /etc/rc0.d/K50nrpe
Hinweis: Nur bei manueller Installation notwendig, das Script install.sh erstellt die Links
selbstständig.
Nach der Installation kann der NRPE gestartet werden
tivadmin@tivoli-40 # /opt/Tivoli/nagios/nrpe/nrpe.sh start
Starting /opt/Tivoli/nagios/nrpe/nrpe

- 126 -
7.6.3 Einsatz von send_nsca
Der NSCA-Daemon übergibt passive Resultate an den Nagios Prozess. Das Kapitel 4.4.2 hat
sich bereits auführlich mit der Theorie beschäftigt. Um einen Service-Check vom remote Host
über den NSCA zum Nagios Prozess zu übertragen, muss Nagios passive Service-Checks
akzeptieren. Des Weiteren sollte der korrespondierende Service-Check als passiv deklariert
sein.
Für das Proof of Concept wird ein Beispielscript erstellt, welches einen generischen
Longrunner mit der Laufzeit von 360 Sekunden darstellt. Im Anschluss übermittelt es ein
Dummy-Ergebnis mit Datum und Uhrzeit an Nagios.
#!/bin/sh
sleep 360
echo „debian[tab]Longrunner via NSCA[tab]0[tab]OK Übertragung mit NSCA\
erfolgreich am `date`“ | ./send_nsca -H tivoli-1 -c send_nsca.cfg
Dieses wird zyklisch 17 Minuten nach jeder vollen Stunde per cron aufgerufen.
tivadmin@debian # crontab -e
17 * * * * /opt/Tivoli/nagios/nsca/longrunner.sh
Damit der NSCA-Daemon diese Nachricht auch akzeptiert, muss die IP des Hosts debian in
nsca.cfg bekannt gemacht werden. Hierzu wird die Option allowed_hosts um die IP des
remote Hosts debian erweitert:
allowed_hosts=127.0.0.1,10.105.205.105
Der Host debian sowie der Service longrunner müssen in der Nagios-Konfiguration als
Objekte definiert werden.
define host{
use
generic-unix-host
host_name
debian
alias
debian
address 10.105.205.105
}
define service {
name
longrunner
use
generic-unix
active_checks_enabled 0
passive_checks_enabled 1
check_freshness 0
service_description Longrunner via NSCA
check_command
check_ping!100.0,20%!500.0,60%
}

- 127 -
Die erfolgreiche Übertragung kann anhand der Datei status.log überprüft werden.
[1089356332] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;debian;Longrunner via
NSCA;0;OK Übertragung mit NSCA erfolgreich am Fri Jul 9 07:24:50 CEST 2004
Erscheint daraufhin keine Fehlermeldung in der status.log, wurde der Service-Check
erfolgreich verarbeitet und ist umgehend im Webinterface einzusehen.
Hinweis: Die Option normal_check_interval (Konfiguration der Services) hat keine
Auswirkung auf die Verarbeitung von externen bzw. passiven Resultaten.
7.6.4 Einsatz von check_by_ssh
Die Funktionsweise des check_by_ssh lehnt sich eng an check_nrpe an. Als Vorausetzung
muss auf dem remote Host ein SSH-Daemon laufen und der Public-Key des Benutzers nagios
vorliegen. Wurde der remote-Host mit Hilfe des install-Scriptes aufgesetzt, liegen die Public-
Keys bereits an der richtigen Stelle (~/.ssh).
Wird nun mit dem check_by_ssh-Plugin eine Verbindung aufgebaut, wird die manuelle
Bestätigung des remote Host Keys erwartet. Durch den Host-Key-Check können man-in-themiddle-Attacken
erkannt werden. Da der Aufwand jedoch zu hoch wäre, für jeden entfernten
Host die Host-Keys zu pflegen, wird eine benutzerspezifische
SSH-Konfigurationsdatei mit folgender Direktive angelegt:
nagios@tivoli-1: # cat ~/.ssh/config
StrictHostKeyChecking no
Dadurch wird auf manuelle Bestätigungen beim Check des Host-Keys verzichtet.

- 128 -
Als nächstes wird ein checkcommand definiert, welcher von check_by_ssh Gebrauch macht:
define command {
command_name check_by_ssh_args
command_line $USER1$/check_by_ssh -l tivadmin -t 120\
-H $HOSTADDRESS$ -C '/opt/Tivoli/nagios/libexec/check_$ARG1$ $ARG2$'
}
Ergänzend wird ein Service definiert, welcher den Mountpoint / auf dem Host debian
überwachen soll.
define service {
name
use
host_name
service_description
check_command
}
ssh_disk_root
generic-unix
debian
Disk / by ssh
check_by_ssh_args!disk!-w5% -c2% -p/
Die Datei status.log präsentiert den erfolgreichen Check anhand folgender Zeile:
[1089361446] SERVICE ALERT: debian;Disk / by ssh;WARNING;HARD;3;DISK WARNING
[151860 kB (5%) free on /dev/hda1]
Deutlich zu sehen ist die Service-Description und Status, in diesem Falle WARNING.

- 129 -
7.7 Besonderheiten und Hinweise für AIX
Für das PoC standen zwei remote Hosts mit AIX 5.1 und 5.2 zur Verfügung. Um die Plugins,
NRPE und send_nsca zu kompilieren, werden mindestens der gcc und gettext benötigt. Diese
GNU-Tools sind bereits vorkompiliert auf der IBM-Seite
http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html zu finden. Folgende
Versionen werden installiert:
root@l11tiv03m # rpm -U gettext-0.10.40-1.aix5.1.ppc.rpm
root@l11tiv03m # rpm -U gcc-2.9.aix51.020209-4.aix5.2.ppc.rpm
Da die SSL-Unterstützung des NRPE unter AIX fehlerhaft ist, wird der Daemon ohne SSL
kompiliert.
tivadmin@l11tiv03m # cd /net/tivoli-1/global/nagios/client/AIX/2/src/nrpe/latest
tivadmin@l11tiv03m # ./configure --enable-command-args --disable-ssl\
--with-nrpe-user=tivadmin --with-nrpe-group=tivadmin
tivadmin@l11tiv03m # make
Der NSCA wird aus Performancegründen generell nur mit XOR-Verschlüsselung betrieben.
Daher kann der send_nsca ohne mcrypt-Unterstützung kompiliert werden.
tivadmin@l11tiv03m # cd /net/tivoli-1/global/nagios/client/AIX/2/src/nsca/latest
tivadmin@l11tiv03m # ./configure --with-nsca-user=tivadmin --with-nsca-grp=tivadmin
tivadmin@l11tiv03m # make
Die Plugins werden wie gewohnt mit einem einfachen ./configure und make kompiliert.
Hinweis: Wird das Plugin check_by_ssh eingesetzt, muss der SSH-Daemon installiert sein.

- 130 -
Auf den Seiten 121ff ist das Kopieren der Binaries in die Distributionsverzeichnisse für
SunOS beschrieben, was sich weitestgehend auf AIX und weitere Plattformen übetragen lässt.
Das install.sh-Script muss jedoch etwas modifiziert werden:
#!/bin/sh
nfs_dir="/net/tivoli-1/global/nagios/client"
nfs_distrib="$nfs_dir/`uname`/`uname -r`/distrib"
local_dir="/opt/Tivoli/nagios"
echo "lege verzeichnisse an"
mkdir -p $local_dir/nrpe
mkdir -p $local_dir/nsca
mkdir -p $local_dir/libexec
echo "setze rechte auf tivadmin:tivadmin"
chown -R tivadmin:tivadmin $local_dir
echo "installiere distribution `uname`/`uname -r`"
su - tivadmin -c "cp $nfs_distrib/nrpe/latest/* $local_dir/nrpe"
su - tivadmin -c "cp $nfs_distrib/nsca/latest/* $local_dir/nsca"
su - tivadmin -c "cp $nfs_distrib/plugins/latest/* $local_dir/libexec"
su - tivadmin -c "mkdir .ssh"
su - tivadmin -c "cp $nfs_dir/ssh/* .ssh"
ln -s $local_dir/nrpe/nrpe.sh /etc/rc.d/rc2.d/S99nrpe

- 131 -
7.8 Besonderheiten und Hinweise für HP-UX
Beim Kompilieren der Plugins auf HP-UX 11.11 sind einige Randbedingungen zu beachten. 1
• Der GCC für HP-UX 11.0 kann nicht verwendet werden, es wird der GCC für
HP-UX 11.11 PA-RISC benötigt. Dieser ist auf den Seiten von HP zu finden:
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,4682,
00.html
• Das ursprüngliche make von HP ist veraltet und wird primär zum Kompilieren des HP-
Kernels verwendet. Es empfiehlt sich die Verwendung des GNU make 3.8, zu finden unter
http://www.gnu.org/software/make. Andreas Ericsson von OP5 (www.op5.se) gab einen
entscheidenen Hinweis auf die Probleme beim Kompilieren:
It's not so much a requirement for GNU make as it is a requirement for
something else than HP's make, which is old, ugly and more than a little
incompetent. 2
• Zusätzlich wird GNU flex (schnelles Text-Analyse-Tool) ab der Version 2.5.4 benötigt.
Dieses ist unter http://www.gnu.org/software/flex/flex.html zu finden.
Das configure-Script für die Erkennung des ps-Kommandos aus nagios-plugins-1.4.0alpha1
ist fehlerhaft. Abhilfe schafft die Verwendung der CVS-Version
(http://nagiosplug.sourceforge.net/snapshot), in welcher der Fehler behoben wurde (siehe auch
Kapitel 7.2.2.2). 3
Selbst im CVS noch immer fehlerhaft ist das check_swap-Plugin. Dieses muss anhand des
Kapitels 7.2.2.3 ersetzt werden. Des Weiteren ist darauf zu achten, dass das Verzeichnis
/usr/sbin im Pfad des Benutzers tivadmin ist, damit das Tool
/usr/sbin/swapinfo vom configure-Script und später von check_swap gefunden werden kann.
Anhand dieser Voraussetzungen können der NRPE (ohne SSL), NSCA (ohne mcrypt) und die
Nagios Plugins (CVS) analog zum vorhergehenden Kapitel kompiliert sowie installiert
werden.
1 Vgl: Mailingliste nagios-users, Message-ID: 8138913, 29.04.2004
2 Vgl: Mailingliste nagios-users, Message-ID: 8138879, 28.04.2004
3 Vgl: Mailingliste nagios-users, Message-ID: 8138988, 30.04.2004

- 132 -
7.9 Besonderheiten und Hinweise für Linux (Intel/s390)
Da Nagios primär für Linux entwickelt wurde, funktionieren die Plugins erwartungsgemäß
zuverlässig. Der NRPE kann problemlos mit SSL kompiliert und betrieben werden. Als
Voraussetzung zum Kompilieren gelten folgende Libraries und Tools:
• OpenSSL 0.9.6 (für die SSL-Unterstützung des NRPE - Version 0.9.7 ebenfalls erfolgreich
getestet)
• SSH 2.9.9p2 (notwendig für das check_by_ssh-Plugin - Version 3.6.1p2 ebenfalls
erfolgreich getestet)
• GCC 2.95.3 (GNU C Compiler - zusätzlich Version 3.3.3 erfolgreich getestet)
• GNU make 3.8 (Werkzeug zum Kompilieren - Version 3.79.1 ebenfalls erfolgreich getestet)
Zur Laufzeit werden die SSL-Libraries und SSH benötigt, sofern der NRPE mit SSL-
Unterstützung kompiliert wurde und check_by_ssh verwendet wird.
Unter SuSE Linux Enterprise Server 7 sollte jedoch aus Gründen der Performance das ps-
Kommando gemäß Kapitel 7.2.2.2 verwendet werden. Dies gilt insbesondere für zLinux.
Hinweis: Neuere procps-Versionen (z.B. procps Version 3.1.14) arbeiten bedeutend
performanter, da sie nur bei Bedarf auf /proc//statm zugreifen.

- 133 -
7.10 Remote Hosts hinter einer Firewall
Eine Firewall grenzt zwei Netzwerke logisch voneinander ab. Dadurch wird es potenziellen
Angreifern erschwert, von einem Subnet ins Nächste zu gelangen. Es werden für diese Arbeit
2 unterschiedliche Typen von Firewalls definiert,weiche und harte.
• Weiche Firewalls
• Verbindungen aus dem Intranet in die DMZ werden generell erlaubt.
• Wenige, festgelegte Verbindungen aus der DMZ ins Intranet werden (wenn möglich
über Application-Proxies) erlaubt.
• Bestehende Verbindungen werden zugelassen.
• Harte Firewalls
• Wenige, festgelegte Verbindungen aus dem Intranet in die DMZ werden erlaubt.
• Verbindungen aus der DMZ ins Intranet werden nur über Application-Proxies erlaubt.
• Bestehende Verbindungen werden zugelassen.
Das hat zur Folge, dass öffentliche Ressourcen von Nagios über weiche Firewalls hinweg
problemlos überwacht werden können. Private Ressourcen sind mit Hilfe des NRPE und
check_by_ssh abzufragen. Das Tool send_nsca kann nur dann eingesetzt werden, wenn dafür
eine explizite Firewallregel definiert wird.
Firewall-Typ NRPE NSCA check_by_ssh öffentliche Ressourcen
weich X (-) X X
hart - - X -
Restrikivere, harte Firewalls, die eine SSH-Verbindung aus dem Intranet in die DMZ
zulassen, können mit dem check_by_ssh-Plugin überwunden werden. Ist auch dieses nicht
erlaubt, empfiehlt es sich, einen eigenen Nagios-Server in der DMZ aufzubauen, für den
explizite Firewallregeln definiert werden, sodass dieser seine Resultate an einen im Intranet
stehenden Nagios-Server weitergeben kann.

- 134 -
7.11 Performance
Im Gegensatz zu der bestehenden Lösung IBM/Tivoli Systems and Applications Monitoring
ist die Performance kaum davon abhängig, wie viele Events bzw. Fehler innerhalb kurzer Zeit
auftreten, sondern die Last steigt proportional zu den überwachten Services/Minute. Dieses
Kapitel wird die Machbarkeit und Grenzen einer grossflächigen Installation deutlich machen.
Um festzustellen, wie viele remote Hosts in der Praxis mit einem Nagios-Server überwacht
werden können, wird eine identische Installation der 49 zur Verfügung stehenden Hosts
realisiert und mit hohem Check-Intervall abgefragt. Dazu wird auf jedem remote Host ein
NRPE-Daemon und die Plugins check_disk, check_swap sowie check_procs installiert.
Da primär die privaten Ressourcen überwacht werden sollen und der NRPE die beste
Performance liefert, werden 20 verschiedene, auf NRPE basierende, Services pro Host
definiert. Damit ergeben sich insgesamt 980 Service-Checks:
20 Checks * 49 Hosts = 980 Service-Checks gesamt
Bei einem Check-Intervall von einer Minute, werden 980 Service-Checks/Minute ausgeführt,
was den berechneten ~1280 Checks/Minute bereits nahe kommt. Da die Last des Nagios-
Servers proportional zu den Service-Checks/Minute steigt, können theoretische Berechnung
für unterschiedliche IT-Umgebungen anhand der ermittelten Ergebnisse durchgeführt werden.
Nagios bringt selber eine, wenn auch sehr rudimentäre, Performance-Information mit. Im
Webinterface unter dem Menüpunkt Performance Info lässt sich folgende Tabelle finden.
Abbildung 27 Nagios Performance Info
Quelle: Screenshot, Nagios Webinterface

- 135 -
• Die Check Execution Time entspricht der Zeit, welche die letzten Plugins zur Ausführung
benötigten. In diesem Beispiel benötigten die Plugins im Durchschnitt 0,297 Sekunden,
bevor sie ein Ergebnis lieferten.
• Die Zeile Check Latency sagt etwas darüber aus, um wie viele Sekunden sich die
Ausführung der Service-Checks verzögert hat. Steigt dieser Wert erheblich
(Erfahrungswert: Average > 15sec), lässt sich darauf schliessen, dass der Nagios-Server
überlastet ist und die Warteschlage der Service-Checks nicht schnell genug abarbeiten
kann.
• Die Zeile Percent State Change zeigt die Anzahl der Statusänderungen (prozentual). Ein
hoher Wert kann auf Netzwerkprobleme hinweisen.
Es empfiehlt sich, das Performanceverhalten von Nagios ständig zu überwachen, um
Probleme und Fehler schnellstmöglich erkennen zu können.
7.11.1 Systemauslastung bei 980 Checks/Minute
Um aussagekräftige Messwerte zu erhalten, werden die CPU-Load und CPU-Usage per
SNMP in 5 Minuten Abständen abgefragt und über das Tool Cacti 1 grafisch aufbereitet.
Folgende Diagramme zur Auslastung der Sun-Fire-280R ergeben sich bei 980 Checks/Minute:
Abbildung 28 CPU-Usage bei 980 Checks/Minute
Quelle: Screenhost Cacti
Die durchschnittliche Last von 93,86% CPU-Usage macht deutlich, das der Nagios-Server
unter Volllast läuft. Trotz der hohen Auslastung fällt die Verzögerung der Service-Checks aus
Abbildung 27 jedoch gering aus.
1 Cacti ist ein Frontend für das Network Monitoring Tool RRDTool und ist unter
http://www.raxnet.net/products/cacti/ zu finden.

- 136 -
Abbildung 29 CPU Load bei 980 Checks/Minute
Quelle: Screenhost Cacti
Auch die CPU-Load suggeriert eine hohe Last des Nagios-Servers. Durchschnittlich warten
mehr als 5 Prozesse auf Abarbeitung. Dies resultiert jedoch primär daher, das der Nagios
Prozess für jeden Service-Check zuerst sich selbst aufspaltet (fork) und danach das Plugin
aufruft. Bei 980 Checks/Minute sind das somit 1960 Prozesse, welche pro Minute gestartet
werden müssen. Das sind mehr als 30 Prozesse/Sekunde.
Hinweis: Für Nagios Version 3 ist geplant, die Multiprozess-Technik gegen Threads zu
tauschen, was der Performance immens zu gute kommen dürfte. 1
1 Vgl: Ruzicka, Dietmar (2004): Linux-Magazin 03/2004, S. 121

- 137 -
7.11.2 Systemauslastung bei 490 Checks/Minute
Da die Last proportional zu den Checks/Minute steigt, wird eine Halbierung der CPU-
Auslastung bei Halbierung der Checks/Minute erwartet. Diese theoretische Überlegung wird
praktisch überprüft, indem der check_intervall von einer Minute auf zwei erhöht wird.
Abbildung 30 CPU-Usage bei 490 Checks/Minute
Quelle: Screenshot Cacti
Die um 11:45 Uhr eingebrochene Auslastung ist deutlich erkennbar. Der Wert von 45.90%
entspricht etwas weniger als die Hälfte von den vorherigen 93,86% CPU-Usage. Auch die
CPU-Load verhält sich nahezu proportional. Nach Halbierung der Checks/Minute sind aus
den 5.69 Prozessen in der run queue nur noch 2.26 Prozesse geworden. Trotz der Load-
Schwankungen lässt sich auch für die CPU-Load ein direkt proportionales Verhalten
approximieren.
Abbildung 31 CPU-Load bei 490 Checks/Minute
Quelle: Screenshot Cacti

- 138 -
7.11.3 Skalierbarkeit durch Veränderung der Prozessoranzahl
Das die von Nagios produzierte Last proportional zu der Anzahl der Checks/Minute steigt,
wurde in den vorangegangenen Kapiteln deutlich. Wird im Laufe einer produktiven Nagios-
Installation die Anzahl der zu überwachenden Hosts größer, muss eventuell die Server-
Hardware erweitert werden, um die auftretende Last bewältigen zu können. Aufgrund der
nahezu liniearen Skalierbarkeit von Nagios, erhöht sich die Anzahl der Checks/Minute
proportional zur Anzahl der Prozessoren.
Um diese These praktisch zu belegen, wird die Nagios-Konfiguration aus Kapitel 7.11.2
verwendet, jedoch einer der beiden UltraSPARC Prozessoren deaktiviert.
root@tivoli-34 # psradm -f 0
root@tivoli-34 # psrinfo
0 on-line since 05/17/04 11:35:48
1 off-line since 07/08/04 10:53:53
Das Deaktivieren eines Prozessors um 16:00 Uhr lässt sich in der Abbildung 32 deutlich
erkennen. Wie erwartet hat sich die Last auf dem Server verdoppelt.
Abbildung 32 CPU-Load bei 490 Checks/Minute (1 Prozessor)
Quelle: Screenshot Cacti

- 139 -
Auch die CPU-Load verhält sich proportional zur der Anzahl der Prozessoren. Wenn nur noch
die Hälfte der Prozessoren zur Verfügung stehen, müssen die übrig gebliebenen Prozessoren
die doppelte Anzahl der Prozesse bearbeiten.
Abbildung 33 CPU-Load bei 490 Checks/Minute (1 Prozessor)
Quelle: Screenshot Cacti
Die gezeigten Abbildungen belegen die nahezu lineare Skalierbarkeit von Nagios, was den
Umfang der auftretenden Kosten für die Hardware kalkulierbar macht; ein wesentlicher
Vorteil gegenüber einer dezentralen Architektur.

8. Ergebnis
- 140 -
Das Proof of Concept macht deutlich, dass Nagios die gestellten Anforderungen erfüllt und
sich insbesondere in Enterprise-Umgebungen durch hohe Skalierbarkeit und praxisnahe
Features auszeichnet. Die Schwächen in der Unterstützung der Plattformen AIX und HP-UX
werden durch den offenen Quelltext und das hohe Engagement der Entwickler kompensiert.
Für den Einsatz von Nagios bei Volkswagen stellen sich folgende Argumente in den
Vordergrund:
• Erfüllt die gestellten Anforderungen des heterogenen Server-Monitorings
• Kostengünstiges und herstellerunabhängiges Produkt
• Flexibilität und einfache Erweiterbarkeit durch offene Standards und Schnittstellen
• Direkte Ansprechpartner, um in den Entwicklungsprozess der Software einzugreifen
• Schnelle Fehlerkorrektur durch freien Zugriff auf den Quellcode (GPL 1 )
9. Ausblick
Derzeit konzentriert sich die Entwicklung von Nagios auf das kommende Release 2.0. Neben
der Möglichkeit, Services in Gruppen zusammenzufassen, gibt es sehr viele
Detailverbesserungen. Dazu gehören unter anderem die Auswertung von regulären
Ausdrücken 2 in Objektdefinitionen sowie passive Host-Checks, was dem Distributed
Monitoring zugute kommt. Für die Version 3.0 ist es geplant, die Service-Checks unter
einzelnen Threads zu starten, anstatt fork zu nutzen. Des Weiteren denkt Galstad darüber
nach, die Logfiles im XML-Format abzulegen.
1 Die GNU General Public Licenses (GPL) erlaubt legales kopieren, verbreiten und/oder Veränderungen der
Quellen. Einzusehen unter http://www.gnu.org/copyleft/gpl.html
2 Die Linuxfibel (http://www.linuxfibel.de/regex.htm) beschreibt reguläre Audrücke wie folgt: Ein regulärer
Ausdruck ist nichts anderes als ein Suchmuster, um übereinstimmende Muster in einer Eingabe zu finden.

- 141 -
Anhang
eMail-Korrespondenz: Schmitz, Martin, 03.05.2004
Hallo,
nein, dazu gibt es momentan keine Pläne.
Da ich noch nie mit embedded Perl gearbeitet habe, habe ich auch keine
Vorstellung davon, wie lange eine Anpassung dauern würde.
--
Mit freundlichem Gruß
Martin Schmitz
On Monday 03 May 2004 10:14, you wrote:
> Hallo,
> ich evaluiere seit > 2 Monaten Nagios und bin auf Euer Eventlog-Addon
> gestossen. Leider bekomm ich es nicht mit embedded Perl Nagios zum Laufen
> (no output). Ist geplant (oder überhaupt möglich) das Perl-Script
> ePN-kompatibel zu machen?>
> Mit freundlichen Grüssen,
> Sven Schaffranneck
> K-DOI-5/4
> Volkswagen AG
> Brieffach 1883
> 38436 Wolfsburg>
> Telefon: +49 (5361) 9-3 88 58
> http://www.volkswagen.de

- 142 -
eMail-Korrespondenz: Voon, Ton, 30.04.2004
Hi Ton,
> I
> have found a bug in the configure script for ps -el (AIX 4.1
> style) where it
> is expecting the wrong number of columns. Can you try the snapshot at
> http://nagiosplug.sourceforge.net/snapshot when it next
> updates and let me
> know what the configure output is for ps. I am guessing it
> will say ps -ef (AIX 4.1).
Hit. Now it works. Thanks!
One problem anymore, but i'll make a new thread.
Greets Sven

- 143 -
Quellcode: Init-Script /opt/Tivoli/nagios/nrpe/nrpe.sh
#!/bin/sh
LD_LIBRARY_PATH=/opt/Tivoli/nagios/lib
export LD_LIBRARY_PATH
PROG="/opt/Tivoli/nagios/nrpe/nrpe"
CONF="/opt/Tivoli/nagios/nrpe/nrpe.cfg"
OPTION="-d"
case "$1" in
start)
echo "Starting $PROG"
$PROG -c $CONF $OPTION
;;
stop)
PID=`ps -A|awk '($4 == "nrpe")||($4 == "nrpe_ssl"){print $1}'`
if [ ! "$PID" ]; then
echo "no running NRPE Daemon found!"
else
echo "Stopping PID: $PID"
kill $PID
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "try $0 ||";
;;
esac
exit 0

- 144 -
Quellcode: Init-Script /etc/init.d/nsca
#!/bin/sh
LD_LIBRARY_PATH=/global/nagios/local/lib
export LD_LIBRARY_PATH
PROG="/global/nagios/nsca/nsca"
CONF="/global/nagios/nsca/nsca.cfg"
case "$1" in
start)
echo "Starting $PROG"
$PROG -c $CONF $OPTION
;;
stop)
PID=`ps -A|awk '($4 == "nsca"){print $1}'`
if [ ! "$PID" ]; then
echo "no running NSCA Daemon found!"
else
echo "Stopping PID: $PID"
kill $PID
fi
;;
restart)
$0 stop
$0 start
;;
*)
echo "Try $0 start || stop || restart";
;;
esac
exit 0

- 145 -
Quellcode: Init-Script /etc/init.d/nag-apache
# BEGIN
APACHE_HOME=/global/nagios/apache
CONF_FILE=/global/nagios/apache/conf/httpd.conf
PIDFILE=/global/nagios/apache/logs/httpd.pid
if [ ! -f ${CONF_FILE} ]; then
exit 0
fi
case "$1" in
start)
/bin/rm -f ${PIDFILE}
cmdtext="starting"
;;
restart)
cmdtext="restarting"
;;
stop)
cmdtext="stopping"
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
;;
esac
echo "httpd $cmdtext."
status=`${APACHE_HOME}/bin/apachectl $1 2>&1`
if [ $? != 0 ]; then
echo "$status"
exit 1
fi
exit 0
# EOF

- 146 -
Quellcode: check_swap.c für HP-UX-Plattformen
/****************************************************************************
*
* Program: Swap space plugin for Nagios
* License: GPL
*
* License Information:
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* Copyright (c) 2000 Karl DeBisschop
* (kdebisschop@users.sourceforge.net)
*
* $Id: check_swap.c,v 1.24 2003/11/12 05:37:19 kdebisschop Exp $
*
****************************************************************************/
#include "common.h"
#include "popen.h"
#include "utils.h"
const char *progname = "check_swap";
const char *revision = "$Revision: 1.24 $";
const char *copyright = "2000-2003";
const char *email = "nagiosplug-devel@lists.sourceforge.net";
int check_swap (int usp, long unsigned int free_swap);
int process_arguments (int argc, char **argv);
int validate_arguments (void);
void print_usage (void);
void print_help (void);
int warn_percent = 0;
int crit_percent = 0;
long unsigned int warn_size = 0;
long unsigned int crit_size = 0;
int verbose;
int allswaps;
int
main (int argc, char **argv)
{
int percent_used, percent;
long unsigned int total_swap = 0, used_swap = 0, free_swap = 0;
long unsigned int dsktotal, dskused, dskfree;
int result = STATE_OK;
char input_buffer[MAX_INPUT_BUFFER];
char *perf;
#ifdef HAVE_PROC_MEMINFO
FILE *fp;
#else
# ifdef HAVE_SWAP
int conv_factor; /* Convert to MBs */
char *temp_buffer;
char *swap_command;
char *swap_format;
char total_str[32];
# endif
#endif
char str[32];

- 147 -
char *status;
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
status = strdup("");
perf = strdup("");
if (process_arguments (argc, argv) != OK)
usage (_("Invalid command arguments supplied\n"));
#ifdef HAVE_PROC_MEMINFO
fp = fopen (PROC_MEMINFO, "r");
while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, fp)) {
if (sscanf (input_buffer, " %s %lu %lu %lu", str, &dsktotal, &dskused,
&dskfree) == 4 &&
strstr (str, "Swap")) {
dsktotal = dsktotal / 1048576;
dskused = dskused / 1048576;
dskfree = dskfree / 1048576;
total_swap += dsktotal;
used_swap += dskused;
free_swap += dskfree;
if (allswaps) {
percent = 100 * (((double) dskused) / ((double) dsktotal));
result = max_state (result, check_swap (percent, dskfree));
if (verbose)
asprintf (&status, "%s [%lu (%d%%)]", status, dskfree,
100 - percent);
}
}
}
fclose(fp);
#else
# ifdef HAVE_SWAP
asprintf(&swap_command, "%s", SWAP_COMMAND);
asprintf(&swap_format, "%s", SWAP_FORMAT);
conv_factor = SWAP_CONVERSION;
/* These override the command used if a summary (and thus ! allswaps) is\
required. The summary flag returns more accurate information about
swap usage on these OSes */
# ifdef _AIX
if (!allswaps) {
asprintf(&swap_command, "%s", "/usr/sbin/lsps -s");
asprintf(&swap_format, "%s", "%d%*s %d");
conv_factor = 1;
}
# else
# ifdef sun
if (!allswaps) {
asprintf(&swap_command, "%s", "/usr/sbin/swap -s");
asprintf(&swap_format, "%s", "%*s %*dk %*s %*s + %*dk %*s = %dk
%*s %dk %*s");
conv_factor = 2048;
}
# else
# ifdef __hpux
asprintf(&swap_format, "%s", "%s %d %d %d %*d");
conv_factor = 1;
if (allswaps) {
asprintf(&swap_command, "%s", "/usr/sbin/swapinfo -mt");
} else {
asprintf(&swap_command, "%s", "/usr/sbin/swapinfo -mtdf");
}
# endif
# endif
# endif
if (verbose >= 2)
printf (_("Command: %s\n"), swap_command);
if (verbose >= 3)

- 148 -
printf (_("Format: %s\n"), swap_format);
child_process = spopen (swap_command);
if (child_process == NULL) {
printf (_("Could not open pipe: %s\n"), swap_command);
return STATE_UNKNOWN;
}
child_stderr = fdopen (child_stderr_array[fileno (child_process)], "r");
if (child_stderr == NULL)
printf (_("Could not open stderr for %s\n"), swap_command);
sprintf (str, "%s", "");
/* read 1st line */
fgets (input_buffer, MAX_INPUT_BUFFER - 1, child_process);
if (strcmp (swap_format, "") == 0) {
temp_buffer = strtok (input_buffer, " \n");
while (temp_buffer) {
if (strstr (temp_buffer, "blocks"))
sprintf (str, "%s %s", str, "%f");
else if (strstr (temp_buffer, "dskfree"))
sprintf (str, "%s %s", str, "%f");
else
sprintf (str, "%s %s", str, "%*s");
temp_buffer = strtok (NULL, " \n");
}
}
/* If different swap command is used for summary switch, need to read format
differently */
# ifdef _AIX
if (!allswaps) {
fgets(input_buffer, MAX_INPUT_BUFFER - 1, child_process); /* Ignore first
line */
sscanf (input_buffer, swap_format, &total_swap, &used_swap);
free_swap = total_swap * (100 - used_swap) /100;
used_swap = total_swap - free_swap;
if (verbose >= 3)
printf (_("total=%d, used=%d, free=%d\n"), total_swap, used_swap,
free_swap);
} else {
# else
# ifdef sun
if (!allswaps) {
sscanf (input_buffer, swap_format, &used_swap, &free_swap);
used_swap = used_swap / 1024;
free_swap = free_swap / 1024;
total_swap = used_swap + free_swap;
} else {
# else
# ifdef __hpux
fgets(input_buffer, MAX_INPUT_BUFFER - 1, child_process);
sscanf (input_buffer, swap_format, total_str, &total_swap, &used_swap,
&free_swap);
while (strcmp(total_str, "total")) {
fgets(input_buffer, MAX_INPUT_BUFFER - 1, child_process);
sscanf (input_buffer, swap_format, total_str, &total_swap, &used_swap,
&free_swap);
}
total_swap, used_swap, free_swap);
# endif
# endif
# endif
while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, child_process)) {
sscanf (input_buffer, swap_format, &dsktotal, &dskfree);
dsktotal = dsktotal / conv_factor;
/* AIX lists percent used, so this converts to dskfree in MBs */
# ifdef _AIX
dskfree = dsktotal * (100 - dskfree) / 100;
# else
dskfree = dskfree / conv_factor;
# endif

- 149 -
if (verbose >= 3)
printf (_("total=%d, free=%d\n"), dsktotal, dskfree);
dskused = dsktotal - dskfree;
total_swap += dsktotal;
used_swap += dskused;
free_swap += dskfree;
if (allswaps) {
percent = 100 * (((double) dskused) / ((double) dsktotal));
result = max_state (result, check_swap (percent, dskfree));
if (verbose)
asprintf (&status, "%s [%lu (%d%%)]", status, dskfree, 100 - percent);
}
}
# ifdef _AIX
}
# else
# ifdef sun
}
# endif
# endif
/* If we get anything on STDERR, at least set warning */
while (fgets (input_buffer, MAX_INPUT_BUFFER - 1, child_stderr))
result = max_state (result, STATE_WARNING);
/* close stderr */
(void) fclose (child_stderr);
/* close the pipe */
if (spclose (child_process))
result = max_state (result, STATE_WARNING);
# endif /* HAVE_SWAP */
#endif /* HAVE_PROC_MEMINFO */
}
percent_used = 100 * ((double) used_swap) / ((double) total_swap);
result = max_state (result, check_swap (percent_used, free_swap));
asprintf (&status, _(" %d%% free (%lu MB out of %lu MB)%s"),
(100 - percent_used), free_swap, total_swap, status);
asprintf (&perf, "%s", perfdata ("swap", (long) free_swap, "MB",
TRUE, (long) max (warn_size/1024, warn_percent/100.0*total_swap),
TRUE, (long) max (crit_size/1024, crit_percent/100.0*total_swap),
TRUE, 0,
TRUE, (long) total_swap));
printf ("SWAP %s:%s |%s\n", state_text (result), status, perf);
return result;
int
check_swap (int usp, long unsigned int free_swap)
{
int result = STATE_UNKNOWN;
free_swap = free_swap * 1024; /* Convert back to bytes as warn and crit
specified in bytes */
if (usp >= 0 && crit_percent != 0 && usp >= (100.0 - crit_percent))
result = STATE_CRITICAL;
else if (crit_size > 0 && free_swap = 0 && warn_percent != 0 && usp >= (100.0 - warn_percent))
result = STATE_WARNING;
else if (warn_size > 0 && free_swap = 0.0)
result = STATE_OK;
return result;
}
/* process command-line arguments */
int
process_arguments (int argc, char **argv)
{

- 150 -
int c = 0; /* option character */
int option = 0;
static struct option longopts[] = {
{"warning", required_argument, 0, 'w'},
{"critical", required_argument, 0, 'c'},
{"allswaps", no_argument, 0, 'a'},
{"verbose", no_argument, 0, 'v'},
{"version", no_argument, 0, 'V'},
{"help", no_argument, 0, 'h'},
{0, 0, 0, 0}
};
if (argc < 2)
return ERROR;
while (1) {
c = getopt_long (argc, argv, "+?Vvhac:w:", longopts, &option);
if (c == -1 || c == EOF)
break;
switch (c) {
case 'w': /* warning size threshold */
if (is_intnonneg (optarg)) {
warn_size = atoi (optarg);
break;
}
else if (strstr (optarg, ",") && strstr (optarg, "%") &&
sscanf (optarg, "%lu,%d%%", &warn_size, &warn_percent) == 2)
{ break; }
else if (strstr (optarg, "%") &&
sscanf (optarg, "%d%%", &warn_percent) == 1) {
break; }
else {
usage (_("Warning threshold must be integer or percentage!\n"));
}
case 'c': /* critical size threshold */
if (is_intnonneg (optarg)) {
crit_size = atoi (optarg);
break;
}
else if (strstr (optarg, ",") && strstr (optarg, "%") &&
sscanf (optarg, "%lu,%d%%", &crit_size, &crit_percent) == 2)
{ break; }
else if (strstr (optarg, "%") &&
sscanf (optarg, "%d%%", &crit_percent) == 1)
{ break; }
else {
usage (_("Critical threshold must be integer or percentage!\n"));
}
case 'a': /* all swap */
allswaps = TRUE;
break;
case 'v': /* verbose */
verbose++;
break;
case 'V': /* version */
print_revision (progname, revision);
exit (STATE_OK);
case 'h': /* help */
print_help ();
exit (STATE_OK);
case '?': /* help */
usage (_("Invalid argument\n"));
}
}
c = optind;
if (c == argc)
return validate_arguments ();
if (warn_percent == 0 && is_intnonneg (argv[c]))
warn_percent = atoi (argv[c++]);
if (c == argc)

- 151 -
return validate_arguments ();
if (crit_percent == 0 && is_intnonneg (argv[c]))
crit_percent = atoi (argv[c++]);
if (c == argc)
return validate_arguments ();
if (warn_size == 0 && is_intnonneg (argv[c]))
warn_size = atoi (argv[c++]);
if (c == argc)
return validate_arguments ();
if (crit_size == 0 && is_intnonneg (argv[c]))
crit_size = atoi (argv[c++]);
}
return validate_arguments ();
int
validate_arguments (void)
{
if (warn_percent == 0 && crit_percent == 0 && warn_size == 0
&& crit_size == 0) {
return ERROR;
}
else if (warn_percent < crit_percent) {
usage
(_("Warning percentage should be more than critical percentage\n"));
}
else if (warn_size < crit_size) {
usage
(_("Warning free space should be more than critical free space\n"));
}
return OK;
}

- 152 -
void
print_help (void)
{
print_revision (progname, revision);
printf (_(COPYRIGHT), copyright, email);
printf (_("Check swap space on local server.\n\n"));
print_usage ();
printf (_(UT_HELP_VRSN));
printf (_("\n\
-w, --warning=INTEGER\n\
Exit with WARNING status if less than INTEGER bytes of swap space are
free\n\
-w, --warning=PERCENT%%\n\
Exit with WARNING status if less than PERCENT of swap space has been
used\n\
-c, --critical=INTEGER\n\
Exit with CRITICAL status if less than INTEGER bytes of swap space
are free\n\
-c, --critical=PERCENT%%\n\
Exit with CRITCAL status if less than PERCENT of swap space has been
used\n\
-a, --allswaps\n\
Conduct comparisons for all swap partitions, one by one\n"));
printf (_("\n\
On Solaris, if -a specified, uses swap -l, otherwise uses swap -s.\n\
Will be discrepencies because swap -s counts allocated swap and
includes\n\ real memory\n"));
printf (_("\n\
On AIX, if -a is specified, uses lsps -a, otherwise uses lsps -s.\n"));
printf (_(UT_SUPPORT));
}
void
print_usage (void)
{
printf (_("Usage:\n\
%s [-a] -w %% -c %%\n\
%s [-a] -w -c \n\
%s (-h | --help) for detailed help\n\
%s (-V | --version) for version information\n"),
progname, progname, progname, progname);
}

- 153 -
Quellcode: ps.pl für zLinux (S/390) Plattformen
#!/usr/bin/perl
#############################################################################
# ps Kommando Ersatz fuer Nagios auf zOS #
#############################################################################
# Sven Schaffranneck (sven.schaffranneck@volkswagen.de) #
# Release 2004.06.10 #
#############################################################################
# Todo: #
# ----- #
# - Prozentuale CPU-Auslastung pro Prozess berechnen. Derzeit wird nur #
# Dummy-Wert von 99.9% ausgegeben #
#############################################################################
# Intention: #
# ---------- #
# Das ps-Kommando auf SuSE SLES7 (zLinux) greift bei jedem Aufruf auf #
# /proc/pid/statm zu, was eine hohe Systemlast erzeugt. #
# Dieses Verhalten ist bei einer Umgebung mit shared-Ressourcen #
# problematisch und soll umgangen werden. #
# Nachzubauendes Kommando: #
# /bin/ps -weo 'stat uid ppid vsz rss pcpu comm args' #
#############################################################################
#STAT UID PPID VSZ RSS %CPU COMMAND COMMAND
format STDOUT=@

- 154 -
@uidhash{$i}=@tmp[2];
} else {
if ($line =~ /^PPid:/ ) {
@tmp=split(/ +/, $line );
@ppidhash{$i}=@tmp[1];
} else {
if ($line =~ /^VmSize:/ ) {
@tmp=split(/ +/, $line );
@vszhash{$i}=@tmp[1];
} else {
if ($line =~ /^VmRSS:/ ) {
@tmp=split(/ +/, $line );
@rsshash{$i}=@tmp[1];
} else {
if ($line =~ /^Name:/ ) {
@tmp=split(/ +/, $line );
@namehash{$i}=@tmp[1];
};
};
};
};
};
};
};
close(STATUS);
# Auslesen der langen Commandline mit Argumenten
if ( open(CMDLINE, "

- 155 -
}
if ( @rsshash{$i} == "" ) {
@rsshash{$i} = 0;
}
# Pid ist zwischendurch gestorben, in @alivepidhash merken.
} else {
if ($debug) { printf "Pid: $i existiert nicht mehr\n" };
@alivepidhash{$i}=0;
};
};
# Ausgabe wie /bin/ps -weo 'stat uid ppid vsz rss pcpu comm args'
# todo: (sortierung ist anders, nach was sortiert ps??)
print "STAT UID PPID VSZ RSS %CPU COMMAND
COMMAND\n";
foreach $pid (@pids) {
if ( @alivepidhash{$pid} ) {
write;
}
}

- 156 -
Literaturverzeichnis
• Galstad, Ethan (2002): Sample NSCA Client Config File, [On-line], Available:
http://cvs.sourceforge.net/viewcvs.py/nagios/nsca/send_nsca.cfg,
Abfragedatum: 26.05.2004
• Galstad, Ethan (2002), Sample NSCA Daemon Config File, [On-line], Available:
http://cvs.sourceforge.net/viewcvs.py/nagios/nsca/nsca.cfg,
Abfragedatum: 25.05.2004
• Galstad Ethan (2003): Nagios Documentation Version 1.0, [On-line], Available:
http://nagios.sourceforge.net/docs/1_0/distributed.html, Abfragedatum: 07.06.2004
• Galstad Ethan (2004): Upcoming Version Information, [On-line], Available:
http://www.nagios.org/upcoming.php, Abfragedatum: 02.07.2004
• iETSolutions GmbH (2003): ITIL - De-Facto-Standard für Service Management,
München, S. 2-6
• Inverso, John (2003): IBM Corporation Tivoli Systems Management Software,
Gartner Research
• MASTERS Consulting GmbH (2004): Schulung ITIL Foundation, Release 3.04,
Hamburg, S. 4ff
• Mailingliste nagios-users, Message-ID: 8138879, 28.04.2004, [On-line], Available:
https://sourceforge.net/mailarchive/message.php?msg_id=8138879,
Abfragedatum: 08.07.2004
• Mailingliste nagios-users, Message-ID: 8138913, 29.04.2004, [On-line], Available:
https://sourceforge.net/mailarchive/message.php?msg_id=8138913,
Abfragedatum: 08.07.2004
• Mailingliste nagios-users: Message-ID 8138925, 29.04.2004, [On-line], Available:
https://sourceforge.net/mailarchive/message.php?msg_id=8138925,
Abfragedatum: 25.06.2004
• Mailingliste nagios-users, Message-ID: 8138988, 30.04.2004, [On-line], Available:
https://sourceforge.net/mailarchive/message.php?msg_id=8138988,
Abfragedatum: 08.07.2004
• Meister, Stefan (2001): Großflächiger Einsatz von Linux in einem Unternehmen,
FH-Wolfenbüttel

- 157 -
• Nagios Plugin Development Team (2003): check_by_ssh detailed help, [On-line],
Available:
http://cvs.sourceforge.net/viewcvs.py/nagiosplug/nagiosplug/plugins/check_by_ssh.c,
Abfragedatum: 27.05.2004
• Nagios Plugins Development Team (2004): Nagios plug-in development guidlines,
[On-line], Available: http://nagiosplug.sourceforge.net/developer-guidelines.html,
Abfragedatum: 17.05.2004
• Nagios Plugin Requirements, rev. 1.5, [On-line], Available
http://cvs.sourceforge.net/viewcvs.py/nagiosplug/nagiosplug/REQUIREMENTS,
Abfragedatum: 08.07.2004
• Office of Government Commerce (2000): ITIL Service Support CD-ROM Version 1.3,
Norwegen
• Pollmeier, Dirk (2003): Ihr IT-Powershop, PowerPoint Präsentation, 28.10.2003
• Ruzicka, Dietmar (2004): Netzwerk-Monitoring mit Nagios, dem Nachfolger von Netsaint,
in: Linux-Magazin 03/2004, S. 121
• Schaffranneck, Sven (2004): Studienarbeit zum Thema „Analyse ausgewählter Event-
Management-Tools auf Basis der Anforderungen der Volkswagen AG unter
Berücksichtigung von OpenSource“, Fachhochschule Braunschweig/Wolfenbüttel
• Schmitz, Martin (2004): eMail-Korrespondenz Schmitz, Martin, 03.05.2004,
siehe Seite 141
• Twele, Horst (2000): Partielle Sicherung und Wiederherstellung der Tivoli proprietären
Objektorientierten Datenbank mit Hilfe einer Java Applikation, Fachhochschule
Braunschweig/Wolfenbüttel
• Voon, Ton (2004): eMail-Korrespondenz Voon, Ton, 30.04.2004, siehe Seite 142

- 158 -
Verzeichniss der relevanten Internet Links
• http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,4682,
00.html
Link zum GNU GCC für HP-UX 11.11 PA-RISC.
• http://httpd.apache.org
Webseite des OpenSource Webservers Apache.
• http://mcrypt.hellug.gr
Bezugsquelle für die mcrypt-Library.
• http://nagiosplug.sourceforge.net
Projektseite der Nagios-Plugins auf sourceforge.net.
Hinweis: Unter http://nagiosplug.sourceforge.net/snapshot ist der tagesaktuelle CVS-
Snapshot zu finden.
• http://naplax.sourceforge.net/check_logsurfer.html
Webseite der Nagios Plugins and Extensions auf sourceforge.net. Sammlung von
zusätzlichen Plugins für Nagios.
• http://sourceforge.net/projects/nrpe
Webseite des NRPE auf sourceforge.net.
• http://sunsolve.sun.com/pub-cgi/retrieve.pl?type=0&doc=fpatches%
2F112438&display=plain
Link zum SunOS Patch 112438, um /dev/random und /dev/urandom bereit zu stellen.
• http://support.tsmgsoftware.com
Forum der NSClient- und NRPE_NT-Entwicklerteams. Neben Support werden hier auch
die neuesten Versionen zur Verfügung gestellt.
• http://www.gnu.org/copyleft/gpl.html
Inhalt der GNU General Public Licence im HTML-Format.
• http://www.gnu.org/software/flex/flex.html
Webseite des GNU-Tools flex.
• http://www.gnu.org/software/make
Webseite des GNU-Tools make.
• http://www.linuxfibel.de/regex.htm
Die Linuxfibel bietet Beschreibungen und Hilfestellungen rund um Linux.

- 159 -
• http://www.nagios.org
Webseite des Server-Monitoring-Tools Nagios von Ethan Galstad.
• http://www.nagios.org/download/extras.php
Sammlung einiger Zusatztools für Nagios wie NRPE. NSCA und NSClient.
• http://www.openssh.org
OpenSSH ist eine freie Implementierung der SSH Protokollsammlung und ist für viele
Plattformen verfügbar.
• http://www.openssl.org
Webseite der OpenSource-Implementierung des SSL-Protokolls.
• http://www.raxnet.net/products/cacti
Webseite von Cacti (Frontend für das Network Monitoring Tool RRDTool).
• http://www.saintcorporation.com/
Webseite von dem kommerziellen Security-Scanner SAINT.
• http://www.sunfreeware.com
Kostenlose OpenSource Softwaresammlung für Sun Solaris.
• http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html
Sammlung von GNU-Tools für das IBM Betriebssystem AIX.

Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne
unerlaubte fremde Hilfe angefertigt habe, andere als die angegebenen Quellen nicht benutzt
und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche
kenntlich gemacht habe.
Wolfsburg, im August 2004
______________________________
Sven Schaffranneck