LinuxTechnicalReview02 Monitoring

Feature
Vergleich
Welches Tool eignet sich fr welchen Zweck besonders gut? Was ist die Schokoladenseite, was
der Pferdefu? Die Redaktion hat die wichtigsten
Features der bekanntesten berwachungstools fr
kleine und mittlere Umgebungen auf den folgenden
Seiten gegenbergestellt.
www.linuxtechnicalreview.de
bersichten
Tabelle 1: Featurevergleich

Opensmart
Nagios
Version
Homepage
untersttzte Plattformen
(Server)
Entwickler
Preis
1.0
opensmart.sourceforge.net
Linux, HP/UX, Solaris, *BSD,
AIX, Windows
4
-
2.7
1.0.2
v. 3.2
www.nagios.org
www.bigsister.ch/bigsister.htm www,bb4.com
All POSIX (Unix, Linux, betriebssystemunabhnig
viele Unixe - Windows XP/
BSD)
2000/2003/Vista
2 + 11 fr Plugins
14
2
-
- $ 100 pro monitored
Node
Big Sister
Big Brother
Architektur
Frontend
Browser-GUI
zentrale Agent-Konfiguration mglich
zentrale Agent-Updates
mglich
Browser-GUI
nein
nein
Browser-GUI
nein
nein
Browser-GUI
nein (geplant)
nein (geplant)
Statuschecks
Fllungsgrad Filesysteme
ja (disk)

Lnge Mailqueue
ja Sendmail (mailq)
Memory Usage
nein
ja (check_disk,
check_disk_smb)
ja (check_)
nein
ja (diskfree)
ja
ja Qmail (qmqueue)
optional
ja (memory) nativ unter Windows, optional unter Unix
Swap benutzt
ja (swap)
ja
ja (load)
nativ unter Windows, op-

tional unter Unix
Performancedaten
Auslastung Platten-IO
CPU Idle Time
Load Average
nein
nein
ja (load)
nein
ja
ja
ja (diskload)
ja (load)
ja (cpuload)
ja
ja
ja
Funktionschecks
Erreichbarkeit (Ping)
ja (ping)
Port offen
ja (sockets)
Prozess luft
ja (proc)
Returncode beliebiger Befehl ja (simple)
Webapp-Check (URL-Abruf) ja (webapp)
ja (check_ping)
ja (check_sockets)
ja (check_procs)
-
ja (check_httpd)
ja (ping)
ja
ja (tcp)
ja
ja (procs)
ja
ja (command)
ja
ja (http, realhttp) nativ unter Windows, optional unter Unix
Standard-Services
DHCP
DNS
FTP
NTP
POP3
RPC
SMTP
SSH
nein
ja (dns)
ja (ftp)
ja (ntp, ntp-remote)
nein
nein
ja (smtp)
nein
ja
ja
ja (check_dns)
ja (check_ntp)
ja
nein
ja (check_smtp)
ja
ja
ja
ja
ja (ntp)
ja (tcp)
ja (rpc)
ja (tcp)
ja (tcp)
optional
ja
ja
ja
ja
optional
ja
ja
SNMP
SNMP-Support
SNMP-Traps
nein
nein
ja (check_snmp)
ja
ja
ja
nein
ja
Log-Checks
Regulrer Ausdruck
ja (logs)
ja (check_log2)
Windows Event Log
ja (eventlog)
ja (syslog) nativ unter Unix, optional

unter Windows
ja (eventlog)
ja
Konfigurationsoptionen
eigene User-/Rechte-
verwaltung
Gruppieren von Hosts
Gruppieren von Services
Abhngigkeiten zw.
Services
Wartungsfenster
nein
ja
nein
N/A
nein
nein
-
ja
ja
ja
ja
ja
ja
ja
ja
optional
ja
ja
ja
ja
bersichten
Tabelle 1: Featurevergleich Fortsetzung

Zenoss
Zabbix
Open NMS
Version
v. 1.1
v. 1.1.5
v. 1.2.9
Homepage sourceforge.net/projects/ sourceforge.net/
www.opennms.org
zenoss
projects/zabbix
untersttzte Plattformen (Server) All BSD Platforms, All POSIX -
AIX, FreeBSD, OpenBSD,
Linux, Solaris, OS X

Linux, Mac OS X, Solaris
HP-UX, Linux, MacOS, Solaris,

SCO Open Server, Tru64/OSF

Entwickler
10
4
32
Preis
-
-
-
Architektur
Frontend
Browser-GUI (Python, AJAX)
Browser-GUI
eigenes, (event management daemon)

zentrale Agent-Konfiguration
-
nein
nein, fr Version 1.3.2 geplant

zentrale Agent-Updates
-
nein

Statuschecks
Fllungsgrad Filesysteme
ja
ja
optional (ber SNMP-Agent)
Lnge Mailqueue
N/A
ja
Memory Usage
ja
ja
Swap benutzt
ja
ja
Performancedaten
Auslastung Platten-IO
ja
ja
CPU Idle Time
ja
ja
Load Average
ja
ja
Funktionschecks
Erreichbarkeit (Ping)
ja
Port offen
ja
Prozess luft
ja
Returncode beliebiger Befehl
ja

Webapp-Check (URL-Abruf)
ja
ja
ja (nur TCP)
ja
optional (Nach-
arbeit erforderlich)
ja
ja
ja
ja
ja
Standard-Services
DHCP
DNS
FTP
NTP
POP3
RPC
SMTP
SSH
N/A
ja
ja
ja
ja
N/A
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
ja
ja
ja
ja
nein
ja
ja
SNMP
SNMP-Support
SNMP-Traps
ja
ja
ja
ja
ja
ja
Log-Checks
Regulrer Ausdruck
Windows Event Log
ja
ja
ja
ja
ja
nein
Konfigurationsoptionen
eigene User-/Rechteverwaltung
Gruppieren von Hosts
Gruppieren von Services
Abhngigkeiten zw. Services
Wartungsfenster konfigurierbar
Netzwerk-Visualisierung
N/A
ja
ja
N/A
N/A
N/A
ja
ja
ja
ja
N/A
ja
ja
ja
ja
ja
ja
bersichten
Pandora FMS
moodss
Bartlby
GPM
SisIYA
NINO
v.1.2.0
v. 21.5
v. 1.2.7
4 (Beta)
0.4-23
v. 4.1.8
sourceforge.net/
moodss.sourceforge.net www.bartlby.org gpm-system.
sisiya.sourceforge. sourceforge.net/
projects/pandora
sourceforge.net
net
projects/nino
Plattformunabhngig Unix/Linux
betriebssystemunabAll BSD Platforms, All
All POSIX, OS X
Linux
POSIX, Linux, Solaris,
(Java-basiert, getestet
hngig
Win2K, WinXP, Win2003,
unter Windows, Linux)
HP-UX, IBM AIX
7
1
1
3
1
1
-
-
-
-
-
-
Browser-GUI (PHP)
eigenes
Browser-GUI (PHP)

N/A
ja (via HTTP/s

und Cron)

N/A
ja (via HTTP/s

und Cron)
1. Java-basierte
GUI, 2. Web-GUI
ja
Browser-GUI (PHP)
Browser-GUI
nein
ja
nein
ja
ja
ja
ja
ja
ja
nein
ja (Exim4)
nein
N/A
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja

ja
ja
nein
ja
N/A
ja
ja
nein
ja
ja
ja
ja
ja
ja
ja
ja
optional
ja
ja
ja
ja
ja

ja
ja
ja
ja
ja
nen
nein
nein
ja
ja
ja
ja
nein
nein
nein
nein
ja
ja
ja
N/A
ja
nein
ja
ja
ja
nein
ja
nein
N/A
ja

ja
ja
ja
ja
ja
ja
ja
ja
optional
optional
optional
optional
optional
optional
optional
optional
nein
ja
ja
nein
ja
nein
ja
ja
nein
nein
nein
nein
nein
nein
nein
nein
N/A
N/A
ja
ja
ja
N/A
ja
ja
nein
ja
ja
nein
ja
nein
ja
ja
ja
ja
ja
ja
ja
nein
nein
nein
N/A
N/A
ja
ja

nein
ja
ja
nein
nein
nein
nein
nein
ja
N/A
optional (ber SNMP)

optional (ber WMI)

ja
ja
nein, geplant fr v. 1.3
nein
optional
ja
optional
ja
optional
nein
optional
nein
N/A
ja
nein
nein
nein
nein
nein
nein
nein
N/A
ja
N/A
nein
N/A
N/A
ja
ja
ja
nein
N/A
ja
Monitoring
als Managementbaustein
An welchen Zielen soll man sich bei der Konzeption
einer Monitoring-Lsung orientieren? Die IT Infrastructure Library kann hier mit praxiserprobten Vorgaben weiterhelfen. Wilhelm Dolle
Studien
Die bestndig wachsende Zahl von Servern und

Diensten in Unternehmen schraubt auch die
Ansprche an ein zentralisiertes Management
oder zumindest Monitoring in die Hhe. In groen, komplexen und heterogenen Rechnerlandschaften setzt man in den allermeisten Fllen
noch Lsungen von kommerziellen Anbietern
ein. Fr solche Schwergewichte im Markt wie
beispielsweise HP Openview, BMC Patrol oder
IBM Tivoli sprechen auch tatschlich eine ganze
Reihe von Grnden, wie der folgende Artikel
diskutieren wird.
Allerdings gelten diese Argumente nicht in jedem Fall. Deshalb greifen zumindest kleine und
auch mittelstndische Anwender zunehmend
zu quelloffenen Lsungen, in den meisten Fllen sowohl aus Kostengrnden als auch aus
der Erkenntnis heraus, dass man den kompletten Funktionsumfang einer groen Lsung gar
nicht immer bentigt.
Doch auch im Open-Source-Bereich ist die
Auswahl inzwischen gro, und es stellt sich die
Frage, nach welchen Kriterien man eine passende
Software auswhlen kann. Der erste Schritt liegt
vielleicht in der Antwort auf die Frage, was man
warum beobachten will. Daraus ergeben sich die
bentigten Funktionen. Fr eine entsprechende
Analyse gibt es verschiedene Verfahren, eines,
das sich an der IT Infrastructure Library ITIL
orientiert, stellt dieser Beitrag vor.
IT Infrastructure Library
Die wachsende Abhngigkeit von Informationssystemen fhrte Ende der 80er Jahre zur Konzeption und Entwicklung der IT Infrastructure
Library (ITIL). Urheber war die Central Computer and Telecommunications Agency (CCTA),
eine IT-Dienstleistungsorganisation der britischen Regierung. Ziel des Projektes war es, die
Kosten von IT-Dienstleistungen zu verringern
und gleichzeitig deren Qualitt zu steigern. Beim
Start des Projekts gab es noch keine umfassende
Grundlage, die den Weg zu wirtschaftlichen und
zweckmigen IT-Dienstleistungen gewiesen
htte. Inzwischen sind die anerkannten Verfahrensweisen des IT-Servicemanagement in ITIL
dokumentiert.
ITIL versucht dabei keine Standardisierung,
sondern verfolgt einen sogenannten BestPractice-Ansatz. Der beinhaltet in der Praxis
erfolgreiche Modelle und Organisationsformen,
die jedes Unternehmen adaptieren und auf seine
Bedrfnisse zuschneiden kann. ITIL beschreibt
auerdem nicht, wie etwas zu erledigen ist, sondern nur, was zu tun ist. Zu ITIL gehrt die ISONorm 20000, die aus einem britischen Standard
(BS 15000) entstand. ITIL ist bis heute die einzige umfassende, nicht-proprietre und ffentlich zugngliche Verfahrensbibliothek in diesem
Bereich. Ihre Verfasser hatten vor allem Anwender im Blick, die fr die Planung, berwachung
und Steuerung von IT-Services verantwortlich
sind.
Die erste Version der Library kam 1995 heraus,
zwischen 1999 und 2003 erschienen die Publikationen der Version 2, und aktuell arbeitet man
an der Version 3, deren Verffentlichung in diesem Jahr ansteht. Zustzliche Informationen
und weiterfhrende Links ber ITIL findet man
unter anderem auf den Webseiten des deutschen
Ablegers des Information Technology Service
Management Forum (itSMF, [1]).
ITIL und Monitoring

ITIL gliedert die Prozesse des IT-Service-Managements grob in zwei Bereiche: Service-Delivery und Service-Support. Service-Delivery beschreibt die Prozesse zur Planung und Lieferung
der IT-Services, die ein Unternehmen bentigt.
Zustzlich wird definiert, wie die erforderlichen
Voraussetzungen und Manahmen fr die Erbringung dieser Services aussehen.
Service-Delivery ist wiederum in fnf thematische Blcke unterteilt: Service-Level-Management (qualitative und quantitative Steuerung der
IT, Service-Level-Agreements, SLAs), FinanceManagement fr IT-Services (Verwaltung und
Steuerung der IT-Kosten), Capacity-Management (Planung der IT-Ressourcen fr qualitativ und quantitativ ausreichende Performance),
Availability-Management (gewhrleistet die
vereinbarte Verfgbarkeit von IT-Services) und
Continuity-Management fr IT-Services (Erstellung, Pflege und Verifikation eines Notfallplanes).
Service-Support beschreibt sowohl die Prozesse zur Untersttzung und zum Betrieb der
IT-Services als auch den Zugang der Anwender
und Kunden zum richtigen IT-Service. Wie Service-Delivery ist auch Service-Support in Blcke
unterteilt: die Funktion Service-Desk (erster
Ansprechpartner fr Anwender), Incident-Management (Bearbeitung von IT-relevanten Anfragen und Strungen), Problem-Management
(Ergrnden der Ursachen von Strungen in
der IT-Infrastruktur), Configuration-Manage-
Studien
ment (Statusberwachung der IT-Infrastruktur; Sammeln, Verwalten und Bereitstellen von

Dokumentationen ber die IT-Infrastruktur),
Change-Management (Steuerung, Planung und
kontrollierte Durchfhrung von nderungen)
und Release-Management (Rollout-Planung,
Integration, Tests und Archivierung von Hardund Software-Installationen).
Zustzlich gibt es innerhalb von ITIL noch das
IT-Security-Management. Dieses beschftigt
sich vor allem mit der Einfhrung und Durchsetzung eines definierten Sicherheitsniveaus fr
die IT-Umgebung. Dabei wird detailliert auf die
primren Sicherheitsziele Vertraulichkeit, Integritt und Verfgbarkeit eingegangen. Durch
eine Risikoanalyse ermittelt man dabei die kundenspezifischen Anforderungen an die Sicherheit. Der interne, minimale Sicherheitsanspruch
wird dabei als IT-Grundschutz bezeichnet. Als
Grundlage fr ein IT-Security-Management
lsst sich die Norm ISO 27001 beziehungsweise
das IT-Grundschutzhandbuch des Bundesamtes
fr Sicherheit in der Informationstechnik (BSI)
heranziehen [2]. Darber hinausgehende Ansprche sind individuell zu bearbeiten.
Bezogen auf ITIL, ist Monitoring insbesondere
fr die folgenden Disziplinen wichtig:
nCapacity-Management
nService-Level-Management
nAvailability-Management
nProblem-Management
nIT-Security-Management
Da die einzelnen Bereiche zum Teil unterschiedliche Ziele verfolgen, ist die Wahl des geeigneten
Monitoring-Werkzeugs beziehungsweise der
passenden Klasse von Werkzeugen sehr wichtig.
Capacity-Management
Das Capacity-Management hat die Aufgabe,
stndig die korrekte Kapazitt an IT-Ressourcen
zu vertretbaren Kosten und entsprechend den
Kundenbedrfnissen zur Verfgung zu stellen.
Diese Bedrfnisse sind blicherweise in SLAs
festgehalten. Das Monitoring sollte also in diesem Fall die Auslastung verschiedener Komponenten der Infrastruktur widerspiegeln und
dabei nicht nur eine Momentaufnahme liefern,
sondern eine Trendanalyse erlauben.
Beispiele fr die zu berwachenden Komponenten sind die CPU-Kapazitt, Speicherplatz
auf Storage-Systemen, Netzwerkbandbreite oder
auch die Zahl der verfgbaren und verwendeten Lizenzen. Das Capacity-Management nutzt
insbesondere die Trendanalysen, um Engpssen

und Ausfllen durch rechtzeitiges Aufstocken
von Ressourcen vorzubeugen. (Daneben lassen
sich Performance und Ressourcenverbrauch
auch durch Simulation schtzen, wie ein weiterer Beitrag dieser Ausgabe demonstriert.)
Ein Beispiel ist die Darstellung von CPU-, Speicher- und Bandbreitenauslastung eines E-MailAnbieters im letzten halben Jahr. Aus dieser
Darstellung kann man dann extrapolieren,
wann man sinnvollerweise seine Kapazitten
erweitern sollte. Typische Open-Source-Tools
fr diese Art von Monitoring sind der Klassiker MRTG [3] oder Cacti [4], auf das ein weiterer Beitrag dieser Ausgabe ausfhrlich eingeht.
Beide Werkzeuge gehren zu den verbreitetsten
grafischen Monitoring-Tools und sind leicht an
die Bedrfnisse des Capacity-Managements anzupassen.
Service-Level-Management
Zielsetzung des Service-Level-Managements ist
die Pflege und stndige Verbesserung der mit
dem Kunden vereinbarten IT-Services. Zu diesem Zweck trifft das Service-Level-Management
Vereinbarungen hinsichtlich der zu erbringenden Leistungen in SLAs, die es berwacht und
dokumentiert. Typische Leistungszusagen betreffen beispielsweise eine bestimmte Verfgbarkeit oder eine definierte Antwortzeit eines
Services.
Availability-Management
Zielsetzung des Availability-Managements ist es,
kostengnstig ein bestimmtes Verfgbarkeitsniveau fr alle IT-Services zu gewhrleisten. Das
Availability-Management stellt eine wichtige
Komponente dar, um die vom Service-LevelManagement ausgehandelten SLAs einzuhalten. In den SLAs knnen allerdings neben Anforderungen an die Verfgbarkeit auch nahezu
beliebige weitere Eigenschaften eines Services
festgelegt sein, unter anderem beispielsweise
Qualittskriterien.
Fr die Verfgbarkeit wird meist ein Schwellwert festgelegt der nicht ber- beziehungsweise
unterschritten werden darf. Fr das Monitoring
erstellt man zustzlich weitere darber beziehungsweise darunterliegende Warnschwellen,
die darauf hinweisen, dass eine Verletzung der
zugesicherten Service-Level droht. Im diesem
Teilbereich des Monitoring stellt vor allem Nagios [5], mit dem sich zahlreiche Beitrge die-
Studien
ser Ausgabe beschftigen, eine sehr ausgereifte

und verbreitete Lsung dar, die mit den meisten
kommerziellen Anbietern mithalten kann und
sich bereits in vielen Unternehmen im professionellen Einsatz bewhrt.
Nagios ist ein leistungsfhiges Werkzeug zur
berwachung von komplexeren IT-Strukturen.
Es lassen sich sowohl Dienste als auch Infrastrukturkomponenten sehr einfach beobachten. Da Nagios ein Plugin-Konzept verfolgt, ist
es sehr einfach um selbstgeschriebene Komponenten zu erweitern. Eine aktive Community
nutzt diesen Vorteil auch ausgiebig aus, sodass
im Laufe der Zeit Nagios-Plugins fr sehr viele
Einsatzflle entstanden sind.
Auerdem bietet Nagios eine Eskalationsstrategie, die es erlaubt, statusabhngig bestimmte
Aktionen auszulsen, also beispielsweise den
Service-Level- oder Availability-Manager auf
die bevorstehende Verletzung des SLA hinzuweisen, unter Umstnden bevor der Anwender
etwas mitbekommt.
einbarten Zeitraums gewhrleisten. Nach den

englischen Begriffen nennt man diese Hauptziele auch CIA-Triade.
Von diesen Primrzielen leiten sich blicherweise noch sekundre Ziele wie Nichtabstreitbarkeit oder Anonymitt ab. Das IT-SecurityManagement soll einerseits die Schaffung eines
gewissen Grundschutzniveaus erlauben, andererseits soll es die Einhaltung der Sicherheitsanforderungen gewhrleisten. Auerdem sind
weitere externe Anforderungen wie regulatorische oder gesetzliche Regelungen und Aspekte
aus der Sicherheits-Policy der beteiligten Unternehmen zu bercksichtigen. Besonders fr das
Hauptziel der Verfgbarkeit gilt fr das Monitoring das oben beschriebene. Allerdings sollten
hier zustzlich spezielle Werkzeuge wie Nmap,
Nessus oder Snort zum Einsatz kommen. Dem
Security-Monitoring und den dafr verfgbaren Open-Source-Tools ist ein eigener Beitrag in
dieser Ausgabe gewidmet.
Problem-Management
Mchte man die Anforderungen an ein modernes IT-Service-Management nach ITIL erfllen,
so bentigt man dafr nicht zwangslufig kommerzielle Software. Open-Source-Software bieten in vielen Fllen eine analoge oder auf jeden
Fall eine ausreichende Leistung, um Services
auch innerhalb von komplexen IT-Infrastrukturen beobachten zu knnen.
Ein bisher allerdings noch ungelstes Problem
ist die Integration der verschiedenen Komponenten in ein komplettes System-ManagementFramework. Diese Aufgabe hat sich inzwischen
jedoch das Open Management Consortium
(OMC, [6]) auf die Fahnen geschrieben. Interessierte Anwender sollten die Ergebnisse dieser
vielversprechenden Initiative im Auge behalten.
(jcb)
nnn
Die Zielsetzung des Problem-Managements besteht in der Lokalisierung, Dokumentation und

Verfolgung von strukturellen Strungen und in
deren (vorbergehender) Lsung. Um dies zu
erreichen, fhrt man sowohl proaktive als auch
reaktive Manahmen durch. Proaktiv versucht
das Problem-Management unter anderem,
durch Monitoring potenzielle Faktoren fr Strungen zu identifizieren, bevor die eigentlichen
Strungen berhaupt auftreten. Zu den Werkzeugen fr diese Art der berwachungen zhlen
die schon erwhnten Tools MRTG, Cacti und
Nagios. Reaktiv wird unter anderem Monitoring
durchgefhrt, um bekannte Fehler zu berwachen oder die Untersuchung von Strungen zu
erleichtern. Dafr eignen sich auch zahlreiche
Linux-Bordwerkzeuge, wie ein eigener Artikel
spter beschreibt.
IT-Security-Management
IT-Security-Management ist bei ITIL Teil eines
Rahmenkonzeptes fr Informationssicherheit.
Die Hauptziele dabei sind: die Vertraulichkeit
(Confidentiality) wahren, also der Schutz von
Informationen vor unautorisierter Kenntnisnahme und unbefugter Benutzung, die Integritt (Integrity) sichern, also die Richtigkeit und
Vollstndigkeit der Information und die Verfgbarkeit (Availability) innerhalb des im SLA ver-
Fazit
Der Autor
Wilhelm Dolle ist Senior
Security Consultant
bei der Hisolutions AG,
einem Beratungshaus
fr Information Security
Infos
[1] Deutsche Seiten des Information Technology
Service Management Forum: [http://www.itsmf.
de/bestpractice/index.asp]
[2] Bundesamt fr Sicherheit in der Informationstechnik: [http://www.bsi.de/gshb/index.htm]
[3] MRTG: [http://oss.oetiker.ch/mrtg]
[4] Cacti: [http://www.cacti.net]
[5] Nagios: [http://www.nagios.org]
[6] Open Management Consortium: [http://www.
openmanagement.org]
und Risk Consulting in

Berlin, und seit vielen
Jahren im IT-Sicherheitsumfeld ttig. Er ist CISA,
CISSP, lizensierter ISO
27001 / Grundschutzauditor und ITIL-ServiceManager.
Eher vom Band
als durch Bastelei

Fr das System-Monitoring mit einer quelloffenen
und kostenfreien Open-Source-Lsung ist Nagios
lngst nicht mehr die einzige Alternative. Die Konkurrenz konzentriert sich dabei mit Vorliebe auf
das Enterprise-Segment, in dem auch Geld zu verdienen ist. Grbt das der kommerziellen berwachungssoftware, die um dieselben Kunden wirbt,
inzwischen schon das Wasser ab? Dieser Artikel
beschreibt, was kostenpflichtige Angebote in die
Waagschale zu werfen haben. Ingo Averdunk
Studien
Kommerzielle Monitoring-Programme unterscheiden sich scheinbar nur wenig von den Alternativen aus dem Open-Source-Lager. Beide
untersttzen eine Vielzahl von Plattformen,
greifen auf umfangreiche Metriken der berwachten Systeme zu und erlauben das Erkennen
von Strungen, sei es durch Schwellwertberschreitung, Verfgbarkeitsmessung oder Patternmatching.
Monitoring-Tools, die nicht blo eine berschaubare Umgebung berwachen, sondern sich
unternehmensweit bewhren sollen, mssen
dafr besondere Anforderungen erfllen. Vor
allem wichtig sind hier die Skalierbarkeit, die Sicherheit, die vorausschauende Fehlererkennung
(proaktives Monitoring), ein aussagekrftiges
Reporting oder die Fhigkeit, komplexe Zusammenhnge sinnfllig zu visualisieren. Darber
hinaus verstrkt sich besonders in einer groen
Umgebung die Gewichtung bestimmer Anforderungen die wichtigsten davon diskutiert
dieser Beitrag.
Zentrale Konfiguration
Warehousing & Reporting

Eine unternehmensweite Monitoring-Lsung
geht in der Regel weit ber die einfache Reaktion
auf Schwellwertberschreitungen hinaus. So ist
die Visualisierung von Messdaten eine oft gestellte Anforderung. Dafr speichert man die gesammelten berwachungsdaten normalerweise
in einem Datawarehouse. Auf dieser Grundlage
lassen sich schlielich Charts generieren, die
die historische Entwicklung und Trends veranschaulichen. So lsst sich beispielsweise erkennen, ob ein Filesystem stndig wchst und zuknftig mit einem Speicherengpass zu rechnen
ist. Die Verbindung von historischen Daten aus
dem Datawarehouse und aktuellen Daten des
Monitors helfen den Support-Mitarbeitern, ein
Problem schneller zu isolieren und Gegenmanahmen zu ergreifen.
Zustzlich zu diesen Reports die hufig gleich
in eine Helpdesk-Konsole eingebettet sind sollen sich aus denselben Daten auch professionelle
Reports fr interne wie externe Kunden erstellen lassen. Und schlielich bedient sich auch das
Capacity-Management hier, denn die Messwerte
ermglichen Aussagen ber die Auslastung entscheidender Ressourcen wie Memory, CPU oder
I/O jetzt und in der Zukunft.
Ein solches Warehouse kann durchaus Gigabytes an Daten erzeugen. Die Datenhaltung und
das Reporting mssen daher mit solchen Massen effizient umgehen knnen.
E
Zu eben diesen Anforderungen, die mit zunehmender Unternehmensgre immer mehr an

Relevanz gewinnen, gehrt die zentrale Konfiguration. Denn nur so ist es mglich, den berblick zu bewahren, berall einheitliche Policies
durchzusetzen oder die Module und berwachungsparameter effizient zu pflegen. Auch das
Change- und Release-Management vereinfacht sich
durch die zentrale Steuerung
merklich.
Ein zweiter Aspekt betrifft
die
Nachvollziehbarkeit:
Die Verfgbarkeit von Anwendungen ist hufig die
zentrale Metrik von Service
Level Agreements und
damit zugleich ein sensibler
Punkt in der Beziehung zwischen dem Servicedienstleister und seinem Kunden.
Entsprechend wichtig ist,
dass hier ausschlielich koordinierte und autorisierte
Eingriffe mglich sind und
dass ein Auditlog zuverlssig protokolliert, wer welche
nderungen wann durchge- Abbildung 1: Integration verschiedener Monitoring-Module im Tivoli Enterprise Portal am Beispiel SAP-Monitoring.
fhrt hat.
Studien
Skalierbarkeit
Ein wichtiger Punkt fr den unternehmensweiten Einsatz einer Lsung ist die Skalierbarkeit.
So haben Unternehmen nicht selten mehrere
Tausend Server im Einsatz, internationale Konzerne sogar Zehntausende von Servern. Jeder
dieser Server beherbergt Middleware, Datenbanken oder Anwendungen. Wenn man annimmt, dass pro Server im Schnitt zehn Events
pro Tag anfallen, dann wird deutlich, welche
Event-Volumen zu Stande kommen knnen.
Nur durch mchtige Korrelationen und Automationen lsst sich sicherstellen, dass am Ende
eine geringe Anzahl von Events brig bleibt, die
Helpdesk oder Experten noch beherrschen.
Solche Umgebungen erzwingen eine hoch-skalierbare Monitoring-Architektur. Die berwachung verteilt sich ber mehrere, oft redundant
ausgelegte Ebenen. Die einzelnen Ebenen fungieren dabei als intelligente Manager, um Korrelation aber auch Automation weitgehend unabhngig von einer zentralen Instanz durchfhren zu knnen. Auch lassen sich diese Ebenen
nutzen, um die Verteilung von berwachungskommandos und Parametern effizient zu organisieren und so das dabei anfallende Datenaufkommen oder die Anzahl der Verbindungen zu
minimieren.
Skalierbarkeit bezieht sich nicht allein auf die
Anzahl der zu berwachenden Systeme wei-
tere Aspekte kommen oft hinzu, zum Beispiel

Anzahl der aktiven Benutzer, Mandantenfhigkeit, Rollen und Rechte der Benutzer und Umfang der Datensammlung im Datawarehouse.
Agentenbasiert oder
agentenlos
An dieser Stelle kommt unweigerlich auch das

Thema agentenbasiertes versus agentenloses
Monitoring zur Sprache, das schon Gegenstand
vieler Diskussionen war.
Frher arbeitete das System-Monitoring berwiegend mit Agenten auf den Zielsystemen, whrend Netzmanagement in der Regel agentenlos
arbeitete. Allerdings bedingt ein agentenbasiertes
Management ein abgestimmtes Betriebskonzept,
wollen doch Ablufe wie Deployment der Agenten, Pflege der Agentensoftware und Betrieb dieser Infrastruktur gut durchdacht sein.
Daher haben sich am Markt inzwischen Lsungen etabliert, die weitgehend ohne Agenten auskommen. Sie arbeiten in erster Linie auf Basis
von SNMP und ermitteln die Verfgbarkeit ber
IP- und Port-Probeing.
Wie die agentenbasierten Lsungen, haben
auch agentenlose durchaus Nachteile. Bei ihnen schlgt etwa die aufwndige Pflege von
Credentials (in der Regel Benutzername und
Passwort) negativ zu Buche. Auch ergeben sich
Sicherheitsbedenken, wenn nicht die Version 3
des SNMP-Protokolls zum
Einsatz kommt. Oft sind hier
zudem Skripte und Konfigurationdateien auf die Zielsysteme zu transferieren.
Fr eine detaillierte, proaktive und automatisierte berwachung von Betriebssystemen und Anwendungen knnen aber auch diese Systeme
nicht darauf verzichten, die
Monitore auf dem Zielsystem
auszufhren, oft unter Zuhilfenahme von Infrastrukturen wie Secure Shell. Nur in
Einzelfllen verwenden Abfragen von einem entfernten
System beispielsweise RFCs
(Remote Function Calls).
Weil sich fr beide TechnoAbbildung 2: Das Tivoli Software Availability Portfolio beschreibt die Interaktion von System-,
logien mit und ohne AgenNetz-, und Security-Management in eine einheitliche Servicemanagement-Lsung unter Verten Einsatzbereiche finden
wendung von Konfigurationsdatenbank (CMDB) und Portal (Service Dashboard).
lassen, haben sich viele Her-
Studien
steller kommerzieller Lsungen wie IBM Tivoli,

BMC, HP oder CA dazu entschieden, in ihrem
Portfolio beide Mglichkeiten vorzusehen. Ihre
Kunden haben so die Mglichkeit, die fr ihre
Umgebung beste Technologie auszuwhlen.
Anwendungs-Monitoring
Das Monitoring von Anwendungen und Middleware erfordert ein hohes Ma an Kenntnis der
internen Strukturen, der kritischen Parameter
und deren Schwellwerte. Das Identifizieren von
geeigneten Metriken, die Konfiguration des Monitoring und die Integration in den Life-Cycle
der Anwendung kann durchaus eine beachtliche
Eigendynamik entwickeln und wertvolle Ressourcen binden.
Daher ist es vorteilhaft, das Monitoring solcher
Komponenten in eine generische MonitoringStruktur einzubetten. Anstelle von Punktlsungen nimmt man lieber eine Lsung mit vielleicht
nur 90-prozentiger Abdeckung in Kauf, die sich
aber auch effizient betreiben lsst.
Hersteller von kommerziellen Monitoring-Suiten haben eine Vielzahl spezialisierter Module
im Angebot. Sie ermglichen beispielsweise die
mageschneiderte berwachung von Datenbanken (DB2, Informix, Oracle, MySQL, Sybase,
MS-SQL und andere), von ERP- und CRM-Programmen (etwa SAP, Siebel oder Peoplesoft),
von Web-Infrastrukturen (Websphere, BEA,
Jboss, Apache), von Middleware (MQ-Series,
Message Broker) oder Collaboration Software
(Lotus Notes, Exchange). Heutzutage sind solche Module in der Regel mit so genannten BestPractices kombiniert, die eine Auswahl von
relevanten Metriken vorgeben. Damit wird der
Aufwand fr Installation und Konfiguration,
aber auch das ntige Know-how auf der Anwenderseite reduziert.
Die Integration in eine Produktlsung erleichtert den Einsatz beim Endkunden. Das Suchen
von geeigneten Plugins, deren Konfiguration
und Integration in eine Monitoring-Lsung und
die Wartung und Pflege dieser Lsung wird zum
Groteil vom Hersteller der Monitoring-Suite
bernommen.
Diese Monitoring-Module sind mittlerweile
uerst mchtig und durchaus vergleichbar mit
anwendungsspezifischen berwachungspaketen. Fr eine umfassende berwachung einer
SAP-Landschaft verwenden sie beispielsweise
eine Vielzahl von Schnittstellen, zum Beispiel
CCMS, IDOC, SAP syslog, Statistical Records,
JMX und ABAP-Programme. Dieser Entwicklungsaufwand ist kaum im nichtkommerziellen

Bereich zu leisten. Zudem arbeiten Hersteller
von Anwendung und berwachungsprogramm
gemeinsam an der Zertifizierung dieser Kombination. Ein so zertifiziertes Monitoring soll
sicherstellen, dass nicht die Monitore selbst Probleme in der Anwendungslandschaft auslsen,
es gibt also Antwort auf die Frage Quis custodes custodiet? (Wer wird die Wchter bewachen?)
Mageschneiderte Monitore
Neben Modulen fr kommerzielle Anwendungen ist es selbstverstndlich notwendig, auch fr
kundenspezifische Lsungen Monitore selbst
entwickeln zu knnen. Hierzu bieten Hersteller von Monitoring-Suiten generische Agenten
oder Toolkits an. IBM Tivoli bietet beispielsweise ber den Universal Agent ein derartiges
reichhaltiges Spektrum an Adaptoren zum
Beispiel der Klassen API, File, SNMP, ODBC,
Socket und Script die fr die Integration von
eigenen Lsungen zur Verfgung stehen. Daneben hat IBM mit der Open Process and Automation Library [1] eine Platform etabliert, die
entsprechende Best Practices fr Kunden zum
freien Download anbietet.
Zunehmend setzen sich lose gekoppelte Komponenten gegenber monolithischen Anwendungen durch, man spricht von Composite Applications und Service Oriented Architectures
(SOA). Teile der Anwendung laufen auf unterschiedlichen Komponenten und Plattformen ab,
vom Webserver auf Linux-Farmen bis zur Datenbank auf dem Mainframe. Damit wird auch
fr das Monitoring solcher Applikationen eine
Lsung notwendig, die auf all diesen Plattformen einsetzbar ist und die an unterschiedlichen
Orten ermittelte Einzelergebnisse zu einer Gesamtschau kombinieren kann.
Sicherheit
Oft umfasst das Monitoring gerade auch die
unternehmenskritischen Server, daher ist eine
sicherheitskritische Bewertung zwingend erforderlich. Sie umfasst Themen wie die sichere
Kommunikation zwischen einzelnen Komponenten oder die Robustheit des Codes gegen Attacken.
Ein hufiges Problem dabei ist die Kommunikation zwischen Monitoring-Server und Agenten ber Firewalls hinweg. In diesem Bereich
Studien
hat sich beispielsweise seit langem IBM Tivoli

erfolgreich positioniert. Die Lsung erlaubt
eine SSL-verschlsselte Kommunikation, bei
der nicht nur der Port frei whlbar ist, sondern
auch die Richtung des Kommunikationsaufbaus. Komponenten der Tivoli-Lsung bndeln
den Verkehr innerhalb eines Subnetzes, agieren
als Proxy und gleichzeitig als Application Layer
Gateway. Das erlaubt eine sichere Kommunikation selbst in komplexen und umfangreichen
Firewall-Umgebungen.
Netzberwachung
Ein Aspekt des Monitoring ist die Netzberwachung primr der aktiven Netzkomponenten
wie Router, Switches oder Hubs. Auch Protokolle oder die Performance in diesen Netzen
lassen sich berwachen. Entscheidend fr die
Qualitt der berwachung ist dabei die korrekte
Abbildung der Netzwerktopologie.
Whrend die Pflege von kleineren Netzen auf
Layer-3- Ebene vielleicht noch realisierbar ist,
ist dies in greren Umgebungen nicht mehr
praktikabel. Kommerzielle Netzwerklsungen
stellen daher aufwndige Autodiscovery- und
automatische Topologiefunktionen zur Verfgung. Sie gewinnen ihre Information neben dem
OSI-Layer 3 auch aus den tieferen Schichten.
Zudem untersttzen sie moderne Netzwerktechnologien wie Multi Protokoll Label Switching (MPLS).
Integration
Einer der wesentlichen Grnde, warum groe
Unternehmen kommerzielle berwachungstools einsetzen, ist die Integration in ein bergeordnetes System- und Servicemanagement.
Oft agieren berwachungstools dabei nicht isoliert sondern integriert in ein Monitoring-Portal (Dashboard). Alle beobachteten Ereignisse
laufen hier zusammen. Die einzelnen Events
lassen sich dann miteinander korrelieren und in
einer grafischen Konsole prsentieren. Gerade
bei greren Umgebungen ist es hier besonders
wichtig, fr bersichtlichkeit zu sorgen, denn
allzu schnell kann sich der Benutzer in einer zu
detaillierten Anzeige verlieren.
Oft ist diese Konsole in einen Servicedesk integriert, sodass sie automatisch Trouble Tickets
(Incidents) generieren kann. Sollte die Eskalation nicht ohnehin im Servicedesk-Tool erfolgen, kann sie auch direkt der Event-Manager
steuern. Man unterscheidet hier oft zwischen
funktioneller Eskalation (Weiterleitung an die
entsprechende Fachgruppe) und hierarchischer
Eskalation (Weiterleitung, wenn das Problem
nach einer vorgegebenen Zeit fortbesteht).
Reaktion auf Strungen
Abbildung 3: Das Zusammenspiel von Verfgbarkeitsinformation (links oben), Detailinformationen (rechts oben) und spezifischen Handlungsanweisungen (unten)
verdeutlicht die Mglichkeiten eines integrierten Monitoring-Portals.
Eine oft genutzte Funktion ist die automatische Reaktion auf Fehler und
der Versuch einer Fehlerbehebung
bereits durch den Monitor-Agenten.
Ein einfaches Beispiel dafr ist das automatische Neustarten von Diensten
nach einem Ausfall oder das Lschen
von temporren Dateien, sobald ein
Filesystem voll luft. Eine grafische
Anzeige der Ergebnisse ist Bestandteil eines jeden Monitoring-Pakets.
Neben einer tabellenartigen, priorisierten Liste der Ereignisse kommen
zunehmend baumartige Strukturen
in Mode, welche die Bedeutung eines
Ereignisses fr ein Business-System
verdeutlichen.
Damit der Administrator schnell und
sicher auf ein bestimmtes Ereignis
reagieren kann, lassen sich Handlungsanweisungen mit dem Monitor
Studien
verlinken und in der Konsole einblenden. Diese

Handlungsanweisungen knnen kundenspezifisch und somit eng auf die Arbeits- und Prozessumgebung des Unternehmens zugeschnitten
sein. Auf der anderen Seite stellen Hersteller ihren Kunden zunehmend Knowledge-Bases zur
Verfgung, die Probleme beschreiben und Reaktionen hierzu empfehlen. Eine Verlinkung mit
diesem externen Wissen ist zunehmend gefragt,
erspart das doch unter Umstnden den mhsamen Aufbau einer eigenen Wissensdatenbank.
Anreicherung von Events

Um Probleme effizient bearbeiten zu knnen, ist
es mglich, Events mit zustzlichen Informationen anzureichern und mit weiteren Datenquellen zu verknpfen. Neben den schon erwhnten
Handlungsanweisungen knnen das auch Informationen zum Standort, zum Ansprechpartner
fr die betroffene Resource, zum verantwortlichen Servicemanager oder dem betroffenen
SLA sein.
Diese Integration gewinnt besonders dann an
Bedeutung, wenn nicht nur Spezialisten mit der
Lsung arbeiten, sondern auf der ersten Ebene
beispielsweise zunchst ein allgemeiner Helpdesk die meisten Probleme zu bewltigen versucht.
CMDB
Eine besondere Bedeutung hat hier die Integration mit einer Konfigurationsdatenbank (Configuration Management Database, CMDB). ber
eine CMDB lassen sich alle fr ein Betriebsmittel relevanten Konfigurationsinformationen und
deren Beziehungen abrufen. So knnen etwa
Soll- und Istzustand verglichen werden, wobei
Inventory- und Discovery-Tools zum Einsatz
kommen. Dabei kann man nachvollziehen, welche nderungen wann durchgefhrt wurden.
Wie wichtig dieses Wissen ist, veranschaulicht
eine Zahl: 85 % aller Probleme haben ihre Ursachen in nderungen in der IT (Quelle: Tivoli
Primary Research 2005).
Die in der CMDB hinterlegten Informationen
geben auch Aufschluss ber die Bedeutung des
Betriebsmittels aus technischer und wirtschaftlicher Sicht. War es redundant ausgelegt oder
ein Single Point of Failure? Ist es eine unternehmenskritische Anwendung? Wurden Service
Level Agreements (SLAs) vereinbart, und sind
diese in Gefahr? Werden Vertragsstrafen bei
lngerem Ausfall fllig?
Wirtschaftliche Aspekte
Neben diesen technischen und funktionellen
Aspekten unterscheiden sich kommerzielle
Tools auch in wirtschaftlicher Hinsicht von
Open-Source-Lsungen. Als Erstes stehen hier
oft die Lizenz- und Wartungskosten zur Diskussion, die bei einer kommerziellen Lsung
anfallen. Oft ist dies auch der wesentliche Motivationsgrund, sich nach freier Software umzusehen.
Auf der anderen Seite muss man aber in Kauf
nehmen, dass die Integration und Konfiguration der Module und Plugins dann eben nicht
ber das Produkt geliefert wird, sondern selbst
zu leisten ist. Nachdem viele Unternehmen in
den letzten Jahren auf Kosteneinsparungen fokussiert waren, fehlt dort nun die notwendige
Erfahrung fr Open-Source-Produkte. Immer
hufiger sind sie gezwungen, auf die Dienstleistung von Spezialisten und externen Beratungshusern zurckzugreifen, was die Kostenvorteile von Open-Source-Lsungen schnell wieder
relativieren kann.
Ein von Unternehmen oft geforderter, zentraler, namentlich bekannter Ansprechpartner, der
zudem auch die Verantwortung bernimmt, ist
im Open-Source-Bereich nicht immer die Regel. Selten ist auch ein professioneller Support
fr 24 Stunden an sieben Wochentagen. Gerade
fr unternehmenswichtige Anwendungen und
fr den IT-Betrieb zhlt das Monitoring allemal
zu dieser Kategorie ist dies eine unabdingbare
Forderung.
Fazit
Eine unternehmensweite Monitoring-Lsung
ist weit mehr als das einfache berwachen von
Diensten oder Ressourcen. Themen wie Visualisierung, Reporting, aber auch Netzmanagement
und Anwendungsmanagement gehren seit
langem zu den Anforderungen, nicht nur von
groen Unternehmen. Die zunehmende Notwendigkeit, Monitoring mit einer Incident- und
Problemmanagement-Lsung zu verbinden,
zeigt die Richtung der knftigen Entwicklung:
von einer technisch motivierten Lsung hin zur
prozessorientierten, fast schon fabrikhnlichen
Automation, die alle ntigen Komponenten integriert. (jcb)
nnn
Infos
[1] Open Process and Automation Library (OPAL);
[http://www.ibm.com/software/tivoli/opal]
Der Autor
Ingo Averdunk ist als
Consulting IT Architect
bei IBM Tivoli ttig. Zu
seinem Verantwortungsbereich gehrt
Architekturberatung
fr strategische Kunden. Ingo Averdunk
hat einen Abschluss in
Informatik und besitzt
das Zertifikat ITIL Service Manager.
Das darf man

berwachen
Monitoring ist berwachung. berwachung bedeutet Kontrolle. Kontrolle von betriebsinternen Ablufen, aber auch von Mitarbeitern. Ist der betriebliche
Big Brother ein juristisches Problem? Fred Andresen
Studien
Jger und Sammler, so hat sich der Mensch seit

Urzeiten stets definiert. In der heutigen Arbeitswelt gilt das gleiche: Wer auf der Jagd nach der
besten Betriebsorganisation ist, muss erst einmal eine Bestandsaufnahme durchfhren. Zur
bloen Kontrolle, oder um das Ergebnis in eine
Verbesserung umzusetzen. Deshalb muss sich
auch jeder Admin irgendwann damit auseinandersetzen, wer in seiner EDV wann was macht.
Das damit verbundene Speichern und Auswerten von Daten betrifft aber nicht nur die Maschinen, denn notwendigerweise sind auch
die Menschen betroffen, die die Maschinen bedienen.
Glserne Mitarbeiter sind kein

technisches Problem
In Betracht kommen hier die Teilbereiche
Netzzugriffe (etwa auf bestimmte Server oder
Verzeichnisse des Intranets), Zugriffe auf Internet-Content, Telefonie- oder E-Mail-Verkehr zwischen Mitarbeitern oder nach auen.
All das lsst sich in Relation zur Zeit setzen; so
kann man Spitzenzeiten erkennen oder individuellen Netzverkehr an bestimmte Uhrzeiten
binden. Dies ist heute bereits Standard. Zumindest mittelfristig mglich scheinen aber auch
Systeme, die anhand von Video- oder Infrarotberwachung Bewegungsprofile der Mitarbeiter
zwischen Schreibtisch, Kopierer und Teekche
auswerten, etwa um durch Umorganisieren die
Browege zu verkrzen.
Niemand wird bestreiten, dass ein Unternehmen, das im Wettbewerb erfolgreich sein will
oder auch nur ums schlichte berleben kmpft,
vitales Interesse an der Optimierung interner
Ablufe hat. Solche Verbesserung setzt zwingend die laufende Bestandsaufnahme und damit
ein Messen und Auswerten voraus.
Ohne Zweifel steht es einem Unternehmer zu,
zu prfen, ob und inwieweit seine Arbeitnehmer
oder Vertragspartner ihre arbeits- oder dienstvertraglichen Pflichten erfllen. In den Fllen,
in denen eine solche Leistungsberprfung
dem Gesetzgeber oder der Rechtsprechung zu
weit geht, greifen diese auf zwei Anstze zurck,
das Kontrollrecht zu begrenzen. Ein Ansatz ist
die Bewertung der arbeits- oder dienstvertraglichen Pflichten selbst, also das Zurechtrcken
des Vertragsinhalts. Ein Beispiel hierfr ist, auf
so genannte betriebliche bungen abzustellen,
also Verhaltensmuster, die im Betrieb schon seit
lngerer Zeit durch den Unternehmer geduldet
werden oder sich eingespielt haben. Betriebliche

bungen sieht man dabei als nderungen etwa
eines Arbeitsvertrages an, sie gelten also als Vertragsinhalt.
Wird in einem Betrieb zum Beispiel durch den
Arbeitgeber ber einen gewissen Zeitraum toleriert, dass die Mitarbeiter die vom Unternehmen
zur Verfgung gestellten E-Mail-Konten auch
fr private Mails benutzen, so gilt dies als erlaubt, auch wenn die einzelnen Arbeitsvertrge
keine Regelung hierzu treffen. Das gleiche gilt
dann selbst in den Fllen, in denen das im Vertrag ausdrcklich verboten ist. Gerade die Frage,
ob in einem Betrieb private Mails der Mitarbeiter gestattet sind, ist in der Praxis von entscheidender Bedeutung fr die Protokollierung, Filterung und berwachung aller E-Mails.
Ein anderer Ansatz, das Kontrollrecht einzuschrnken, ist die Anerkennung des Persnlichkeitsrechts jedes Mitarbeiters, das diesen
vor harschen Einschnitten in seine Privatsphre
schtzt. Die Obergerichte haben schon vor etlichen Jahren dieses Persnlchkeitsrecht zementiert und wenden es unter anderem auch als Begrenzung arbeitsvertraglicher Kontrollrechte an.
Privates berwachen
Das Interesse des Unternehmers an Optimierung der EDV-Ablufe findet dort seine Grenze,
wo die individuelle Sphre der Arbeitnehmer
oder freier Mitarbeiter beginnt. Dabei ist zu
beachten, dass sich die Grenzen beider Sphren berlappen und eine exakte Grenzziehung
schwierig und nur im Einzelfall sicher feststellbar ist. Der Arbeitnehmer (und auch der freie
Mitarbeiter) hat ein Recht auf angemessene
Privatsphre am Arbeitsplatz. Das bedeutet, die
Kontrolle seiner Arbeistleistung in qualitativer
wie auch in quantitativer Hinsicht ist gewissen
Einschrnkungen unterworfen. Das bedeutet
somit auch, die berwachung dessen, was er tut,
ist im gleichen Mae eingeschrnkt.
Der Schutzbereich des Persnlichkeitsrechts
umfasst das Recht des Arbeitnehmers, auch an
seinem Arbeitsplatz eine angemessene Privatsphre zu erhalten. Kerninhalte des Persnlichkeitsrechts, die bei der Arbeit ebenfalls berhrt
sein knnen, sind das Recht am eigenen Wort
und das Recht am eigenen Bild. Aber auch der
Zwang, bestimmte Handlungen auszufhren
oder zu unterdrcken, kann durch den permanenten psychologischen Druck veranlasst sein,
wenn sich der Arbeitnehmer einer dauerhaften
Studien
berwachung bewusst ist. Aber auch eine dauerhafte, ohne bestimmten Anlass eingerichtete
Videoberwachung, von der die Mitarbeiter
nichts wissen, verstt gegen ihre Menschenrechte.
An eine verdeckte berwachung, also Monitoring, von dem der Mitarbeiter keine Kenntnis
hat, stellt die Rechtsprechung hhere Anforderungen: Sie sei allenfalls dann zulssig, wenn
eine offene berwachung keinen Erfolg bringt.
Eine Frage der Mitbestimmung

Nach 87 Abs. 1 Nr. 6 des Betriebsverfassungsgesetzes (BetrVG) [2] unterliegen Manahmen
zur berwachung von Mitarbeitern mittels
technischer Einrichtungen der Mitbestimmung
des Betriebsrates. Dabei kommt es nicht darauf
an, ob die durch die technische Einrichtung erfassten Daten tatschlich zur berwachung der
Mitarbeiter eingesetzt werden, sondern nur darauf, ob das als Nebeneffekt objektiv mglich
wre. Der Begriff der technischen Einrichtung
ist jedenfalls weit auszulegen und umfasst damit auch jede Art von Software, die Netzverkehr
berwacht, Protokolle anlegt oder auswertet
solange dies im Verbund eine berwachung
auch nur mglich macht. Bereits das Anlegen
von Protokolldateien, die durch Filtern oder
auch nur Ablesen eine Auswertung individueller Mitarbeiterzugriffe erlaubt, fllt somit unter
diese Bestimmung.
Der Verbund aus PC und Systemsoftware, die
Benutzereingaben im weiten Sinne bereits von
sich aus loggt, wie jedes Linux-System in der
Standard-Konfiguration, kann durchaus schon
als solche technische Einrichtung gelten. Es

kommt ja nicht darauf an, ob es die Logdateien
zu dem Zweck anlegt, den Benutzer in irgend einer Form zu berwachen, es gengt, dass etwa
durch das einfache Kommando w offenbar
wird, wann sich ein Mitarbeiter an seinen Rechner gesetzt hat. Um so mehr gilt natrlich ein
augefeiltes Monitoring-System, das jede Art von
Intranet-, Internet- und Dienstaufrufen protokolliert und auswertet, als technisches berwachungssystem.
Mitbestimmung des Betriebsrates bedeutet, dass
der Betriebsrat sofern ein solcher existiert
nicht blo zu informieren ist, sondern mit ihm
eine Einigung zu erzielen ist. Der Betriebsrat
hat, weil es um zwingend zu schtzende Rechte
der Mitarbeiter geht, nicht nur ein bloes Recht,
sondern eine Pflicht zur Mitbestimmung.
Gibt es keinen Betriebsrat, kann naturgem
auch keine Mitbestimmung erfolgen. Aus dem
Umkehrschluss der Vorschriften des BetrVG
lsst sich allerdings nachweisen, dass eine berwachung von Mitarbeitern mittels technischer
Einrichtungen grundstzlich zulssig ist, wenn
auch die aufgezeigten Grenzen bestehen.
brigens: Auch wenn ein Betriebsrat den Einsatz der Monitoring-Tools absegnet, heit das
noch nicht, dass jede Manahme rechtlich
zulssig ist. Denn Persnlichkeitsrechte sind
hchst individuell und der Verfgung durch
Dritte (den Betriebsrat) oder in bestimmten
Fllen selbst der eigenen Disposition entzogen.
Eine Betriebsvereinbarung zwischen Betriebsrat
und Arbeitgeber, die einen wesentlichen Eingriff
in die Privatsphre der Mitarbeiter erlauben soll,
Grundstze der Internationalen Arbeitsorganisation (ILO) zur berwachung

Arbeitnehmer haben Anspruch auf eine angemessene Privatsphre am Arbeitsplatz.
nArbeitnehmer wissen, welche elektronische berwachungsmethoden verwendet werden und wie der Arbeitgeber die dabei erhobenen Daten verwendet.
nDer Arbeitgeber verwendet elektronische berwachungsmethoden oder Durchsuchungen von Datensammlungen, Netzwerkkommunikation oder E-Mail so wenig wie
mglich. Dauernde elektronische berwachung ist nicht
gestattet.
nArbeitnehmer sind an der Entscheidung, wann und wie
elektronische berwachungsmethoden oder Durchsuchungen stattfinden, beteiligt.
nDaten werden nur zu klar definierten, mit der Arbeit zusammenhngenden Zwecken erhoben und verwendet.
nDie Beurteilung der Leistungen der Arbeitnehmer beruht
nicht allein auf den berwachungsergebnissen.

nArbeitnehmer haben das Recht, die bei der elektroni-
schen berwachung ber sie erhobenen Daten einzusehen, zu kritisieren und zu berichtigen.
nAufnahmen, die fr den Zweck, zu dem sie erhoben wurden, nicht mehr lnger bentigt werden, sind zu vernichten.
nberwachungsdaten, durch die individuelle Arbeitnehmer identifizierbar sind, drfen nicht Dritten bekannt gegeben werden, es sei denn, es besteht dafr eine gesetzliche Pflicht.
nArbeitnehmer oder zuknftige Arbeitnehmer knnen auf
das Recht auf Privatsphre nicht verzichten.
nVorgesetzte, welche diese Grundstze verletzen, mssen
mit Disziplinarmanahmen oder Entlassung rechnen.
Studien
kann ebenso nichtig sein, wie eine ausdrckliche

Einverstndniserklrung des Arbeitgebers im
Arbeitsvertrag. Kommt es zum Streit, knnten
solche Klauseln wertlos sein.
Die Internationale Arbeitsorganisation (Internationale Labour Organisation, ILO, [3]), eine Unterorganisation der Vereinten Nationen (UN),
hat zum angemessenen und mavollen Einsatz
des EDV-Monitoring eine Reihe von Grundstzen (siehe Kasten) aufgestellt, die die Mitgliedsstaaten beachten.
Eine weitere Einschrnkung der berwachungsmglichkeiten ergibt sich auch fr ratlose Betriebe aus der Verordnung ber Sicherheit
und Gesundheitsschutz bei der Arbeit an Bildschirmgerten (BildscharbV, [4]). Nach Ziff. 22
des Anhangs zu dieser bundesweit gltigen Vorschrift, die fr die meisten Betriebe gilt, ist ohne
Wissen der Benutzer keine Vorrichtung zur qualitativen oder quantitativen Kontrolle zulssig.
Im Gegensatz zur technischen Einrichtung
des BetrVG ist fr die Vorrichtung der BildscharbV die Zweckbestimmung entscheidend.
Ist die berwachung der Arbeitsleistung der
Mitarbeiter hier zwar denkbar, aber erkennbar
nicht das Ziel der Vorrichtung, steht das Verbot
dem Einsatz nicht entgegen. Die Kombination
aus PC und Programm gilt auch im Sinne der
BildscharbV als Vorrichtung.
Abteilung, Marsch!
Grund- und Menschenrechte sind individuelle
Rechte. Das Argument liegt demnach auf der
Hand, wenn das Monitoring nicht auf individuelle Arbeitspltze also auf einzelne Arbeitnehmer ausgerichtet ist, wren die gesammelten
Daten ja nicht einzelnen Personen zuzuordnen,
und deshalb knnten keine individuellen Rechte
verletzt sein. Dieser Ansatz ist jedoch falsch.
Das Bundesarbeitsgericht hat bereits in seinem
Beschluss vom 26.7.1994 [5] festgehalten, dass
technische berwachungsmanahmen einer
Arbeitsgruppe geeignet sind, einen Gruppendruck aufzubauen, der insoweit mittelbar die
freie Entfaltung der Persnlichkeit der einzelnen
Gruppenmitglieder und damit deren individuelle Rechte beeintrchtigt.
Je weniger Personen eine solche Gruppe umfasst, desto grer ist die Wahrscheinlichkeit,
dass einzelner Netzverkehr von einem der Gruppenmitglieder verursacht ist. Daraus folgt: Je
kleiner die gemonitorte Gruppe, desto eher sind
individuelle Persnlichkeitsrechte betroffen.
Kommunikation ist alles

Unabhngig von der berwachung betriebsinterner Ablufe, unterliegt jede Form der persnlichen Kommunikation einem besonderen
Schutz. Die berwachung des privaten E-Mailund Telefonie-Verkehrs ist ebenso unzulssig,
wie die der privaten Internetzugriffe. Monitoring-Tools, die auf diese Bereiche abzielen, sind
grundstzlich unzulssig.
Weil nur die private Kommunikation der Mitarbeiter geschtzt ist, die rein betriebliche jedoch
nicht, kommt es darauf an, ob das Monitoring
berhaupt private Kommunikation erfasst. Sind
den Mitarbeitern die private Internetnutzung,
private E-Mails oder Telefonate gestattet, darf
man hier nichts mehr berwachen. Nur, wenn
diese Arten persnlicher Kommunikation nicht
erlaubt sind, darf der Unternehmer davon ausgehen, dass auch alle Kommunikationsdaten
seiner Verfgung unterliegen und seine Monitoring-Tools darauf ansetzen.
Betriebsinteresse steht zurck

Monitoring ist grundstzlich zulssig, allerdings
sind die Rechte der Mitarbeiter, die sozusagen
inzident mit berwacht werden, zu bercksichtigen. Der Einsatz des Monitoring-Systems
muss den Mitarbeitern bekannt sein, und seine
Funktionsweise sollte so klar beschrieben sein,
dass jeder Beschftigte zumindest nachvollziehen kann, welche seiner Ttigkeiten einer Auswertung unterliegt. Ist jedem klar, dass die Auswertung der betriebsinternen EDV-Ablufe der
Verbesserung der Betriebsorganisation und damit auch der Arbeitserleichterung der einzelnen
Mitarbeiter dient, wird es kaum Streit geben.
Falls doch, ist das Monitoring so anzupassen,
dass es die Persnlichkeitsrechte der Mitarbeiter
ausreichend schtzt. (jcb)
nnn
Infos
[1] Wikipedia zu Monitoring: [http://de.wikipedia.
org/wiki/Monitoring]
[2] Betriebsverfassungsgesetz: [http://bundesrecht.
juris.de/bundesrecht/betrvg/gesamt.pdf]
[3] Internationale Arbeitsorganisation: [http://www.
ilo.org/public/german/region/eurpro/bonn/
index.htm]
[4] Bildschirmarbeits-Verordnung: [http://
bundesrecht.juris.de/bildscharbv/]
[5] Bundesarbeitsgericht zur Gruppenberwachung: [http://www.lexrex.de/rechtsprechung/
innovativ/ctg1086615676632/1386.html]
Eher unbekannt, doch leistungsstark:

Zabbix
Die Featureliste liest sich wie das Ergebnis einer
Kreuzung der bekanntesten Open-Source-Monitore in einem unbekannten Produkt. Denn was
viele Konkurrenten erst mit Untersttzung durch
Third-Party-Software schaffen, das bringt Zabbix
gleich mit.
Daniel Drrer, Bogdan Taru, Markus Feilner
Projekte
Bis vor einigen Monaten war Zabbix [1] nur

Eingeweihten ein Begriff. In letzter Zeit aber gewinnt das sechs Jahre alte Open-Source-berwachungstool an Popularitt, ist es doch angetreten, dem Platzhirsch Nagios das Revier streitig zu machen.
Dabei gibt seit zwei Jahren die Firma SIA Zabbix
mit Sitz in der lettischen Hauptstadt Riga Rckendeckung. Sie bietet professionellem Support
und Untersttzung bei Entwicklung und Test.
Ob das Produkt dadurch tatschlich schon dem
Anspruch gerecht wird, die besten Features der
Konkurrenz zu vereinen, zeigt der Test auf den
folgenden Seiten.
Informationsbeschaffung
Bereits beim Sammeln von Informationen, der
Grundfunktion jeder berwachungssoftware,
gibt sich Zabbix kaum eine Ble. Es beherrscht
alle gngigen Methoden: aktive und passive,
solche, die sich auf Netzwerkprotokolle sttzen,
und natrlich auch SNMP. (Mit dem SNMPProtokoll beschftigt sich ein weiterer Artikel
dieser Ausgabe.)
Direkt nach der Installation stehen bereits rund
100 eingebaute Tests zur Verfgung, mit denen
sich grundlegende Funktionen und Ressourcen
wie die CPU-Last oder der Speicherverbrauch
beobachten lassen. Fr viele dieser Tests kommt
ein so genannter Agent zum Einsatz, der entweder auf dem zentralen Server oder dem berwachten Client als Informationsbeschaffer ttig
ist. In manchen Fllen sammelt er permanent
Informationen, gibt sie aber nicht ungefragt
weiter. In anderen ist er auch selbststndig ttig

und kann etwa aus eigener Initiative eine Logdatei regelmig nach bestimmten Mustern
durchforsten.
Dieser Agent fhlt sich auf vielen Unix- und
Windows-Plattformen heimisch, so unter Linux,
Solaris, HP-UX, AIX, FreeBSD, OpenBSD, Mac
OS X, Tru64/OSF1, Windows NT4.0, Windows
2000, Windows 2003 oder Windows XP.
Sollte der Agent fr eine bestimmte berwachungsaufgabe noch nicht geschult sein, kann
man ihm leicht mit einem eigenen Perl- oder
Shellskript oder einem C-Modul auf die Sprnge
helfen. Zuknftige Zabbix-Versionen sollen
sogar mit einer Diensteerkennung ausgerstet
sein, mit deren Hilfe er automatisch die wichtigsten Services ins Auge fassen knnte.
Gerte im Netz, die SNMP sprechen, kann Zabbix direkt befragen, denn es beherrscht das Esperanto der Devices ebenfalls. Daneben kann
die Software zahlreiche Netzwerkdienste testen,
indem sie sich als zugehriger Client ausgibt
und eine Konversation beginnt. Die Antwort des
Gegenbers verrt in der Regel viel ber seinen
Gesundheitszustand. Solche Checks sind wie
die SNMP-Abfragen natrlich nicht auf das
LAN beschrnkt.
Zentrallager fr Daten
Alle Beobachtungswerte gelangen in eine zentrale Datenbank, von wo aus sie zum Beispiel in
vielfltig konfigurierbare Diagramme einflieen.
Mglich sind Kurzzeitdarstellungen und Statusbersichten ebenso wie Langzeitstatistiken, wie
Abbildung 1: Ein bersichtliches Webfrontend bildet die Zabbix-Zentrale, zustndig fr Konfiguration

und Kommunikation mit dem Anwender. Im Bild: die Liste der berwachten Parameter.
Projekte
Kartierte Informationen
Abbildung 2: Zabbix sammelt Informationen ber verschiedene Kanle, neben seinen Agenten verwendet es SNMP oder zapft Netzwerkprotokolle an.
man sie beispielsweise fr die Kapazittsplanung

bentigt.
Eine besondere Spezialitt von Zabbix sind Diagramme, in denen sich die Darstellung mehrerer Werte (Items) berlagert. Die Abbildung 3
zeigt beispielhaft eine Grafik mit dem aktuellen
Verlauf der Prozessorauslastung whrend der
letzten Stunde in den Kategorien idle, user, nice
und system.
Der Dialog Configuration | Graphs | Create
Graph ist der Ausgangspunkt beim Erstellen
einer solchen Grafik. ber seine Schaltflche
Edit lassen sich beliebige Items aus einem
Drop-down-Men whlen.
Zabbix kann darber hinaus Statusinformationen mit Karten (Maps) verknpfen, die die
Infrastruktur entweder physisch oder logisch
abbilden. Diese Karten lassen sich zudem so
verschachteln, dass man von einer bersichtsdarstellung in immer detailliertere Ansichten
hinein absteigen kann. Eine Karte als Ausgangspunkt beschleunigt erfahrungsgem die
Fehlersuche, weil sie dem Administrator einen
schnellen berblick verschafft. Dabei lsst sich
der Zugriff auf bestimmte Zoom-Stufen oder
Bereiche an die Berechtigungen bestimmter
Nutzer knpfen.
Die Karten lassen sich komplett ber das Frontend im Browser erstellen. Alles ntige findet
sich im Dialog Configuration | Maps | Create
Map. Hier legt der Administrator eine neue
Karte an, benennt sie und platziert anschlieend
via Add Element beliebige von Zabbix berwachte Objekte. Auch die Verbindungen zwischen den Hosts sind sowohl darstell- wie auch
berwachbar.
Templates
Beim schnellen Integrieren neuer Hosts in das
berwachungssystem helfen Vorlagen dem
Administrator. Diese Templates fr Web-, Application-, Datenbank- oder Mailserver oder
auch Desktoprechner legen fest, welche Dienste
oder Systemparameter zu berwachen, welche
Checks dafr auszufhren sind und in welchen
Grafiken Zabbix die Werte darstellt. Auch fr
ganze Hostgruppen stehen Templates zur Verfgung, so dass Administratoren Serverfarmen
oder Cluster mit wenigen Mausklicks hinzufgen und in gemeinsamen Grafiken berwachen
knnen.
Abbildung 3: Verschiedene Zeitreihen in einem Diagramm sind eine Spezialitt von Zabbix.
Projekte
Dashboards fr jeden
Ein besonders interessantes Feature von Zabbix
stellen die so genannten Screens dar. Das sind
Ansichten, in denen sich beliebige Tabellen,
Listen, Karten oder Diagramme auf einer Bildschirmseite kombinieren lassen. ber Configuration | Screens | Create Screen kann der Administrator die gewnschten Beobachtungspunkte
fr eine auf seine Bedrfnisse zugeschnittene
Ansicht auswhlen.
Zabbix beinhaltet wie jede Software seiner Art
Algorithmen, die die Beobachtungsergebnisse
mit bestimmten Grenzwerten vergleichen, die
auch in Service Level Agreements (SLAs) festgeschrieben sein knnen. Bei einer Verletzung
dieser Limits, die sich auf Fehlerraten, Ressourcenauslastung oder auch Performancekennwerte beziehen knnen, lst Zabbix ber einen
Triggermechanismus beliebige Aktionen aus.
Auf diese Weise lsst sich sowohl die Alarmierung steuern wie auch jede andere Aktion starten, die beispielsweise zur Schadensbegrenzung
oder Selbstheilung sinnvoll erscheinen mag. Zustzlich kann der Admin Zeitfenster festlegen,
in denen ein bestimmter Trigger reagieren oder
pausieren soll.
Die Standardkonfiguration berwacht bereits
direkt nach der Installation so viele Items, dass
es oft sinnvoll erscheint, zuerst die nicht bentigten zu deaktivieren (unter Configuration |
Items). Dasselbe lsst sich auch schon auf der
Ebene der Vorlagen einstellen. Dazu whlt man
als Gruppe Templates und als Host das entsprechende Template.
Zabbix-Installation
Die Installation des Zabbix-Servers und seiner
Agenten stellt den Administrator vor keine groen Probleme. Allerdings muss er dafr berwiegend auf der Kommandozeile operieren, wogegen sich die folgende Konfiguration dann fast
vollstndig in der Browser-GUI erledigen lsst.
Im Beispiel kam ein Ubuntu Server LTS 6.0.6
(installiert mit LAMP-Option) zum Einsatz, bei
einem weiteren Agenten ein Red Hat Enterprise
Linux 4.
Damit die Installation gelingt, sollte allerdings
eine Reihe von Voraussetzungen erfllt sein
(siehe Tabelle 1).
Auerdem empfiehlt sich das Anlegen eines Accounts fr den Benutzer zabbix. Und
schlielich sollte auch die Datenbank fertig und
arbeitsfhig eingerichtet sein, bevor man die
Abbildung 4: Netzwerkdarstellungen, die den Status der berwachten Gerte reflektieren, lassen sich direkt in Zabbix entwerfen.
Monitoring-Lsung installiert. Dafr legt der

Installateur zunchst eine leere Datenbank an
im Beispiel unter MySQL etwa mittels create
database zabbix;. Danach kommt das mitgelieferte Create-Skript fr die jeweilige Datenbank
zum Zug, dass die ntigen Datenbankobjete erzeugt. Unterhalb des Installationsverzeichnisses
findet es sich in create/mysql:
$ cat schema.sql | mysql -u root zabbix
$ cd ../data/
$ cat data.sql
| mysql -u root -p zabbix
$ cat images.sql | mysql -u root -p
Dann kann es losgehen. Weil sich Zabbix im

Moment strmisch weiterentwickelt, empfiehlt
Abbildung 5: Neue Hosts lassen sich auf der Grundlage von Templates
leicht integrieren.
Projekte
conf) gelangen leider nicht automatisch nach

/etc, allerdings finden sich im Installationsverzeichnis im Unterordner misc/conf/ Vorlagen mit einer Beispielkonfiguration. Sie lassen
sich einfach nach /etc/zabbix kopieren.
In der Konfigurationsdatei des Servers zabbix_
server.conf sind folgende Eintrge anzupassen:
ListenIP=<Server IP>
DBHost=<DB-Server>
DBName=zabbix
DBUser=<DB-User>
DBPassword=*********
Anschlieend starten die Befehle

zabbix@monitoring:/etc/zabbix$ U
Abbildung 6: Bildschirmdarstellungen so genannte Screens lassen sich

in Zabbix frei zusammenstellen. Das Beispiel zeigt eine Karte, die signalisiert, dass im Bundesland Baden-Wrttemberg zwei Probleme aufgetreten
sind. Darunter wurde ein CPU-Last-Graph platziert.
sich die Installation aus den Quellen. Der Quellcode steht auf der Zabbix-Homepage [1] zum
Download bereit. Das Configure-Skript bentigt folgende Optionen:
$ ./configure \
--enable-server \
--enable-agent \
--with-mysql \
--with-net-snmp
Der Parameter --with-net-snmp ist optional. Der Parameter --with-mysql hngt von
der Datenbank ab, die als Backend verwendet
wird. Im Beispiel soll der Zabbix-Server sich
auf dem lokalen Rechner selbst berwachen.
Dafr braucht es auerdem einen Agenten, also
--enable-agent. Nach configure komplettieren make und make install den Dreisatz
ohne Besonderheiten.
Konfiguration
Im Anschluss an das bersetzen trgt der Installateur
die ntigen Ports in /etc/
services ein.
zabbix_agent
10050/tcp
zabbix_trap
10051/tcp
Die Konfigurationsdateien
des Zabbix-Servers (zabbix_server.conf) und des
Agenten (zabbix-agentd.
/usr/local/bin/zabbix_server
zabbix@monitoring:/etc/zabbix$ U
/usr/local/bin/zabbix_agentd
den Zabbix-Server und seinen Agenten. Das

Kommando zabbix_agentd startet dabei den
Zabbix-Agenten als Stand-alone Daemon, das
Programm zabbix_agent ist fr den Start des
Agenten ber den inetd verfgbar. Wer sich
davon berzeugen mchte, dass Server und
Agent tatschlich laufen, schaut in die Protokolldateien standardmig liegen sie in /tmp,
lassen sich aber genauso gut in das passendere
/var/log-Verzeichnis konfigurieren. Passende
Init-Skripte fr den automatischen Start liegen
im Unterverzeichnis misc/init.d/ fr die meisten Distributionen bereit.
Konfiguration des Frontends

und Aufruf
Der Code des Webfrontend von Zabbix ist komplett in PHP geschrieben und muss vom Installateur in das Document-Root des Webservers
bewegt werden.
Tabelle 1: Bentigte Softwarekomponenten

Apache ab 1.3.12
MySQL ab 3.22 oder PostgreSQL ab 7.0.2
MySQL- oder ProstgreSQL-Header und -Libraries
PHP ab 4.0 oder 5.0
PHP GD- oder GD2-Modul
PHP MySQL- oder PostgreSQL-Modul
NET-SNMP oder UCD-SNMP-Header und -Libraries
OpenSSL-Header und -Libraries
GNU Make
GNU C Compiler
Projekte
zabbix@monitoring:/var/www$ sudo cp -R U
/home/zabbix/install/zabbix-1.1.6/U
frontends/php/ ./zabbix
Danach ist ihm die verwendete Datenbank ber

seine Konfigurationsdatei bekannt zu machen:
zabbix@monitoring:/var/www/zabbix$ U
sudo vim include/db.inc.php
//$DB_TYPE ="ORACLE";
//$DB_TYPE ="POSTGRESQL";
$DB_TYPE
="MYSQL";
$DB_SERVER ="DB-Host";
In dieser Zeile sollte der Admin fr dieses Beispiel DB-Host durch localhost (oder die IP
des Datenbankservers) ersetzen. Die folgenden
Zeilen enthalten die Zugangsdaten fr den Datenbankserver:
$DB_DATABASE ="zabbix";
$DB_USER
="DB-User";
$DB_PASSWORD ="**********";
Danach ist das Frontend bereits startklar,

man erreicht es ber die URL [http://Monitoring-Host/zabbix]. Die Anmeldung ist mit dem
Standardbenutzer admin ohne Passwort mglich.
Einschleusen eines Agenten

Solange es keinen Host berwacht, schaut das
Webfrontend allerdings noch recht leer aus.Die
Installation der Agenten erfolgt in analogen
Schritten, allerdings reicht hier configure --enable-agent aus. Auf dem Client ist nach dem
bersetzen lediglich in der Konfigurationsdatei
zabbix_agentd.conf der Server einzutragen.
Das gelingt mit Server=192.168.111.249. Die
Adresse muss mit dem Wert des Listen-Parameters der Server-Konfiguration bereinstimmen.
Nun startet der Zabbix-Agent nach /usr/local/
bin/zabbix_agentd.
Windows-Agenten
Der Zabbix-Agent fr Windows-Systeme ZabbixW32.exe verwendet den Performance Data
Helper PDH, um Informationen unter Windows 2000 und XP zu sammeln. In Windows
NT 4.0 ist PDH nicht enthalten, ein Artikel aus
der Microsoft Knowledge Base [2] beschreibt die
nachtrgliche Installation. WMI (Windows Management Instrumentation) wird offensichtlich
noch nicht untersttzt, ebenso fehlt ein Client
fr Vista.
Abbildung 7: Eine Statusbersicht vermittelt einen raschen berblick.
Die Konfiguration des Zabbix-Agenten vollzieht

sich auch unter Windows in einer Konfigurationsdatei mit identischer Syntax wie unter Linux/Unix, eine Liste der spezifischen WindowsParameter gibt es auf der Zabbix-Website unter
[3]. ZabbixW32.exe ist ein reines Befehlszeilentool, das zum Beispiel einen Syntaxcheck der
Konfigurationsdatei ausfhren oder als Quelle
fr das Windows Event Log dienen kann. Auf
Wunsch integriert sich der Client in die Windows-Diensteverwaltung und wird von ihr automatisch gestartet und angehalten.
Zabbix konfigurieren
Im Webfrontend ist der Zabbix-Server ber die
Arbeitsaufnahme seines Agenten zu unterrichten. Das geschieht ber Login | Configuration |
Hosts | Create Host. Bereits unmittelbar danach
sind dank der automatischen Checks zahlreiche
Beobachtungswerte abfragbar. Ein Klick auf den
Reiter Monitoring besttigt das. Ganz rechts
in dieser Liste der Trigger befindet sich jeweils
eine Spalte fr jeden berwachten Host. Weitere
Einstellungen erfordern von nun an kein Editieren von Konfigurationsdateien mehr, sondern
nur noch die Mens der GUI.
E
Projekte
Daneben lassen sich die Beobachtungswerte

auch individuell verknpfen, und beispielsweise
automatisch mit den Eckdaten von Service Level
Agreements (SLAs) vergleichen. Auch ausfhrliche Reports und Zusammenfassungen generiert Zabbix auf Wunsch. Darber hinaus bietet
es umfangreiche Mglichkeiten der Dokumentation, Analyse und Inventarisierung der berwachten Systeme.
Redundante Checks und unntige Alarme vermeidet Zabbix durch Abhngigkeiten, die der
Administrator in der Konfiguration der Trigger
eintrgt. Fllt beispielsweise ein Router aus, so
erkennt Zabbix automatisch, dass diverse Server
dahinter nicht mehr erreichbar sind und fhrt
die berflssigen Checks und Alarmierungen
nicht durch. Mit der Zuordnung der Trigger zu
Fehlerkategorien von Information bis Desaster bietet Zabbix Eskalationsstufen mit angepassten Benachrichtigungsmethoden.
Zabbix-Benutzerverwaltung
Abbildung 8: Die Benutzerverwaltung von Zabbix erlaubt ein fein abgestuftes Berechtigungskonzept.
Alarmierung
Fr den Einsatz in greren Unternehmen ntzlich ist die flexible Benutzer- und Rechteverwaltung von Zabbix. Auch sie kann der Administrator komplett im Webfrontend konfigurieren
(Abbildung 8). Im oberen Teil der Abbildung
sind die Daten eines neu angelegten Benutzers
und einige Einstellungen zu sehen. In der unteren Hlfte dieses Dialoges stehen die User-Berechtigungen.
Der Administrator hat fr den Beispiel-User offensichtlich sehr strenge Vorgaben gewhlt: Der
Benutzer darf nur Screens betrachten (Read
Meldet ein Agent eine Strung, kann er den Administrator auf den blichen Wegen benachrichtigen: ber E-Mail, SMS, Pager oder beliebige
externe Programme. Das Zabbix-Forum auf
Sourceforge [4] enthlt zahlreiche Anleitungen
dazu; die Spanne der Mglichkeiten reicht von Audio Alerts
bis zur Benachrichtigung ber
WinPopUps.
Als Grundlage fr Alarme dienen Zabbix wahlweise auch kumulierte Daten oder die Ergebnisse von Berechnungen. Ein
Administrator erhlt in diesem
Fall bereits eine E-Mail, wenn
der bentigte Speicher oder die
durchschnittliche CPU-Auslastung einer Gruppe von Hosts,
zum Beispiel eines Clusters, einen vordefinierten Schwellwert
bersteigt. Die Vitalitt der gesamten Infrastruktur zeigt die
zentrale Statusbersicht (Abbil- Abbildung 9: In der kommenden Zabbix-Version soll die Installation komplett in der Web-GUI ablaufen.
dung 7).
Projekte
only), die Konfiguration, Graphen und das Benutzermanagement bleiben vollstndig vor ihm
verborgen (Hide).
Der Dialog am unteren Ende des Bildschirms
erstellt neue Berechtigungen (die verwendbaren
Optionen sind Add, Hide, Read-Write
und Read-Only). Durch die geschickte Verknpfung von Ressource-IDs mit Berechtigungen kann der Administrator jeden User auf eine
fr ihn mageschneiderte Zabbix-Umgebung
beschrnken. Der Entzug von Ressourcen ist
dabei umfassend und betrifft alle Elemente von
Zabbix, einschlielich der Kommentare und Benachrichtungen
Ausblick: die Betaversion

Neben der stabilen gibt es eine aktuelle Betaversion von Zabbix, die bereits einen Blick in die
Zukunft gestattet. Ihre Installation verluft komplett im Webfrontend und beinhaltet einen Systemcheck und die Einrichtung der Verbindung
zum Datenbankserver, wie das bei anderen
PHP-basierten Programmen auch der Fall ist.
Eines ihrer besonderen Features ist der Ex- und
Import der Konfiguration von Objekten in oder
aus XML-Dateien. Dadurch liee sich beispielsweise ein Host bequem von einem zu einem anderen Zabbix-Server migrieren. Des Weiteren
behoben die Programmierer zahlreiche Bugs,
ergnzten die Untersttzung fr SQLite3 und
verbesserten viele weitere Details.
Auf der Roadmap steht auch, die in fast jedem
Dialog verfgbaren Kommentarfelder im Webinterface nach und nach zu einem Trouble Ticket System auszubauen. Bisher bieten diese
Felder immerhin die Mglichkeit, Fehler und
Fehlerbehebung zu dokumentieren.
Das Engagement von SIA Zabbix spiegelt sich
in umfangreichen, freien Dokumentationen mit
Tutorials, Quick Start Guide und detaillierten
Beschreibungen der Datenbankstrukturen wider. Mittlerweile sind auch Red Hat und Ubuntu
auf Zabbix aufmerksam geworden, das Kompilieren der Quellen ist allerdings die einzige vollstndige Installationsart und die einzige, die der
Hersteller supportet. Anders als bei Nagios oder
Cacti existieren keine offiziellen RPM- oder Debian-Pakete, die alle Features untersttzen.
Zusammenfassung
Zabbix macht einen sehr ausgereiften Eindruck,
was angesichts des geringen Bekanntheitsgrades
berrascht. Der Hersteller testet nach eigenen
Abbildung 10: Beliebige Host-Daten lassen sich

direkt aus dem Webfrontend als XML-File exportieren oder importieren.
Angaben regelmig mit mehr als 5000 Devices

und Servern, er erhlt Feedback aus zahlreichen
Installationen in der Praxis und untersttzt die
wachsende Community. Clients gibt es fr fast
alle Betriebssysteme. Der fehlende Vista-Client
und die WMI-Unterstzung lassen sicher nicht
lange auf sich warten. Der Ansatz, zur offenen
Software kommerziellen Support anzubieten,
hat sich in vielen anderen Projekten bewhrt
und drfte Zabbix gerade fr den Einsatz in Unternehmen interessant machen.
Das Webfrontend von Zabbix berzeugt durch
eine einfache und verstndliche Darstellung mit
vielen Mglichkeiten. Zabbix kann Daten aus
fast beliebigen Quellen sammeln und voneinander unabhngige Werte in gemeinsamen Karten, Screens oder Diagrammen anzeigen. Eine
gelungene Benutzerverwaltung, umfangreiche
Vorlagen und das gute Event-Management machen es zu einer ernstzunehmenden Alternative
zu Nagios und Cacti. (mfe)
nnn
Die Autoren
Bogdan Taru arbeitet

als System-Engineer
bei Thinking Objects
Software GmbH. Er
beschftigt sich hauptschlich mit den Themen AIX, Websphere
und DB2.
Infos
[1] Zabbix-Homepage: [http://www.zabbix.com/
download.php]
[2] Installation PDH unter NT 4.0: [http://
support.microsoft.com/default.
aspx?scid=kb;en-us;284996]
[3] Zabbix Windows-Agent: [http://www.zabbix.
com/manual_config_w32.php]
[4] Zabbix-Projektseite bei Sourceforge: [https://
sourceforge.net/projects/zabbix]
Daniel Drrer arbeitet

als System-Engineer
bei Thinking Objects
Software GmbH. Sein
Arbeitsschwerpunkt ist
Unix- und Linux-Administration.
Projekte
Applikations-Monitoring mit

Opensmart
Mit flexiblen Konfigurationsmglichkeiten, leistungsfhigen Built-In-Checks und besonderen

Strken bei der Logauswertung empfiehlt sich
Opensmart fr kleinere und mittlere berwachungsaufgaben. Holger Schulthei
Projekte
Eine besondere Strke von Opensmart sind

seine agilen Agenten: Auf den Systemen, die sie
berwachen, haben sie die Lizenz fr selbststndige Aktionen. So liefern sie nicht nur Messwerte, sondern knnen beispielsweise auch alleine einfache Fehler beheben. Sie arbeiten nicht
immer stur nach Schema F, sondern sind in
der Lage, Randbedingungen ins Kalkl zu ziehen, die ihnen der Admin vorgibt. So beachten
sie etwa Wartungsfenster und untersttzen im
Fehlerfall automatisch die Ursachenforschung
durch zustzliche Tests. Oder sie starten in hoch
verfgbaren Umgebungen autonom Dienste
nach, die zuvor andernorts ausgefallen waren.
Die Agenten verfgen ber ein groes Repertoire eingebauter Checks, die nur noch konfiguriert werden mssen. Wo diese Tests nicht ausreichen, lassen sich beliebige eigene Prfskripte
integrieren.
Daneben zeichnen Opensmart leistungsfhige
Werkzeuge fr die Log-Auswertung aus. Sie
kommen mit verschiedenen Formaten zurecht
und knnen zuverlssig das Vorhandensein
oder Fehlen beliebiger Textmuster in den Eintrgen prfen.
Dem Admin greift dieses Monitoring-System
schlielich mit einer integrierten Softwareverteilung und einem Updatemechanismus fr die
eigenen Komponenten unter die Arme.
Systemarchitektur
berwachten Rechner direkt zum OpensmartServer berichten knnen beispielsweise weil

sie in einem anderen Subnetz oder einer DMZ
zu Hause sind , kann auch ein HTTP(S)-Proxy
die Vermittlung bernehmen (Abbildung 1).
Mit dem zweiten Blick allerdings stt man auf
einige unerwartete und ntzliche Eigenheiten
von Opensmart, die besonders die Administration erleichtern.
Config-Server
Dazu zhlt ein so genannter Config-Server, der
die zentrale Verwaltung von Konfigurationsdateien der Agenten bernehmen kann. Er prft
via HTTP-HEAD-Request, ob die auf dem
Server zentral hinterlegte Agent-Konfiguration
neuer als die lokale ist, und berschreibt sie vor
Ort gegebenenfalls mit der jngeren Version
vom Server.
Den Filetransfer bernimmt ein HTTP-Server (Apache), von dem sich der Agent mittels
HTTP-GET bedient. Symlinks machen es dabei mglich, dass viele Agents auf ein und dieselbe Config-Datei zugreifen, was den Pflegeaufwand von Fall zu Fall dramatisch verringert.
Deployment-Server
Neben dem Config-Server existiert als weitere
Backend-Funktion ein Deployment-Server,
der die Agents mit einer aktuellen Version der
Opensmart-Clientsoftware versorgt. Dies erleichtert insbesondere Updates in Umgebungen mit vielen Agenten. Auch hier wird nur
via HTTP(S) kommuniziert. Abbildung 2 zeigt
schematisch den Ablauf. Um das Software-Repository des Deployment-Servers selbst zu aktualisieren, gibt es ein Kommandozeilentool
Auf den ersten Blick berrascht die Architektur

von Opensmart nicht sonderlich: Wie blich,
sammeln verteilte Agenten auf entfernten Maschinen Statusinformationen oder Performancedaten und melden sie einer Zentrale weiter. Die
Empfangskomponente heit hier Collector-Server, nimmt die Daten via CGI-Skript
entgegen und legt
sie in einer zentralen
Datenbank ab. Deren
Inhalt bewertet und
prsentiert schlielich eine BrowserGUI.
Fr die Kommunikation mit seinen
Agenten verwendet
XML over HTTP
XML over HTTPS
der Opensmart-Server XML over HTTP
Intranet
OpenSMART-Server
Internet
oder auch HTTPS.
Wenn nicht alle Abbildung 1: Die Agenten bermitteln dem zentralen Server ihre Daten in XML-Form via HTTP oder HTTPS.
Projekte
whrend der Installationsvorbereitung Gedanken zur Ressourcenausstattung des OpensmartServers machen. Ausschlaggebend dafr ist die
Anzahl der Agenten, ihr Aufrufintervall und die
Gesamtzahl der Checks.
Config
-Versi
on?
neuer
e Con
fig
Server
Daten
Frontend
Client
Abbildung 2: Ist die auf dem Server hinterlegte Konfiguration fr den

Agenten aktueller als die lokale, so besorgt sich der Agent selbststndig
die neuen Einstellungen.
namens osmart-updater, das von opensmart.

sourceforge.net wahlweise den aktuellsten Testing- oder Stable-Tree der Agent-Software herunterldt und fr die Verteilung bereitliegt.
Webserver-Konfiguration
Da sich sowohl Config- als auch DeploymentServer fr den Filetransfer der Funktionen eines
Webservers bedienen, mssen sie auch in dessen Konfiguration bedacht werden. Ein Beispiel
dafr zeigt Listing 1. Sind mehrere Rechner zu
berwachen, empfiehlt es sich auf jeden Fall,
mod_perl zu verwenden (das jedoch per Default deaktiviert ist). Damit lsst sich wertvolle
CPU-Zeit sparen. Auch sollte sich der Admin
Die Browser-GUI des Opensmart-Servers

prsentiert die Ergebnisse aller Agenten unter [http://Server-IP/cgi-bin/monitorgui.cgi]
bersichtlich (Abbildung 3). Die Darstellung
beruht auf den Daten, die der Collector-Server
von den Agents erhalten und in der Datenbank
abgelegt hat. Dabei sind verschiedene Ansichten
mglich, wie beispielsweise Alle Fehler oder
gefiltert nach bestimmten Hosts oder Checks.
Grundstzlich unterscheidet Opensmart dabei
zwischen den Zustnden NORMAL, INFO,
WARNING, ERROR und FATAL. Aufgrund dieser Klassifizierung kann dann entweder eine Fehlerbehandlungsroutine auf Clientseite oder eine Notify-Regel (auf Serverseite)
ausgefhrt werden.
Die Option Konfig der GUI dient dem Editieren der Filter- und Notify-Regeln. Eine NotifyRegel stt als Reaktion auf bestimmte Ereignisse definierte Aktionen an und benachrichtigt
damit beispielsweise den Admin ber Strungen. Opensmart liefert einige vorgefertigte Notify-Skripte bereits mit.
Hinter dem Reiter Deployment verbirgt sich
der Zugang zur Konfiguration der gleichnamigen Komponente. Hier lassen sich Updates fr
einzelne Agents planen. Anstehende Auslieferungen symbolisiert eine gelbe Ampel, fehlge-
Listing 1: Apache-Konfiguration
01
# osmart.apache.conf
15 <Directory /home/osmart/htdocs/deployment>
02
<VirtualHost osmart.company.com>
16 Order allow,deny
03 ServerName osmart.company.com
17 Allow from all
04 ErrorLog /var/log/apache/osmart-error.log
18 Header set Cache-Control no-cache
05 CustomLog /var/log/apache/osmart-access.log
19 Options +Indexes
common
20 </Directory>
06
21
07 DocumentRoot /home/osmart/htdocs
22 <Directory /home/osmart/htdocs/conf>
08 ScriptAlias /cgi-bin/ /home/osmart/cgi-bin/
23 Order allow,deny
09 <Directory /home/osmart/cgi-bin>
24 Allow from all
10 Options +ExecCGI +FollowSymlinks
25 Header set Cache-Control no-cache
11 Order allow,deny
26 Options +Indexes
12 Allow from all
27 </Directory>
13 </Directory>
28
14
29
</VirtualHost>
Projekte
Listing 2: Datenbank-Konfiguration fr MySQL

01
# For MySQL Databases:
02
$data_source="DBI:mysql:osmart";
03
04
# 2. Username and Password.
05
$user_name = "osmart";
06
$passwd
= "geheim";
07
08
# 3. Opensmart uses auto_commit
09
$has_autocommit=1;
schlagene eine rote. Eine grne Ampel steht fr

eine erfolgreiche Aktualisierung.
Der Menpunkt Reporting schlielich ermglicht die Auswertung von Daten, welche die
Agenten geliefert haben. Diagramme knnen
etwa Load-Kurven, die Anzahl laufender Prozesse, die Auslastung von Swapspace oder Festplatten darstellen. Die Verfgbarkeit von Services lst sich momentan noch nicht auswerten,
das ist aber auf jeden Fall fr eine der nchsten
Releases geplant.
Systemvoraussetzungen
Opensmart stellt keine hohen Ansprche. Alles,
was auf dem zu berwachenden Server bentigt
wird, ist ein Perl-Interpreter in Version 5.005
oder hher und etwa 1 MByte Speicherplatz fr
die Installation des Ag.ents.
Auf der Serverseite braucht Opensmart einen
Apache-Webserver, dessen mod_perl Funktion (optional), die Perl-Module XML::Simple,
Chart::Lines und DBI sowie eine Datenbank.
Die Datenbank nimmt alle Werte auf. Dafr
kommen derzeit MySQL (ab Version 4.1), PostgreSQL, Oracle oder DB2 in Frage.
Auf der Downloadseite [1] finden sich die folgenden drei Tar-Archive:
nopensmart-server-version.tgz: Beinhaltet
das Server-Paket von Opensmart.
nopensmart-docs-version.tgz: Dokumentation fr Server und Checks, die auf dem Server laufen.
nopensmart-agent-version.tgz: Dieses TarFile beinhaltet den Opensmart-Agenten mit
allen Built-In-Checks.
Server-Installation
Nach dem Entpacken wird die Server-Installation durch das Kommando export OSMART_
HOME=$HOME /usr/bin/perl ./source/server/
install_server $OSMART_HOME gestartet.
Die Variable $OSMART_HOME bestimmt
dabei das Zielverzeichnis der Server-Installation. Hier ist es das Home-Verzeichnis des Benutzers, der die Installation startet.
Zu beachten ist, dass der Benutzer, unter dessen Kennung Apache luft, Schreibrechte
auf die Logdatei $OSMART_HOME/logs/
opensmart.log haben muss. Fr die Konfiguration der Datenbank liegen Create-Skripte
unter
$OSMART_HOME/install/createdb_
RDBMS_.sql. Das Schema lsst sich mit dem
Befehl cat createdb_mysql-1.0.sql | mysql -u
osmart -p 'geheim' osmart anlegen. Die Konfigurationsdatei, die der Opensmart-Server fr
die Datenbank-Verbindung bentigt, liegt unter
$OSMART_HOME/etc/opensmart.db.config
Listing 3: Crontab-Eintrge
01
export $OSMART_HOME=$HOME
02
03
# Notify-Server alle 5 Minuten
ausfuehren
04
* */5 * * * $OSMART_HOME/bin/
notifysrv
05
06
# archive_errors jede halbe Stunde
ausfuehren
07
* */30 * * * $OSMART_HOME/bin/
archive_arrors
Abbildung 3: Default-Ansicht der Monitor-GUI.
Projekte
bereit. Im Beispiel wird eine MySQL-Datenbank

verwendet (Listing 2). Fr andere Datenbanken
finden sich jeweils geeignete Beispiele im Verzeichnis $OSMART_HOME/etc/opensmart.
db.config.example.
im Browser etwas anderes zu lesen sein als You

haven't sent any data, dann msste man im
Logfile des Webservers oder auch in der Opensmart-Protokolldatei ($OSMART_ROOT/logs/
opensmart.log) nach Hinweisen suchen.
Zum Abschluss der Installation werden noch
zwei Cronjobs bentigt. Der erste, notifysrv,
prft in der Datenbank, ob sich eine Statusnderung ergeben hat. Je nachdem triggert eine Notify-Regel dann ein Kommando wie notify_by_
Test des Servers

Ein Test des Collector-Servers [http://Server-IP/cgi-bin/collectorcgi.pl]zeigt,obderOpensmart-Server grundstzlich funktioniert. Sollte
Listing 4: Agent-Konfiguration
001
<!DOCTYPE OSAGENT SYSTEM "osagentconfig.dtd">
040
002 <OSAGENT>
041 
003 
042 <PROC>
004 <OSAGENTCONFIG>
043
005
044
<PROCNAME>squid</PROCNAME>
045
<ERRORLEVEL>ERROR</ERRORLEVEL>
046

048
<FIXCMD>sudo /etc/init.d/squid restart</
FIXCMD>
049
</PROCESS>
050
<PROCESS>
051
<PROCNAME>sshd</PROCNAME>
014 </OSAGENTCONFIG>
052
015 
053
</PROCESS>
016
054
<PROCESS>
017 
055
018 <DISK>
056
019
057
</PROCESS>
<PROCESS>
<FS>
020
<FSNAME>.*</FSNAME>
058
021
<ERRORLEVEL>WARNING</ERRORLEVEL>
059
022
<VALUE>85</VALUE>
060
023
<FORMULA>PERCENT</FORMULA>
061
<PROCNAME>xinet</PROCNAME>
<PROCNAME>crond</PROCNAME>
</PROCESS>
024
</FS>
062 </PROC>
025
<FS>
063
026
<FSNAME>.*</FSNAME>
064 

<FS>
068
eigene Skripte / Pruefroutinen -->

<SCRIPT>
<SCRIPTNAME>/home/opensmart/bin/uptime</
SCRIPTNAME>
069
070
<CHECKNAME>uptime</CHECKNAME>
034
<FSNAME>/mnt/tmp</FSNAME>
071
035
<ERRORLEVEL>NORMAL</ERRORLEVEL>
072
036
<VALUE>105</VALUE>
073

037
074
<SCRIPT>
038
</FS>
039 </DISK>
<PROCESS>
075
</SCRIPT>
<SCRIPTNAME>/home/opensmart/bin/checkfan</
SCRIPTNAME>
Projekte
mail, notify_by_sms oder auch notify_by_

rss. An dieser Stelle kann der Admin aber auch
eigene Skripte fr die Alarmierung hinterlegen.
Es hat sich als sinnvoll erwiesen, den NotifyServer alle 5 Minuten durch Cron ausfhren zu
lassen (Listing 4).
Der zweite Cronjob, archive_errors (Listing
3), hat die Aufgabe, in regelmigen Abstnden
die Inhalte von bestimmten Datenbanktabellen
zu archivieren. Das ist aus Grnden der Perfor-
mance ntig: Tte man dies nicht, verlngerten sich nach und nach die Antwortzeiten des
Frontends. Bei einer groen Anzahl von Agenten, lassen sich die einzelnen OpensmartBackend-Komponenten auch auf verschiedene
Rechner verteilen.
Agent installieren
Der Opensmart-Agent wird, hnlich wie der
Server, durch ein Installationsskript aufgespielt:
Listing 4: Agent-Konfiguration Fortsetzung

076
077
<CHECKNAME>fan</CHECKNAME>
116
<HTTPRQST>GET http://www.linux-magazin.de
HTTP/1.0</HTTPRQST>
</SCRIPT>
078 </SIMPLE>
117
<TEXT2CHECK>Linux New Media AG</TEXT2CHECK>
079
118
080 
119
<RUNIF_CUSTOM>ping -c 4 www.google.de</RUNIF_
CUSTOM>
081 <SOCKETS>
082 
120 </APP2CHECK>
083 <CHECK4SOCKET>
121 </WEBAPP>
084
<INTERFACE>0.0.0.0</INTERFACE>
122
085
<PORT>22</PORT>
123 
086
124 <SWAP>
087 </CHECK4SOCKET>
125 <TRESHOLD>
088 
126
<MAX>60</MAX>
089 <CHECK4SOCKET>
127
090
<INTERFACE>0.0.0.0</INTERFACE>
128 </TRESHOLD>
091
<PORT>3128</PORT>
129
092
130 <TRESHOLD>
093 </CHECK4SOCKET>
131
<MAX>90</MAX>
094 </SOCKETS>
132
095
133 </TRESHOLD>
096 <LOAD>
134 </SWAP>
097 
135
098 <LOAD2CHECK>
136 
099
<LOADINTERVALL>1</LOADINTERVALL>
137 <LXSWRAID>
100
<LOADALLOWED>6</LOADALLOWED>
138 
101
139 <DEVICE>
102 </LOAD2CHECK>
140
<NAME>md0</NAME>
103 
141
104 <LOAD2CHECK>
142 </DEVICE>
105
<LOADINTERVALL>15</LOADINTERVALL>
143 
106
<LOADALLOWED>8</LOADALLOWED>
144 <DEVICE>
107
145
<NAME>md1</NAME>
108 </LOAD2CHECK>
146
109 </LOAD>a
147 </DEVICE>
110
148 </LXSWRAID>
111 <WEBAPP>
149
112 <APP2CHECK>
150 
114
<HOST>192.168.1.1</HOST>
152
115
<PORT>3128</PORT>
153
</OSAGENT>
Projekte
Apache-Webserver. Eine vollstndige Tag-Referenz fr den Agenten ist unter [2] zu finden.
In unserem Beispiel wird das Betriebssystem
(hier Debian Sarge) sowie die Applikation Squid
[3] berwacht. Aus der Liste der Built-In-Checks
[4] werden dafr die folgenden ausgewhlt:
nuptime: Hat der Proxyserver unerlaubterweise gebootet (Listing 4, Zeile 67-71)?
ndisk: Filesysteme ab einem Fllgrad von
85 Prozent werden aufgrund der Konfiguration mit dem Status WARNING dargestellt,
ab 90 Prozent wird ein ERROR gemeldet
(Zeile 18-39). Wichtig: Wird ein Filesystem
wie etwa Ext3 verwendet, so ist zu bercksichtigen, dass meistens die Option Reserved-Block-Count nicht auf Null steht und
sich somit die Ausgabe von df von der
Rechnung Gesamtkapazitt - Benutzer-Speicher unterscheidet.
nproc: Elementare Betriebssystem-Prozesse
sowie der Squid-Prozess werden berwacht
(Zeile 42-62).
nlogs: Regulre Ausdrcke filtern Systemund Squid-Logfiles auf Fehler.
nload: Steigt der Load-Average des Systems,
kann unter Umstnden eine Beeintrchtigung
des Dienstes die Folge sein ( Zeile 96-109).
nlxswraid: Dieser Check signalisiert md-
export OSMART_HOME=$HOME /usr/bin/

perl ./source/agent/install_agent $OSMART_
HOME.
Es ist darauf zu achten, dass dieses Kommando
mit den voll qualifizierten Angaben zum PerlInterpeter aufgerufen wird, da alle CheckSkripte diesen Interpreter in ihre Hash-BangZeile bernehmen. Gestartet wird der Agent
durch den Aufruf von $OSMART_HOME/bin/
osagent. Im Moment ist dies jedoch noch nicht
sinnvoll, da vorher eine Konfigurationsdatei zu
erstellen ist. Spter wird der Agent durch einen
Crontab-Eintrag alle 5 Minuten aufgerufen.
Konfiguration des Agenten

Im Gegensatz zur Installation erfordert die Erstellung und Pflege der Konfigurationsdatei
($OSMART_HOME/etc/osagent.conf.xml)
fr den Agenten mehr Aufwand. In unserem
Beispiel wird die Datei zuerst auf dem Config-Server platziert. Listing 4 beschreibt unter anderem den globalen Konfigurationsteil
des Agents (Zeile 4-14), in dem die IP-Adresse
192.168.1.1 den Opensmart-Server darstellt.
Hier knnte anstatt des Protokolls HTTP auch
HTTPS oder eine Authentifizierung des Clients
via Basic-Auth konfiguriert werden. Voraussetzung dafr ist ein entsprechend konfigurierter
Listing 5: Logfiles filtern

01
<OSAGENT>
21
<REGEX>session.*opened.*for.*user</REGEX>
02
[ .. ]
22
<REGEX>last message repeated \d+ times</
03 <LOGS>
REGEX>
04 
23
05 <LOGFILE>
24
06
25
<LOGFILENAME>/var/log/messages</LOGFILENAME>
07
08
09
26

10
11
12
13
<AGE>
<MAXAGE>300</MAXAGE>
</AGE>

16
17
18
19
20


<LOGFILTER>
29
<PRIORITY>200</PRIORITY>
30
31
32
<REGEX>.*</REGEX>
</LOGFILTER
33 </LOGFILE>
34
14
15
[ .. ]
</LOGFILTER>
<LOGFILTER>
<PRIORITY>100</PRIORITY>
<ERRORLEVEL>NORMAL</ERRORLEVEL>
<REGEX>syslogd.*restart</REGEX>
<REGEX>session.*closed.*for.*user</REGEX>
35 
37 [ .. ]
38 </LOGS>
39 [ .. ]
40
</OSAGENT>
Projekte
Devices im Zustand degraded, nicht selten

aufgrund eines Plattenausfalls (Zeile 137148).
nsockets: berwachung von Sockets im Status LISTEN (Port 22/ssh, Port 3128/squid).
Ein Beispiel ist in Zeile 81-94 zu sehen.
nswap: Prft anhand von Schwellwerten
(hnlich wie Disk) den Fllgrad des SwapSpeichers (Zeile 124-134).
nwebapp: Sendet eine HTTP-Anfrage an
die Adresse www.linux-magazin.de und wertet die Rckgabe durch regulre Ausdrcke
(<STRING2CHECK>) aus (Zeile 111-121).
Conditional-Tags
Um Checks nur unter bestimmten Bedingungen
ablaufen zu lassen, stehen so genannte RUNIFTags (conditional checks) zur Verfgung, die
zusammen mit jedem anderen Test verwendbar
sind. Sie bewirken, dass der Agent Checks nur
in bestimmten Zeitfenstern startet (RUNIF_
TIME), nur dann ausfhrt, wenn ein definiertes
Verzeichnis existiert (RUNIF_DIR), eine bestimmte Zeitspanne seit der letzten Ausfhrung
verstrichen ist (RUNIF_INTERVAL) oder ein
benutzerdefinierter Befehl den Returncode 0
liefert (RUNIF_CUSTOM). Diese Konditionen
sind in vielen Fllen sehr ntzlich, zum Beispiel:
nRUNIF_TIME: Eine Datenbank wird in
der Zeit zwischen 02:00 und 03:00 Uhr morgens fr ein Offline-Backup gestoppt. Ansonsten soll der Datenbankprozess allerdings
berwacht werden. Dieses Zeitfenster wird in
einer Cron-hnlichen Syntax im RUNIFTag verpackt: <RUNIF_TIME>* 03-02 * *
*</RUNIF_TIME>
nRUNIF_DIR: Ein Heartbeat-Cluster (Aktiv/Passiv) arbeitet mit Shared Storage, der
immer vom aktiven Knoten gemountet wird.
Nur auf diesem Knoten luft dann auch der
Applikations-Prozess mysql-safe. Mit Hilfe
einer RUNIF_DIR-Bedingung (zum Beispiel <RUNIF_DIR>/mnt/san/lost+found
</RUNIF_DIR>) kann nun der Agent feststellen, ob sein Knoten der aktive ist und ob
er also hier auch nach dem Applikations-Prozess schauen muss.
nRUNIF_CUSTOM: Um die Funktion unseres Proxyservers zu testen, wird ein HTTPRequest an www.linux-magazin.de gesendet.
Liefert dieser Request nicht das gewnschte
Ergebnis (nmlich die HTML-Seite des Linux-Magazins), so kme als Ursache entwe-
Tipp zum Editieren der Konfigurationsfiles

Groe Erleichterung beim Umgang mit XMLDateien schafft das Tool xmllint [6]. In vielen
Distributionen ist dieser XML-Parser bereits als
Paket enthalten. Ein Aufruf von xmllint -noout
osagent.conf.xml vermittelt sofort eine bersicht ber syntaktische Fehler. Auerdem mssen Umlaute in der Konfigurations-Datei XMLgem maskiert werden, da sonst der Parser
des Agents dies als Fehler darstellt.
der ein nicht funktionsfhiger Squid oder

eine ausgefallene Internetverbindung infrage.
Ein Kommando im RUNIF_CUSTOM-Tag
wie ping -c 4 www.google.de kann die Fallunterscheidung treffen. Wird eine RUNIFBedingung fr einen Check verwendet und
trifft sie nicht zu, so wechselt im Frontend der
Status von ACTIVE auf INACTIVE.
Selbstheilung
Wie die RUNIF-Tags, ist auch das Tag FIXCMD in allen Konfigurationsbereichen verwendbar. Jeder Built-In-Check kann so versuchen, eine Fehlerbehebung zu starten, sobald
das Check-Ergebnis ungleich NORMAL ist.
Listing 4 Zeile 48 zeigt ein FIXCMD-Tag fr
den Proc-Check. Luft der Prozess Squid nicht
mehr, so wird versucht, diesen durch ein Kommando (FIXCMD) wieder zu starten. In unserem Beispiel wre dies der Befehl sudo /etc/init.
d/squid restart.
Logfiles durchstbern
Eines der hilfreichsten Tools aus Opensmarts
Werkzeugkiste ist der Check LOGS. Er ermglicht es, Logfiles zeilen- oder blockweise
auf das Vorhandensein oder Fehlen bestimmter
Muster zu durchsuchen. Listing 5 beschreibt das
LOGS-Element anhand des Squid-Proxyserver-Beispiels. Zum einen wird das System-Logfile /var/log/messages geprft, zum anderen
/var/log/squid/cache.log, in dem alle Squidrelevanten Meldungen stehen.
Doch zunchst zum LOGFILE-Element von
/var/log/messages (Zeile 5-33). Unterhalb
dieses Elements sind zwei Logfilter-Klassen definiert. Alle Eintrge, auf die Filter der Klasse 1
nicht zutreffen (Zeile 16-24), werden von Klasse
2 erfasst (Zeile 28-32). Dabei wird die Reihen-
Projekte
folge der Verarbeitung der Logfilter-Elemente

durch die Prioritt beeinflusst: Eine Logmeldung (zum Beispiel eine Syslog-Zeile) wird zuerst gegen die Logfilter-Klasse mit der geringsten Prioritt geprft, anschlieend gegen die mit
der nchsthheren Prioritt und so weiter. Dabei knnen so viele Logfilter-Elemente wie ntig
definiert werden.
Innerhalb des LOGFILTER-Elements werden
mit den REGEX-Tags die regulren Ausdrcke im Perl-Stil formuliert, die darber entscheiden, ob die Logzeile den Filter passiert. Eine Zusammenfassung von gngigen Perl-Regex-Ausdrcken ist unter [5] zu finden. Die Unterteilung
der REGEX-Ausdrcke in mehrere LOGFILTER-Klassen hat den Vorteil, dass eine Logausgabe A als NORMAL gilt, whrend die Logausgabe Bals WARNING interpretiert wird
und eine Logausgabe C als FATAL.
Eine weitere Funktion von LOGS bietet die
MAXAGE-Klasse (Zeile 10-13): Ist der letzte
schreibende Zugriff auf das berwachte Logfile lter als x Minuten, so wird ein Fehlerstatus
gesetzt (Zeile 12) denn wozu nutzte das beste
Logfile-Monitoring, wenn der Syslog-Daemon

seine Arbeit eingestellt hat? Logzeilen, die einen Status ungleich NORMAL ergeben, leitet
der Agent zum einen an den Server weiter, zum
anderen legt er sie in der Datei $OSMART_
HOME/var/logfile.error ab. Wird dieses File
geleert oder auch gelscht, findet der Fehler in
den folgenden Lufen des Agenten keine Beachtung mehr.
Logformate
Der LOGS-Check kann mit einzelnen Logzeilen oder auch Logblcken umgehen. Eine Syslog-Ausgabe kann mit dem LOGTYPE NORMAL (default) analysiert werden, Spezial-Logformate die beispielsweise IBMs DB2 oder auch
Websphere MQ verwenden, werden mit einem
LOGTYPE UDB beziehungsweise MQS geprft.
Eigene Checks einbinden

Beim Monitoring ergibt sich oft die Notwendigkeit, speziell auf eine Applikation, ein Gert
oder auch auf einen Prozess abgestimmte, eigene
Listing 6: chckfan
01
#!/bin/bash
18 echo "FATAL"
02
19 echo
03
# Script, um alle Luefter von HP-Proliant
20 echo "/proc/cpqfan Status-File ist nicht
Hardware zu ueberwachen
vorhanden."
04
# Wenn ein oder mehrere Luefter nicht den Status
"Nominal"
22
fi
05
# haben, so wird der ERRORLEVEL "ERROR"
23
ausgegeben
24
# /proc/cpqfan auslesen
06
07
# Wichtig: Alle cpq* Module muessen geladen sein
08
09
# ein "normaler" Output von "cat /proc/cpqfan"
ist:
10
#ID
TYPE
LOCATION
Low
12
# 2
Low
13
# 3
Low
14
# 4
Low
Var. Speed
(
Processor Zone
Nominal
Yes
I/O Zone
Nominal
Yes
Processor Zone
Nominal
Yes
Pwr. Supply Bay Nominal
Yes
( 15)
Var. Speed
(
8)
Var. Speed
( 20)
"LOCATION" \
26
"Nominal"
| grep -v
\
| wc -l`
28
8)
Var. Speed
25
export failed_devices=`cat /proc/cpqfan | grep -v
27
STATUS
REDUNDANT FAN SPEED

11
# 1
21 echo "Sind alle Module geladen?"
29
if [ $failed_devices -ge 1 ]; then
30 echo "ERROR"
31 echo
32 echo "$failed_devices Luefter meldet ein Status
<> Nominal:"
33 cat /proc/cpqfan
34
else
35 echo "NORMAL"
15
36 echo
16
# pruefen, ob /proc/cpqfan vorhanden ist:
37 cat /proc/cpqfan
17
if [ ! -e /proc/cpqfan ]; then
38
fi
Projekte
Checks zu implementieren. Opensmart bewerkstelligt dies mit dem so genannten SIMPLEAdapter. Dies ist ein mitgeliefertes kleines Programm, das ein beliebiges eigenes Check-Skript
ausfhrt.
Einzige Bedingung fr dieses Skript: Die Fehlerklasse (ERRORLEVEL) muss in der ersten Zeile der Ausgabe (STDOUT) hinterlegt
sein. Die restliche Ausgabe wird nicht durch den
SIMPLE-Adapter interpretiert, sondern nur
als Detail an den Opensmart-Server weitergegeben. Listing 4, Zeile 74-77 zeigt die Einbindung
des Shell-Skripts checkfan (unter Listing 6 zu
finden). ber den SIMPLE-Adapter lassen
sich auerdem auch Nagios-Plugins einbinden.
Dies wird ber das dafr vorgesehene CHECKTYPE-Tag konfiguriert.
Erster Test der Installation

Beinhaltet die osagent.conf.xml korrektes
XML, so steht einem ersten Aufruf des Agenten nichts im Wege (Abbildung 4). Sollten beim
Ausfhren Fehler auftreten oder die Check-Ergebnisse nicht korrekt an den Server bermittelt werden, so kann $OSMART_ROOT/logs/
opensmart.log fr eine Fehlerdiagnose hinzugezogen werden. Fr Debug-Zwecke kann
der Loglevel des Agenten unter $OSMART_
ROOT/lib/Opensmart/debugmod.pm gendert werden.
Fazit
Opensmart stellt ein breites Spektrum an Werkzeugen und eingebauten Checks zur Verfgung.
Sie eignen sich unter anderem besonders dafr, Datenbanken wie Oracle, DB2 oder auch
MySQL zu berwachen. Auch verbreitete Middleware wie Websphere, Websphere MQ, Tomcat,
Jboss oder ein Webserver lsst sich mhelos mit
Opensmart beobachten. Built-In-Checks fr die
verschiedensten Unix-Derivate sind ebenfalls
mit an Bord.
Die Konfiguration der Agenten der zeitaufwndigste Teil bei der Implementierung einer
Monitoring-Lsung bleibt dem Admin aber
nach wie vor nicht erspart. Untersttzt wird er
dabei durch Monitoring Guides, die in der Benutzer-Dokumentation von Opensmart [7]
enthalten sind. Sie erleichtern merklich die korrekte Konfiguration, was sich wiederum durch
automatische Fehlerbehebung, vereinfachte Diagnosen und letztlich durch hhere Verfgbarkeit auszahlt.
Abbildung 4: Manueller Start des OpensmartAgenten (osagent).
Mit dem automaischen Deployment der Agenten und der zentralen Konfigurationsverwaltung
verfgt Opensmart ber zwei Features, die selbst
wesentlich umfangreichere Lsungen nicht immer mitbringen.
Bei allem bleibt Opensnart schlank und handlich und empfiehlt sich daher besonders auch
dort, wo wesentlich komplexere Software, die
entsprechened mehr Verwaltungsaufwand bentigte, ungerechtfertigt wre. (jcb)
nnn
Infos
[1] Opensmart-Homepage:
[http://opensmart.sourceforge.net]
[2] Tags zur Konfiguration des Agenten:
[http://opensmart.sourceforge.net/
docs/documentation/userguide/
osagentxmlcommon.html]
[3] Squid-Homepage:
[http://www.squid-cache.org]
[4] bersicht Built-In-Checks:
[http://opensmart.sourceforge.net/docs/
documentation/userguide/overview_checks.
html]
[5] Perl Regular-Expressions Howto:
[http://www.comp.leeds.ac.uk/Perl/matching.
html]
[6] xmllint-Homepage: [http://xmlsoft.org]
[7] Opensmart-Userguide:
[http://opensmart.sourceforge.net/docs/
documentation/userguide/]
10
Open NMS
Die meisten Netzwerkmanagement-Lsungen starteten ihre Karriere als Hacks dazu geschrieben,
eine kleine berwachungsaufgabe einfach zu lsen.
Mit der Zeit und anderen Anforderungen wuchsen
und generalisierten sich die Pakete dann. Nicht so
Open NMS. Charly Khnast
Projekte
Open NMS grast damit die mglichen 254 Nodes zwischen 10.50.5.1 und 10.50.5.254 regelmig ab. Bekommt es auf einem Interface eine
Antwort, unterzieht die Software dieses Interface
einem Portscan. Die gefundenen Dienste landen
gleich mit in der berwachung, ebenso wie alle
Informationen, die sich eventuell per SNMP
beziehen lassen. Damit das Datensammeln per
SNMP funktioniert, muss der Admin die dazugehrigen SNMP-Communities einrichten. Das
passiert in einer anderen Konfigurationsdatei,
der snmp-config.xml. Sie sieht beispielsweise
so aus:
<snmp-config retry="3" timeout="800"
read-community="public"
write-community="private">
<snmp-config>
Abbildung 1: Besonders einfach lassen sich

neue Pollings per Webinterface anlegen.
Open NMS [1] ist angenehm anders: Seine Entwickler haben es von Anfang an mit dem Ziel
entwickelt, umfangreiche Netze im Blick halten
zu knnen. In der Tat arbeitet das Paket berdurchschnittlich hufig in sehr groen Installationen, wie bei Hostern oder Internetprovidern.
Open NMS ist Open Source, in Java geschrieben
und auf vielen Linux-Distributionen, Solaris 8
und 9 sowie Mac OS X lauffhig.
Um mglichst effizient zu sein, konzentriert sich
Open NMS auf drei Kernbereiche: die Ausfallberwachung von Systemen und Diensten, das
Datensammeln via SNMP und das Alarmierungsmanagement. Open NMS bringt ein Web
interface mit, ber das der Admin die hufigsten
Konfigurationsarbeiten erledigen kann, jedoch
bei weitem nicht alle. Fr fortgeschrittene Funktionen oder das Feintuning gibt es eine Reihe
von XML-Konfigurationsdateien. Eine davon
regelt das Auto-Discovery.
Auto-Discovery konfigurieren
Nicht immer kann oder will der Admin jede
einzelne zu berwachende Komponente eigenhndig einpflegen. Fr diesen Fall gibt er der
Auto-Discovery-Funktionen einen Netzbereich
vor, innerhalb dessen Open NMS vorhandene
Nodes selbst findet und automatisch in die
berwachung einbindet. Die zustndige Konfigurationsdatei heit discovery-configuration.
xml und sieht der aus Listing 1 hnlich.
Sind fr einen bestimmten Netzbereich oder

einzelne Hosts eigene Einstellungen notwendig,
so lsst sich ein Definitionsblock einfgen, der
die Defaults in einem bestimmten Bereich auer
Kraft setzt:
<definition version="v3">
<specific>10.50.5.200</specific>
</definition>
Dies zwingt Open NMS, den Host 10.50.5.200

per SNMP V3 abzufragen.
Polling als Normalfall

Die Dienste, die Open NMS auf den einzelnen Nodes gefunden hat, unterzieht dessen so
genannter Poller zyklisch einer Prfung. Die
Parameter der Checks definiert die Datei poller-configuration.xml. Der Abschnitt, der fr
den Funktionstest der HTTP-Server zustndig
ist, sieht wie Listing 2 aus. Das dort verankerte
Polling-Intervall misst in Millisekunden, der
Listing 1: discovery-configuration.xml
01
<discovery-configuration threads="1" packets-per-second="1"
02
initial-sleep-time="300000" restart-sleep-time=
"86400000"
03
retries="3" timeout="800">
04
05
<include-range retries="2" timeout="3000">
06
<begin>10.50.5.1</begin>
07
08
<end>10.50.5.254</end>
</include-range>
09
</discovery-configuration>
Projekte
Wert 300000 im Listing entspricht also genau

fnf Minuten.
Die Prfung lsst sich weiter verfeinern. Ist etwa
ein Webangebot zu testen, das per Name-based
Virtual Hosting gemeinsam mit weiteren Angeboten auf einem Webserver untergebracht liegt,
akzeptiert Open NMS auch dessen Namen:
<parameter key="host-name" value=U
"kuehnast.com"/>
In Open NMS sind 17 Dienste per se definiert,

andere lassen sich auf einfache Weise hinzufgen. Um beispielsweise zustzlich den IRC-Port
6667 zu berwachen, gengen die Zeilen aus
Listing 3. Wer sich bei den Parametern fr das
Polling mit den Defaults zufrieden gibt, darf
neue Dienste wie in Abbildung 1 ber das Web
interface eintragen.
Natrlich ist es auch mglich, eigene Skripte an
die Polling-Engine zu bergeben, um auf spezifische Bedrfnisse einzugehen. Beispiele dafr
finden sich im Open-NMS-Wiki, zum Beispiel
unter [3]. Auch remote installierte Nagios- oder
Netsaint-Daemons vermag Open NMS abzufragen. Jedoch ist diese Funktion noch recht frisch
und nicht gut dokumentiert. Wie in Abbildung
2 zu sehen, liefert das Webinterface auf seiner
Startseite zugleich eine bersicht ber den aktuellen Status der berwachten Nodes.
Geplante Wartungsfenster
In der Poller-Datei poller-configuration.xml
findet sich serienmig ein Verweis auf den
Wartungskalender:
<outage-calendar xmlns="">zzz fromU
poll-outages.xml zzz</outage-calendar>
Dort kann der Administrator einzelne oder wiederkehrende Termine definieren, zu denen ein
Listing 2: poller-configuration.xml
01
<service name="HTTP" interval="300000" user-defined="false"
status="on">
02
<parameter key="retry" value="1"/>
03
<parameter key="timeout" value="3000"/>
04
<parameter key="port" value="80"/>
05
<parameter key="url" value="/"/>
06
<parameter key="rrd-repository" value="/opt/OpenNMS/
share/rrd/response"/>
07
<parameter key="ds-name" value="http"/>
08
</service>
Server oder Dienste wegen Wartungsarbeiten,

Reparaturen oder Upgrades nicht zur Verfgung stehen. Ein Beispiel: Im Einsatz sind zwei
SMTP-Server. Der erste geht jeden Freitag ab 10
Uhr vormittags fr eine halbe Stunde in Wartung, der zweite ab 11 Uhr. Damit Open NMS
whrend dieser Zeiten die beiden von der Alarmierung verschont, definiert poll-outages.xml
aus Listing 4 diese Auszeiten.
Bei einzelnen, nicht periodisch wiederkehrenden Downtimes erwartet die poll-outages.xml
dagegen ein genaues Datum:
<outage name="IRC Server Maintenance"U
type="specific">
<time begins="15-Mar-2007 15:00:00"U
ends="15-Mar-2007 16:20:00"/>
<interface address="10.50.5.144"/>
</outage>
Die Downtimes handhaben

Open NMS pollt also per Default die zu prfenden Dienste alle fnf Minuten. Wrde das System das Schema stur durchhalten, stnde jeder
Ausfall mit mindestens fnf Minuten Downtime in den Bchern, selbst wenn der tatschliche Ausfall nur 30 Sekunden gedauert hat. Um
das zu vermeiden, gibt es das adaptive Polling:
Findet Open NMS einen leblosen Dienst, so
verkrzt es zunchst das Polling-Intervall. Es
schaut statt alle fnf Minuten alle 30 Sekunden
nach, ob sich der Service wieder erholt hat.
Der verkrzte Polling-Zyklus luft in Summe
fnf Minuten lang. Ist der Dienst nach dieser
Systemvoraussetzungen
Fr die Tests anlsslich dieses Beitrags kam
Open NMS 1.3.2 aus dem Subversion-Respository der Projektseite zum Einsatz, um mit einer mglichst neuen Version zu arbeiten. Da
Open NMS zum berwiegenden Teil in Java
geschrieben ist, sind Tomcat 5.5 und Suns JDK
in der Version 5.0 mit im Boot. Als Datenbank
diente PostgreSQL, sptere Versionen von
Open NMS werden wohl auch andere Datenbanksysteme untersttzen.
Als Testsystem diente ein Debian von der bevorstehenden Version Etch. Unter [2] gibt es
eine brauchbare Installationsanleitung fr
Open NMS auf dieser Plattform. Sie ist sicherheitstechnisch etwas fragwrdig, fr einen
Testbetrieb aber genau das Richtige.
Projekte
Zeit noch immer down, fhrt Open NMS das

Polling-Intervall fr die kommenden zwlf
Stunden auf die ursprnglichen fnf Minuten
zurck. Danach steigt das Intervall auf zehn
Minuten. Sollte der Dienst nach fnf Tagen weiterhin nicht antworten, stellt ihn Open NMS auf
forced unmanaged, das heit, das System pollt
ihn berhaupt nicht mehr, bis dass ein Admin
manuell eingreift.
Alarmierungsmanagement
Stellt nun ein Server drei Dienste bereit und fllt
er pltzlich vollstndig aus, wre es unschn,
wenn Open NMS vier separate Alarme sendet
einen pro Dienst und einen fr den Node. Besser wre, wenn die Software lediglich node
down senden und auf die Alarmierung der einzelnen ausgefallenen Dienste verzichten wrde.
Der Admin konfiguriert dieses Verhalten, indem
er in der Poller-Konfiguration die Zeile
<node-outage status="on">
einfgt. Ebenso kann er Path-Outages definieren: Fllt beispielsweise ein Switch aus, so sind
in der Regel alle daran angeschlossenen Nodes
nicht mehr verfgbar. Solche Beziehungen lassen sich in Open NMS abbilden, sodass es beim
Ausfall einer zentralen Komponente nur deren
Malheur anzeigt, nicht aber der Ausfall aller davon abhngigen Nodes.
Auf hohem Niveau

Das Projekt Open NMS sieht sich selbst auf Augenhhe mit kommerziellen Werkzeugen wie
IBM Tivoli oder HP Openview. Im Prinzip hlt
die Software dieses Versprechen, doch es gehrt
ein engagierter Administrator dazu, der sich
nicht scheut, viel Handarbeit in die Konfiguration zu stecken.
Alternativ bietet die Open NMS Group weniger
kenntnisreichen Anwendern kommerziellen
Support, individuelle Entwicklungsleistungen
und eine komplette Fernadministration an. Dafr fallen allerdings Kosten an, die ebenfalls in
Augenhhe mit den kommerziellen Mitbewerbern rangieren [4]. (jkl)
nnn
Abbildung 2: Das Webinterface informiert ber den Status der berwachten Nodes. Hier scheint der Datenbankserver pflegebedrftig zu sein.
[3] Skripte an die Polling-Engine bergeben: [http://
opennms.org/index.php/CheckWebSite.pl]
[4] Preisliste fr Open-NMS-Dienstleistungen: [http://
www.opennms.com/site/index.php?option=
com_content&task=view&id=13&Itemid=26]
Der Autor
Charly Khnast administriert Unix-Betriebssysteme
im Rechenzentrum Niederrhein in Moers. Zu seinen
Aufgaben gehren die Sicherheit und Verfgbar
keit der Firewalls und der DMZ (demilitarisierte
Zone). Er schreibt zudem jeden Monat im LinuxMagazin eine Admin-Kolumne, welche die gleichnamige Rubrik einleitet.
Listing 3: IRC-Port berwachen

01
<service name="IRC" interval="300000" user-defined="true"
status="on">
02
<parameter key="timeout" value="3000"/>
03
<parameter key="banner" value="*"/>
04
<parameter key="retry" value="3"/>
05
<parameter key="port" value="6667"/>
06
</service>
Listing 4: poll-outages.xml
01
<outage name="Mailserver1 Maintenance" type="weekly">
02
<time day="friday" begins="10:00:00" ends="10:30:00"/>
03
Infos
04
</outage>
[1] Open NMS: [http://opennms.org]

[2] Installation von Open NMS auf Debian Etch:
[http://opennms.org/index.php/Debian_4_tomcat5.5_jdk_1.5_install_log]
06
<time day="friday" begins="11:00:00" ends="11:30:00"/>
07
05
<outage name="Mailserver2 Maintenance" type="weekly">
08
</outage>
Langzeitberwachung mit
Rrdtool und Cacti

Jeder Systemadministrator kennt die Situation: Auf
den Servern steigt die Last, Datenverkehr verstopft
die Netzwerkkarten. Da auf den ersten Blick keine
Ursache zu finden ist, hilft nur ein Blick in die Vergangenheit: Hufig lassen sich Probleme erst dann
isolieren und verfolgen. Marc Grimme
Praxis
Wenn ein Server ins Stocken gert, gehen die

Meinungen, was die Ursache ist, schnell auseinander. Oft verwirren die unterschiedlichen Ansichten, die der Systemadministrator von Kollegen hrt oder im Internet findet.
Wertvolle Hinweise geben dagegen Werkzeuge
zur Langzeitberwachung, die Daten ber lngere Zeitrume aufzeichnen und sie grafisch
aufbereiten. Fr diese berwachungs- und Archivierungsaufgaben kommt im Open-SourceBereich meist die umfangreiche Softwarebibliothek Rrdtool zum Einsatz. Als Webfrontend
automatisiert Cacti die Messungen von Rrdtool
und stellt eine komfortable und intuitive Oberflche fr die Benutzer zur Verfgung.
Round Robin Databases

RRD ist ein Akronym fr Round Robin Database und steht fr ein Konzept, das ber einen
langen Zeitraum gemessene Sensordaten effizient archiviert. Dabei gilt es, die Datenmenge
auf ein sinnvolles Ma zu reduzieren, ohne dass
wichtige Informationen verloren gehen: Es interessiert weniger, wie hoch die Temperatur im
Server-Gehuse im letzten Monat zu einer bestimmten Stunde war. Von Interesse ist vielmehr
die Durchschnitts- oder Maximaltemperatur im
Wochenverlauf. Bei der Temperatur von heute
sind dagegen krzere Zeitabschnitte relevant.
Hier setzt das Konzept der Round Robin Archive
an. Ein solches Archiv kann man sich wie ein
Zifferblatt vorstellen, dessen umlaufender Zeiger jeder Zahl zyklisch neue Messwerte zuweist.
Zu jeder vollen Stunde errechnet die Datenbank
Minimal-, Maximal- und Mittelwerte oder andere statistische Daten. Jeder dieser Werte wird
seinerseits in eine Zeitreihe eingeordnet, von
denen es bei Bedarf auch verschiedene Generationen geben kann.
Rrdtool, das hauptschlich von Tobias Oetiker
entwickelt wurde, archiviert Sensordaten in der
beschriebenen Weise. Es ist Bestandteil aller
groen Distributionen. Neben der Archivfunktion enthlt es auch Programmierschnittstellen
fr die Visualisierung der gespeicherten Daten.
Ausfhrliche Dokumentationen und weiterfhrende Informationen zur Programmierung von
Erweiterungen bietet [1].
Rrdtool
ein Name, der Typ, ein Intervall in Sekunden

(heartbeat), das den zeitlichen Abstand von
zwei Messwerten spezifiziert, sowie ein Minimum und ein Maximum.
Gltige Werte fr den Typ sind COUNTER,
GAUGE, DERIVE und ABSOLUTE.
Counter sind Zhlerwerte, die kontinuierlich
ansteigen. Ein Counter zhlt zum Beispiel die
ber einen Switchport oder eine Netzwerkkarte
bertragenen Pakete. Im Gegensatz dazu beschreiben Gauges aktuelle Statuswerte wie Temperaturen. Derive beschreibt einen Counter, der
auch abnehmende Werte darstellen kann. Vom
Typ Absolute sind Counter, die nur die Unterschiede zwischen den Werten, die Deltas, beinhalten. Der lteste gespeicherte Wert ist dabei
unbekannt, da dieser automatisch zurckgesetzt
wird die Deltas sind absolut.
Der maximale zeitliche Abstand zwischen zwei
Messwerten heit Heartbeat. Wird diese Zeit bis
zum Eintreffen der Daten berschritten, erhlt
der aktuelle Eintrag den Wert UNKNOWN.
Je nach Typ hat die Wahl der Maximum- und
Minimumwerte unterschiedliche Auswirkungen. Treten zum Beispiel bei internen berlufen fehlerhafte, unsinnige Werte auf, wrden
dadurch die Grafiken mit herausragenden Peaks
unleserlich. Voreingestellte Maximalwerte verhindern dies, sind aber natrlich nur mglich,
wenn die Dimension der erwarteten Werte bekannt ist.
Messzyklen
Wenn klar ist, welche Datentypen sich fr die
Messung eignen, ist es an der Zeit, die Intervalle
fr die Aufzeichnung festzulegen. Die Zahl der
Messwerte eines Zyklus (die Schrittweite oder
Steps) und die Zahl der Generationen bestimmen die Struktur der Round Robin Archive
(RRAs). Eine Konsolidierungsfunktion errechnet aus den archivierten Daten Minimal- und
Maximalwerte fr den nchsten Zyklus.
E
Listing 1: Erstellen einer RRD

01
rrdtool create filename [--start|-b start time]
[--step|-s step]
02
DS:ds-name:GAUGE | COUNTER | DERIVE |
ABSOLUTE:heartbeat:min:max
03
[[DS:ds-name:GAUGE | COUNTER | DERIVE |
Listing 1 zeigt die Syntax fr das Erstellen einer

Round Robin Database mit Rrdtool. DS im
Befehlsaufruf steht fr Datasource, darauf folgt
ABSOLUTE:heartbeat:min:max]...]
04 RRA:AVERAGE | MIN | MAX | LAST:xff:steps:rows
05
[[RRA:AVERAGE | MIN | MAX | LAST:xff:steps:rows]...]
Praxis
Auer Maximum, Minimum oder Durchschnitt

existieren noch weitere Funktionen zur Konsolidierung, auf die dieser Artikel jedoch nicht
eingeht, da sie nur in Spezialfllen zum Einsatz
kommen. Ein so genannter Xfiles-Faktor legt
das Verhltnis von gltigen und ungltigen
Messwerten fest, ab dem der konsolidierte Wert
fr den nchsten Round-Robin-Zyklus den Wert
UNKNOWN erhlt.
Messwerte fr die Datenbank

Ein einfaches Beispiel fr das Anlegen einer
Datenbank mit Rrdtool ist der create-Befehl,
mit dem Cacti implizit eine neue Round Robin Database fr die Lastwerte eines Servers
anlegt (Listing 2). Weitere Informationen zu
Cacti liefert die zweite Hlfte dieses Artikels. Zu
erkennen sind drei Datenquellen fr drei unterschiedliche Load-Werte (Parameter DS:)
und acht Round Robin Archive (RRA:). Alle
Load-Datasources sind gleich aufgebaut. Sie
sind vom Typ Gauge, haben einen Heartbeat
von 600 Sekunden und mssen im Bereich von
0 bis 500 liegen. Die RRAs liegen als Typ AVERAGE und MAX vor. Zwischen 600 und 797
Werte (letzter Parameter) werden erfasst und
zwischen 1 und 288 Werten zu einem Mitteloder Maximalwert (vorletzter Parameter) konsolidiert. Rrdtool speichert also 600 Stichproben
fr die letzten 2 Tage (50 Stunden), 700 Werte
fr die letzten 2 Wochen (15 Tage), 775 Werte
fr 2 Monate (65 Tage) und 797 Werte fr die
letzten 2 Jahre (797 Tage). Diese Zeitwerte ergeben sich aus der Formel timeperiod[seconds]=
step*rows*steps.
Listing 2: Beispiel fr rrdtool

create
01
rrdtool create \
02
localhost_load_1min_5.rrd \
03
--step 300
04
DS:load_1min:GAUGE:600:0:500 \
05
06
07
RRA:AVERAGE:0.5:1:600 \
08
09
10
11
RRA:MAX:0.5:1:600 \
12
RRA:MAX:0.5:6:700 \
13
RRA:MAX:0.5:24:775 \
14
RRA:MAX:0.5:288:797
Messwerte fr die Datenbank

Nach dem Anlegen fllt der Befehl rrdtool update die Datenbank mit Messwerten:
rrdtoolU
update N|timestamp:value[:value...]U
at-timestamp@value[:value...]U
[at-timestamp:value[:value...] ...]
Jeder update-Befehl akzeptiert mehrere Wertetupel. Der Zeitstempel lautet entweder N fr

den Zeitpunkt des Befehlsaufrufs, oder er gibt
die Zeit relativ dazu in Sekunden oder absolut
als Unix Time Stamp an.
Graphen aus Round Robin

Databases
Der Befehl rrdtool graph visualisiert die in der
RRD gespeicherten Daten. Dieser Abschnitt beschreibt nur die Optionen, die fr das Verstndnis von Cacti ntig sind. Eine detaillierte Anleitung liefert [1]. Der Befehlsaufruf gliedert sich
in mehrere Abschnitte:
rrdtool graph filename [option ...]U
[data definition ...]U
[data calculation ...]U
[variable definition ...]U
[graph element ...]U
[print element ...]
Der erste Parameter legt den Dateinamen der

Round Robin Database fest. Fehlt er, liest Rrdtool die Daten von der Kommandozeile ein.
Die Option --imgformat bestimmt das Dateiformat der ausgegebenen Grafik, --start und
--end den Aufzeichnungszeitraum, --heigth
und --width die Gre des Graphen in Pixel,
--lower-limit und --upper-limit die Skalierung der y-Achse.
Die Optionen --alt-autoscale-max beziehungsweise --alt-autoscale sorgen dafr, dass
Rrdtool den Achsenmastab automatisch so
whlt, dass alle Werte in die festgelegte Bildgre passen. Mit der Option --rigid hlt
Rrdtool bei eingeschalteter Autoskalierung die
angegebenen Grenzwerte dennoch ein. --logarithmic skaliert die y-Achse logarithmisch,
--units-exponent legt eine Zehnerpotenz
fr den Mastab fest. Wichtig ist es, dabei die
--base passend zur gemessenen Gre entweder auf 1000 oder 1024 zu setzen.
Der nchste Rrdtool-Parameter, die data definition, stellt die Messwerte aus der Datenbank
zur Verfgung. Jede Datendefinition ist durch
Praxis
Abbildung 1: Ein Beispiel fr einen mit Rrdtool erzeugten Graphen, der

sich aus dem Befehlsaufruf in Listing 3 ergibt.
den Bezeichner vname eindeutig zu kenzeichnen. Das folgende Listing zeigt die Syntax fr
den Zugriff auf die Datenbank:
<vname>=<rrdfile>:<ds-name>:U
<CF>[:step=<step>]U
[:start=<time>][:end=<time>]U
[:reduce=<CF>]
vname besteht aus dem Typ der Datenquelle

(DEF, CDEF oder VDEF), auf die nach
einem Doppelpunkt der Name der Datenquelle
folgt. DEF extrahiert Werte aus der Datenbank ohne rechnerischen Zwischenschritt,
CDEF und VDEF erlauben es, die Werte vor
der Visualisierung aufzubereiten. Die Manpages
zu rrdgraph und rrdgraph_data geben dazu
Auskunft. Weitere Informationen finden sich
auch unter [1].
Die Parameter vname, rrdfile und den Namen einer Datensource (vergleiche Befehlsaufruf beim Erstellen des Archivs) reichen fr eine
gltige Datendefinition aus. Ist keine Start- und
Endzeit angegeben, visualisiert Rrdtool die gesamte Aufzeichnung.
Layout der Graphen
GPRINT druckt aus Parametern im printf-Format Texte fr die Legende.

Ein an den Einsatz mit
Cacti ausgerichteter Funktionsaufruf, der einen Graphen fr die Loadwerte
zeichnet, knnte wie in
Listing 3 aussehen. Abbildung 1 zeigt den Graphen,
der sich aus dem Befehls
aufruf ergibt.
Cacti: Rrdtool automatisiert

Cacti erweitert Rrdtool um eine automatische
Aktualisierung und um ein Webfrontend. Cacti
ist vollstndig in PHP programmiert und hlt
alle Daten auer den Monitoring-Werten in einer MySQL-Datenbank vor. Die Software bettet
sich damit optimal in die bliche LAMP-Umgebung ein.
Cacti liegt den meisten Distributionen als Paket
bei und lsst sich daher ohne Probleme installieren. Meist legen die postinstall-Skripte einen
Listing 3: Graphen erzeugen mit Rrdtool

01
rrdtool graph - \
02
--imgformat=PNG \
03
--start=-86400 \
04
--end=-300 \
05
--title="Localhost - Load Average" \
06
--rigid \
07
--base=1000 \
08
--height=120 \
09
--width=500 \
10
--alt-autoscale-max \
11
--lower-limit=0 \
12
--units-exponent=0 \
Nach der Datenquelle in der data definition

ist noch die Art der Visualisierung festzulegen:
LINE erzeugt eine Linie, AREA zeichnet
darunter zustzlich einen gefllten Bereich.
Beide Zeichenfunktionen erwarten die gleichen
Argumente: den Namen der darzustellenden
Datendefinition, einen hexadezimalen Farbwert
und einen beschreibenden Text fr die Legende
der Grafik.
Der optionale Parameter STACK bewirkt,
dass Rrdtool den aktuellen Wert zum vorausgehenden addiert. Die Funktionen HRULE und
VRULE zeichnen gerade Linien mit Parametern fr Farbe und x- oder y-Wert.
13
--vertical-label="processes in the run queue" \
14
--slope-mode \
15
DEF:a="/var/www/cacti/rra/localhost_load_1min_5.rrd":load_
1min:AVERAGE \
16
DEF:b="/var/www/cacti/rra/localhost_load_1min_5.rrd":load_
5min:AVERAGE \
17
DEF:c="/var/www/cacti/rra/localhost_load_1min_5.rrd":load_
15min:AVERAGE \
18
AREA:a#EACC00:"1 Minute Average"
19
GPRINT:a:LAST:" Current\:%8.2lf\n"
20
LINE2:b#EA8F00:"5 Minute Average"
\
\
21
GPRINT:b:LAST:" Current\:%8.2lf\n"
22
LINE1:c#FF0000:"15 Minute Average"
23
GPRINT:c:LAST:"Current\:%8.2lf\n"
Praxis
der Datenbank in include/

config.php angepasst werden.
Diese Datei sollte nicht von auen lesbar sein.
In ltereren Versionen wies
Cacti einige kritische Sicherheitslcken auf, die jedoch in
aktuellen Fassungen bereinigt
sind. Die eingesetzte Cacti-Version sollte auf jedem Fall einem
Sicherheitsreview unterzogen
werden, wenn Cacti im Internet
erreichbar ist.
Ein erster Test

Nach dem Initialisieren der Datenbank ist Cacti bereit fr einen
Test. Die Konfigurationsdatei
Abbildung 2: Cacti bindet neue Gerte ber eine grafische Eingabemaske ein und erenthlt die URL fr die Cactizeugt nach Abschluss der Konfiguration automatisch den passenden Aufruf fr Rrdtool.
Startseite, in der Regel lautet sie
ber das Drop-down-Men Hosts Template whlt der Administrator eine Vorlage.
http://hostname/cacti. Nach der
erfolgreichen Authentifizierung
eigenen Benutzer fr Cacti an. Auerdem in- erscheint die Startseite mit den Bereichen constallieren sie die Programmdateien mit den pas- sole und graphs. Der console-Modus dient
senden Zugriffsrechten im Webroot und richten zur Konfiguration, die graphs-Ansicht zeigt
einen Cronjob ein, der die Daten alle drei Mi- die Daten der berwachten Gerte an.
nuten erfasst (Poller). Die Datenbank muss der ber den Link create devices trgt der AdmiAdministrator manuell einrichten (Listing 4). nistrator neue Gerte fr die berwachung ein.
Datenquellen im Netz werden hauptschlich mit Abbildung 2 zeigt die Werte fr einen ersten
SNMP eingebunden.
Linux-Server. Der folgende Screen im KonfiguDas Tool bringt bereits viele Vorlagen fr klassi- rationsdialog fr neue Gerte fragt ab, welche
sche berwachungsaufgaben mit: Ein Template Sensorwerte Cacti berwachen soll. Im nchsfr Netzwerk-Devices, die RMON-Mib (Remote ten Aufruf bercksichtigt der Poller die neuen
Network Monitoring Management Information Einstellungen. Nach zwei Aufrufen sind dann
Base) untersttzen, gehrt ebenso zum Lie- die ersten Daten sichtbar.
ferumfang wie Voreinstellungen fr Windows- Fr mehrere Maschinen des gleichen Typs erfolHosts. Im Home-Verzeichnis des Cacti-Benut- gen die weiteren Eintrge in die Gerteliste anazers bentigt Cacti noch die Grundstruktur log zum ersten Server. Zahlreiche Templates lasder Round Robin Database. Auerdem mssen sen sich hierfr nutzen oder unkompliziert neu
MySQL-Benutzer und -Passwort und der Name erstellen. Mehr Vorlagen gibt es auf der Webseite
des Cacti-Projektes und unter [4].
Listing 4: Datenbank fr Cacti

anlegen
01
# mysqladmin --user=root create cacti
02
# mysql --user=root mysql
03
mysql> GRANT ALL ON cacti.* TO
cactiuser@localhost IDENTIFIED BY
'somepassword';
04
mysql> flush privileges;
05
mysql> quit
06
# mysql -u cacti -p cacti < cacti.sql
Cacti in der Praxis

Fr das Verstndnis der fortgeschrittenen Funktionen von Cacti ist ein Blick auf die Architektur
des Monitoring-Werkzeugs hilfreich: Fr jedes
berwachte Device zeichnet Cacti eine beliebige
Anzahl von Graphen; jeder Graph kann seine
Daten aus mehreren Datenquellen beziehen.
Die Graphen sind dabei nicht zwangslufig an
bestimmte Gerte gebunden. Vorlagen bestimmen, welche Werte Cacti abfragt. Implizit ergibt
sich daraus der Aufbau der RRD und der Gra-
Praxis
phen. Hinter den meisten Einstellungen sind die entsprechenden Rrdtool-Parameter erkennbar. Cacti verwaltet die Vorlagen fr Devices, Graphen und
Datasources in einem eigenen
Abschnitt der Konsolenansicht.
Details dazu finden sich auf der
Webseite [2], die ergiebigste Anlaufstelle fr spezielle Fragen ist
das Cacti-Forum [3].
Apache und Cacti

Cacti enthlt im Lieferumfang
zwar keine Vorlagen fr Webserver, das Forum liefert jedoch Abbildung 3: Cacti bettet die mit Hilfe der Rrdtools erzeugten Diagramme in der Graphenzahlreiche Hilfestellungen fr Ansicht ein. Die Grafiken sind in Firefox und im Internet Explorer frei zoombar.
die Apache-berwachung.
Zunchst ist das Apache-Statusmodul zu aktivie- frontend von Cacti in der Console-Ansicht ber
ren und einzurichten. Meist ist es auskommen- Import Templates einbinden (Abbildung 4).
tiert in der Apache-Konfiguration vorhanden, Wenn alles gut geht, fhrt ein Aufruf des Polso dass der Administrator nur das Kommen- ling-Skripts zu einer Ausgabe wie in Listing 5.
tarzeichen zu entfernen braucht. Das folgende ber den Menpunkt Devices auf der Seite
Listing zeigt einen Auszug aus der Apache- Console kann der Administrator die Werte
Konfiguration, die die Statusabfrage von der IP fr eingebundene Server mit Hilfe der neuen
10.10.10.10 zulsst:
Vorlage anzeigen lassen.
<Location /server-status>
Enterprisefhigkeit
SetHandler server-status
Order deny,allow
Deny from all
Allow from 10.10.10.10
</Location>
Fr Setups, die nicht auf SNMP basieren, steht

im Cacti-Forum [4] ein Polling-Skript bereit,
das die Daten auf dem Server einliest.
Eine XML-Datei, die in Cacti passende Graphund Datasource-Templates erzeugt, findet sich
im selben Thread. Diese Datei lsst sich im Web-
Im tglichen Umgang zeigt Cacti viele Strken,

aber auch einige Schwchen: Viele Administrationsaufgaben werden mit etlichen Klicks und
Ladevorgngen der Seite im Webfrontend zum
Geduldspiel. Bei einigen Hundert berwachten
Gerten brauchen Vernderungen an der Baumstruktur der darzustellenden Graphen schnell
mehrere Stunden.
Wo Templates zum Einsatz kommen, spart Cacti
dagegen viel Zeit, da auch neue Vorlagen schnell
importiert werden knnen. Ein simples Kom-
Listing 5: Ausgabe des Polling-Skripts

01
-sh-3.00$ id
02
uid=102(cacti) gid=103(cacti) groups=103(cacti)
03
-sh-3.00$ /var/www/cacti/scripts/ws_apachestats.pl node03.mgmt
04
Use of uninitialized value in concatenation (.) or string at /var/www/cacti/scripts/ws_apachestats.pl
line 63.
05
Use of uninitialized value in concatenation (.) or string at /var/www/cacti/scripts/ws_apachestats.pl
line 65.
06
apache_total_hits: apache_total_kbytes: apache_busy_workers:1 apache_idle_workers:7 thread_O:248
threadC:0 threadD:0 threadG:0 threadI:0 threadK:0 threadL:0 threadR:0 threadS:0 threadW:1 thread_W:7
apache_cpuload:__W_____
07
....
Praxis
Abbildung 4: Fr den Austausch von Templates kennt Cacti ein eigenes XML-Dateiformat.
mandozeilen-Interface, ber das sich Ttigkeiten mit vielen Arbeitsschritten automatisieren

lassen, fehlt jedoch sehr.
One job, one tool und KIS (keep it simple)
gelten im Unix-Bereich als Grundprinzipien
fr die Softwareentwicklung. Rrdtool hlt sich
daran: Die Software ist nicht als vollstndiges
berwachungswerkzeug konzipiert, sondern
stellt lediglich eine Datenbank und eine API fr
die Visualisierung der gespeicherten Daten zur
Verfgung. Sie lsst sich daher leicht in andere
Programme integrieren.
Cacti dagegen ist nicht auf Integrierbarkeit angelegt: Es enthlt ein in sich abgeschlossenes Userinterface, das alle fr die Langzeitberwachung
ntigen Features zur Verfgung stellen mchte.
Problematisch daran ist, dass Langzeitberwachung selbst nur Teil eines greren Ganzen
ist: Weitere Hilfsmittel wie Nagios [6] oder BigBrother [7] sind unverzichtbare Bestandteile einer umfassenden Serverberwachung.
Dass es wnschenswert wre, diese zusammen
mit Cacti unter einer gemeinsamen Oberflche
zu vereinen (Abbildung 5), beweisen viele Anfragen. Zwar gibt es einige Bestrebungen, Cacti
in andere Oberflchen einzubinden, wegen der
fehlenden Trennung von GUI und Datacontrolling ist dann jedoch kein Upgrade von Cacti
mehr mglich.
Fazit
Cacti und Rrdtool sind die im Moment wohl
verbreitetsten Werkzeuge fr die Langzeitberwachung. Die grafische Oberflche von Cacti
erleichtert die Bedienung der leistungsfhigen
Bibliothek Rrdtool. Dass Cacti nicht alle Features von Rrdtool erfasst, ist als Kompromiss
akzeptabel: Die Weboberflche ist bersichtlich
und konsequent strukturiert.
Strend wirkt allerdings, dass manche Administrationsaufgaben wegen der vielen erforderlichen Schritte, die immer mit einem Reload der
Seite einhergehen, viel Zeit kosten.
Ein Kommandozeilen-Interface, um solche Vorgnge zu automatisieren, fehlt. Eine Einbindung
von Cacti in eine Kundenoberflche oder ein
berwachungswerkzeug, das neben der Langzeitberwachung noch andere Monitoring-Aspekte erfasst, ist wegen der fehlenden Trennung
von Oberflche und Datenhaltung nur unter
groem Aufwand mglich. (pkr)
nnn
Infos
[1] Rrdtool: [http://oss.oetiker.ch/rrdtool]
[2] Cacti: [http://www.cacti.net]
[3] Cacti-Foren: [http://forums.cacti.net]
[4] Templates: [http://www.debianhelp.co.uk/
cactitemplates.htm]
[5] Forum-Thread zum Apache-Monitoring:
[http://forums.cacti.net/about9861.html]
[6] Nagios: [http://www.nagios.org]
[7] BigBrother: [http://www.bb4.org/home1.html]
Der Autor
Abbildung 5: Cacti integriert in eine individuelle Administrationsoberflche hlt meistens nur bis zum nchsten Update.
Dipl.-Inform. Marc Grimme ist einer der Geschftsfhrer der Atix GmbH. Sein Ttigkeitsschwerpunkt
umfasst Storage- un d hochskalierbare Infrastrukturlsungen sowie Cluster auf Linux..
Erste Schritte mit

Nagios
Nagios ist sicher das verbreitetste Open-SourceMonitoring-System. Dabei ist es eigentlich gar
keine berwachungssoftware, sondern nur
das Grundgerst fr deren Eigenbau. Die damit
verbundene Komplexitt hat zwei Seiten: Profis
schtzen Nagios als mchtiges Werkzeug, doch
Anfngern scheint die Einstiegshrde womglich zu hoch. Das ndert dieser Workshop, der
schrittweise und verstndlich alle Nagios-Basics
erklrt. Julian Hein
Praxis
Alles, was es berwacht, egal ob Rechner, Router oder jede andere Ressource im Netz, nennt
Nagios einen Host. Um ber dessen Zustand
etwas sagen zu knnen, prft ihn die Software
regelmig, entweder lediglich auf Erreichbarkeit (Hostcheck) oder funktional. Die Funktionsprfung (Servicecheck) bezieht Dienste
unter der Adresse des Host ein oder untersucht
zum Beispiel die Inanspruchnahme von Ressourcen, etwa den Fllstand der Festplatte. Die
Ergebnisse vergleicht Nagios mit zwei festgelegten Warnschwellen und stellt so fest, ob sich der
Proband im Status OK, WARNING oder
CRITICAL befindet. Stellt sich dabei ein Problem heraus, lst das eine Benachrichtigung der
Admins aus, etwa via E-Mail oder SMS.
Die eigentlichen Checks fhrt Nagios dabei gar
nicht selbst aus, sondern bedient sich dafr externer Plugins, also kleiner, eigenstndiger Testprogramme. Ihnen bergibt der Admin ber
eine standardisierte Schnittstelle Parameter wie
die IP-Adresse des Ziel-Host oder Schwellwerte
fr die Statuslevel. Im Gegenzug melden sie ihr
Prfergebnis ebenso wohl formatiert zurck.
Der Vorteil dieses Konzeptes ist seine leichte Erweiterbarkeit, denn die ntigen Plugins lassen
sich in beinahe jeder Sprache selbst programmieren.
Installation vorbereiten
Die aktuelle, stabile Nagios-Version ist derzeit
2.7, und fr den produktiven Einsatz in kleinen
und mittleren Netzwerken ist das auch genau
die richtige. Lediglich fr die berwachung
eines sehr groen Netzes, also ab 300 oder 400
Hosts, kann sich auch schon jetzt ein Blick auf
die kommende Version 3.0 lohnen, denn sie bietet vor allem in greren Umgebungen deutliche
Performancevorteile und kann Probleme noch
schneller erkennen. (Ausfhrliches zur Zukunft
von Nagios in einem Beitrag seines Entwicklers
und Maintainers Ethan Galstad lesen Sie ebenfalls in dieser Ausgabe.)
Grundstzlich ist es unproblematisch, die Nagios-Pakete der eingesetzten Linux-Distribution
zu verwenden, solange sie im Vergleich zur aktuellen Version nicht zu weit hinterherhinken.
Fr eine erste interne Evaluierung reicht Nagios
ab Version 2.5 bereits vllig aus. Pakete fr Debian bekommt man beispielsweise unter [1], fr
Red Hat, Fedora oder Red Hat Enterprise direkt
auf [2] und fr Suse auf den bekannten FTPMirrors. Fr den produktiven Einsatz ist es aber
sicher besser, Nagios selbst zu kompilieren besonders, weil sich Sicherheitsupdates so schneller einspielen lassen.
Nagios bersetzen
Um Nagios selbst zu kompilieren, sollten auf
dem Server die Pakete apache oder apache2,
libgd, libjpeg-devel und openssl-devel
inklusive der entsprechenden Abhngigkeiten
installiert sein. Die folgenden Kommandos bereiten den Server auf die kommende Nagios-Installation vor:
useradd nagios
groupadd nagios
mkdir /usr/local/nagios
chown nagios:nagios /usr/local/nagios
useradd nagcmd
groupmod -A nagcmd www-data
groupmod -A nagcmd nagios
Danach konfiguriert und bersetzt man den

Sourcecode:.
tar zxvf nagios-2.7.tar.gz
cd nagios-2.7
./configure --with-command-group=www-data
make all
Eine bersicht aller verfgbaren Parameter fr

den Build-Vorgang liefert ./configure --help.
Nach dem bersetzen kann man die Anwendung mit make install installieren. Weitere
Make-Kommandos spielen anschlieend noch
Abbildung 1: Die Nagios-Startseite begrt den Anwender, der die ersten

Hrden der Installation berwunden hat.
Praxis
ein Init-SKript, eine Beispielkonfiguration und

eine Pipe fr die Kommunikation zwischen
Webinterfaces und Daemon auf:
make install-init
make install-config
make install-commandmode
Das Nagios-Paket selbst enthlt keine Plugins.

Sie sind separat zu installieren. Aktuell ist die
Version 1.4.6 der Plugins. Viele Plugins kompilieren allerdings nur, wenn sich vorher bestimmte Headerfiles oder Clientbibliotheken
auf dem System befinden. Ebenso liegen einige
Plugins nur als Perl-Skripte bei oder befinden
sich im Unterverzeichnis contrib des Pakets.
Solche Plugins kopiert der Installateur einfach
nach /usr/local/nagios/libexec.
Die Nagios-Konfiguration im
berblick
Die zentrale Nagios-Konfigurationsdatei /usr/
local/nagios/etc/nagios.conf enthlt alle globalen Einstellungen fr den Nagios-Server selbst.
Weitere Einstellungen, die vor allem festlegen,
was, wann, wo und wie zu berwachen ist, bezeichnet Nagios als Object Configuration. Derartige Einstellungen landen in eigenstndigen
Konfigurationsdateien, auf die nagios.conf
verweist. Am besten legt man dafr ein komplettes Unterverzeichnis an und legt dort die
verschiedenen Objekte in einer oder mehreren
Dateien ab.
Damit Nagios auch nur eine einzige berwachung in Angriff nehmen kann, bentigt es
mindestens Konfigurationseintrge fr die folgenden Objekte.
nTimeperiods: Zeitperioden
nCommands: berwachungschecks und Benachrichtigungen
Listing 1: Timeperiod-Konfiguration
01
define
timeperiod {
02
timeperiod_name
nonworkhours
03
alias
Ausserhalb der Arbeitszeit
04
monday
00:00-09:00,17:00-24:00
05
tuesday
00:00-09:00,17:00-24:00
06
wednesday
00:00-09:00,17:00-24:00
07
thursday
00:00-09:00,17:00-24:00
08
friday
00:00-09:00,17:00-24:00
09
saturday
00:00-24:00
10
sunday
00:00-24:00
11
}
nContacts:
Ansprechpartner und E-MailAdressen

nContactgroups: Zusammenfassung von Contacts zu Gruppen
nHosts: Festlegen von Gerten und deren Einstellungen
nHostgroups: Zusammenfassung von Hosts zu
Gruppen
nServices: Konfiguration der Dienstberwachung
Zustzlich gibt es noch Objekte, die nicht unbedingt notwendig sind, sondern lediglich erweiterte Konfigurationsmglichkeiten bieten:
nServicegroups: Zusammenfassung von berwachten Diensten zu Gruppen
nDependencies: Definition von Abhngigkeiten zwischen Hosts oder Services
nEscalations: Eskalationsregeln fr Benachrichtigungen
nExtendedInformation: Erweiterte Einstellungen fr das Webinterface
Zeitrume
Hat man sich einen ersten berblick verschafft,
kann man sich den Objekten im Einzelnen zuwenden. Ein erstes, leicht zu berblickendes
Objekt sind die so genannten Timeperiods. Sie
verwendet Nagios an unterschiedlichen Stellen,
berall dort, wo festzulegen ist, wann etwas zu
berwachen ist oder wann Benachrichtigungen
zu verschicken sind. Die Definition eines Timeperiod-Objekts ist dabei recht einfach (siehe
Listing 1).
Das wichtigste Attribut bei der Definition eines
Zeitraums ist der timeperiod_name, den spter
viele andere Stellen in der Nagios-Konfiguration
referenzieren. Den ausfhrlichen Aliasnamen
dagegen verwendet vor allem das Webinterface.
Die Zeitangaben in den einzelnen Zeilen beziehen sich jeweils auf einen Wochentag. Fr die
Timeperiods empfiehlt sich eine eigene Konfigurationsdatei, zum Beispiel /usr/local/nagios/
etc/objects/timeperiods.cfg. Anfangs braucht
man hchstens drei solcher Definitionen, zum
Beispiel fr always, workhours und nonworkhours.
Kommandodefinitionen
Unter der berschrift Commands subsumiert
Nagios alle Arten von Kommandodefinitionen,
die Programme oder Konsolenbefehle aufrufen.
Die wichtigsten Commands sind natrlich die
Aufrufe der Check-Plugins. Weiter zhlen aber
Praxis
auch Benachrichtigungsbefehle oder EventHandler zu den Commands. Ein Beispiel fr

eine solche Kommandodefinition knnte etwa
so aussehen:
define
command {
command_name
check_smtp
command_line
$USER1$/check_smtp -H
$HOSTADDRESS$ -p $ARG1$ -w $ARG2$ U

-c $ARG3$
}
Das Command-Objekt legt hier fest, dass Nagios

das Plugin check_smtp mit bestimmten Parametern ausfhren soll. $HOSTADDRESS$ bezeichnet dabei ein so genanntes Nagios-Makro,
das bei der Ausfhrung passende Daten erhlt.
Der Plugin-Parameter -p steht fr die SMTPPortnummer, und hinter -w und -c bergibt
man die Warnschwellen fr WARNING und
CRITICAL.
Welche Daten man an dieser Stelle definieren
muss, ist von Plugin zu Plugin verschieden. Eine
HTTP-berwachung bentigt mglicherweise
die Parameter Servername, Pfadangabe, Username und Passwort, whrend ein Ping-Check
eine IP-Adresse mitgeliefert bekommt. Der einfachste Weg, herauszufinden, welche Angaben
ein Nagios-Plugin bentigt, ist, es mit dem Parameter --help auszufhren.
Personen und Kontaktadressen definiert Nagios
unter der Rubrik Contacts. Diese dienen vor
allem der Benachrichtigungen bei Problemen,
aber auch zur Festlegung der Zugriffsrechte auf
das Webinterface. Ein Beispieleintrag eines Contact kann so aussehen wie in Listing 2.
Hier kommen nun zum ersten Mal Objekte zum
Einsatz, die vorhergehende Schritte definierten:
So ist nonworkhours eine der Timeperiods,
die an dieser Stelle festlegt, dass der User nur auerhalb der normalen Arbeitszeiten Benachrichtigungen erhlt. Die Angaben notify-by-email
und host-notify-by-email stehen fr Commands, mit deren Hilfe Nagios Benachrichtigungen weitergibt.
Um spter nicht sehr viele einzelne Kontakte
aufzhlen zu mssen, kann sie der Admin zu
Gruppen zusammenfassen:
define
hostgroup {
hostgroup_name
linux-servers
alias
Linux Server
members
linux1,linux2,tux,U
webserver,mybox
Listing 2: Contacts in Nagios

01
define
contact {
02
contact_name
03
alias
Jon Doe
04
service_notification_period
nonworkhours
05
host_notification_period
nonworkhours
06
service_notification_options
w,u,c,r
07
host_notification_options
d,u,r
08
service_notification_commands
notify-by-email
09
host_notification_commands host-notify-by-email
10
email
jdoe
jdoe@example.com
11
}
Listing 3: Host-Definition
01
define
host {
02
host_name
linux1
03
alias
Linux Server 1
04
address
192.168.1.254
05
parents
main-switch
06
check_command
check-host-alive
07
max_check_attempts
08
check_period
always
09
contact_groups
linux-admins
linux-admins
10
notification_interval
30
alias
Linux Administratoren
11
notification_period
always
members
jdoe,mtestmann,wadmin
12
notification_options
d,u,r
define
contactgroup {
contactgroup_name
Wie schon erwhnt, definiert man alle zu berwachenden Gerte gleich welcher Art als Hosts
(Listing 3).
Wichtigste Eigenschaften des Host sind sein
Name und seine IP-Adresse. Die Variable max_
check_attempts definiert, wie oft ein Check zu
wiederholen ist, bevor Nagios wirklich einen
Ausfall annimmt. Dabei legt contact_groups
fest, wer von dem Ausfall erfahren soll. Das Beispiel verwendet eine zuvor angelegte Contactgroup.
Einzelne Hosts lassen sich beliebig zu Hostgroups zusammenfassen. Diese Gruppen machen vor allem die Anzeige im Webinterface
bersichtlicher oder vereinfachen die berwachung zusammengehriger Hosts :
13
}
Praxis
Notify Service
Notify Host
Host Notify Command

Service Notify Command
Commands
Timeperiods
Member
Of
Contacts
Contact
Groups
Notify
Notify
Acces
s
Member
Of
Host
Groups
Hosts
Services
Abbildung 2: Die Nagios-Konfigurationsdateien referenzieren sich ausgiebig gegenseitig. Das erhht die bersicht und vermindert zugleich den
Tippaufwand.
Noch berwacht Nagios in unserem Beispiel

nichts. Timeperiods und sogar Hosts sind nur
Objekte, die es ermglichen, die Konfigurationsdateien kompakt und bersichtlich zu halten. Man definiert nicht jedes Mal aufs Neue,
wer E-Mails bekommen soll, sondern verwendet
einfach ein vorher definiertes Contact-Objekt.
Die Services definieren die tatschlich zu berwachenden Ressourcen oder Rechner. An dieser
Stelle luft alles vorher Festgelegte zusammen
(Listing 4). Diejenigen Objekte, die anderswo
hinterlegte Definitionen referenzieren, erscheinen im Listing fett gedruckt.
Listing 4 zeigt auch die Parameterbergabe
an das Check-Kommando, getrennt durch
Listing 4: Konfiguration eines Servicecheck
01
define
service {
02
service_description
smtp check
03
host_name
linux1
04
check_command
<B>check_smtp<B>!25!10!20
05
max_check_attempts
06
normal_check_interval
07
retry_check_interval
08
check_period
always
09
notification_interval
30
10
notification_period
always
11
w,c,r
12
contact_groups
linux-admins
13
!. Damit gelangen die Werte in die Makros $ARG1$, $ARG2$ und so weiter, die
schlielich das Plugin bergeben bekommt.
Im normalen Betrieb ist es sinnvoll, die Nagios-Konfiguration auf viele einzelne Dateien
zu verteilen und je nach Projekterfordernissen
in verschiedenen Unterverzeichnissen zu strukturieren. Fr den Anfang reicht aber auch ein
einzelnes File. Die Nagios-Quellen liefern eine
Datei localhost.cfg oder minimal.cfg mit,
die sich sehr gut fr erste Gehversuche mit Nagios eignen.
Nach dem Neuanlegen oder ndern der Nagios-Konfigurationsdateien empfiehlt es sich,
zuerst einen Konfigurations-Check durchzufhren. Mit dem Switch -v berprft Nagios die
komplette Konfiguration auf syntaktische Fehler
und vor allem darauf, ob smtliche Bezge auf
andere Objekte korrekt auflsbar sind. Als Argument erwartet Nagios dabei nur den Namen
der Hauptkonfigurationsdatei: /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.
cfg.
Im Erfolgsfall meldet der Konfigurationstest am
Ende Things look okay. No serious problems
were detected during the pre-flight check und
man kann den Daemon mit dem folgenden
Kommando starten: /etc/init.d/nagios start.
Wenn der Daemon schon luft, reicht ein Reload
aus, um die neue Konfiguration zu aktualisieren:
/etc/init.d/nagios reload.
Wenn Nagios dabei keine Fehlermeldungen
mehr ausgibt, ist der Daemon gestartet und
berwacht nun die konfigurierten Hosts und
Services. Welche Schritte Nagios dabei gerade
ausfhrt, kann man sich im Nagios-Logfile
genau ansehen: tail -f /usr/local/nagios/var/
nagios.log.
Konfiguration des Webinterface

Fr die normale Bedienung und vor allem den
Einblick in den aktuellen Status aller berwachten Server liefert Nagios ein integriertes Webinterface mit, das aber noch in den lokal installierten Apache einzubinden ist. Im Falle des
Apache2 erzeugt man dazu am besten die Datei
/etc/apache2/conf.d/nagios, deren Inhalt Listing 5 zeigt.
Damit sich die User mit Namen und Passwort
am Nagios-Webinterface anmelden knnen,
hinterlegt man in der Datei htpasswd.users
entsprechende Accounts. Wenn die Datei noch
Praxis
nicht vorhanden ist, muss sie der Admin mit

htpasswd erstellen:
touch /usr/local/nagios/etc/U
htpasswd.users
htpasswd /usr/local/nagios/etc/U
htpasswd.users jdoe
Die Benutzernamen mssen dabei mit den vorher angelegten Nagios-Contacts bereinstimmen, damit das Webinterface den richtigen User
erkennen und nur die ihm zugeordneten Hosts
anzeigen kann. Weitere Funktionen des Webinterface und andere Berechtigungseinstellungen
steuert die Datei cgi.cfg.
berwachungen im Detail
Wenn der Nagios-Server erstmal luft, ist es nun
an der Zeit, einen genaueren Blick auf die Plugins zu werfen. Da es eigenstndige Programme
sind, kann man neue Plugins einfach auf der
Kommandozeile aufrufen und testen. Am besten erledigt man das gleich mit dem User-Account des Nagios-Servers, da der die Plugins im
Livebetrieb ja auch ausfhrt. Der Aufruf unterscheidet sich allerdings je nach Plugin, da jeder
Check-Typ ja mglicherweise andere Parameter
bentigt. Einzig die Option -h oder --help
sollte bei allen Plugins implementiert sein, wenn
es nach den Nagios Developer Guidelines geht.
Nach diesem ersten Schritt hat man einen guten
Anhaltspunkt und kann die verschiedenen Optionen testen. Als Beispiel hier ein Aufruf des
check_disk-Plugins:
der besseren Lesbarkeit noch einmal das Ergebnis der berwachung im Klartext, wie im obigen Beispiel das DISK OK zeigt. Darauf kann
man sich allerdings nicht verlassen und sollte im
Zweifel den Returncode zurate ziehen.
Den dritten Teil der Rckgabe trennt das PipeSymbol | vom Rest. Nagios nennt diesen Abschnitt Performance Data. Diese Werte verarbeiten Add-ons weiter, beispielsweise zu Charts
oder Graphen, die den Verlauf des Wertes darstellen. Performance Data ist aber ein optionaler
Wert nur neuere Nagios-Plugins liefern ihn
zurck. Notwendig sind nur die ersten beiden
Bestandteile, also Returncode und Plugin-Output. Wenn Nagios das Plugin nicht finden kann,
es nicht ausfhrbar ist oder es keine korrekte
Antwort an den Daemon zurckliefert, zeigt das
Webinterface den Status UNKNOWN, mit
der Fehlermeldung Return Code of 127 is out
of bounds an.
Die oben angefhrten Parameter -w und -c
sind bei den meisten Plugins vorhanden, denn
sie definieren die Warnschwellen fr WARNING und CRITICAL. Das Beispiel legt die
Schwellwerte fr den verbleibenden freien Platz
Listing 5: Konfiguration fr Nagios-Webinterface

01
ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin
02
03
<Directory "/usr/local/nagios/sbin">
04 Options ExecCGI
05 AllowOverride None
06 Order allow,deny
nagios# ./check_disk -w 50% -c 20% -p /U
07 Allow from all
DISK OK - free space: / 45256 MB U
08 AuthName "Nagios Access"
(64% inode=98%);U
09 AuthType Basic
| /=25137MB;37080;59328;0;74160
10 AuthUserFile /usr/local/nagios/etc/htpasswd.users
Die Rckmeldungen der Plugins bestehen in

der Regel aus drei Teilen. Der wichtigste davon ist das Ergebnis der berwachung, also
OK, WARNING, CRITICAL oder
UNKNOWN. Dieser Wert entspricht dem
Returncode des Plugin und ist deswegen an der
Konsole nicht direkt sichtbar. Allerdings zeigt
ihn ein echo $? an. Die verschiedenen numerischen Rckgabewerte stehen dabei fr die
folgenden Ergebnisse: 0 fr OK, 1 fr
WARNING, 2 fr CRITICAL und 3 fr
UNKNOWN.
Der zweite Teil des Rckgabewertes ist der sichtbare Plugin-Output, den auch das Webinterface
angezeigt. Viele Plugins codieren hier wegen
11 Require valid-user
12
</Directory>
13
14
Alias /nagios /usr/local/nagios/share
15
16
<Directory "/usr/local/nagios/share">
17 Options None
18 AllowOverride None
19 Order allow,deny
20 Allow from all
21 AuthName "Nagios Access"
22 AuthType Basic
23 AuthUserFile /usr/local/nagios/etc/htpasswd.users
24 Require valid-user
25
</Directory>
Praxis
munity-Strings fllen. Wichtiger sind aber die

$ARGx$-Makros. Sie nehmen die Parameter
aus der Definition des Service auf:
define service {
service_description
disk check root
host_name
linux1
check_command
check_disk!50%!20%!/
(...)
}
Die einzelnen Werte trennt man dabei mit einem

Ausrufezeichen ! voneinander. Dieser Mechanismus erlaubt es, einen Check nur einmal, als
Check-Typ zu definieren und dann in vielen
Service-Definitionen wiederzuverwenden.
Fern-berwachung per SSH

Abbildung 3: In einer solchen bersicht prsentiert Nagios den Status aller
berwachten Hosts in einer mit einem Blick erfassbaren Ampeldarstellung.
der Partition auf 50 beziehungsweise 20 Prozent

fest. Wenn man das Plugin auf der Konsole testet, empfiehlt es sich, auch die Gegenprobe zu
machen: Man whlt absichtlich eine sehr niedrige Warnschwelle, um zu sehen, ob das Plugin
dann auch wirklich den gewnschten Status zurckliefert.
Fllt das Ergebnis der Vorbereitungen und Tests
zufriedenstellend aus, kann man das Plugin als
Check-Kommando in die Nagios-Konfiguration
eintragen:
define
command {
command_name
check_disk
command_line
$USER1$/check_disk -w U
$ARG1$ -c $ARG2$ -p $ARG3$

}
In der Regel codiert man die Warnschwellen

und auch die Angabe der Partition nicht fest ein,
sondern gibt diese Werte erst bei der Definition
des Service an. Schlielich steht ja erst dann fest,
auf welchem Host der Check laufen soll. Damit
man hier mglichst flexibel bleibt, bietet Nagios die bereits erwhnten Makros an. Das sind
Strings, die $-Zeichen am Anfang und Ende
begrenzen und die sich erst zur Laufzeit mit Daten fllen. Das $USER1$-Makro ist in der Datei resources.cfg definiert und dient vor allem
dazu, nicht jedes Mal den vollstndigen PluginPfad angeben zu mssen. An der gleichen Stelle
kann man auch eigene $USERx$-Makros
anlegen und beispielsweise mit SNMP-Com-
Bei der berwachung entfernter Ressourcen

unterscheidet Nagios zwischen direkten und
indirekten Checks. Direkte Checks starten lokal
auf dem Nagios-Server. Fast alle berwachungen, die sich auf Netzwerkprotokolle und hnliches wie beispielsweise Ping, DNS, SMTP oder
HTTP beziehen, arbeiten als direkte Checks und
simulieren den Zugriff hnlich wie ein normaler
Client:
nagios# ./check_http U
-H linux-magazin.de -w 5 -c 10
HTTP OK HTTP/1.1 200 OK - U
78673 bytes in 0.366 seconds
Indirekte Checks verwendet Nagios, wenn das

Plugin lokale Daten eines entfernten Host abfragen soll. Dazu muss sich Nagios erst an diesem
Host anmelden, um dann das Plugin direkt vor
Ort auszufhren.
Die einfachste Mglichkeit dazu ist, zwischen
dem Nagios-Server und den zu berwachenden
Clients passwortlose SSH-Verbindungen mit
Zertifikaten einzurichten und dann die PluginAufrufe ber SSH auszufhren. Dazu stellt das
Nagios-Plugin-Paket ein check_by_ssh-Plugin bereit. Um das check_disk-Plugin remote
auf einem anderen Server zu starten, muss man
es in check_by_ssh kapseln. Das sieht dann
etwa so aus:
define command {
command_name check_ssh_disk
command_line $USER1$/check_by_ssh U
-t 60 -H $HOSTADDRESS$ -C U
"$USER2$/check_disk -w $ARG1$ U
-c $ARG2$ -p $ARG3$"
Praxis
Lokal startet check_by_ssh. Es meldet sich am

zu berwachenden Server an und fhrt das dort
installierte Plugin check_disk aus. Der Pfad
zu den Plugins auf den entfernten Servern ist in
der Variable $USER2$ definiert, so dass man
sich an dieser Stelle die Angabe des Pfades sparen kann.
Fernberwachung per NRPE

Eine weitere Mglichkeit ist der Nagios Remote
Plugin Executor (NRPE), ein Nagios Client-Server-Programm, um Remote-Plugins zu starten.
Es erfordert die Installation des NRPE-Servers
zustzlich zu den Plugins auf den berwachten
Servern. NRPE besteht aus einem Daemon fr
die Nagios-Clients und einem Check-Plugin fr
den Nagios-Server. Das Plugin kompiliert man
am besten direkt auf dem Nagios-Server. Nach
dem Entpacken reicht ein einfaches ./configure und make all. Das dabei entstandene
check_nrpe kopiert man dann in das passende
lokale Verzeichnis zu den andern Plugins und
konfiguriert ein passendes Check-Kommando:
define
command{
command_name check_nrpe
command_line $USER1$/check_nrpe -H U
Abbildung 4: Statusbersichten kann Nagios auch in Form von Karten darstellen, die logische oder physische Beziehungen zwischen berwachten
Objekten abbilden.
Arbeit, insbesondere bei spteren nderungen

an Warnschwellen. Es spricht also vieles fr
SSH, das ja auf den meisten Linux-Servern sowieso vorhanden ist.
SNMP ganz einfach
$HOSTADDRESS$ -c $ARG1$
}
Um Arbeit zu sparen, kann man den NRPEDienst auf den Clients aus Paketen installieren
oder vom Nagios-Server kopieren. Es ist ratsam, den NRPE unter inetd oder xinetd zu
betreiben und TCP-Wrapper zu verwenden.
Eine passende Anleitung dafr findet sich im
README-File des NRPE-Pakets. Die mglichen Checks, die der NRPE dann remote ausfhren soll, trgt man schlielich in nrpe.cfg
(Listing 6) ein. Beispiele dafr finden sich in der
sample-Datei:
Zwar ist der NRPE quasi das offizielle Tool fr
Remote-Checks, aber es hat gegenber SSH
doch deutliche Nachteile: So bentigt es einen
zustzlichen Daemon und auerdem einen weiteren geffneten Port. Auch die Konfiguration
der Checks auf den Clients bedeutet zustzliche
Gerade bei Netzwerkhardware ist SNMP das

Tool der Wahl, um Daten von entfernter Hardware einzuholen. Das Plugin-Paket stellt dazu
check_snmp bereit, mit dem sich Werte ber
die OID der jeweiligen Hersteller-MIB abfragen lassen. (Weitere Artikel dieser Ausgabe beschreiben die Grundlagen von SNMP und seinen Einsatz unter Nagios im Detail.) Der Aufruf
lautet analog zu den anderen Nagios-Plugins:
nagios# ./check_snmp -H ip_address -o OID
-w warning -c critical -m:
Wichtig, aber wenig dokumentiert, ist vor allem
das letzte Argument -m:. Es verhindert, dass
das Plugin versucht, die lokal installierten MIBs
einzulesen. Das fhrt bei lteren Plugin-Versionen zu Fehlermeldungen und kostet ansonsten
nur unntig Performance. Die passenden OIDs
muss man allerdings selbst ermitteln, entweder
Listing 6: NRPE-Beispiele
01
command[check_users]=@libexecdir@/check_users -w 5 -c 10
02
command[check_load]=@libexecdir@/check_load -w 15,10,5 -c 30,25,20
03
command[check_disk1]=@libexecdir@/check_disk -w 20 -c 10 -p /dev/hda1
04
command[check_disk2]=@libexecdir@/check_disk -w 20 -c 10 -p /dev/hdb1
Praxis
Abbildung 5: In der Windows-Dienstesteuerung kann man sich die Namen

der Dienste auflisten lassen, die man fr die Konfiguration der berwachung braucht.
durch einen Blick in die MIBs des Herstellers

oder eigene Versuche mit snmpwalk.
Viele SNMP-Abfragen erfordern allerdings
mehr Logik als das simple Anfragen eines Werts.
Um beispielsweise die aktuelle Auslastung einer
Netzwerkschnittstelle zu ermitteln, bentigt
man neben dem aktuellen auch einen lteren Interfacecounter, um die Differenz pro Zeiteinheit
zu berechnen. Das kann man in einem einfachen
Check-Kommando nicht mehr hinterlegen,
sondern man bentigt
ein Plugin mit etwas
mehr interner Logik,
wie check_iftraffic,
das diese Berechnungen automatisch vornimmt.
Windows-Agent. Der Name NsClient bezieht

sich noch auf den Namen NetSaint, den Nagios
bis etwa 2001 trug. Und mit NsClient++ gibt es
inzwischen ein Nachfolgeprojekt, das die Funktionen beider Alternativen in einem einzigen
Agenten zusammenfhrt.
Die Installation ist denkbar einfach: Nach dem
Entpacken des Zip-Files kopiert man alle Dateien
an einen passenden Ort auf dem Windows-Server, beispielsweise c:\Programme\NsClient++,
und passt die Settings aus der NSC.ini-Datei
an die lokalen Erfordernisse an. Dabei schaltet
man insbesondere die einzelnen Module am Anfang der Konfigurationsdatei frei. Danach installiert der Admin den Windows-Dienst ber Start
| Ausfhren mit c:\Programme\NSClient++
/install sowie net start nsclient++.
Da der Agent ja die beiden Vorgnger beinhaltet,
lassen sich auf Seiten des Nagios-Servers auch
beide Plugins verwenden, also check_nt oder
check_nrpe. Das erste liefert Werte fr die Parameter CLIENTVERSION, CPULOAD,
UPTIME, MEMUSE, USEDDISKSPACE,
SERVICESTATE, PROCSTATE und alle
Counter des Windows-PerfMon zurck. Ein
Aufruf zur Statusabfrage eines Windows-Dienstes sieht damit so aus:
./check_nt -H host_address -p port U
-s passwort -v SERVICESTATE U
-l dienstname
Den Namen des abzufragenden Windows-
Nagios wacht
ber WindowsServer
Natrlich
existieren
auch fr die berwachung von WindowsServern mehrere Lsungen. Neben NRPE,
der auch in einer Windows-Version verfgbar ist, galt lange Zeit
NsClient als recht einfach zu verwendender
Abbildung 6: Perfomance-Messwerte aus einer Windows-Umgebung kann

Nagios vom Windows-PerfMon bernehmen.
Praxis
Dienstes findet man am schnellsten in den Eigenschaften der Windows-Dienstesteuerung,

also unter Start | Verwaltung | Dienste. Whrend sich die meisten anderen Parameter von
selbst erklren, verdienen die Performancecounter eine extra Betrachtung. Unter Windows
dient der PerfMon, auf Deutsch etwas umstndlich mit Leistungsprotokolle und Warnungen
bersetzt, als zentrale Schnittstelle fr Performancewerte. Damit lassen sich nicht nur Windows-interne Leistungsdaten, sondern auch die
Werte vieler Serverapplikationen wie ExchangeServer oder SQL-Server abfragen. Die Syntax
dazu lautet:
#./check_nt -H <host_address> -p <port> U
-v COUNTER U
-l "\\Leistungsobjekt(Instanz)\\ U
Indikator"
Zustzlich kann man den zurckgelieferten

Wert fr die Ausgabe im Plugin-Output auch
noch umformatieren. Die Belegung der Auslagerungsdatei auf einem deutschen WindowsSystem sieht dann beispielsweise so aus:
#./check_nt -H $HOSTADDRESS$ -v COUNTER U
-l "\\Auslagerungsdatei(_Total)U
\\Belegung (%)","Paging File usage U
is %.2f %%" -w $ARG1$ -c $ARG2$
Alerting
Die beste berwachung Ihres Netzwerks bringt
wenig Erfolg ohne Benachrichtigung des Admins im Problemfall. Auch dafr bietet Nagios
ausgeklgelte Funktionen. Jedes Mal, wenn es
irgendwo im System einen Fehler erkennt, startet es eine komplexe Analyse und prft, ob und
wer darber zu informieren ist. Zuerst prft die
Software, ob jemand den Fehler schon besttigt
hat (siehe max_check_attempts), ob vielleicht
im Webinterface eine Downtime fr den Host
oder Service eingetragen ist und ob zur aktuellen Zeit berhaupt Benachrichtigungen zu
versenden sind (siehe notification_intervall).
Danach ermittelt Nagios die diesem Host zugeordneten Contacts und prft deren Benachrichtigungseinstellungen. Sollen die Contacts berhaupt Benachrichtigungen erhalten, und wenn
ja, welche (siehe notification_options). Zuletzt
gilt es noch zu checken, ob der Contact zum aktuellen Zeitpunkt Benachrichtigungen erhalten
soll (siehe notification_period). Dank dieses
Schemas lassen sich die Benachrichtigungen
sehr individuell steuern. Abhngig von Host,

Zeit und Ansprechpartner lassen sich verschiedene Nachrichten ber unterschiedliche Kanle
versenden.
Um diesen Mechanismus noch weiter zu verfeinern, erlauben es die Escalations, jede weitere Benachrichtigung zu einem bestehenden
Problem nochmals anders zu behandeln, also
beispielsweise zuerst per E-Mail zu benachrichtigen und dann weitere Alerts per SMS oder Telefonanruf zu versenden.
Um die eigentliche Benachrichtigung abzusetzen, verwendet Nagios analog zu den Checks
wieder ein Command. Die Benachrichtigungen
sind also nicht fest in Nagios verdrahtet. Stattdessen realisiert sie ein Aufruf eines Shell-Befehls oder eines Skripts (Listing 7).
Wichtig ist dabei nur, welche Daten das Mailprogramm erhlt. Die bergabe geschieht wieder ber Makros. Eine vollstndige Auflistung
der verfgbaren Makros befindet sich in der Nagios-Dokumentation.
Verwaltung der
Konfigurationsdateien
Als Ausgangspunkt fr die ersten eigenen Versuche mit der Objekt-Konfiguration liefert Nagios verschiedene Beispieldateien mit. Die Datei
minimal.cfg implementiert nur einige wenige
berwachungen fr den lokalen Rechner. In der
bigger.cfg sind weitergehende Beispiele enthalten. Schon ab der berwachung eines kleineren Netzes ist es allerdings sinnvoll, sich etwas
mehr Gedanken ber die Organisation der Ob-
Listing 7: Konfiguration von Benachrichtigungen

01
define
command {
02
command_name notify-by-email
03
command_line /usr/bin/printf "%b" $$
04
"***** Nagios 1.0 *****\n\n $$
05
Notification Type: $NOTIFICATIONTYPE$\n\n $$
06
Service: $SERVICEDESC$\n $$
07
Host: $HOSTALIAS$\n $$
08
Address: $HOSTADDRESS$\n $$
09
State: $SERVICESTATE$\n\n $$
10
Date/Time: $DATETIME$\n\n $$
11
Additional Info:\n\n $$
12
$OUTPUT$" | /usr/bin/mail -s $$
13
"** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/
$SERVICEDESC$ $$
14
is $SERVICESTATE$ **" $CONTACTEMAIL$
15
}
10
Praxis
Standorte Ihres Netzwerks. Auf der nchsten

Ebene befinden sich dann einzelne Unterverzeichnisse fr Kunden, Abteilungen oder Gertetypen. Dabei kann man zusammengehrende
Objekte, also beispielsweise einen Host und die
ihm zugeordneten Services und Contacts, einfach in derselben Konfigurationsdatei versammeln. Am besten arrangiert man dieses so, dass
man die Objekte einerseits einfach und schnell
wiederfindet und andererseits bei spteren nderungen mglichst wenige verschiedene Files
bearbeiten muss.
Ausblick und Add-ons
Abbildung 7: Sehr hilfreich beim Auswerten von Performancedaten sind

Charts, wie sie der Nagios Grapher automatisch erzeugen kann.
jektkonfiguration zu machen. Die Literatur und

auch die Nagios-Dokumentation empfehlen,
die Objekte sortiert nach ihrem Typ auf unterschiedliche Files zu verteilen. Auf diese Weise
erhlt man also eine dedizierte Datei hosts.
cfg, eine services.cfg, eine contacts.cfg und
so weiter.
Aber auch dieses Vorgehen wird bei einer greren Installation ziemlich schnell unbersichtlich, und eigentlich gibt es auch keinen wirklichen Grund, die einzelnen Objekttypen voneinander getrennt zu speichern. Denn Nagios
findet die Objekte, egal wie sie auf verschiedene
Files oder sogar Directories aufgeteilt sind. Der
Admin muss sie dafr lediglich in der nagios.
cfg richtig angegeben haben.
Es bietet sich daher vielmehr an, die Konfiguration nach logischen Gesichtspunkten in Unterverzeichnisse zu strukturieren, beispielsweise
auf der ersten Ebene globale Einstellungen und
Der Autor
Julian Hein ist Grnder und geschftsfhrender
Gesellschafter der Netways GmbH [http://www.
netways.de], die sich seit mehr als zehn Jahren mit
der Implementierung und dem Betrieb von groen
und komplexen Netzwerken aller Hersteller beschftigt. Der Hauptfokus dabei ist die Nutzung von
Linux- und Open-Source-Tools wie Nagios fr das
Netz- und System-Management.
11
Nagios bietet natrlich noch wesentlich mehr,

als die in diesem Artikel beschriebenen Grundfunktionen. Vor allem durch die unzhligen
Add-ons und Zusatzprojekte lassen sich fast alle
erdenklichen berwachungsaufgaben bewltigen.
Ein wichtiges Beispiel dafr sind Performanceauswertungen, die sich mit dem Nagios Grapher
fast von selbst erstellen lassen. (Mit dem Nagios
Grapher beschftigt sich ausfhrlich ein weiterer
Beitrag dieser Ausgabe.) Interessant sind auch
Benachrichtigungssysteme, die SMS und sogar
Telefonanrufe versenden knnen um einen Administrator ber Probleme zu informieren. (Der
Kombination von Nagios mit der Open-SourceTelefonsoftware Asterisk und einem Sprachsynthesizer ist ein separater Beitrag in diesem Linux
Technical Review gewidmet.)
Das Add-on-Portal [3] ist dabei die beste Anlaufstelle fr die Suche nach Nagios-Erweiterungen oder -Plugins. Egal wie ausgefallen Ihre
berwachungsanforderungen auch sein mgen,
dort findet sich mit hoher Wahrscheinlichkeit
das passende Plugin oder wenn nicht, dann zumindest eines, dass sich als Ausgangsbasis fr
eine Eigenentwicklung verwenden lsst. Allerdings sollte man auch nicht vergessen, spter
die selbst programmierten Resultate dort wieder
zum Download fr andere zur Verfgung zu
stellen. (jcb)
nnn
Infos
[1] Debian-Repository mit Nagios-Paketen: [http://
www.backports.org]
[2] Nagios-Homepage: [http://www.nagios.org]
[3] Add-on-Portal: [http://www.NagiosExchange.
org]
Nagios
Zukunft
Noch nie gab es so viel Neues auf einen Schlag:
Die kommende Release Nagios 3 bringt die weit

reichendsten Verbesserungen aller bisherigen Versionen der letzten sieben Jahre mit. Sein Entwickler
stellt sie vor. Ethan Galstad
Projekte
Knapp ein Jahr ist seit der Release der ersten

Stable-Version von Nagios 2 vergangen. Nun
steht Nagios 3 ins Haus, dessen Entwicklung fast
genauso lang gedauert hat. Dieser zeitliche Rahmen gab mir die Gelegenheit, viele von Benutzern vorgeschlagene Erweiterungen zu implementieren, aber auch einige Ideen, die mir schon
seit Jahren durch den Kopf gehen. Dabei konnte
ich auch einige grere Performanceengpsse
beheben, und ich freue mich riesig darauf, zu
erfahren, wie sich der neue Code in groen Produktionsumgebungen verhlt, die ich in meiner
Testumgebung nicht nachbilden kann.
Im Folgenden mche ich einige der wichtigsten
Neuerungen im Detail vorstellen.
stammen, das heit, die lokalen Variablen berschreiben in den meisten Fllen die aus den
Vorlagen ererbten. In manchen Fllen wre es
unter Umstnden wnschenswert, die Werte
der geerbten und lokalen Variablen gemeinsam
zu nutzen. Das wird nun mglich. Dazu mssen
die lokalen String-Variablenwerte lediglich mit
einem Pluszeichen (+) beginnen, wie das folgende Beispiel in Listing 2 zeigt.
In diesem Fall hngt der Host linuxwebserver
den Wert der lokalen Variablen hostgroups an
den aus generic-host geerbten Wert an. Die
sich daraus ergebende Definition von linuxwebserver sieht folgendermaen aus:
define host{
Vererbung
Schon heute ist der Vererbungsmechanismus
eines der wichtigsten Features des Nagios-Konfigurationsformats. Schlielich sorgt die Mglichkeit, Objektvariablen von anderen Objektvorlagen zu erben, besonders in einer komplexen Umgebung fr mehr bersicht und weniger
Tipparbeit. Nagios 3 baut die Ausdrucksmglichkeiten dieser Objektvererbungslogik nun
noch weiter aus.
Traditionell konnten Objektdefinitionen lediglich variable Werte aus einer einzigen Vorlage
erben. Mit Nagios 3 knnen nun Objektdefinitionen variable Werte aus mehreren Vorlagen
erben. Ein erstes Beispiel zeigt das Listing 1.
In diesem Beispiel erbt der Host devweb variable Werte aus zwei Quellen: Zum einen von
generic-host und zum anderen von development-server. Wie zu sehen ist, definieren beide
Quellen eine Variable namens check_interval.
Weil generic-host die erste Vorlage ist, die in
der devweb-Host-Definition erscheint, hat sie
Vorrang. Die resultierende Definition von devweb sieht daher wie folgt aus:
# Entwicklungs-Webserver
define host{
host_name
linuxwebserver
hostgroups
all-servers,U
linux-servers,U
web-servers
...
}
Dieses Feature kann sehr ntzlich sein, wenn es

auf eine mglichst effiziente Nutzung von Vorlagen ankommt.
E
Listing 1: Erben von mehreren Vorfahren

01
# Vorlage fr generische Hosts
02
define host{
03
name
generic-host
04
active_checks_enabled
05
check_interval
10
06
...
07
register
08
09
10
# Vorlage fr Entwicklungs-Webserver
11
define host{
12
name
13
check_interval
15
14
d,u,r
15
...
host_name
devweb
16
register
active_checks_enabled
17
check_interval
10
18
d,u,r
19
# Entwicklungs-Webserver
...
20
define host{
21
use
22
generic-host,development-server
23
host_name
24
...
25
Eine zweite nderung der Vererbungslogik betrifft die so genannte additive Vererbung. Unter Nagios haben lokale Variablen in der Regel
Vorrang gegenber Variablen, die aus Vorlagen
development-server
devweb
Projekte
GENERIC HOST
DEVELOPMENT SERVER
define host{
host_name
webserver
contact_groups
contacts
web-admins
john,paul,!eric
...
}
Active Checks,
Check Interval
Notification
Options
WEBDEV _1
Abbildung 1: Neu in Nagios 3: Eine Objektdefinition kann Teile von mehreren verschiedenen Vorfahren gleichzeitig erben.
define hostgroup{
Objekte
hostgroup_name
Nagios 3 ndert einige Objektdefinitionen, um

die Verwaltung der Konfiguration zu vereinfachen. So lassen sich unter Nagios 3 nun auch individuelle Kontakte in den Host-, Service-, HostEscalation- und Service-Escalation-Definitionen definieren. Bisher musste man dazu immer
zuerst eine Kontaktgruppe anlegen, auch wenn
sich das dort gar nicht lohnte, wo nur ein paar
Benutzer Alarmmeldungen erhalten sollten. Natrlich gibt es die Kontaktgruppen auch weiterhin, daneben aber kann es nun Einzelkontakte
und eine Mischung beider Varianten geben.
Listing 2: Additive Vererbung

01
define host{
02
name
generic-host
03
hostgroups
all-servers
04
...
05
register
06
07
08
define host{
Um die Verwaltung der Gruppenmitgliedschaft

zu vereinfachen, untersttzt Nagios 3 nun eine
Methode, um grere Gruppen aus Untergruppen aufbauen zu knnen. Die Definitionen fr
Host-, Service- und Kontaktgruppen umfassen
nun die Variablen hostgroup_members, servicegroup_members beziehungsweise contactgroup_members. Mithilfe dieser Variablen
kann man Nagios mitteilen, dass die Mitglieder
einer oder mehrerer Untergruppen in eine grere Gruppe einzugliedern sind. Ein Beispiel
dazu zeigt Listing 3.
Durch die Nutzung von Untergruppen erhalten
wir eine Definition von hg3, die effektiv der
folgenden gleicht:
09
use
generic-host
10
host_name
linuxwebserver
11
hostgroups
+linux-servers,web-servers
12
...
13
members
hg3
webserver,linuxserver,
fileserver,firewall
...
}
Die Verwaltung der Gruppenmitgliedschaft unter Nagios gestaltet sich dadurch viel einfacher
als je zuvor.
Benutzerspezifische
Objektvariablen
Seit einigen Jahren wnschen sich die Benutzer
neue Variablen fr die Host-, Service- und Kontaktdefinitionen. Auf der Wunschliste stehen
Variablen fr die SNMP-Community, die MACAdresse, den AIM-Benutzernamen, die SkypeNummer und die Strae die Liste nimmt kein
Ende. Das Problem, das ich dabei sehe, ist dass
Nagios dadurch weniger allgemeingltig wird
und strker von der Infrastruktur abhngt.
Dabei sollte es mglichst flexibel bleiben, weshalb sich die Entwicklung eher an generischen
Funktionen orientiert. Zum Beispiel besitzen
die Hostdefinitionen in Nagios eine generische
Variable address, die alles mgliche enthalten kann, von einer IP-Adresse bis hin zu einer
Wegbeschreibung, was auch immer sich fr die
Umgebung des Nutzers am besten eignet.
Projekte
Dennoch ist eine Methode ntig, mit deren

Hilfe Administratoren Informationen ber die
eigenen Infrastrukturkomponenten in der eigenen Nagios-Konfiguration speichern knnen,
ohne dass diese spezifischen Variablen fr alle
verbindlich wren. Nagios 3 bemht sich um
eine Lsung, indem User benutzerspezifische
Variablen in ihren Objektdefinitione einfgen
knnen. Dank dieser benutzerspezifischen Variablen lassen sich zustzliche Eigenschaften
in die Host-, Service- und Kontaktdefinitionen
aufnehmen und deren Werte fr Benachrichtigungen, Event-Handler sowie Host- und Service-Checks einsetzen.
Dafr muss man allerdings ein paar wichtige Informationen ber benutzerspezifische Variablen
beachten:
nBenutzerspezifische Variablennamen mssen mit einem Unterstrich (_) beginnen, um
Namenskollisionen mit Standardvariablen zu
vermeiden.
nBenutzerspezifische Variablennamen unterscheiden nicht zwischen der Gro- und
Kleinschreibung.
nBenutzerspezifische Variablen sind genau wie
normale Variablen innerhalb von Objektvorlagen erblich.
nSkripte knnen jetzt mithilfe von Makros
und von Umgebungsvariablen die Werte der
benutzerspezifischen Variablen referenzieren.
Das folgende Beispiel (Listing 4) demonstriert
die Verwendung benutzerspezifischer Variablen
in Objektdefinitionen.
Listing 3: Einschlieen von Untergruppen

01
define hostgroup{
02
hostgroup_name
hg1
03
members
webserver,linuxserver
04
...
05
06
07
define hostgroup{
08
hostgroup_name
hg2
09
members
fileserver,firewall
10
...
11
12
13
define hostgroup{,
14
hostgroup_name
hg3
15
hostgroup_members
hg1,hg2
16
...
17
Skripte und Programme zur Prfung oder Benachrichtigung knnen benutzerspezifische

Variablenwerte ber Makros und Umgebungsvariablen referenzieren. Um Namenskollisionen zwischen benutzerspezifischen Variablen
unterschiedlicher Objekttypen zu vermeiden,
fgt Nagios in Makro- oder Umgebungsvariablennamen die Namensprfixe _HOST, _SERVICE oder _CONTACT ein. Tabelle 1 zeigt
die entsprechenden Makro- oder Umgebungsvariablennamen fr die weiter oben definierten
benutzerspezifischen Variablen.
Benutzerspezifische Objektvariablen bieten bei
der Anpassung von Nagios an die unterschied-
Listing 4: Benutzerspezifische Variablen

01
define host{
02
host_name
linuxserver
03
_mac_address
00:06:5B:A6:AD:AA
<-- Custom
04
MAC_ADDRESS variable
05
_rack_number
R32
<-- Custom
14
SNMP_COMMUNITY variable
15
_TechContact
Jane Doe
<-- Custom
16
TECHCONTACT variable
17
....
18
19
06
RACK_NUMBER variable
20
define contact{
07
...
21
contact_name
john
08
22
_AIM_username
john16
john32
09
<-- Custom AIM_USERNAME
10
define service{
11
host_name
linuxserver
12
description
Memory Usage
13
_SNMP_community public
23
variable
24
_YahooID
<-- Custom YAHOOID variable

;
<-- Custom
25
...
26
Projekte
Datenmengen bergeben knnten. Durch die

Erhhung mssen sich die Benutzer keine SorALL DISKS OK - free space =27% to 84% | /=2643MB
gen mehr um knstlich verkrzte Ausgaben der
/ 15272 MB (77%)
Host- und Service-Check-Ergebnisse machen.
/boot 68 MB (27%)
Zweitens knnen Perl-Plugins nun optionale Direktiven enthalten, die Nagios explizit mitteilen,
/var/log 819 MB (84%) | /boot=68MB
ob sie der (optional) integrierte Perl-Interpre/var/log=818 MB
ter ausfhren soll. Dieses Feature ist besonders
ntzlich fr solche User, bei denen 90 % ihrer
Plugins von der hheren Geschwindigkeit des
integrierten Perl-Interpreters profitieren knALL DISKS OK - free space =27%
| to
/=2643MB
84%
nen, die aber auerdem ein paar Plugins einsetzen, die nicht besonders gut (oder gar nicht)
/ 15272 MB (77%)
mit dem integrierten Interpreter laufen. Diese
/boot 68 MB (27%)
Benutzer knnen nun die Ausfhrung pro Perl/var/log 819 MB (84%)
Plugin festlegen, welcher Interpreter zum Einsatz kommen soll.
/var/log=818 MB
Last, but not least untersttzt die Plugin-Spezifikation nun die Rckgabe von mehreren Zeilen
Output durch Host- und Service-Checks. Dieses
Textoutput ($SERVICEOUTPUT$)
Feature hatten sich in der Vergangenheit so viele
Performance Data ($SERVICEPERFDATA$)
User gewnscht, dass ich ganz sicher bin, dass es
bei den Benutzern gut ankommt. Die AbwrtsLong Text Output ($LONGSERVICEOUTPUT$)
kompatibilitt zu bestehenden Nagios-Plugins
bleibt brigens erhalten. Plugin-Ausgaben knAbbildung 2: Oft gewnscht, nun erfllt: Plugins knnen mehrere Zeilen
Information zurckgeben.
nen nun Folgendes enthalten:
neine Zeile mit kurzer Textausgabe und optiolichen Anforderungen in verschiedenen Organalen Performancedaten
nisationen viel Flexibilitt und Leistungsfhig- neine oder mehrere Zeilen mit optionaler zukeit. Viele User, die sich an den frhen Tests des
stzlicher Textausgabe
Nagios-3-Codes beteiligten, waren von diesem neine oder mehrere Zeilen mit optionalen zuneuen Feature begeistert.
stzlichen Performancedaten
Die Abbildung 2 zeigt ein Beispiel fr eine
Verbesserte Plugins
mehrzeilige Plugin-Ausgabe und deren UmsetAuch die Plugins erfahren in Nagios 3 etliche zung durch Nagios. Mehrere Zeilen mit zustzmerkliche Verbesserungen. Erstens wird die lichem Text speichert das neue Makro $LONGmaximale Lnge des Output, den der Nagios- SERVICEOUTPUT$ (Zeilenschaltungen schtzt
Daemon aus einem Plugin liest, von 350 Byte in es durch Escape-Zeichen), sofern dieses Plugin
Nagios 2.x auf 4 KByte in Nagios 3 erhht. Die fr einen Service-Check eingesetzt wird. Zuneue Beschrnkung auf 4 KByte, die sich bei Be- stzliche Zeilen mit Performancedaten hngt es
darf ohne weiteres erhhen lsst, dient in erster an die erste derartige Zeile an und speichert sie
Linie dem Schutz des Nagios-Daemon vor wild im Makro $SERVICEPERFDATA$. Die neuen,
gewordenen Plugins, die potenziell unendliche lngeren Plugin-Ausgaben lassen sich sowohl in
Tabelle 1: Benutzerspezifische Variablen
Objekttyp
Variablenname
Makroname
Host
Host
Service
Service
Contact
Contact
MAC_ADDRESS
RACK_NUMBER
SNMP_COMMUNITY
TECHCONTACT
AIM_USERNAME
YAHOOID
$_HOST_MAC_ADDRESS$ NAGIOS__HOST_MAC_ADDRESS
$_HOST_RACK_NUMBER$ NAGIOS__HOST_RACK_NUMBER
$_SERVICE_SNMP_COMMUNITY$ NAGIOS__SERVICE_SNMP_COMMUNITY
$_SERVICE_TECHCONTACT$ NAGIOS__SERVICE_TECHCONTACT
$_CONTACT_AIM_USERNAME$
NAGIOS__CONTACT_AIM_USERNAME
$_CONTACT_YAHOOID$
NAGIOS__CONTACT_YAHOOID
Umgebungsvariable
Projekte
aktiven als auch in passiven Host- und ServiceChecks einsetzen.
Benachrichtigungen
Unter Nagios 3 lassen sich Benachrichtigungen
nun bei Beginn, Ende oder Stornierung von geplanten Auszeiten fr Hosts oder Services bermitteln. Eine Benachrichtigung ist auerdem
mglich, wenn die Flap-Erkennung fr Hosts
oder Services deaktiviert wird.
Manchmal mchte man nicht sofort von einem
Problem mit einem Host oder einem Service
erfahren. Abwarten heit hier die Devise: Vielleicht erledigt sich das Problem ja auch von alleine, und das ist den meisten Admins allemal
lieber als eine Unterbrechung der Nachtruhe,
weil jemand ein Kinkerlitzchen als Problem
gemeldet hat. Um diesem Wunsch entgegenzukommen, gibt es nun eine Variable first_notification_delay, um Erstwarnungen verzgert
ausgeben zu knnen. Mithilfe der Variable definieren Sie die Verzgerung zwischen dem Auftreten eines problematischen Status und dem
Versenden der ersten Benachrichtigung. Vor
Nagios 3 musste man dazu komplexe Host- und
Service-Escalation-Definitionen einsetzen: Jetzt
lsst sich die gleiche Funktionalitt viel einfacher implementieren.
beroder untergeordneten Hosts aus, um den

aktuellen Status des Host schnell feststellen zu
knnen. Hngt der Host in Bezug auf Benachrichtigungen oder Checks von anderen Hosts ab,
lst Nagios auerdem parallele Prfungen dieser
Hosts aus, um sicher zu stellen, dass die Daten
ber Abhngigkeiten so aktuell und genau wie
mglich sind. Die Abbildung 3 zeigt parallele
Checks fr einen Host im Status DOWN oder
UNREACHABLE.
Nachdem es die parallelen Checks der beroder untergeordneten Hosts abgeschlossen hat,
kann Nagios sehr genau feststellen, ob der Host
ausgefallen oder unerreichbar ist. Die Unterscheidung zwischen diesen beiden problematischen Zustnden ist wichtig, weil Admins dadurch eine sehr genaue Diagnose erhalten.
Die neue Host-Check-Logik in Nagios 3 ist der
Logik der frheren Versionen stark berlegen,
sowohl in Bezug auf Leistung wie Genauigkeit.
Besonders deutlich wird dieser Vorteil bei Netzwerkausfllen in greren Umgebungen.
Performancesteigerungen
Nagios 3 enthlt weitere Performanceverbesserungen im Vergleich zu den bisherigen Releases. Bei vielen handelt es sich um Code-VerNagios
berarbeiteter Host-Check
In der Vergangenheit verursachten Host-Checks
die grten Performanceeinbuen im Monitoring-Prozess. Das ndert sich mit Nagios 3. Ich
habe mich dazu entschlossen die Host-CheckLogik komplett von Grund auf neu zu schreiben, und die bisherigen Ergebnisse zeugen von
deutlichen Performanceverbesserungen. Die
folgende Liste fhrt einige der nderungen der
Host-Check-Logik auf:
nHost-Checks laufen parallel, wie ServiceChecks.
nHost-Check-Retries knnen verzgert starten, wie Service-Checks.
nZeitgesteuerte Host-Checks knnen die Leistung sogar verbessern, statt sie zu beeintrchtigen.
nGecachete Host-Checks verbessern die Effizienz der Monitoring-Logik.
Einer der grten Performancevorteile der
neuen Host-Check-Logik rhrt daher, dass die
Host-Checks grtenteils parallel laufen. Wenn
Nagios eine Statusnderung bei einem Host
feststellt, lst es parallele Prfungen aller direkt
Up
Monitor_1
Not Up
Parallel Host Check
Host Depenency
Parent-Child-Relationship
Switch_1
File_1
Web_1
EMail_1
Router_1
Switch_2
Comp_2
Comp_1
Firewall_1
Switch_3
Router_2
Abbildung 3: In der nchsten Version wird Nagios im Bedarfsfall viele Hosts

parallel checken knnen, was sehr effizient ist.
Projekte
Nagios
Monitor_1
Switch_1
File_1
Web_1
EMail_1
Router_1
Switch_2
Comp_2
Comp_1
Firewall_1
Switch_3
Router_2
Abbildung 4: Nagios unterscheidet nicht erreichbare Hosts (orange) von

ausgefallenen (rot) und bercksischtigt den Unterschied bei Alarmen.
besserungen unter der Motorhaube, die sich bei

den meisten Benutzern als geringere CPU- und
Speicherauslastung niederschlagen. Es gibt auerdem ein paar konfigurierbare Performanceoptionen, die besonders von Vorteil sein knnen, wenn Sie eine groe Installation oder kom-
plexe Konfigurationsdateien berwachen mssen. Groe Nagios-Installationen profitieren

insbesondere von der neuen Option use_large_
installation_tweaks. Wenn Sie diese Option aktivieren, nutzt Nagios einige Abkrzungen, um
den mit der Durchfhrung einer groen Anzahl
von Host- und Service-Checks zusammenhngenden CPU-Overhead zu reduzieren. Dieses
einfache Performancetuning kann Ihnen helfen,
die Systemlast zu reduzieren.
Zu den weiteren konfigurierbaren Performancetweaks zhlen Optionen, die den Zeitaufwand
fr das Starten oder Neustarten des Nagios-Prozesses reduzieren knnen. Wenn Nagios startet,
muss es Ihre Konfigurationsdateien verarbeiten
und verifizieren, bevor es mit der berwachung
Ihrer Umgebung beginnen kann. Admins mit
groen Installationen setzen berdurchschnittlich oft auf erweiterte Konfigurationsfeatures,
wie die weiter oben besprochene Objektvererbung. Obwohl diese Konfigurationskniffe die
Verwaltung unter Umstnden vereinfachen, verlangen sie doch dem Nagios-Daemon beim Parsen mehr Arbeit ab. Das Suchen nach zyklischen
Pfaden in den Definitionen verursacht ebenfalls
ziemlich viel Overhead. Unter Nagios 3 knnen
Sie die Startup-Zeiten nun drastisch reduzieren,
indem Sie die Erkennung von zyklischen Pfaden
deaktivieren und die Objektkonfigurationsdateien zwischenspeichern. Um festzustellen, wie
viel Zeit diese beiden Optionen insgesamt ein-
Listing 5: Benchmark-Resultate
01
/usr/local/nagios/bin/nagios $$
20
Register:
2.654628 sec
02
-s /usr/local/nagios/etc/nagios.cfg
21
Free:
0.021347 sec
03
22
============
04
...
23
TOTAL:
11.555925 sec
05
= 8.393170 sec (72.63%) estimated savings
06
OBJECT CONFIG PROCESSING TIMES
24
07
(* = Potential for precache
25
Timing information on configuration
08
savings with -u option)
26
verification is listed below.
09
----------------------------------
27
10
Read:
0.486780 sec
11
Resolve:
0.004106 sec
29
(* = Potential for speedup with -x option)
12
Recomb Contactgroups: 0.000077 sec
30
----------------------------------
13
Recomb Hostgroups:
0.000172 sec
31
Object Relationships: 1.400807 sec
14
Dup Services:
0.028801 sec
32
Circular Paths:
54.676622 sec
15
Recomb Servicegroups: 0.010358 sec
33
Misc:
0.006924 sec
16
Duplicate:
5.666932 sec
34
============
17
Inherit:
0.003770 sec
35
TOTAL:
56.084353 sec
18
Recomb Contacts:
0.030085 sec
19
Sort:
2.648863 sec
28
CONFIG VERIFICATION TIMES
= 54.676622 sec (97.5%) estimated savings
Projekte
sparen, gibt der Befehlszeilenparameter -s

nun die fr die Verarbeitung der Konfiguration
bentigte Zeit aus. Eine verkrzte Ausgabe aus
einer Beispielkonfiguration mit 25 Hosts und
10000 Services ergab die Resultate, die Listing 5
prsentiert.
Auf Basis dieser Ausgabe hat Nagios etwa 68 Sekunden gebraucht, um meine Konfigurationsdateien zu verarbeiten und zu verifizieren. Indem
ich die Erkennung zyklischer Pfade deaktiviere,
kann ich etwa 55 Sekunden einsparen und durch
das Cachen der Konfigurationsdateien spare ich
weitere acht Sekunden ein.
Insgesamt lsst sich durch Aktivieren beider
Optionen die Startup-Zeit von 68 Sekunden auf
nur 5 Sekunden reduzieren.
Und das geht so:
1. Der Anwender startet Nagios mit der Befehlszeilenoption -s, um festzustellen, welche Zeitersparnisse erreichbar sind:
/usr/local/nagios/bin/nagios -s U
/usr/local/nagios/etc/nagios.cfg
2. Er verifiziert seine Nagios-Konfiguration und

cacht die Objektkonfigurationsdateien mit den
Befehlszeilenargumenten -vp:
/usr/local/nagios/bin/nagios -vp U
/usr/local/nagios/etc/nagios.cfg
3. Nagios startet als Daemon und erhlt durch

das Befehlszeilenargument -uxd die Anweisung, beide Performancetweaks anzuwenden:
/usr/local/nagios/bin/nagios U
-uxd /usr/local/nagios/etc/nagios.cfg
4. Vor jedem knftigen Neustart von Nagios ist

Schritt 2 fllig, der eine gecachete Objektkonfigurationsdatei generiert. Liee man diesen
Schritt aus, wrde Nagios weiterhin die alte
Objektdatei aus dem Cache einlesen. Im Effekt
blieben dadurch alle nderungen unbercksichtigt.
Die Nutzung dieser beiden Optionen fr den
schnelleren Start bietet besonders solchen Administratoren groe Vorteile, die Nagios aufgrund von regelmigen nderungen der eigenen oder kundenspezifischen Infrastruktur oft
neu starten mssen. In Kombination mit anderen Verbesserungen kann man davon ausgehen,
dass sich Nagios viel besser skalieren lsst als je
zuvor eine Nachricht, die fr Administratoren
in sehr groen Monitoring-Setups sicherlich
sehr willkommen ist.
berarbeitung der Zeitspannen

Die meisten Administratoren wird es freuen
zu erfahren, dass Nagios neue Definitionen fr
Zeitspannen erhalten hat. Obwohl die Spezifikationen der neuen Zeitspannendefinition noch
nicht abgeschlossen sind, plane ich die Implementierung einer Funktionalitt, die eine viel
genauere Steuerung ermglicht. Ein Beispiel
einer mglicherweise in Nagios 3 gltigen zeigt
Listing 6.
Erweiterte Zeitspannendefinitionen wie die Definition im obigen Beispiel bieten dem Administrator sehr viel Flexibilitt in der Zeitplanung
fr Benachrichtigungs-Services. Auerdem
knnen Sie Nagios leichter mitteilen, dass Sie
keine Alerts whrend der Ferien oder Ihres Urlaubs wnschen.
Die Zukunft
Ich bin gerade dabei, den Code und die Dokumentation fr die Nagios-3.0-Alpha-Release abzuschlieen. Groe Abschnitte der bestehenden
Dokumentation neu zu schreiben, ist sehr zeitaufwndig, aber ich bin mir sicher, dass dieser
Schritt letztendlich zu einem besseren Produkt
fhren wird Der Gedanke an die bevorstehende
Nagios-3.0-Release ist ziemlich aufregend, nicht
nur wegen der Verbesserungen, sondern auch in
Bezug auf die geplanten nderungen, nachdem
Nagios 3.0 sich stabilisiert hat.
Im nchsten Jahr knnen Sie sich auf die Verffentlichung einiger Tools freuen, welche die Synchronisierung der Daten in redundanten, Failover- und verteilten Monitoring-Umgebungen
zum Kinderspiel machen; auerdem beginnt die
Entwicklung eines neuen PHP-basierten Webinterface fr Nagios. Es ist eine spannende Zeit
in der Nagios-Entwicklung, und ich bin mir
ziemlich sicher, dass das Ergebnis einmal viele
Anwender zufriedenstellt. (jcb)
nnn
Listing 6: Neue Definitionen fr Zeitspannen

01
define timeperiod{
02
monday
; Jeden Montag (bereits implementiert)
03
tuesday 3
; am 3. Dienstag des Monats
04
thursday -1 nov
; am letzten Donnerstag in
November
05
day 21
; am 21. eines jeden Monats
06
july 4
; am 4. Juli
07
12-25-2007
; an einem bestimmten Kalenderdatum
08
Nagios
lernt zeichnen
Nagios bietet selbst keine Mglichkeit, Peformancewerte grafisch aufzubereiten. Mit Nagios Grapher
wird diese Funktion nachgerstet, ohne Nagios
selbst verndern zu mssen. Gerd Mller
Praxis
Viele Administratoren versuchen, die fehlende

grafische Aufbereitung von Performancedaten
in Nagios dadurch auszugleichen, dass sie auf
eigenstndige Softwareprojekte aus dem Umfeld
des Rrdtool von Tobias Oetiker [1] zurckgreifen. Das aber hat leider entscheidende Nachteile. Abgesehen von der nicht immer trivialen
Konfiguration der Zusatzsoftware, fragen damit
auch immer zwei Prozesse beim berwachten
System die Perfomancedaten ab. Das verursacht
die doppelte Last auf dem System und zustzlich
doppelten Datenverkehr. Was liegt nun nher,
als Nagios mit einem entsprechenden Statistiktool zu kombinieren? So entstand die Idee zum
Open-Source-Projekt Nagios Grapher.
Installation
Die aktuellste Version von Nagios Grapher bekommt man auf NagiosExchange [2]. Die Installation nach dem Auspacken braucht nur wenige
Schritte. Zuerst passt man die Konfiguration an
das laufenden System an. Bei einer Nagios-Standardinstallation aus den Sourcen in /usr/local/
nagios gelingt das mit:
autoconf
./configure
Ist Nagios an einem anderen Ort installiert, gengt es, das File config.layout entsprechend
anzupassen und die Konfiguration mit dem entsprechenden Layoutwert aufzurufen, etwa:
./configure --with-layout=debian
Nagios Grapher ist bis auf eine Ausnahme ein

reines Perl-Projekt und setzt daher einige PerlBibliotheken voraus. Ob das Zielsystem alle notwendigen Abhngigkeiten erfllt, lsst sich nun
einfach mittels make testdeps berprfen.
Fehlende Bibliotheken sollten sich am einfachsten ber Pakete der verwendeten Distribution
nachinstallieren lassen. Sind sie dort nicht vorhanden, bietet der Nagios Grapher die Mglichkeit, sie per CPAN zu beschaffen. Dazu reicht
ein make fixdeps.
Bei einigen Distributionen fehlt die Untersttzung von ImageMagick [3]. In diesem Fall ist
ImageMagick zuerst zu bersetzen und zu installieren. Auch sollte man daran denken, dass
Nagios Grapher auf der aktuellen Version 1.2.X
des Rrdtool aufbaut. Ob die eigene diesen Anforderungen gengt, lsst sich mit rrdtool -v
prfen. Ist sie zu alt, sind zwingend auch die
Sourcen des Rrdtool mit
Abbildung 1: Ein kleines klickbares Grapher-Icon fhrt im NagiosWebinterface direkt zur Kurvendarstellung.
./configure --enable-perl-site-install
zu konfigurieren und zu bersetzen.

Im Anschluss an diese Vorbereitungen steht der
eigentlichen Installation ber make install
nichts mehr im Wege. Am Ende befinden sich
alle wesentlichen Teile des Nagios Grapher an
ihrem Ort.
Was noch fehlt, ist ein passendes Init-Skript.
Dieses wird nicht mit installiert. Im Installationspaket unter contrib befinden sich jedoch
zahlreiche Beispiele fr verschiedene Distributionen. Allerdings muss der Installateur bei allen
Skripten die Pfade berprfen und die Skripte
in einen geeigneten Runlevel einbinden.
Nagios konfigurieren
Nach der erfolgreichen Installation sind nur
noch wenige Schritte notwendig, damit Nagios
Werte an den Nagios Grapher bermittelt. Die
Datei nagios.cfg braucht dafr folgende Eintrge:
cfg_dir=/usr/local/nagios/etc/serviceext
process_performance_data=1
service_perfdata_command=U
process-service-perfdata
Die Option service_perfdata_command legt

das Command fest, dass Nagios nach jedem Service-Check aufruft. Der Nagios Grapher nimmt
auf diesem Weg die Ergebnisse von jedem Service-Check entgegen, interpretiert sie und speichert die ermittelten Werte in den entsprechenden RRD-Datenbanken. Die Definition des Service-Command sieht wie folgt aus:
E
Listing 1: Auszug aus check_http.ncfg

01
define ngraph{
02
graph_value
http
03
graph_units
seconds
04
graph_legend
HTTP response time
05
rrd_plottype
AREA
06
rrd_color
c0c0ff
07
service_name
HTTP
08
graph_perf_regex
time=\s*(\d+\.\d+)
09
}
Praxis
unter /usr/local/nagios/etc/ngraph.ncfg und

zum anderen die Definitionen der Graphen.
Dazu aber spter mehr. Nahezu smtliche Einstellungen der Main Configuration passen fr
Nagios-Standardinstallationen wie voreingestellt. Dennoch verdienen folgende Parameter
eine kurze Erwhnung:
log_level
1023
use_authentication
yes
cfg_dir=/usr/local/nagios/etc/ngraph.d
Abbildung 2: Ein von Nagios Grapher automatisch gezeichnetes Diagramm.

define command{
command_name process-service-perfdata
command_line /usr/local/U
nagios/contribU
/udpecho 127.0.0.1 5667
}
Nach einem Neustart von Nagios und dem Start

von Nagios Grapher ist die Installation abgeschlossen. Als Nchstes ist die eigentliche Konfiguration des Nagios Grapher an der Reihe.
Nagios Grapher konfigurieren

Konfigurieren lsst sich der Grapher ber Textfiles, die hnlich strukturiert sind wie die NagiosKonfigurationsdateien. Jedoch tragen diese Files
eine andere Endung nmlich .ncfg . So ist
sichergestellt, dass Nagios sie nicht interpretiert.
Die Einstellungen des Nagios Grapher gliedern
sich in zwei Bereiche. Zum einen gibt es die so
genannte Main Configuration standardmig
Listing 2: Definition eines berechneten Graphen

01
define ngraph{
02
type
CDEF
03
graph_value
http_cdef
04
graph_calc
http_res
05
rrd_plottype
LINE1
06
rrd_color
000000
07
service_name
HTTP
08
}
Ein log_level von 1023 bedeutet, dass Nagios

Grapher smtliche Vorgnge im entsprechenden Logfile protokolliert. Vorsicht! Das kann zu
einem rasend schnell wachsenden Logfile fhren! Dieser Loglevel eignet sich zum Debuggen
neuer Graphen oder neuer Optionen, aber nicht
fr den laufenden Betrieb. Fr diesen empfiehlt
sich ein Wert von 7 als Loglevel.
Die zweite Einstellung, die immer wieder zu
Verwirrung fhrt, ist use_authentication. Nagios Grapher erlaubt dem User genau wie Nagios nur Zugriff auf Graphen von denjenigen
Hosts, bei denen der Anwender selbst als Kontakt eingetragen ist. Hufig wird diese Kontrolle
der Rechte jedoch ber einen zentral in der
cgi.cfg hinterlegten Masteruser (meist nagios oder nagiosadmin) umgangen. Dann
lsst Nagios diesen User smtliche Hosts und
Services betrachten, jedoch verweigert Nagios
Grapher verstndlicherweise den Zugriff auf die
Graphen. In diesem Fall schaltet use_authentication no die Authentifizierung komplett aus.
Der letzte oben erwhnte Parameter cfg_dir
verhlt sich exakt wie die Nagios-Option. Dieser
Parameter regelt wie erwartet das Startverzeichnis der Nagios-Grapher-Konfiguration. Ab diesem Verzeichnis liest Nagios Grapher smtliche
*.ncfg_Dateien ein. Obwohl der Parameter
per Default auf /usr/local/nagios/etc/ngraph.
d zeigt, ist das natrlich nderbar die Konfiguration lsst sich beliebig verteilen.
Der erste Graph

Nach dem Start analysiert der Nagios Grapher
automatisch smtliche Ausgaben der Plugins
von Nagios und versucht, sie zu erkennen und
dafr Graphen zu zeichnen. Wie funktioniert
das genau?
Im Prinzip ist es ganz einfach, erfordert aber
etwas Disziplin bei der Definition der Services.
Nagios-Plugins haben leider noch keine eindeutige ID, mit der es mglich wre, diese au-
Praxis
tomatisch zu erkennen. Auch gibt es noch kein

zentrales Verzeichnis fr die Plugins und deren
Ausgaben. Deshalb ist kein wirklicher Automatismus mglich. Der Nagios Grapher umgeht
diesen Mangel, indem er sich an der Service-Description der Services orientiert. Dort erkennt er
Services beziehungsweise ihre Plugins anhand
eines regulren Ausdrucks. Ein Beispiel: Services fr das Plugin check_http erkennt der
Nagios Grapher beispielsweise alleine an dem
Wort http in ihrer Service-Description.
Solch eine Zuordnung der Graphen zu den Services ist eine der wichtigsten Funktionen im
Nagios Grapher. So muss der Anwender nur ein
einziges Mal einen Graphen fr eine Gruppe
von Services mit gleichem Plugin anlegen. Jeder
Service, der dieser Definition entspricht, erzeugt
automatisch ohne Zutun des Administrators
einen neuen eigenen Graphen.
Wie wird nun solch ein Graph definiert? Bleiben
wir gleich bei dem HTTP-Beispiel. Angenommen, es ist ein Service mit der Service-Description http www.nagios definiert. Als Plugin
kommt check_http zum Einsatz. Nach dem
Ausfhren des Plugins erhlt Nagios beispielhaft
folgende Werte von ihm:
HTTP OK HTTP/1.1 200 OK -- 20628 bytes
in U
3.616 seconds
|time=3.615749s;;;0.000000
size=20628B;;;0
Vor dem Pipe-Symbol befindet sich die Ausgabe

des Services (Nagios-Makro: SERVICEOUTPUT), danach die Performancewerte (NagiosMakro: SERVICEPERFDATA). Damit msste
die Definition des Graphen wie in Listing 1 aussehen. Dieser Block stammt aus der mitgelieferten check_http.ncfg-Konfigurationsdatei.
Wofr stehen nun diese Parameter? Jeder Wert
bentigt einen eigenen, eindeutigen Namen,
den so genannten graph_value. Die Einheiten der y-Achse des Graphen legt graph_units
fest. Dagegen entspricht graph_legend der Legende des Graphen, rrd_plottype bestimmt,
ob eine Flche oder eine Linie zu zeichnen ist,
und rrd_color ordnet ihm die Farbe zu; service_name und graph_perf_regex sind regulre Ausdrcke nach Perl-Konvention.
Im Beispiel trifft die sehr einfache Regex http
bei service_name auf die Service-Description
http nagios.org zu. Die Regex bei dem Parameter graph_perf_regex ist komplexer. Sie
Abbildung 3: Die veredelte Version des Graphen. Eine feine schwarze Linie
schliet die Flche nach oben hin ab.
extrahiert den Wert aus einem Ausdruck wie

time=3.615749s, der innerhalb der bermittelten Performancedaten eintrifft. Dabei bedeutet
time=\s*(\d+\.\d+) in Worten: Den Rahmen
bildet eine Zeichenkette, in der auf das Wort
'time' und ein Gleichheitszeichen eventuell ein
Leerzeichen folgt, an das sich der gesuchte Wert
anschliet, der seinerseits aus mindestens einer
Ziffer vor und mindestens einer Ziffer nach einem Punkt besteht. Damit erkennt der Nagios
Grapher bei der oben gezeigten Plugin-Ausgabe
den Wert 3.615749 und speichert diesen in
der zugehrigen RRD-Datenbank.
Der Block in Listing 1 definiert also einen Wert,
der aus der Ausgabe des check_http-Plugins gefischt, gespeichert und in einem Graphen
dargestellt wird. Wichtig ist, dass ein Block immer nur genau fr einen Wert zustndig ist,
das heit, gibt ein Plugin nicht nur einen Wert
zurck, so sind entsprechend viele Blcke zu
definieren. Die Zahl der Blcke pro Service
entspricht auch der Menge der Werte pro Service innerhalb einer RRD-Datenbank. Die lsst
sich brigens zusammen mit dem Parameter
graph_value nicht nachtrglich verndern.
Daher ist es ratsam, fr smtliche Werte eines
Plugin einen Block zu definieren.
Damit nun der Nagios Grapher die Definition
neu einliest und die Graphen fr die HTTP-Services zeichnet, ist ein Neustart des Nagios Grapher ntig: /etc/init.d/nagios_grapher restart.
Zum Testen der Konfiguration empfiehlt es sich,
den jeweiligen Service ber ein Re-schedule
Next Service Check im Nagios-Webinterface
sofort neu prfen zu lassen. So kann man erkennen, ob die Definition funktioniert. Was passiert
dabei genau? Zuerst ruft Nagios das Plugin wie
Praxis
blich auf. Den Output des Plugin bergibt

anschlieend das Command process-serviceperfdata an den Nagios Grapher. Der Nagios
Grapher wiederum nimmt diese Ausgabe, erkennt an der Service-Description den dazuzugehrigen Graphen, ermittelt smtliche Werte
und speichert sie in einer neuen Rrdtool-Datenbank.
Auerdem wird fr jeden neuen Service mit
Graphen ein so genannter ServiceExt angelegt.
Den Pfad hierfr legt ngraph.ncfg fest. Dieses ServiceExt ist fr die Integration des Nagios
Grapher in das Nagios-Webinterface verantwortlich. Nach einem anschlieenden Reload
von Nagios befindet sich neben dem Service im
Nagios-Webinterface ein kleines Logo (Abbildung 1) des Nagios Grapher das per Klick direkt
zum entsprechenden Webinterface des Graphen
(Abbildung 2) fhrt.
Stattdessen ist der Parameter type zu definieren. Fr die Berechnung von neuen Werten
stellt das Rrdtool den Typ CDEF zur Verfgung.
graph_calc bedeutet nichts anderes, als dass
fr den Wert der Linie der Wert von http_res
benutzt wird. CDEF ist nur einer der vielen Typen, die das Rrdtool zur Verfgung stellt. Alle
untersttzten sind in der Dokumentation zum
Nagios Grapher zu finden.
Nach der Definition und einem Neustart wird
der Graph nun optisch ansprechender gezeichnet. Abbildung 3 zeigt den neuen Graphen. Alle
Elemente eines Graphen, die nicht zur Definition eines Wertes aus dem Plugin dienen, lassen
sich jederzeit hinzufgen oder entfernen. Diese
zustzlichen Definitionen funktionieren dann
nicht erst ab dem Zeitpunkt der Definition, sondern bereits rckwirkend ab dem ersten aufgezeichneten Wert.
Der Nagios Grapher bietet noch eine Flle weiterer Mglichkeiten, vor allem die Untersttzung
smtlicher Typen des Rrdtool (GPrint, VDEF,
Tick und so weiter) verdient Erwhnung. Fr
Interessierte bilden die mit dem Nagios Grapher
mitgelieferten Graphen einen guten Ausgangspunkt. Das Rrdtool als Basis des Nagios Grapher ist ebenfalls sehr gut dokumentiert. Es sind
smtliche verwendbaren statistischen Funktionen und Typen beschrieben. Zustzlich kann
der Nagios Grapher Graphen aus verschiedenen
Services in einem so genannten MultiGraph
kombinieren (Abbildung 4). Auch wie sich das
bewerkstelligen lsst, ist in der Dokumentation
ausfhrlich beschrieben. Ein typischer Anwendungsfall dafr ist der Vergleich zwischen verschiedenen Services.
Berechnete Graphen
Fazit
Natrlich kann der Nagios Grapher noch mehr,

als nur einfach bermittelte Werte wiedergeben.
So ist es unter anderem mglich, auch berechnete Werte innerhalb der Graphen zu zeichnen.
Ein sehr einfaches Beispiel ist ebenfalls in der
Beispielkonfiguration zum check_http-Plugin
(siehe Listing 2) enthalten.
Das Beispiel bedient sich eines einfachen optischen Tricks. Flchig gezeichnete Graphen sehen wesentlich besser aus, wenn der Graph mit
einer feinen Linie abgeschlossen wird. Der Wert
der schwarzen Linie ist dafr auszurechnen.
Weil er nicht direkt aus den Daten zu entnehmen ist, die das Plugin bergibt, braucht man
auch den Parameter graph_perf_regex nicht.
Dieser Artikel zeigt, dass der Nagios Grapher

nach etwas Einarbeitung recht leicht zu beherrschen ist. Auch wird jede Definition eines
Graphen schon beim zweiten dazu gehrigen
Service belohnt. So entsteht ein System, dass
einmal eingerichtet sich im Hintergrund ohne
weiteres Zutun des Administrators um smtliche Graphen kmmert. (jcb)
nnn
Abbildung 4: Ein so genannter Multigraph, der zwei verschiedene Werte

im Zeitverlauf vergleichen kann.
Infos
[1] Rrdtools: [http://oss.oetiker.ch/rrdtool/]
[2] NagiosExchange: [http://www.
nagiosexchange.org]
[3] ImageMagick: [http://www.imagemagick.org]
Nagios
lernt sprechen
Eine zuverlssige Mglichkeit, das Administrato-
renteam zu alarmieren ist ein Telefonanruf mit den

wichtigsten Informationen zu dem Problem und einem Sprachmen fr den Administrator. Michael Streb
Praxis
Systemfehler treten auch zu den ungnstigsten

Zeitpunkten auf. Typischerweise alarmiert die
Monitoring-Software Mitarbeiter im Bereitschaftsdienst per E-Mail oder SMS. Ein Problem
stellt dabei die fehlende Interaktivitt dar: Fr
den Absender bleibt in der Regel unklar, ob und
wann die Nachricht den richtigen Ansprechpartner erreicht hat.
Die Empfnger werden nur ber den Fehler informiert, kein Mitglied eines alarmierten Teams
bekommt Auskunft, wer sich gerade um die
Fehlerbehebung kmmert oder erfhrt einen genauen und aktuellen Status zur Fehlermeldung.
Abhilfe schafft hier die Alarmierung ber das
Telefon mit Hilfe der Open-Source-Telefonanlage Asterisk und freier Programme zur Sprachsynthese.
Dieser Workshop gibt einen Einblick in
die Installation von Asterisk und die Einrichtung
der
Sprachbenachrichtigungen
fr Nagios mit Hilfe der Tools Mbrola und
Txt2pho.
VoIP, SIP, ISDN...

Die vielfltigen Channeltreiber von Asterisk ermglichen es, Sprachnachrichten ber fast beliebige Telefonverbindungen zu versenden, unter anderem stehen Anrufe ber VoIP mit SIP,
ISDN, analoge Telefone oder einen Anlagenanschluss zur Verfgung. Das folgende Beispiel
nutzt fr die Benachrichtigung einen ISDN-Anruf aus dem Festnetz.
Hardwarevoraussetzung ist lediglich eine CAPIfhige und funktionsfhig konfigurierte ISDNKarte im Asterisk/Nagios-Server. Die Synthese
der Nachrichten bernimmt Mbrola in Kombination mit Text2pho. Beide Programme sind
frei verfgbar, solange man sie nicht kommerziell nutzt.
Ein Asterisk-Dialplan bildet die Reaktionsmglichkeiten der alarmierten Kontaktperson in
einem Men ab. Durch die Eingabe von Nummern besttigt der Angerufene die Annahme
des Problems und weist Nagios zum Beispiel an,
keine weiteren Alarmierungen mehr fr diesen
Fehler zu versenden.
Installation der Software
zum Einsatz. Auf dem Sarge-System werden

zustzlich lediglich die Development-Pakete libedit-dev, libssl-dev und zlib1g-dev bentigt.
Nach dem Entpacken des Asterisk-Quelltextes wird dieser mit make und make install
kompiliert und installiert. Ein anschlieendes
make samples erledigt die Installation der
Beispielkonfiguration. Der Telefonserver ist
einsatzbereit, sobald der Administrator das mitgelieferte Init-Skript aus dem Unterverzeichnis
der Asterisk Quellen ./contrib/init.d/rc.debian.
asterisk ins Standardverzeichnis der RunlevelSkripte /etc/init.d kopiert und mit chmod
0755 ausfhrbar macht.
ISDN-Treiber bersetzen
Die Verbindung zwischen Asterisk und CAPI-fhigen ISDN-Karten stellt der Treiber ChanCapi
[2] her. Die Installation aus dem Quelltext dieses
Paketes [3] bentigt auf dem System die Header
der Treiber aus dem Paket libcapi20-dev.
Nach der Installation mit make und make
install erzeugt das Kommando make install_
config eine funktionierende Beispielkonfiguration. Ein zustzlicher Eintrag in /etc/asterisk/
Listing 1: /etc/asterisk/modules.conf
01
load => res_features.so
02
load => chan_capi.so
03
04
[global]
05
chan_capi.so=yes
Listing 2: Txt2pho-Konfiguration
01
DATAPATH=/usr/local/mbrola/txt2pho/data/
02
INVPATH=/usr/local/mbrola/txt2pho/data/
03
TEMPPATH=/tmp/
04
05
# Default prosody (male or female)
06
INVENTORY=female
07
# Debuglevel
08
DEBUGLEVEL=0
09
# Reduction level
10
REDUCTION=0
11
# Prominence computation by rule or CART tree
Asterisk ist in den meisten aktuellen Distributionen enthalten, auch die Installation aus den
Quellen bereitet keine Schwierigkeiten mehr.
Fr das folgende Beispiel kommt die aktuelle
Version von Asterisk 1.2.15 [1] unter Debian
12
PROMCOMP=1
13
# Default speech rate
14
SPEECHRATE=1.50
15
# Duration computation
16
USENET=3
Praxis
modules.conf sorgt dafr, dass die Telefonanlage das Modul beim nchsten erfolgreichen
Start automatisch ldt (Listing 1). Die Reihenfolge der Eintrge spielt dabei eine wichtige
Rolle: chan_capi.so darf erst nach res_features.so geladen werden, sonst bringt Asterisk
beim Starten eine Fehlermeldung.
ChanCapi testen
Die Beispielkonfiguration von ChanCapi in
/etc/asterisk/capi.conf ist in den meisten Fllen ausreichend. Ob Asterisk das neue Modul
geladen hat, zeigt nach dem Start des Telefonservers die Ausgabe des CLI im interaktiven Debug Mode mittels asterisk -vvvvvgc.
Listing 3: call.pl
01
#!/usr/bin/perl -w
34
02
35
print_help ("") if($opt_h);
03
use strict;
36
($opt_n) || print_help("Number not specified\n");
04
use Getopt::Long;
37
($opt_m) || print_help("No message specified\n");
05
use vars qw($opt_n $opt_h $opt_m $opt_c $opt_H
38
($opt_C) || print_help("No channel specified\n");
$opt_S $opt_C $PROGNAME);
39
($opt_c) || print_help("No Callerid specified\
06
n");
07
my $tmp="/tmp/";
40
($opt_c) || print_help("No Host specified\n");
08
my $prefix="";
41
09
my $filename="$$";
10
my $asterisk_sounds=$prefix."/var/lib/asterisk/
sounds/voicealerts/";
11
my $asterisk_spool=$prefix."/var/spool/asterisk/
outgoing/";
12
my $txt2pho=$prefix."/usr/local/mbrola/txt2pho/
txt2pho -f -p ".$prefix."/usr/local/mbrola/
txt2pho/data/ ";
14
my $mbrola=$prefix."/usr/local/mbrola/mbrola
".$prefix."/usr/local/mbrola/voices/".$voice." ".$tmp.$filename.".wav";
15
my $sox="/usr/bin/sox ".$tmp.$filename.".wav
-t wav -r 8000 - > ".$asterisk_
47
my $output="";
49
$output.="MaxRetries: 2\n";
50
$output.="RetryTime: 60\n";
51
$output.="WaitTime: 30\n";
52
$output.="Context: Voicealerts\n";
53
$output.="Extension: s\n";
57
$output.="Set: CONTACT=$opt_n\n";
17
58
$output.="Set: HOST=".$opt_H."\n";
18
$PROGNAME = "call.pl";
59
$output.="Set: SERVICE=$opt_S\n";
19
60
open(OUT,"> ".$asterisk_spool.$filename.".call");
20
sub print_help($);
61
print OUT $output;
21
22
Getopt::Long::Configure('bundling');
23
GetOptions
46
56
$output.="Set: MSG=voicealerts/".$filename."\n";
".$tmp.$filename.".wav";
24 ("n:s" => \$opt_n, "number"
=> \$opt_n,
25
"c:s" => \$opt_c, "callerid"
=> \$opt_c,
26
"C:s" => \$opt_C, "channel"
=> \$opt_C,
27
"H:s" => \$opt_H, "host"
=> \$opt_H,
28
"S:s" => \$opt_S, "service"
=> \$opt_S,
=> \$opt_h, "help"
45
system("$unlink");
55
$output.="Callerid: $opt_c\n";
16
my $unlink="/usr/bin/unlink
"h"
44
system("$sox");
54
$output.="Priority: 1\n";
sounds.$filename.".wav";
30
rola;
43
system($syntax);
48
$output.="Channel: $opt_C\n";
13
my $voice="de3/de3";
29
42
my $syntax='echo "'.$opt_m.'"|'.$txt2pho.'|'.$mb
=> \$opt_h);
62
close(OUT);
63
64
exit 0;
65
66
sub print_help ($) {
67
my ($message) =@_;
68
print "Usage: $PROGNAME -n <number/name> -c
<callerid> -C <channel> -H <host> -S <service>\

n";
31
while(<STDIN>) {
69
print $message."\n";
32 $opt_m.=lc $_;
70
exit 0;
33
}
71
}
Praxis
Das Kommando capi info zeigt im Erfolgsfall

fr eine ISDN-Karte mit zwei B-Kanlen eine
Ausgabe wie die folgende:
Contr1: 2 B channels total, U
2 B channels free.
Das CLI des Asterisk-Servers beendet der Befehl

stop now.
Der Sprachsynthesizer Mbrola

Die Installation der Synthesesoftware Mbrola
[4] gestaltet sich einfach: Das Binary wird einfach nach /usr/local/mbrola entpackt.
Die Auswahl von Stimme und Sprache der Ansagen ist dem User vorbehalten, im folgenden
Beispiel wird die weibliche deutsche Stimme
de3 [5] verwendet.
Das Mbrola-Projekt der polytechnischen Fakultt der Universtitt Mons hat sich zum Ziel
gesetzt, mglichst viele Sprachen und Stimmen
zur Verfgung zu stellen, die umfangreiche Liste
auf [6] spiegelt zehn Jahre Arbeit wider. Eine Archivdatei mit Stimmen wird einfach in das Unterverzeichnis /usr/local/mbrola/voices extrahiert und steht sofort zur Verfgung.
In Verbindung mit Mbrola bringt das Texttospeech Frontend Txt2pho aus dem Hadifix-Projekt [7] der Universitt Bonn den installierten
Stimmen das Vorlesen der Alarmierungstexte
von Nagios bei. Das TTS-Frontend wird unter
[8] als Binrpaket zum Download angeboten;
die Installation erfolgt wie bei Mbrola durch
simples Entpacken des Archivs nach /usr/local/
mbrola. Listing 2 zeigt die Konfiguration fr
Txt2pho in /usr/local/mbrola/txt2pho/data/
hadifix.cfg.
Eine bessere Qualtit der Sprachausgabe frdie mnnlichen Stimmen bewirkt die Option
INVENTORY=male. Fr die Anpassung der
Sampling-Rate wird ein Soundtranslator bentigt. Sox ist in allen aktuellen Distribution enthalten und wird von Mbrola untersttzt.
Nagios lernt Asterisk
Abbildung 1: Anruf von Nagios an den Anschluss SIP/21, beobachtet von

der Asterisk-Konsole aus
Das Beispiel in Listing 4 zeigt ein derartiges

Callfile. In ihm sind die Informationen hinterlegt, die Asterisk zu Aufbau und Verarbeitung
eines Anrufes bentigt.
Fr Callfiles im Spooler-Verzeichnis initiiert
Asterisk automatisch Anrufe, die zugehrigen WAV-Dateien liegen in /var/lib/asterisk/
sounds/voicealerts.
Damit Nagios WAV-Dateien und Callfiles dort
hinterlegen kann, brauchen die Mitglieder der
Gruppe nagios Schreibrechte an den Verzeichnissen outgoing und voicealerts.
Nagios-Kommandos
In einer Konfigurationsdatei fr Nagios-Objekte
(typischerweise misccommands.cfg) mssen
die Kommando-Definitionen zur Erzeugung der
Sprachbenachrichtigung eingetragen werden.
In Listing 5 definieren die Zeilen, die mit command_line beginnen, den Aufruf von call.pl.
Das Skript erwartet den Alarmierungstext auf
Listing 4: Asterisk-Callfile
01
Channel: CAPI/ISDN1/1234
02
MaxRetries: 2
03
RetryTime: 60
04
WaitTime: 30
Die Asterisk-Konfiguration ist nun vollstndig,

die Integration in Nagios kann beginnen. Um
die Textnachrichten zu vertonen und an Asterisk weiterzugeben, dient das Skript call.pl
(Listing 3). Dieser Wrapper wandelt den Alarmierungstext mittels Txt2pho und Mbrola in
eine WAV-Datei um und erzeugt ein Callfile in
Asterisks Spooler-Verzeichnis /var/spool/asterisk/outgoing.
05
Context: Voicealerts
06
Extension: s
07
Priority: 1
08
Callerid: 110
09
Set: MSG=voicealerts/31764
10
Set: CONTACT=voice
11
Set: HOST=localhost
12
Set: SERVICE=VoiceTest
13
StartRetry: 31175 1 (1171128433)
Praxis
STDIN, zustzlich bergibt Nagios die Parameter fr Kontaktname, anrufende Nebenstelle

und anzurufende Nummer. In diesem Kontext
stehen dem Administrator auch Nagios-Makros
wie $HOSTNAME$ zur Verfgung. Aus den
bergebenen Parametern baut das Perl-Skript
WAV-Datei und Callfile und hinterlegt diese fr
Asterisk.
Der von Asterisk erzeugte Anruf wird nach dem

Abheben der Gegenstelle in den in der Datei
/etc/asterisk/extensions.conf definierten Asterisk-Kontext weitergeleitet.
Aus dem Dialplan in Listing 6 geht die Abarbeitung der Benachrichtigung hervor: Die Anweisung exten => s,1,Set(LOOP="54321") beispielsweise weist Asterisk an, die Nachricht fnf
Mal zu wiederholen. Die letzten sechs Zeilen
definieren die Aktionen, die der Angerufene zur
Verfgung hat: Beim Drcken der Taste 1 auf
dem Telefon wird der Fehler besttigt, mit der
Taste 2 die Alarmierung fr den entsprechenden
Service abgestellt. In beiden Fllen protokolliert
Asterisk als Kommentar den in Nagios definierten und an call.pl bergebenen Namen des
Kontaktes.
Der Anruf beim Administrator

Bei der Wahl des Benachrichtigungstextes ist es
sinnvoll, eine kurze Eingewhnungsphase an die
etwas holprige Stimme einzuplanen, bevor diese
die eigentlich wichtige Information ber den
Ausfall vorspricht. Vor allem bei berraschenden nchtlichen Alarmierungen sind lngere
Ansagetexte und Wiederholungen hilfreich.
Listing 5: Ergnzung misccommands.cfg

01
define command{
02
command_name
host-notify-by-voice
03
command_line
/usr/bin/printf "%b" "Dies ist eine Nachricht von Nagios. Der Host $HOSTNAME$.
mit der Addresse .$HOSTADDRESS$. Hat den Status .$HOSTSTATE$.
Die Details sind $HOSTOUTPUT$." | /usr/
local/nagios/contrib/nagios2asterisk/call.pl -n "$CONTACTNAME$" -c 110 -C "$CONTACTPAGER$" -H $HOSTNAME$

-S $HOSTNAME$
04
}
05
define command{
06
command_name
notify-by-voice
07
command_line
/usr/bin/printf "%b" "Dies ist eine Nachricht von Nagios.
Der Service
.$SERVICEDESC$. auf dem Host .$HOSTNAME$. mit der Addresse .$HOSTADDRESS$. Hat den Status
.$SERVICESTATE$.
Die Details sind $SERVICEOUTPUT$." /usr/local/nagios/contrib/nagios2asterisk/call.pl
-n "$CONTACTNAME$" -c 110 -C "$CONTACTPAGER$" -H $HOSTNAME$ -S $SERVICENAME$

08
}
Listing 6: Der Asterisk-Dialplan

01
[Voicealerts]
02
exten => s,1,Set(LOOP="54321")
; loop n times
03
exten => s,2,Set(GROUP()=voicealert)
04
exten => s,3,Set(TIMEOUT(response)=4)
; Wait for Digits
05
exten => s,4,Background(${MSG})
; Play Msg
06
exten => s,5,Background(nag2ast/acknowledge)
07
exten => s,6,Background(nag2ast/disablenotification)
08
exten => s,7,Set(LOOP=${LOOP:1})
; Loopcounter
09
exten => s,8,Gotoif($["${LOOP}x" != "x"]?4)
; Finished?
10
exten => s,9,Hangup
; Hangup
11
exten => 1,1,AGI(acknowledge.agi|${HOST}|${SERVICE}|${CONTACT})
12
exten => 1,2,Playback(nag2ast/acknowledged)
13
exten => 1,3,Hangup
14
exten => 2,1,AGI(disablenotifications.agi|${HOST}|${SERVICE}|${CONTACT})
15
exten => 2,2,Playback(nag2ast/disablednotifications)
16
exten => 2,3,Hangup
Praxis
Nag2ast
Die eigentlichen Aktionen fhren die Skripte
acknowledge.agi und disablenotifications.
agi aus. Sie geben das jeweils passende externe
Kommando an Nagios weiter. Asterisk erwartet
diese AGI-Skripte als ausfhrbare Dateien im
Verzeichnis /var/lib/asterisk/agi-bin.
Fr die standardisierten Ansagen der verfgbaren Aktionen, zum Beispiel Drcken Sie die 1,
um das Problem zu besttigen, verwendet Asterisk fertige WAV-Dateien aus dem Verzeichnis /var/lib/asterisk/sounds/nag2ast. Die hier
verwendeten AGI-Scripte, WAV-Dateien und
das call.pl-Skript sind auf der Webseite unter
[9] gesammelt.
Zu guter Letzt mssen den Kontakten in der
Nagios-Konfiguration noch die in Listing 5
definierten notification_commands host-notify-by-voice und notify-by-voice zugewiesen werden. Eine Kontaktdefinition mit fr Asterisk gltiger Pager-Definition zeigt Listing 7.
Nagios-Kontakte, die Asterisk per Sprachnachricht alarmieren soll, bentigen eine PagerAdresse. Diese muss einer von Asterisk verwendbaren Dial-Definition ohne Optionen entsprechen, damit Alarmierungen ber mehrere
verschiedene Kanle versendet werden knnen.
Das Listing verwendet fr ISDN CAPI/ISDN1/
Nummer, fr VoIP wre auch SIP/Nummer
mglich. Der neu angelegte oder vernderte
Kontakt wird in Nagios noch in eine Kontaktgruppe eingepflegt und diese wiederum einem
Service zugewiesen.
Nagios spricht
Fr einen besseren berblick ber die Vorgnge
bei einer Sprachbenachrichtigung durch Asterisk empfiehlt es sich, die Telefonanlage zu-
nchst erneut im Debug Modus zu starten. Abbildung 1 zeigt den Vorgang, wenn die Software
einen Admin auf dem Anschluss SIP/21 alarmiert. Wenn der von Nagios berwachte Service
den Status wechselt, wird sofort ein Callfile im
Asterisk Spooler-Verzeichnis erzeugt und ein
Anruf initiiert.
Nach erfolgreicher Installation der Sprachbenachrichtigungen sind der Kreativitt des Administrators keine Grenzen mehr gesetzt. In
weiteren mglichen Konfigurationen alarmiert
das Gespann Asterisk-Nagios eine Kette von
Administratoren nacheinander oder leitet den
Anruf von einem Administrator an den nchsten weiter. Die flexiblen Dial-Plne von Asterisk
bieten hier zahlreiche Mglichkeiten. (mfe)n nn
Infos
[1] Asterisk: [http://ftp.digium.com/pub/asterisk/
releases/asterisk-1.2.15.tar.gz]
[2] Webseite von ChanCapi: [http://www.melware.
org/ChanCapi]
[3] ChanCapi-Download: [ftp://ftp.chan-capi.org/
chan-capi/chan_capi-0.7.1.tar.gz]
[4] Mbrola-Download: [http://tcts.fpms.ac.be/
synthesis/mbrola/bin/pclinux/mbr301h.zip]
[5] Weibliche deutsche Stimme de3: [http://
tcts.fpms.ac.be/synthesis/mbrola/dba/de3/
de3-000307.zip]
[6] Mbrola-Stimmenauswahl: [http://tcts.fpms.ac.
be/synthesis/mbrola.html]
[7] Hadifix-Projekt: [http://www.ikp.uni-bonn.de/dt/
forsch/phonetik/hadifix/]
[8] Txt2pho: [http://www.ikp.uni-bonn.de/dt/forsch/
phonetik/hadifix/txt2pho.zip]
[9] Nag2ast: [http://www.nagiosexchange.org/
Notifications.35.0.html?&tx_netnagext_pi1[p_
Listing 7: Nagios-Kontakte
01
define contact{
02
contact_name
voice
03
alias
Sprachbenachrichtigung
04
service_notification_period
24x7
05
host_notification_period
24x7
06
service_notification_options
w,u,c,r
07
host_notification_options
d,r
08
service_notification_commands
notify-by-voice
09
host_notification_commands
host-notify-by-voice
10
email
nagios-admin@localhost
11 pager
CAPI/ISDN1/<Nummer>
12
}
Der Autor
Michael Streb ist als
Consultant fr
Netzwerk- und NagiosProjekte bei der
Netways GmbH in
Nrnberg angestellt. Er
beschftigt sich seit
zehn Jahren mit OpenSource-Software.
Komplexe Netzwerke berwachen
Nagios
und SNMP
Das freie Monitoring-Programm Nagios erfreut sich
bei Admins schon lange groer Beliebtheit. Doch
in komplexen Netzwerken mit redundanten Verbindungen, Clustern und SANs gilt es, neben Serverdiensten auch die Netzkomponenten zu berwachen. Sptestens hier kommt SNMP ins Spiel.
Jrg Linge
Praxis
Zum effektiven Betrieb eines Rechenzentrums

gehrt eine ausgiebige Systemberwachung der
immer komplexeren IT-Landschaften und Datenwege. Das freie Programm Nagios braucht
sich in diesem Umfeld nicht vor groen kommerziellen Lsungen zu verstecken. Passende
Nagios-Plugins [1] prfen einzelne Rechner
und Dienste komfortabel auf ihre Verfgbarkeit.
Doch die berwachung der Standarddienste
reicht lngst nicht mehr aus.
Server sind in heutigen Rechenzentren hochverfgbar ausgelegt: Netzwerkadapter verteilen
die Daten ber Bonding-Interfaces auf mehrere
Switches, Festplatten stellen ihren Speicher ber
ein SAN zentral zur Verfgung, das SAN selbst
erreichen Clients dank Fibre Channel (FC) oder
iSCSI ber mehrere Pfade alles ist auf Ausfallsicherheit getrimmt. Je redundanter die Systeme
aufgebaut sind, desto wichtiger ist die berwachung dieser redundanten Datenwege.
Neben dem Blick auf einzelne Rechner und
Serverdienste sollten Administratoren ihr Augenmerk also auch auf die berwachung der
Netzwerk- und SAN-Komponenten richten. In
der Regel lsst sich aber auf diesen geschlossenen Systemen keine zustzliche Software fr
diesen Zweck installieren so bleibt lediglich
das SNMP-Protokoll als einzige Mglichkeit
brig. Im Folgenden beschreibt der Autor an einem Beispielszenario, wie Nagios per SNMP die
Ports eines SAN-Switches berwacht.
SNMP-berwachung
Eine genaue Beschreibung des Szenarios findet
sich im Kasten Das Szenario. Da mindestens
zwei FC-Pfade die Server mit dem SAN verbinden, sollte die Software eventuelle Strungen
bereits im Vorfeld erkennen und melden. Die
Strungen lassen sich in der Regel auf den Servern selbst erkennen; allerdings laufen in vielen
Umgebungen die unterschiedlichsten Betriebssysteme auf den Servern.
Grundstzlich knnte ein Programmierer zwar
Nagios-Plugins fr alle Plattformen entwickeln,
es gibt jedoch noch eine einfachere Lsung: die
Prfung der Verfgbarkeit des SAN direkt am
SAN-Switch. Strungen lassen sich so am Status
der FC-Ports im Switch erkennen. Das Administrations-Frontend der Switches liefert zwar
detaillierte Informationen ber die einzelnen
Ports, leider kommt es als Java-Plugin daher
und dient damit nur schwerlich als Datenquelle
fr Nagios-Plugins.
Der Switch untersttzt aber SNMP Version 1,

optimal fr eine Nagios-Datenquelle. Das Nagios-Plugin-Paket enthlt das Plugin check_
snmp, das vom Programmpaket Net-SNMP
[2] abhngt. Wer das check_snmp-Plugin also
selbst kompilieren will, muss vorher die DevelPakete von Net-SNMP installieren.
Die Suche nach den MIBs

Bevor die berwachung beginnt, gilt es noch,
einige Vorarbeit zu leisten. Der Admin muss
festlegen, welche Informationen er fr die berwachung heranziehen will. Im Beispielszenario
soll ermittelt werden, ob alle Server mit allen
Pfaden im SAN erreichbar sind. Daher bietet es
sich an, den Status der Switch-Ports zu berwachen. Dafr sollten alle Ports eingeschaltet und
eine Verbindung zum Server hergestellt sein. Ein
Defekt in einem der empfindlichen Fibre-Channel-Kabel wrde durch die redundanten Wege
im SAN nicht weiter auffallen diese Situation
soll Nagios erkennen und rechtzeitig melden.
SNMP lsst sich auf dem SAN-Switch ber das
Admin-Interface einschalten. Danach beginnt
die Suche nach der passenden SNMP Management Information Base (MIB); sie beschreibt
einzelne Object Identifier (OID) des SNMPBaums. Danach prft der Admin, welche OIDs
den Status der zu testenden Ports darstellen.
Leider rckt nicht jeder Hersteller eine MIB
heraus. Die ersten Informationen liefert daher
der Switch ber eine einfache SNMP-Anfrage
mit dem Net-SNMP-Tool snmpwalk. Den
Aufruf und die Ausgabe zeigt Listing 1. Die
snmpwalk-Option -n stellt die OIDs in der
Ausgabe numerisch dar. Listing 1 zeigt, dass der
SNMP-Agent der Switches auf die EnterpriseOID 1588 reagiert. Als Enterprise wird der Bereich .1.3.6.1.4.1 (iso.org.dod.internet.private.
enterprise) bezeichnet. In diesem Bereich registrieren sich Hersteller einen eigenen OID-
Das Szenario
Die Basis fr diesen Artikel bildet ein Cluster
aus sechs Novell-Netware-6.5-Servern, die mit
einem zentralen SAN ber Fibre Channel verbunden sind. Die Disks der Cluster Volumes
stellt das SAN bereit. Zur Kopplung mit dem
SAN kommen zwei SAN-Switches vom Typ IBM
2104 F32 zum Einsatz. Die Server wiederum sind
jeweils mit beiden SAN-Switches verbunden.
Praxis
ntigt. Sie dient ausschlielich

dem Gewinn von Informationen ber die OIDs.
Nach der Auswahl einer MIB
mit dem Browser des MIBDepots lsst sie sich im Tree
Mode weiter analysieren. Bezieht sich ein OID-Bereich auf
eine dynamische Anzahl von
Eintrgen, so ist dieser Bereich
meistens in Form einer Tabelle
ausgefhrt. Die MIB-Tabelle
swFCPortTable scheint genau
der gesuchte Bereich mit den
Port-Informationen zu sein.
Die Port-Tabelle im Browser
hat, wie in Abbildung 1 zu seAbbildung 1: Von der Website des MIB-Depots [4] holen sich Admins Details ber die SNMPInformationen ihrer Gerte, falls die Hersteller keine nhere Beschreibung mitliefern.
hen, den OID-Bereich 1.3.6.1.
4.1.1588.2.1.1.1.6.2. Mit einem
Bereich bei der IANA. Die Suche nach der OID Aufruf des Tools snmpwalk auf diesen Bereich
.1.3.6.1.4.1.1588 auf [3] weist auf Brocade Com- lsst sich die Information verifizieren; Listing
munications Systems hin. Auf dem SAN-Switch 2 zeigt zugunsten der besseren Lesbarkeit mit
verrichtet also ein SNMP-Agent der Firma Bro- grep nur die Daten des ersten Ports an. Hiercade seinen Dienst. Diese Information erleich- bei offenbart sich auch die Tabellenstruktur: Die
tert die Suche erheblich.
OID .1.3.6.1.4.1.1588.2.1.1.1.6.2.1.1.1 enthlt
den Wert INTEGER: 1 und referenziert somit
MIB-Lager
den ersten Port. Jede weitere OID in dieser TaAuf der Webseite des MIB-Depots [4] findet man belle, die mit dem Wert 1 endet, bezieht sich
ber die Suche nach der OID .1.3.6.1.4.1.1588 damit wieder auf Port 1.
oder dem Hersteller Brocade recht schnell die
SW-MIB v4_0SW.mib. Da sich der Switch, wie Informationen fr Nagios
in Listing 1 zu sehen, mit der Firmware-Version Fr die Aufgabenstellung kommen auf den
4.4.0 meldet, fllt die Wahl auf diese MIB. Der ersten Blick drei OIDs aus der MIB-Tabelle
Browser des MIB-Depots eignet sich wunderbar swFCPortTable in Frage (siehe Abbildung 1):
fr die weitere Analyse. Die MIB selbst wird auf swFCPortPhyState (3), swFCPortOpStatus
dem Nagios-Server zur berwachung nicht be- (4) und swFCPortAdmStatus (5). Die Zahl
in Klammern bezeichnet die relevante Stelle
in den OIDs. Zusammengefasst ergibt sich fr
Listing 1: snmpwalk
swFCPortPhyState des ersten Ports die OID
01
nagios@kassandra:~> snmpwalk -On -v1 -c public san-mb
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3.1.
enterprises
Diese OID liefert den Integer-Wert 6 (siehe
02
...
Listing 2). Um zu erkennen, was dieser Wert
03
.1.3.6.1.4.1.1588.2.1.1.1.1.4.0 = STRING: "Mon Mar 14
bedeutet, gengt ein Klick auf den Link
16:07:28 2005"
swFCPortPhyState im MIB-Depot. Ein Port
04
.1.3.6.1.4.1.1588.2.1.1.1.1.5.0 = STRING: "Mon Mar 14
kann neun unterschiedliche Zustnde anneh16:06:11 2005"
men. Welcher Wert fr Nagios welchen Status
05
.1.3.6.1.4.1.1588.2.1.1.1.1.6.0 = STRING: "v4.4.0b"
darstellt, bleibt dem Administrator berlassen.
06
.1.3.6.1.4.1.1588.2.1.1.1.1.7.0 = INTEGER: 1
Der Status inSync mit dem Wert 6 steht je07
.1.3.6.1.4.1.1588.2.1.1.1.1.8.0 = INTEGER: 1
doch eindeutig fr den Normalzustand und lie08
.1.3.6.1.4.1.1588.2.1.1.1.1.9.0 = INTEGER: 0
fert dementsprechend ein OK.
09
.1.3.6.1.4.1.1588.2.1.1.1.1.10.0 = STRING: "10:00:00:60:69
Zustzlich knnte der Status noGbic mit dem
:90:16:26"
Wert 2 auch einen OK-Status darstellen, denn
10
...
nicht in jedem Port am Switch muss ein GBIC
Praxis
stecken. Nagios liefert in diesem Fall bei leeren

Ports einfach ein OK-Signal zurck. Setzt der
Admin einen GBIC ein, beginnt automatisch die
berwachung.
SNMP-Plugin
Im nchsten Schritt kommt das Plugin check_
snmp zum Einsatz. Bei der gestellten Aufgabe
erreicht der Sysadmin damit aber schnell die
Grenzen des Machbaren. Die WARNINGund CRITICAL-Schwellwerte stellt er ber
die Optionen -w und -c ein. Solange nur der
Wert 6 als OK-Status dient, reicht ein -w :6 -c
6:. Das bedeutet aber, dass alle Werte kleiner als
6 einen CRITICAL-Status und alle Werte ber
6 einen WARNING-Status erzeugen.
Diese Variante ermglicht es nicht, weitere
Werte als OK-Status zu definieren. Bleibt die
Option -r. Ein Aufruf von check_snmp
mit -r [2,6] liefert einen CRITICAL-Status
bei Werten ungleich 6 oder 2. Das kommt der
Anforderung schon recht nahe. Mit -L "Fibre
Channel Port" lsst sich zustzlich ein Label
angeben. Die Ausgabe Fibre Channel Port OK
- 6 sagt schon mehr aus als SNMP OK - 6.
Aus den bis jetzt gesammelten Informationen
ergibt sich folgender Aufruf des Plugin:
check_snmp -H <I>Hostname<I> -C U
<I>Community<I> -o .1.3.6.1.4.1.U
1588.2.1.1.1.6.2.1.3.1 -r [2,6] U
-l "Fibre Channel Port"
Das Plugin liefert daraufhin die Ausgabe Fibre

Channel Port OK - 6 | iso.3.6.1.4.1.1588.2.1.1.1.
6.2.1.3.1=6;;;;.
Jetzt fehlt nur noch die Einbindung des Aufrufs
in die Nagios-Konfiguration. Dazu definiert der
Administrator ein neues Check-Command und
fr jeden Switch-Port eine Service-Definition.
Die Service-Definitionen sollten so einfach wie
mglich aussehen, um die Konfiguration nicht
unntig zu erschweren. Dabei landen alle Optionen, die sich nicht verndern, in der Command-Definition:
define command {
command_name check_brocade_port
command_line $USER1$/check_snmp U
-H $HOSTADDRESS$ -C $USER3$ U
-l "Fibre Channel Port" -r [1,6] -o U
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3.$ARG1$
}
Die Angabe der Community stellt hier eine

Besonderheit dar. Damit der SNMP-Commu-
Listing 2: Informationen verifizieren

01 s
nmpwalk -On -v1 -c public san-mb 1.3.6.1.4.1.1588.
2.1.1.1.6.2 | grep "\.1 ="
17
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.19.1 = Counter32:
15239754
02 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.1.1 = INTEGER: 1
03 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.2.1 = INTEGER: 4
18
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.20.1 = Counter32:
47319301
04 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3.1 = INTEGER: 6
19
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.21.1 = Counter32: 0
05 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.4.1 = INTEGER: 1
20
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.22.1 = Counter32: 0
06 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.5.1 = INTEGER: 1
21
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.23.1 = Counter32: 0
07 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.6.1 = INTEGER: 1
22
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.24.1 = Counter32: 0
08 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.7.1 = INTEGER: 3
23
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.25.1 = Counter32: 0
09 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.11.1 = Counter32:
24
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.26.1 = Counter32:
878380176
6815394
10 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.12.1 = Counter32:
17155371
25
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.27.1 = Counter32: 0
26
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.28.1 = Counter32: 0
11 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.13.1 = Counter32:
2426871545
27
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.29.1 = Counter32: 0
28
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.30.1 = Counter32: 0
12 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.14.1 = Counter32:
3245433487
29
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.31.1 = Counter32: 0
30
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.32.1 = Counter32: 0
13 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.15.1 = Counter32: 0
14 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.16.1 = Counter32:
3245433487
31
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.33.1 = Hex-STRING:
00 00 00 00
32
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.34.1 = Hex-STRING:
15 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.17.1 = Counter32: 0
16 .
1.3.6.1.4.1.1588.2.1.1.1.6.2.1.18.1 = Counter32: 0
20 00 00 60 69 90 16 26
33
.1.3.6.1.4.1.1588.2.1.1.1.6.2.1.35.1 = INTEGER: 3
Praxis
nity-String nicht ber das Nagios-Webfrontend

einsehbar ist, wird er als Macro $USER3$ in
der Nagios-Konfigurationsdatei resource.cfg
definiert. Die Definition der einzelnen Services
gestaltet sich nun nicht weiter schwierig.
Die Parameter beschrnken sich auf die Angabe

des Check-Commands und der Port-Nummer.
Letztere erhlt Nagios als erstes Argument ber
$ARG1$. Daraus ergibt sich die richtige OID
zur Abfrage des Port-Status:
Listing 3: Perl-SNMP-Plugin
39
my $swFCPortRxWords = ".1.3.6.1.4.1.1588.2.1.1.1.
01
#! /usr/bin/perl -w
02
# nagios: +epn
6.2.1.12.$opt_P";
03
use strict;
40
04
use Getopt::Long;
41
my $result = $session->get_request(
05
use Net::SNMP;
42
06
07
my $opt_C="public";
43
);
08
my $opt_H="";
44
09
my $opt_p=161;
45
$session->close;
10
my $opt_P=1;
46
11
my $opt_t="5";
47
if (!defined($result)) {
12
13
Getopt::Long::Configure('bundling');
14
GetOptions(
15
"C=s" => \$opt_C, "community"
=> \$opt_
"H=s" => \$opt_H, "hostname"
=> \$opt_
"p=i" => \$opt_p, "port"
=> \$opt_
"P=i" => \$opt_P, "fc_port"
=> \$opt_
"t=i" => \$opt_t, "timeout"
=> \$opt_
C,
16
H,
17
p,
18
P,
19
t,
22
print "UNKNOWN: No Hostname specified\n" and exit
3 if(!$opt_H);
exit 1;
50
}
51
52
my $PerfData =
"|TxWord=$result->{$swFCPortTxWords}c;;;;
RxWord=$result->{$swFCPortRxWords}c;;;;";
53
54
55
for ($result->{$swFCPortPhyState}){
56
if (/1/){ print "CRITICAL: No Card found in Port
$opt_P (id=$_) $PerfData\n" and exit 2;};
58
if (/3/){ print "CRITICAL: Laser fault on Port
59
if (/4/){ print "CRITICAL: Port $opt_P is not
23
24
# Just in case of problems, let's not hang Nagios
25
$SIG{'ALRM'} = sub {
print ("UNKNOWN: Connection to $opt_H timed
out\n");
recieving Light (id=$_) $PerfData\n" and exit

2;};
60
if (/5/){ print "CRITICAL: Port $opt_P is not in
Sync (id=$_) $PerfData\n" and exit 2;};
61
if (/6/){ print "OK: Port $opt_P is in Sync
exit 3;
(id=$_) $PerfData\n" and exit 0;};
28
};
62
if (/7/){ print "CRITICAL: Power fault on Port
29
alarm($opt_t);
30
31
my ($session, $error) = Net::SNMP->session(
32
-hostname
=> $opt_H,
33
-community => $opt_C,
34
-port
=> $opt_p,
63
if (/8/){ print "CRITICAL: Diag Fault on Port
64
if (/9/){ print "CRITICAL::Lock Ref on Port $opt_
P (id=$_) $PerfData\n" and exit 2;};
35
);
65
}
36
66
37
my $swFCPortPhyState = ".1.3.6.1.4.1.1588.2.1.1.1
67
print "UNKNOWN: State id
.6.2.1.3.$opt_P";
38
my $swFCPortTxWords = ".1.3.6.1.4.1.1588.2.1.1.1.
6.2.1.11.$opt_P";
printf("ERROR: %s.\n", $session->error);
49
(id=$_) $PerfData\n" and exit 0;};
21
27
48
57
if (/2/){ print "OK: No Gbic found in Port $opt_P
20
);
26
-varbindlist => [$swFCPortPhyState,
$swFCPortTxWords, $swFCPortRxWords]
$result->{$swFCPortPhyState} not known for Port

$opt_P\n";
68
exit 3;
Praxis
Define service {
...
service_description fc_port1
check_command
check_brocade_port!1
....
}
Eigene Plugins
Die Aufgabenstellung ist hiermit vorerst erfllt.
Nagios erzeugt einen Alarm, wenn die SwitchPorts nicht den Wert 2 fr noGbic oder 6 fr
inSync liefern. Diese Lsung weist aber noch
einige Unzulnglichkeiten auf: So weist der numerische OID-Wert nicht auf das eigentliche
Problem hin. Bessere wre hier eine Umwandlung in einen aussagekrftigen Text. Dafr eignet sich das Plugin check_snmp jedoch nicht.
Es liegt also nahe, diese Aufgabe durch ein selbst
entwickeltes Plugin zu erledigen.
Die sehr einfache Nagios-Schnittstelle zum
Entwickeln eigener Plugins erweist sich hier als
hilfreich. Es gibt nur wenige Anforderungen, die
ein Plugin fr die Kommunikation mit dem Nagios-Daemon erfllen muss. Genaue Informationen bietet ein eigener Artikel in dieser Ausgabe
sowie die Website der Nagios-Plugins [5] und
das deutschsprachige Wiki [6].
Nagios interpretiert nur die erste Zeile der Plugin-Ausgabe. Alle ntigen Informationen mssen also bereits hier stehen. Den Status ermittelt
Nagios ber den Rckgabewert; beendet sich ein
Plugin mit dem Wert 0, so ergibt dies in Nagios den Status OK der Returncode 1 steht
fr den Status WARNING und 2 fr CRITICAL. Eine Besonderheit stellt der Returncode 3 (UNKNOWN) dar. UNKNOWN
sollte ein Plugin immer dann liefern, wenn interne Fehler in der Verarbeitung auftreten.
Dies sind schon die grundlegenden Eigenschaften eines Plugins, die verwendete Programmiersprache hngt von den eigenen Kenntnissen ab.
Jedoch sollten Entwickler stets auf die Ausfhrungsdauer achten. Ein Plugin, das von Nagios
aktiv aufgerufen wird, sollte so schnell wie mglich ein Ergebnis liefern. Langsame Plugins fhren oft zu einer hohen Service Check Latency.
Daraus resultiert, dass Nagios den Check nicht
mehr zum geplanten Zeitpunkt ausfhrt. Plugins, die schon im Normalzustand lnger als zwei
Sekunden zur Ausfhrung bentigen, sollte der
Programmierer dringend berarbeiten oder als
passiven Check [7] implementieren.
Perl bietet sich als Skriptsprache fr das geplante

Nagios-Plugin durch die gute SNMP-Integration
ber das Modul Net::SNMP an. Listing 3 zeigt
ein Plugin, das die gestellten Aufgaben komplett
erfllt: Der Code in Zeile 5 ldt das Perl Modul Net::SNMP. Die SNMP-Abfrage knnte das
Skript auch durch Aufruf von snmpget durchfhren; zugunsten der Performance sollten Programmierer aber darauf verzichten.
SNMP-Check mit Perl

Die Zeilen 7 bis 20 definieren die Standardwerte
und Optionen, die das Skript beim Aufruf bernimmt. Wichtig fr einen reibungslosen Betrieb
auch im Falle eines Fehlers ist die Timeout-Funktion in den Zeilen 24 bis 29. Sollte der
Switch durch einen Netzwerkfehler oder hnliches nicht antworten, bricht das Plugin nach
fnf Sekunden ab.
Nagios erhlt durch den Returncode 3 den
Status UNKNOWN. Die SNMP-Abfragen
fhrt der Code in den Zeilen 30 bis 45 aus. Er
fragt drei OIDs ab, die in den Zeilen 37 bis 39
definiert werden. Die OID fr den Port-Status
aus Zeile 37 ist bereits aus dem ersten Beispiel
bekannt. Die beiden zustzlichen OIDs beinhalten die Anzahl der empfangenen (Rx) und
gesendeten (Tx) Blcke. Diese Daten haben
keinen Einfluss auf den Status des Plugin, sie
werden nur fr statistische Zwecke ausgelesen,
dazu spter mehr. Ab Zeile 47 gibt das Plugin
den entsprechenden Text aus und beendet sich
mit dem passenden Rckgabewert. Die Definition des Nagios-Check-Command fllt durch
ein spezialisiertes Plugin deutlich einfacher aus:
define command {
command_name check_brocade_port
command_line $USER1$/check_brocade.pl U
-H $HOSTADDRESS$ -C $USER3$ -P $ARG1$
}
Die Definition der Services ndert sich dank der

Verwendung von Makros nicht.
Performancedaten sammeln
Nagios zerlegt wenn mglich die Ausgabe
von Plugins in zwei Teile. Als Trennzeichen
dient dabei das Pipe-Symbol |. Der linke Teil
der Ausgabe wird als Plugin-Output bezeichnet,
der rechte Teil kennzeichnet so genannte Performancedaten. Sie haben zwar keinen Einfluss auf
den Status innerhalb von Nagios, jedoch verfgt
Nagios ber eine Schnittstelle, die diese Perfor-
Praxis
tionen im Falle eines Fehlers erhalten, desto schneller ordnen sie

die Quelle zu und beseitigen das
Problem. Abbildung 2 zeigt, wie
sich mit dem Programm Nagvis
[12] der Aufbau eines Novell-Netware-Clusters grafisch darstellen
lsst. Ein eigener Artikel in diesem Heft beschreibt nher, wie
sich Nagvis in eine vorhandene
Nagios-Installation einbettet.
Doch auch beim Einsatz grafischer bersichten mit Nagvis
sollten die Verantwortlichen nicht
auf schriftliche Dokumentation
verzichten. Anleitungen zum Einbinden von Wikis fr Dokumentationszwecke bietet das deutsche
Nagios-Wiki [6].
Fazit
SNMP erweist sich fr die berwachung eines unbersichtlichen Systems mit Nagios als sehr
hilfreiches Protokoll. Administratoren knnen nach einer kurzen Einarbeitungsphase durchaus ruhiger schlafen whrend
Nagios seinen Dienst tut. Sollte doch ein Fehler
auftreten, bleibt alle Zeit der Welt, um das Problem in Ruhe zu lsen. (mwe)
nnn
Abbildung 2: Nagvis visualisiert das System und hilft, Fehler schnell zu lokalisieren. Ein grnes Icon zeigt den Normalstatus an, bei roten Symbolen gibt es Handlungsbedarf.
mancedaten an zustzliche Add-ons bergibt.

Meist handelt es sich dabei um Programme, die
die Daten auswerten und fr Langzeitstatistiken
aufbewahren.
Die bekanntesten Vertreter dieser Tools sind der
Nagios Grapher [8], PNP [9], N2rrd [10] und
Perf Parse [11]. Diese Tools stellen die bergebenen und gespeicherten Daten grafisch dar und
verknpfen sie im Nagios Webfrontend mit dem
dazugehrigen Service. Durch die Zeile 52 in
Listing 3 erhlt der Admin durch eines der genannten Tools eine Langzeitstatistik ber den
Datendurchsatz der einzelnen Switch-Ports.
Auch wenn diese Werte zu keinem Alarm fhren, so geben die Graphen doch Aufschluss ber
den Datenfluss. Sollen die Fibre-Channel-Karten der Server im Loadbalancing-Betrieb laufen,
so lsst sich die Verteilung der Daten ber die
Graphen leicht erkennen.
Dokumentation
Das Skript lst die Aufgabe sehr komfortabel;
es berwacht die beiden Switches mit jeweils 32
Ports und gibt aussagekrftige Meldungen zurck. Doch was bedeutet die Information ber
Fehler auf einem Switch-Port? Wie schnell muss
reagiert werden? Welcher Server hngt an diesem Port? Je rascher die Admins diese Informa-
Infos
[1] Nagios-Plugins:
[http://nagiosplug.sourceforge.net]
[2] Net-SNMP: [http://net-snmp.sourceforge.net]
[3] Liste der Enterprise-Nummern bei der
IANA: [http://www.iana.org/assignments/
enterprise-numbers]
[4] MIB-Depot: [http://www.mibdepot.com]
[5] Entwickeln eigener Plugins: [http://nagiosplug.
sourceforge.net/developer-guidelines.html]
[6] Deutsches Nagios-Wiki:
[http://www.nagios-wiki.de]
[7] Passive Checks mit Nagios: [http://nagios.
sourceforge.net/docs/2_0/passivechecks.html]
[8] Nagios Grapher: [http://www.nagiosexchange.
org/NagiosGrapher.84.0.html]
[9] PNP: [http://www.ederdrom.de/doku.php/
nagios/pnp]
[10] N2rrd: [http://n2rrd.diglinks.com]
[11] Perf Parse: [http://perfparse.sourceforge.net]
[12] Nagvis: [http://www.nagvis.org]
Nagios-Werkstatt:
Eigenbau von Perl-Plugins
Das riesige Angebot fertiger Lsungen ist eine
der groen Strken von Nagios. Wo selbst das
nicht reicht, ist es aber auch nicht schwer, den
Bedarf mit selbst geschriebenen Skripten zu decken. Wolfgang Barth
Praxis
Nagios lsst prfen. Das heit, es kmmert sich

nicht selbst darum, ob ein bestimmter Dienst
verfgbar und leistungsfhig ist, sondern delegiert diesen Testjob an kleine Helfer, die so
genannten Plugins. Das sind einfache, spezialisierte Prfprogramme, die, mit ein paar Argumenten auf der Kommandozeile aufgerufen,
einen Statuscode zusammen mit einem einzeiligen Text zurckliefern:
nagios@swobspace:~/libexec$./check_smtp U
-H 192.168.1.9
SMTP OK - 0.021 sec. response time|U
time=0.020599s;;;0.000000
Die Ausgabe erfolgt immer nach dem Schema

Art_des_Checks Status - Information. Der Text
nach dem Minuszeichen ist in erster Linie als
Information fr den Administrator gedacht. Er
kann etwa in einer Weboberflche oder in einer Nachricht Verwendung finden. Hinter dem
Pipezeichen | folgen Performancedaten dazu
spter mehr. Nagios selbst wertet einzig und allein den Rckgabewert aus: Dabei steht der Wert
0 fr OK, 1 bedeutet WARNING, 2 CRITICAL und 3 UNKNOWN.
Whrend die ersten drei Zustnde die WebGUI von Nagios stellt sie in den Farben Grn,
Gelb und Rot dar sich selbst erklren, hat der
Zustand UNKNOWN eine besondere Bedeutung. Er signalisiert ein Problem beim Ausfhren des Plugins. Der Test lief nicht, der tatschliche Zustand des Services ist unbekannt. In der
Weboberflche wird das durch die Farbe Orange
signalisiert (siehe Abbildung 1).
Fertige Lsungen fr fast jede

berwachungsaufgabe
Mit den offiziellen Nagios-Plugins des Maintainers Ton Voon von der Nagios-Homepage wird
bereits ein umfangreicher Werkzeugkasten mitgeliefert. Wer jeweils den aktuellsten Stand einsetzen mchte, kann sich diesen von [1] herunterladen und mit dem Dreisatz configure &&
make && make install selbst installieren.
Eine weitere Mglichkeit, an unzhlige fertige

Plugins zu kommen, ist die offizielle NagiosTauschbrse [2], die die Netways GmbH bereitstellt. Trotz des groen Angebots findet man in
seltenen Fllen dennoch nichts Passendes. Das
ist aber kein Beinbruch. Plugins selbst zu schreiben, ist zum Glck nicht besonders schwer, vorausgesetzt, man beherrscht eine Skriptsprache
wie die Bash oder Perl einigermaen. Dieser
Artikel beschreibt die Grundlagen der PluginProgrammierung in Perl. Die hier vorgestellten
Codebeispiele sind unter [3] verfgbar.
Plugins nach dem

Baukastenprinzip
Jedes Plugin setzt sich aus mehreren Funktionsgruppen zusammen (Abbildung 2). Ganz
zu Anfang analysiert es seine Kommandozeile
und ermittelt die Aufrufparameter. Dabei sollte
es auch gleich deren Syntax (Vollstndigkeit der
Angaben) und wenn mglich Semantik (Zulssigkeit der bergebenen Werte) prfen. Danach
folgt der eigentliche Test, der den Zustand eines
Services ermittelt. Das Ergebnis wird wie beschrieben als Text und mit einem Rckgabewert
ausgegeben.
Ein ordentliches Plugin enthlt auerdem eine
Onlinehilfe. Falls es Messwerte ermittelt, sollte
es sie auch als Performancedaten in standardisierter Form weiterreichen. Abgesehen von den
eigentlichen Funktionstests, lassen sich alle anderen Funktionen weitgehend standardisieren.
Fr Standardaufgaben hat Perl seine praktischen
Module die Analyse der Kommandozeile erledigt etwa das Modul GetOpt::Long.
Es gibt einige reservierte Optionen (Tabelle 1),
die nur fr einen festgelegten Zweck benutzbar
sind. Alle anderen darf man beliebig benennen.
Eine Manpage lsst sich als Perl-Online-Dokumentation (POD) gleich in den Quellcode einbauen. Zustzlich kann das Modul Pod::Usage
diese Online-Dokumentation auch als Kurzhilfe
in verkrzter Form ausgeben etwa nach einer
Fehlbedienung ohne den Text doppelt zu be-
Abbildung 1: Mit einer solchen bersicht zeigt Nagios dem Admin auf einen Blick, in welchen Zustand
sich welcher Service befindet.
Praxis
Performancedaten
Checks
durchfhren
Onlinehilfe
Ergebnis
zurckliefern
Kommandozeile
parsen und
prfen
Abbildung 2: In diese Funktionsgruppen gliedert sich intern ein typisches
Nagios-Plugin. Fr viele immer wiederkehrende Aufgaben bieten sich dabei Bibliotheksfunktionen an, die Nagios::Plugin anbietet.
ntigen. Fr die Ergebnisausgabe eignet sich das

recht neue Modul Nagios::Plugin, das neben einer Ausgabefunktion auch passende Konstanten
fr die Zustandswerte oder Funktionen fr Performancedaten enthlt.
Das Modul Nagios::Plugin

installieren
Das Modul Nagios::Plugin ist noch recht neu
und daher in den Standard-Linux-Distributionen kaum verbreitet. Dank CPAN (Comprehensive Perl Archive Network, [4]) ist es trotzdem
recht einfach zu installieren. Wer bis jetzt noch
nie etwas aus dem CPAN installiert hat, sollte
allerdings zunchst das Grundpaket Bundle::

CPAN laden. Dazu fhrt man als Benutzer Root
lediglich das folgende Kommando aus: perl
-MCPAN -e 'install Bundle::CPAN'. Dabei fragt
der Perl-Interpreter eine Reihe von Einstellungen ab, die man bis auf die Angabe der CPANServer alle bedenkenlos mit der Eingabetaste
besttigen kann.
Danach ldt Perl eine Reihe von Modulen nach.
Bei der Modulversion 0.15 von Nagios::Plugin
sind die Abhngigkeiten noch nicht vollstndig
implementiert; um Fehler zu vermeiden, gilt es
deshalb zuerst noch, das Modul Test::Exception zu installieren: perl -MCPAN -e 'install
Test::Exception'. Jetzt steht einer Installation
von Nagios::Plugin nichts mehr im Wege: perl
-MCPAN -e 'install Nagios::Plugin'.
brigens: Welche Module Perl wann und wohin
installiert hat, hlt die Datei /usr/local/perl/
perlversion/perllocal.pod fest, die sich mit perldoc formatiert ausgeben lsst: perldoc perllocal.pod
Im Blick behalten, ob die

DSL-Leitung steht
Als erstes Beispiel (Listing 1) dient ein ganz einfaches Plugin, das die Verfgbarkeit einer DSLLeitung prft, fr die auf dem lokalen Rechner
ein PPP-over-Ethernet- (PPPoE)-Prozess startet. Es enthlt zwar weder eine Onlinehilfe noch
wertet es die Kommandozeile aus, ist dafr aber
direkt einsetzbar. Es gengt, das Interface einzutragen, an dem die DSL-Leitung angeschlossen
ist. Daraufhin fragt das Plugin mittels pppoe -I
<interface> -A ab, ob sich die Gegenstelle mel-
Tabelle 1: Reservierte Optionen von Nagios-Plugins

Short
-V
-h
-t
-w
-c
-H
-v
-C
-a
-l
-p

-u
Long
Beschreibung
- -version Ausgabe der Plugin-Version, Plugin beendet sich sofort
- -help Ausgabe einer Onlinehilfe, die bei -h als Kurzhilfe, bei --help als vollstndige Hilfe ausfallen kann
- -timeout
Timeout, nach dem das Plugin den Test abbricht
- -warning
Warnschwellwert
- -critical
kritischer Schwellwert
- -hostname Hostname oder IP-Adresse (bei Netzwerkchecks)
- -verbose
Debugging-Ausgaben
- -community
SNMP-Passwort (nur bei SNMP-Abfragen)
- -authentication Passwort, sonstige Authentifikationsangaben
- -logname
Loginname
- -port, - -passwd, normalerweise fr die Angabe eines Zielports bei Netzwerkplugins, ist aber auch fr die Angabe
- -passwort eines Passwortes verwendbar.
--url --username URL und/oder Username fr die Authentifikation.
Praxis
det. Dabei wird der Name der Gegenstelle (des

so genannten Access Concentrator) und dessen
MAC-Adresse ausgegeben (Abbildung 3).
Das Laden des Moduls Nagios::Plugin in der
vierten Zeile importiert automatisch einige
Konstanten: OK, WARNING, CRITICAL
und UNKNOWN, die sich spter direkt fr
Rckgabewerte verwenden lassen. Das Interface
des Moduls ist objektorientiert. Die zehnte Zeile
legt eine neue Instanz an. Mit dem Attribut
shortname verpasst man dem Test gleich einen passenden Namen, den spter bei der Textausgabe auch die Methoden nagios_exit (Zeile
28 und 32) und nagios_die (Zeile 13 und 35)
mit ausgegeben (Abbildung 4). Dort folgt nach
der Testbezeichnung bei beiden Methoden auch
der Status OK.
DSL-Leitung im Blick behalten

Der Unterschied zwischen den beiden Methoden
nagios_exit und nagios_die ist marginal:
Bei nagios_die ist der Status UNKNOWN
voreingestellt, diese Methode verwendet man
bei Plugin-Fehlern. Der Status nagios_exit
erfordert dagegen die explizite Angabe eines
Rckgabewertes. Hier kommen die bereits erwhnten Konstanten OK und CRITICAL
zum Zug. Die eigentliche Logik des Plugin ist
schnell erklrt: Mit open (Zeile 12) wird das
Programm pppoe fr den Verbindungsaufbau
Abbildung 3: DSL-Test mit PPPoE: Am anderen

Ende meldet sich der Access Concentrator des
Providers. Die Leitung steht.
Abbildung 4: Ausgabe von check_pppoe.pl. Das

Perl-Skript gibt dieselben Werte in Nagios-Manier
zurck.
zum Provider gestartet und seine Ausgabe zu

dem Filedeskriptor OUT geleitet. Die WhileSchleife (Zeile 15-23) arbeitet diesen Output anschlieend Zeile fr Zeile ab. Bei bestehendem
DSL-Link erhlt das Skript in Zeile 18 den Namen des Access Concentrator auf der Seite des
Providers. Im Fehlerfall gibt pppoe jedoch
einen Timeout-Text (siehe Zeile 20) an den Aufrufer zurck.
Der DSL-Check liefert im Wesentlichen nur
die Information, ob die Verbindung steht oder
nicht, aber keine Messwerte und damit auch
keine Performancedaten.
Das nchste Plugin, das an dieser Stelle vorgestellt werden soll check_du.pl , wertet den
Listing 1: check_pppoe.pl
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
!/usr/bin/perl -w
#
use strict;

use warnings;

use Nagios::Plugin 0.15;

my $interface = 'eth1';

my $accessconcentrator = '';

my $failedconn = 0;

my $verbose = 0;

my $np = Nagios::Plugin->new( shortname =>

"CHECK_PPPOE" );

open ( OUT, "/usr/sbin/pppoe -I $interface -A

2>&1 |" )
or $np->nagios_die( "can't start /usr/sbin/
pppoe" );

while (<OUT>) {

print "$_" if ($verbose);
chomp $_;
if ( /Access-Concentrator:\s+([^ ]+.*$)/ ) {
19
$accessconcentrator = $1;
20 } elsif ( /Timeout waiting for PADO packets/
) {
21
$failedconn++;
22 }
23
}
24
close (OUT);
25
26
SWITCH: {
27 if ( "$accessconcentrator" ne "" ) {
28
$np->nagios_exit( OK, "Access Concentrator:
$accessconcentrator");
29
last SWITCH;
30 }
31 if ( $failedconn > 0 ) {
32
$np->nagios_exit(CRITICAL, "no DSL link"
);
33
last SWITCH;
34 }
35 $np->nagios_die( "for unknown reasons" );
36
}
Praxis
Platzbedarf einzelner Files oder aller Dateien in

einem bestimmten Verzeichnis aus. Es illustriert
als Programmierbeispiel fr ein bereits recht
vollstndiges Plugin den richtigen Umgang mit
Schwellwerten und mit Performancedaten, mit
Kommandozeilenoptionen und mit einer eigenen Onlinehilfe, die alle Aufrufparameter erklrt.
Datei- und Verzeichnissgren

per Plugin testen
Das Plugin check_du.pl (Listing 2) ermittelt und addiert mit Hilfe des Unix-Programms
du die Gre von Verzeichnissen oder auch
von einzelnen Dateien und prft anschlieend,
ob die ermittelte Gesamtgre im Rahmen vorher festgelegter Schwellwerte liegt.

Am Anfang des Skripts befindet sich ein Abschnitt mit der zugehrigen Perl-Online-Dokumentation (POD, Zeile 3-43), die den Text mit
einfachen Schlsselwrtern auszeichnet. Spter
lsst sich diese Doku mit dem Befehl perldoc
check_du.pl formatiert als Manpage ausgeben.
Der Dokumentationsabschnitt endet mit dem
Befehl =cut (in Zeile 43).
Die Schwellwerte bergibt man im NagiosThreshold-Format, das in den Nagios-Developer-Guidlines [5] ausfhrlich beschrieben ist.
Im einfachsten Fall ist nur ein Integerwert ntig:
-w 4000 gibt eine Warnung aus, wenn die er-
Listing 2: check_du.pl
001
#!/usr/bin/perl -w
030
002
031
=item -v|--verbose
003
=head1 NAME
032
004
033
34increases verbosity, specify twice to see the
original output from sapinfo.
005
5check_du.pl - Nagios plugin for checking size
034
of directories and files

006
035 =item -V|--version
007
=head1 SYNOPSIS
036
008
037
print version an exit
038
009 check_du.pl -P path/pattern [-v] \

010
[-w warning_threshold]
[-c critical_threshold]
039
=item -h|--help
040
011 check_du.pl [-h|-V]
041
print help message and exit
012
042
013
=head1 OPTIONS
043
=cut
014
044
use strict;
015
=over 4
045
use warnings;
016
046
017
=item -P|--path=expression
047
use Nagios::Plugin 0.15;
018
048
use Getopt::Long qw(:config no_ignore_case
bundling);
019
Path expression for calculating size. May be a
shell expression like
020
/var/log/*.log
050
021
051
022
=item -w|--warning=threshold
052
my $np = Nagios::Plugin->new( shortname =>
023
threshold can be max (warn if < 0 or > max),
min:max (warn if < min or >
024
max), min: (warn if < min), or @min:max (warn if
>= min and <= max). All values must be
"CHECK_DU" );
053
my $line = '';
054
my $warn_threshold = '0:';
055
my $crit_threshold = '0:';
025
integer.
056
my $what = '';
026
057
my $denied = 0;
027
=item -c|--critical=threshold
058
my $size = 0;
028
059
my $result = UNKNOWN;
029
see --warning for explanation of threshold
format
049
use Pod::Usage;
060
my $version = 'V1.0/2007-01-28/wob';
061
my $printversion = 0;
Praxis
mittelte Gesamtgre grer als 4000 KByte ist.

Das Kommando du arbeitet dabei per Default
mit 1-KByte groen Blcken. Andere Blockgren lassen sich ebenfalls verwenden, wenn
man in diesen Fllen alternativ die du-Option
--blocksize benutzt.
Die Funktion GetOptions() ab Zeile 66 zerlegt
die Kommandozeile und bergibt die vorgefundenen Parameter an die jeweiligen Varia-blen.
w|warning=s bedeutet, dass die Option wahlweise als Short Option -w string oder als Long
Option ?warning=string zulssig ist.
Ruft man das Plugin mit einer unbekannten
Option auf, dann liefert die Funktion GetOptions() einen Fehler als Rckgabewert. Der
sorgt seinerseits wiederum fr den Aufruf der

Funktion pod2usage() in Zeile 73. Der Verbose-Level 0 fhrt hier lediglich zu einer sehr
kurzen Hilfestellung, der Verbose-Level 2 gibt
dagegen eine vollstndige Manualseite aus. Die
pod2usage()-Aufrufe in den Zeilen 77, 81 und
86 kommen allerdings nur dann tatschlich zum
Zug, wenn die zugehrige If-Bedingung erfllt
ist, die sich jeweils an die Funktion anschliet.
Fr die Verarbeitung der Schwellwerte im Threshold-Format hlt Nagios::Plugin gleich mehrere
Methoden bereit. Die Funktion set_thresholds() in Zeile 120 bergibt die aus der Kommandozeile oder den Voreinstellungen ermittelten Werte an die Plugin-Instanz $np. In der-
Listing 2: check_du.pl Fortsetzung

062
my $verbose = 0;
094
063
my $help = 0;
095
critical => $crit_threshold);
064
096
# -- main
065
# -- GetOpt
097
open ( OUT, "LANG=C; /usr/bin/du -cs $what 2>&1
|" )
066
GetOptions(
098
or $np->nagios_die( "can't start /usr/bin/du"
067
"P|path=s"
=> \$what,
068
"w|warning=s"
=> \$warn_threshold,
069
"c|critical=s"
=> \$crit_threshold,
099
070
"h|help"
=> \$help,
100
while (<OUT>) {
071
"V|version"
=> \$printversion,
101
print "$_" if ($verbose);
072
"v|verbose+"
=> \$verbose,
102
chomp $_;
073
) or pod2usage({ -exitval => UNKNOWN,
103
my $line = $_;
074
-verbose => 0,
104
$denied++ if ( /Permission denied/i );
075
-msg
105
=> "*** unknown
);
106
argument found ***" });

076
107
077
pod2usage(-verbose => 2,
108
078
109
079
-exitval => UNKNOWN
last;
}
111
close (OUT);
081
pod2usage(-msg
=> "\n$0 -- version:
112
113
$np->add_perfdata( label => "size", value =>
$version\n",
$size,
082
-verbose => 0,
083
-exitval => UNKNOWN

) if ( $printversion );
114
uom => "kB", threshold =>
$np->threshold() );
115
085
086
pod2usage(-msg
=> "*** no path/pattern
087
$np->nagios_exit( CRITICAL, "unreadable
directories or files");
-verbose => 0,
088
116
if ( $denied ) {
117
specified ***",
089
$size = $1;
110
}
) if ( $help );
080
084
if ( /^(\d+)\s+total$/i ) { # last line
-exitval => UNKNOWN

) if ( "$what" eq "" );
118
}
119
090
120
$result = $np->check_threshold(
091
# -- thresholds
121
092
$np->set_thresholds(
122
$np->nagios_exit( $result, "check size: $size
093
warning
=> $warn_threshold,
$size );
kByte");
Praxis
Abbildung 5: Achtung, das Message-File in /var/log droht berzulaufen!

Das besagt die Ausgabe des hier vorgestellten Plugin check_du.pl, das
den Platzbedarf von Dateien und Verzeichnissen ermittelt.
selben Zeile 120 ermittelt check_threshold()s

dann auch die Gesamtgre aller Files. Der
Rckgabewert ist identisch mit den in Nagios
generell blichen Werten fr die Statuscodes
OK, WARNING und CRITICAL und
lsst sich daher auch direkt in nagios_exit()
verwenden (wie in Zeile 122).
Performancedaten
Die Textausgabe eines Plugin ist, wie schon gesagt, in erster Linie fr den Administrator gedacht, und soll ihn per Weboberflche oder ber
das Benachrichtigungssystem mit Informationen ber das Ergebnis der berprfungen versorgen.
Fr die bergabe von Performancedaten an externe Programme, die solche Werte dann grafisch aufbereiten knnen (ein Beispiel dafr ist
der Nagios Grapher, den ein weiterer Beitrag
dieser Ausgabe ausfhrlich vorstellt), gibt es
eine besondere Syntax. Bei der Weiterleitung
solcher Werte folgt hinter der Textausgabe ein
|-Zeichen. Alle folgenden Textausgaben unterdrckt Nagios. Das einheitliche Format fr
Performancedaten lautet: name=wert[uom];
warn;crit[;min[;max]].
Dabei ist name die Bezeichnung fr eine Variable. Die Abkrzung uom hinter dem zugeordneten Wert steht fr Unit of Measurement,
also eine Maeinheit. Als Einheiten kommen
% (Prozentangabe), s (eine Zeitangabe in
Sekunden, auch Milli- oder Mikrosekunden),
B (eine Datengre in Byte, auch KByte,
MByte oder TByte) oder c fr einen monoton
wachsenden Zhler (Counter) infrage. Die An-
Der Autor
Der studierte Physiker Wolfgang Barth ist Systemadministrator mit Leib und
Seele. Er betreute oder betreut Systeme unter VMS, Digital Unix (Tru64), SunOS/
Solaris, IBM AIX und HP-UX. Linux ist fr ihn nur die logische Fortsetzung zum Unix
berall. Seine Begeisterung fr alles, was mit Systemadministation zu tun hat,
gibt er gerne weiter: In Bchern ("Das Firewall-Buch", "Netzwerkanalyse unter
Linux" oder "Nagios", in Artikeln, Seminaren und im persnlichen Kontakt.
gabe von Minimum und Maximum ist optional.

Nagios::Plugin stellt die Methode add_perfdata() zur Verfgung (Zeile 113), die Information wird beim Aufruf von nagios_exit() einfach mit ausgegeben (Abbildung 5). Einfacher
geht es kaum mehr!
Ausblick
Auch das zweite Beispiel ist noch nicht hundertprozentig perfekt. Noch nachzursten wre etwa
ein Timeout-Mechanismus, ber den NagiosPlugins immer verfgen sollten. Er brche nach
einer voreingestellten Zeit ihre Ausfhrung ab.
Das wiederum wrde gewhrleisten, dass sich
Nagios nicht unntig lange mit aussichtslosen
Versuchen aufhlt, falls etwas bei der Skriptausfhrung klemmt. Es hat sich mittlerwile eingebrgert, diesen Timeout auf 10 Sekunden festzusetzen.
Ermittelt man die Gesamtgre von vielen Verzeichnissen, reicht der Timeout aber nicht. In
Perl lsst sich der zeitgesteuerte Abbruch mit
der Funktion alarm() einrichten, die einen
Aufruf nach einer vom Anwender vorgegebenen
Zeit abbricht.
Die beiden vorgestellten Plugins arbeiten lokal,
das heit, man installiert sie auf der Maschine,
auf der der Test auch auszufhren ist. Um sie alternativ vom Nagios-Server aus ber das Netzwerk aufzurufen, muss man auf Mechanismen
wie den Dienst NRPE (Nagios Remote Plugin
Executor) oder die Secure Shell (SSH) zurckgreifen.
Wer in Perl schon ein paar Erfahrungen gesammelt hat, dem wird der Eigenbau von NagiosPlugins fr spezielle Zwecke nach dem hier vorgestellten Mustersicher nicht mehr schwerfallen.
(jcb)
nnn
Infos
[1] Nagios Plugins:
[http://nagiosplug.sourceforge.net]
[2] Nagios-Tauschbrse:
[http://www.nagiosexchange.org]
[3] Beispiele aus dem Text:
[http://linux.swobspace.net/projects/nagios]
[4] CPAN das Modul-Archiv von Perl:
[http://www.cpan.org]
[5] Nagios Developer Guide:
[http://nagiosplug.
sourceforgenet/developer-guidelines.html
#THRESHOLDFORMAT].
Alle Netzwerk-Komponenten im Blick behalten mit

Nagvis
Wie schnell Admins ein IT-Problem beheben, hngt

davon ab, wie schnell sie es finden. Eine gute Dokumentation leistet hier einige Vorarbeit. Die NagiosErweiterung Nagvis stellt zudem alle berwachten
Komponenten im Netz anschaulich im Browser dar
und erleichtert so die rumliche Zuordnung.
Markus Klimke
Projekte
Den meisten Admins erscheint es als undankbare Aufgabe: die Dokumentation der Netzwerk-Infrastruktur. Was aber fr einen technikorientierten Menschen wie eine Strafe wirkt, hat
durchaus seine Berechtigung. Je mehr die Infrastruktur wchst, desto schwieriger wird es, sich
darin zurechtzufinden. Gerade fr neue Mitarbeiter gleichen undokumentierte Rechnerlandschaften einer Irrfahrt durchs Unbekannte.
Genau aus diesem Grund schmcken Rechnerrume nicht selten DIN-A0-Ausdrucke, auf
denen sich mit Pfeilen verbundene IT-Komponenten tummeln. ndert sich die Infrastruktur,
wird ein neuer Ausdruck fllig. Fr solche Aufgaben haben sich Applikationen wie Microsofts
Visio oder freie Vektorgrafikprogramme wie
Xfig und Inkscape bewhrt.
Diese Tools haben aber gemeinsam, dass der
Admin anhand der Skizzen nicht sieht, in welchem Zustand sich die einzelnen Komponenten
befinden. Eine aktive Skizze des Netzes, die bei
Fehlern gleich die Alarmlampen blinken liee,
wrde das Leben der Systemadministratoren
deutlich erleichtern. Hier bietet sich das NagiosFrontend Nagvis [1] an.
Im Fokus
Als Sammlung von PHP- und JavaScript-Dateien integriert sich Nagvis sehr komfortabel
in eine vorhandene Nagios-Installation und
zeigt die Monitoring-Informationen genau wie
Nagios ber ein Webinterface an. Nagvis stellt
dazu die Daten des Nagios-Servers so dar, dass
sie sich auf einer Hintergrundgrafik anordnen.
Diese Grafik erstellen Admins vorher zum Beispiel mit Visio oder Inkscape.
Nagvis bietet zur Darstellung der Nagios-Daten
eine Browser-basierte Konfigurationsoberflche
an. Im Web User Interface (WUI, siehe Abbildung 1) reprsentieren Icons, die sich auf der
Hintergrundgrafik platzieren lassen, die Hosts,
Services oder Kombinationen aus beiden. Dazu
bietet das WUI in der aktuellen Nagvis-Version
0.9 Final die Mglichkeit, Icons per Drag and
Drop an die gewnschte Position zu verschieben. Vorher mussten Anwender die Positionen
noch explizit ber X- und Y-Koordinaten festlegen. Mittlerweile lassen sich Maps (Hintergrundgrafiken samt positionierter Icons) vollstndig mit dem WUI verwalten.
Icons verndern, je nach Zustand des von ihnen
reprsentierten Objekts, die Farbe. Welches Icon
welche Farbe annimmt, bestimmen so genannte
Icon Sets, die Admins variabel gestalten. Nagvis

bringt standardmig einen Satz Bilder in drei
verschiedenen Gren und Farben mit. Hinzu
kommen Linien, mit denen der Anwender im
WUI Komponenten auf der Skizze verbindet.
Linien verndern ebenfalls ihre Farbe je nach
Status; das kann eine Rsync-Verbindung oder
auch eine Modem-Strecke sein.
Effiziente Fehlersuche
Wer sich ber mgliche Darstellungsformen
seines Netzes informieren will, findet im Kasten Beispiele fr Maps einige Vorschlge fr
Nagvis-Skizzen. Mit Nagvis lassen sich neben
Hosts, Services und Gruppen auch ganze Maps
in Maps einlagern. Anhand eines solchen Gebudeplans reprsentiert die Map dann einen
IT-Schrank auf dem Flur, den Flur als Teile einer
Etagen-Karte und so weiter.
ndert sich der Zustand eines der Objekte in
dieser Map, zeigt das Icon im Gebudeplan den
Wechsel an und signalisiert, dass die dahinterliegende Map einen Problemstatus aufweist. Mit
einem Klick auf das Map-Icon gelangen Benutzer auf diese Map und kreisen so das Problem
ein. Um nicht jeden einzelnen Service auf einer
Map zu platzieren, knnen Hosts und HostGruppen veranlasst werden, den Gesamtzustand
aller enthaltenen berwachten Services anzuzeigen (Option recognize_services=1).
Abbildung 1: Mit dem Web User Interface platziert der Admin Objekte auf
dem Hintergrundbild und verschiebt sie per Drag and Drop direkt im Browser. So lassen sich Plne der Infrastruktur sehr komfortabel erstellen.
Projekte
Tabelle 1: Optionen der Map-Konfigurationsdateien

Option
Beschreibung
global
Allgemeine Einstellungen Zugriffsberechtigungen, Hintergrundbild, Datenbank-Backend, Gesamtzustand, Icon-Set, Hintergrundfarbe

Zeigt einen Host
Hostname, X- und Y-Position, Gesamtzustand, Icon-Set, URL, Linientyp
Zeigt einen einzigen Service
Hostname, Service-Name, X- und Y-Position, Icon-Set, URL
Zustand einer Gruppe von Hosts Gruppenname, X- und Y-Position, Gesamtzustand, Icon-Set, URL
Zustand einer Gruppe von Services Gruppenname, X- und Y-Position, Icon-Set, URL, Linientyp
Zustand einer anderen Map

X- und Y-Position, Icon-Set, URL
Textfeld fr Informationen
X- und Y-Position, Breite, Text/HTML, Hintergrundfarbe
host
service
hostgroup
servicegroup
map
textbox
Parameter
Fllt der Service eines Host oder einer HostGruppe aus, zeigt das Icon einen kritischen
(Farbe Rot) oder Warnungs-Zustand (Orange)
an. Bleibt die Option url (siehe Tabelle 1) eines Icons leer, zeigt ein Klick darauf die NagiosSeite des Objekts an und erlaubt es, den Fehler
zu beurteilen. So lsst sich durch ein paar Klicks
herausfinden, wo das Problem auftritt.
Installation
Nagvis liegt auf der Sourceforge-Seite des Projekts [2] als gezipptes Tar-Archiv vor. Da es
komplett ber eine Weboberflche luft, gestal-
Beispiele fr Maps
Flurplan: Eine Map basierend auf einem Gebude- oder Flurplan. Die
Icons knnen in den Rumen platziert werden und erleichtern einem
Admin somit die Suche (siehe Abbildung 1).
Gebudeplan: Zeichnung eines Gebudes, in das Flurplne als Maps
eingebettet sind. Diese Maps zeigen den Gesamtstatus eines Flures an,
so dass bei Linksklick auf die alarmierende Map der fehlerhafte Host
oder Service lokalisiert werden kann.
Netzwerkplan: Gngiger Fall einer Darstellung, in der die Infrastruktur
anhand von Symbolen skizziert wird. Als grafische Elemente dienen hier
Linien fr die Netzverbindungen, Rechner oder Server. Die Verbindungen zwischen ihnen stellen Pfeile oder Linien dar, die fr das EthernetNetzwerk stehen. Aufgrund des hohen Abstraktionsgrades eignet sich
der Netzwerkplan nicht immer.
Landkarte: Land- oder Stadtkarte einer Region mit berwachten Standorten. Je nachdem, ob es sich um einzeln berwachte Gebiete handelt,
knnen die Standorte ihrerseits mit Maps oder nur mit Hosts/Services
weiter gegliedert sein.
Schrank: Befinden sich Rechner in einem Rack, zeichnet der Admin es
in einem Grafikprogramm nach. Die Zustnde lassen sich neben den
Maschinen darstellen.
Tabelle: Eine Tabelle von Hosts/Services und Orten mit Icons auf ihren
Schnittpunkten. Vorteil hier: Viele Icons passen auf eine Map.
tet sich die Installation recht unspektakulr: Es

gengt, das Paket im Share-Verzeichnis der Nagios-Installation zu entpacken. Im Allgemeinen
befindet es sich nach einer Standardinstallation
von Nagios in /usr/local/nagios/share (eine
detaillierte Installationsanleitung liefert [3]).
Nach der Installation geht es an die Konfiguration. Sie erweist sich als etwas aufwndiger,
da Nagvis als erstes Projekt berhaupt auf den
NDO-Utils basiert (nheres dazu im Kasten
Die NDO-Utils). Diese Programme dienen
Nagvis als Datenbank-Backend und sollen zuknftig den bisherigen Datenaustausch mit
langsamen CGI-Transaktionen ablsen.
Zwar funktioniert Nagvis weiterhin als Backend
im Modus html, dennoch lohnt sich das bersetzen der NDO-Utils. Neben dem deutlichen
Abbildung 2: Der Dialog, mit dem Admins eine

Map konfigurieren oder einrichten. Hier setzen
sie auch gleich die Berechtigungen fr den Zugriff auf die Map.
Projekte
Geschwindigkeitsvorteil landen die Daten

komfortabel in einer
MySQL-Datenbank.
Aufgrund der Abhngigkeit zu MySQL
bentigt Nagvis eine
PHP-Installation mit
My S Q L - Unt e r s tt zung, fr die Grafikfunktionen muss PHP
zudem mit der GDLib
zusammenarbeiten.
Da das Webfrontend
als Editor fr Maps
dient, bentigen einige
Nagios-Verzeichnisse
Schreibrechte (share/
nag v is/etc/maps/,
share/nagvis/maps/
und die Konfigurationsdatei share/nag- Abbildung 3: In der Ansicht einer Map zeigt sich der Status eines jeden Obv i s / e t c / c o n f i g . i n i . jekts. Im Raum R1971 ist eine weitere Map untergebracht (blaues Icon),
php). Tabelle 2 gibt auf die Anwender mit Linksklick verzweigen.
einen berblick ber
wichtige Verzeichnisse und Dateien. Um die Danach kann die Nagvis-Konfiguration ber das
richtigen Schreibrechte auszuwhlen, reicht es, Webfrontend nachbearbeitet werden. Die MapBenutzer und Gruppe an jene Rechte anzupas- Dateien hingegen stehen von Anfang direkt im
sen, unter denen der Apache-Prozess luft.
Browser zur Verfgung. In der vorliegenden
Version 0.9 gibt es leider noch ein Manko: Ein
Wechsel zwischen Konfigurations- (also dem
Web User Interface
WUI) und Ansichtsmodus ist nur ber die
In puncto Konfiguration gilt bei Nagvis das Adressleiste des Browsers mglich. Das WUI
Prinzip der Einfachheit: Die Konfigurations- erreichen Benutzer ber die URL https://DOdateien fr Maps sehen schlicht aus, arbeiten MAIN/nagvis/config.php.
aber effektiv und enthalten eine berschaubare Dort ffnet dank JavaScript ein Klick mit der
Anzahl an Optionen (siehe Tabelle 1 und [4]). rechten Maustaste ein Kontextmen im BrowEinzig die Konfigurationsdatei fr Nagvis selbst serfenster, ber das sich Nagvis vollstndig verenthlt recht viele Optionen, die der Admin walten lsst. Um eine neue Map zu erstellen,
anfangs manuell editiert und konfiguriert. Die klickt der Sysadmin auf Manage im KontextNagvis-Dokumentation unter [4] beschreibt men. Daraufhin ffnet sich ein neues Fenster
diese Datei genauer.
hnlich dem in Abbildung 2. Eine so erstellte
Tabelle 2: Wichtige Verzeichnisse und Dateien

Verzeichnis/Datei
Aufgabe
Berechtigungen
share/nagvis/etc/config.ini.php
share/nagvis/etc/header.nagvis.inc
share/nagvis/etc/maps/
share/nagvis/maps/
share/nagvis/iconsets/
share/side.html
Haupt-Konfigurationsdatei
Kopf der Nagvis-Ansicht
Map-Konfigurationsdateien
Hintergrundgrafiken
Zustands-Icons
Nagios-Sidebar
Lesen und schreiben

Lesen
Lesen und Schreiben
Lesen und Schreiben
Lesen
-
Projekte
Oberflche integriert zu einer einzigen Gesamtbersicht verschmelzen.

Um den Header der Nagvis-Installation zu verndern, gengt es, die Datei share/nagvis/etc/
header.nagvis.inc anzupassen. Dort stehen ausschlielich Links auf die jeweilige Map mit ihren
Beschreibungen. Fr ein Ergebnis wie in Abbildung 4 passen Admins auch die Sidebar der
Nagios-Installation an. Die dazugehrige Datei
side.html finden sie im Share-Verzeichnis.
Fazit
Abbildung 4: Durch einfaches Anpassen der HTML-Vorlagen integrieren

Benutzer die Grafiken in die vorhandene Nagios-Oberflche.
Der Autor
Markus Klimke ist Mitarbeiter des Instituts
fr Modellierung und
Berechnung an der
Technischen Universitt Hamburg-Harburg.
Map fllt der Admin ber Objekt hinzufgen

mit Objekten (siehe Abbildung 1).
In dem sich ffnenden Fenster gibt er dann die
ntigen Parameter an, wie sie Tabelle 1 auflistet. Die Daten fr einen Host findet Nagvis
ber die NDO-Utils. Objekte wie Icons, Linien,
Maps und Textksten lassen sich nachtrglich
durch kurzes Verweilen auf dem Icon bearbeiten. Um sich das Ergebnis anzusehen, hilft der
Wechsel auf Nagvis Index-Seite, inklusive Angabe der Map: https://DOMAIN/nagvis/index.
php?map=Flurplan
In dieser Ansicht nehmen alle Icons die Farben
fr die jeweiligen Zustnde an (siehe Abbildung 3) im Konfigurationsdialog bleiben stets
alle Icons grn. Ein kurzer Aufenthalt mit dem
Mauszeiger auf einem der Symbole bringt den
Namen des Objektes sowie den passenden Statustext zum Vorschein.
Integration in Nagios
Als eigenstndige Webseite, wie in Abbildung 3
zu sehen, kommt die berwachung dieses hier
beispielhaft gezeigten Flures recht einsam daher.
Interessanter und systematischer wird es, wenn
alle Maps in die bereits bestehende Nagios-
Obwohl die Nagvis-Entwickler derzeit eifrig an

Version 1.0 werkeln, arbeitet Version 0.9 bereits reibungslos. Auch Zugriffsberechtigungen
lassen sich fr jene Benutzer setzen, die Leseund Schreibrechte oder nur Leserechte erhalten
sollen. Voraussetzung ist allerdings ein bereits
installierter Nagios-Server mit Zugriffberechtigungen fr die Webseiten und CGI-Skripte. Wer
trotz der einfachen Installation und Konfiguration auf Probleme stt, findet im deutschen
Nagios-Forum [8] Untersttzung.
Da sich mit Nagios und der Plugin-Technologie
nahezu alles berwachen lsst, was in irgendeiner Form Daten produziert, sind Nagvis kaum
kreative Grenzen gesetzt. Nagvis bietet gute
Mglichkeiten, die Systemberwachung zu konkretisieren und an bestimmte Situationen anzupassen. Ein psychologischer Nebeneffekt animiert den Admin dann zustzlich, ausgefallene,
rot markierte Gerte, schnellstmglich wieder
in den Zustand grn zu bekommen. (mwe)n n n
Infos
[1] Nagvis-Projektseiten: [http://www.nagvis.org]
[2] Nagvis-Download: [http://www.nagvis.org/
doku.php?id=downloads]
[3] Nagvis-Installationsanleitung:
[http://www.nagvis.org/doku.php?id=installatio
ninstructions_0_9]
[4] Nagvis-Dokumentation: [http://www.nagvis.org/
doku.php?id=doc]
[5] NDO-Utils-Download: [http://www.nagios.org/
download/]
[6] NDO-Utils auf 64-Bit-Systemen bersetzen:
[http://www.nagios-portal.de/forum/thread.
php?threadid=5363]
[7] Arbeitsprinzip der NDO-Utils: [http://www.
ederdrom.de/doku.php/nagios/ndo]
[8] Nagios-Forum: [http://www.nagios-portal.de/
forum]
Projekte
Die NDO-Utils
Umgebung mit ausschlielich einem Nagios-Server und einer Nagios-Instanz stellt dafr die einfachste Lsung dar.
Der Sinn von Nagios-Instanzen und ihrer eindeutigen Namensvergabe erschliet sich dem Anwender erst dann,
wenn ein Server mehrere Nagios-Prozesse beherbergt. Damit der NDO2DB-Daemon wei, welche Daten von welchem
Nagios-Daemon kommen, werden sie mit einem eindeutigen Namen als Instanz versehen. Genauere Informationen
finden sich als PDF nach dem Entpacken der NDO-Quellen im Verzeichnis docs oder unter [7].
Eine Sammlung von Programmen namens NDO-Utils (Nagios

Data Out, [5]) bildet die Basis fr ein neues Kommunikationsmodell zwischen Nagios-Prozessen. Mit ihnen legt Nagios
Monitoring-Daten in einer MySQL- oder PostgreSQL-Datenbank ab. Die Entwickler planen, sich ab Nagios 3.0 vom CGIModell zu verabschieden und ausschlielich auf PHP und
die NDO-Utils zu setzen. Doch auch Nagios 2.0 kommt schon
mit den NDO-Utils zurecht, die sich durch deutlich krzere
NagiosDaemon
Programm
logik
TCP
Socket
Installation
NDOBroker
Modul
Unix
Nagios-Entwickler Ethan Galstad

hat die NDO-Utils getrennt von
Nagios entwickelt, sie finden sich
als eigenes Paket unter [5]. Nach
Datei
dem Entpacken in einem temporren Ordner reicht ein klassisches ./configure && make;
Abbildung 5: Die NDO-Utils verwenden ein Broker-Modul, um Monitoring-Daten in einer
ein make install gibt es derzeit
MySQL- oder PostgreSQL-Datenbank zu speichern. Es sendet die Daten ber verschienicht. Mgliche Probleme mit 64dene Wege an das NDO2DB-Programm, welches sie in die Datenbank schreibt.
Bit-Maschinen beschreibt [6].
Nach der Kompilierung finden
Reaktionszeiten auszeichnen als das altgediente CGI-Intersich zwei Module im Verzeichnis: das Broker-Modul (ndoface. Dazu bleibt ein NDO-Daemon permanent aktiv. Das
mod-2x.o oder ndomod-3x.o) sowie der Daemon fr
erfordert bei mehr als einem Nagios-Prozess allerdings eine
die Kommunikation mit der Datenbank (ndo2db-2x oder
klare Zuweisung, welcher Prozess (im NDO-Jargon Instanz
ndo2db-3x). Diese beiden Komponenten kopiert der Sysgenannt) welche Daten enthlt. Dazu spter mehr.
admin dann in das bin-Verzeichnis der Nagios-Installation,
meistens /usr/local/nagios.
Das Event-Broker-Modul
Die Konfigurationsdateien im config-Verzeichnis der NDOUm auf die Daten des Nagios-Prozesses zuzugreifen, kommt
Utils landen in /etc/nagios oder relativ zur Nagios-Installaein eigenes Modul zum Einsatz, der NDOMod-Event-Broker.
tion in etc. Eine Installationsanleitung der NDO-Utils fr die
Standardmig ist Nagios schon mit Event-Broker-UntersttZusammenarbeit mit MySQL findet sich unter [7].
zung bersetzt, die es fr den Einsatz des Moduls bentigt.
Der Admin teilt Nagios ber die Konfigurationsdatei /etc/
Konfiguration
nagios/nagios.cfg mit, dass es einen Event Broker gibt, der
Entscheidend bei der Einrichtung des Broker-Moduls ist der
Daten abzweigt. Nach dem bersetzen der NDO-Utils fgt er
Name der Instanz, der beim Betrieb eines Servers mit nur eidazu folgende Zeile ein:
nem Nagios-Prozess auf default stehen sollte. ber die Vabroker_module=/usr/nagios/bin/ndomod.o U
riable output_type legt der Admin fest, wie NDOMod die
config_file=/etc/nagios/ndomod.cfg
Monitoring-Daten weitergibt. Hinzu kommen datenbankspezifische Angaben wie Benutzername und Passwort. Den DaEin Neustart von Nagios versetzt dann das Modul in die Lage,
tenbank-Daemon der NDO-Utils starten Benutzer von Hand:
Daten vom Nagios-Prozess oder einer Nagios-Instanz (bei
Programm
daten
Socket
NDO2DB
mehreren Prozessen) abzugreifen und an eine Datei, einen

Unix- oder TCP-Socket zu schicken.
Daten lesen und speichern

Je nachdem, wohin das NDO-Modul seine Daten schreibt,
bezieht sie der NDO2DB-Daemon, um sie in der Datenbank
abzulegen. Dazu gibt es verschiedene Mglichkeiten. Eine
Datenbank
/usr/nagios/bin/ndo2db -c /etc/nagios/ndo2db.cfg
Insgesamt mssen danach zwei Prozesse laufen: der Master

sowie ein Prozess, der die Nagios-Instanzen verwaltet. Unter
Gentoo Linux befindet sich in /var/nagios eine Logdatei, in
der NDO2DB einen erfolgreichen Start protokolliert. Bei Problemen hilft meistens ein Blick ins Nagios-Forum [8].
Konsolentools
frs Monitoring
Fr die schnelle Abfrage zwischendurch sind die
groen Monitoring-Lsungen oft berdimensioniert.
Zum Glck gibt es zahlreiche unkomplizierte Tools
fr die Konsole. Christoph Wegener
Projekte
Werkzeuge wie SNMP, MRTG, Cacti oder auch

Nagios dominieren das Thema Monitoring, da
sie fr langfristige Datenanalysen eine ideale
Umgebung bieten. Allerdings sind sie in der
Regel nicht fr die schnelle Problemanalyse vor
Ort zu gebrauchen.
Dieser Beitrag zeigt, wie bekannte und weniger
bekannte Werkzeuge dem Netzwerkadministrator zur Hand gehen knnen. Die meisten dieser
Hilfsmittel sind in jeder Standardinstallation
enthalten. Oft werden sie von tglichen Skripten
und Managementtools wie etwa YaST benutzt,
ohne dass der Benutzer etwas davon merkt. Anhand von einfachen Beispielen zeigt dieser Artikel, wie sie dem Administrator in der Praxis
helfen.
Ping
Eines der grundlegendsten Werkzeuge bei der
Analyse von Netzwerkproblemen ist Ping. Es
ermglicht die schnelle berprfung des Status
von Hosts und erzeugt Statistiken ber deren
Verfgbarkeit.
Ping versendet ICMP-Pakete vom Typ Echo Request an einen oder mehrere Server und wartet
auf eine passende Antwort vom Typ Echo Reply. ber die zwischen den beiden Ereignissen
verstrichene Zeit erstellt das Tool eine einfache
Statistik.
Neben der Information ber die Erreichbarkeit
ergibt sich die Verbindungsqualitt zur Gegenstelle aus der Anzahl der erhaltenen Antwortpakete und ihrer Laufzeiten. Ping errechnet das
Verhltnis von verlorenen zu ankommenden
Paketen und stellt dies in Prozentwerten dar.
server mit einer Payload von 16437 Byte fragmentiert werden mssen, gibt der Befehl ping
-s 16437 server -Mdo aus. Ein ping -R server
gibt die Route zu server zurck.
Fping und Hping

Ping bleibt trotz all dieser Mglichkeiten ein relativ einfaches Tool, das nicht gut skaliert: Um
mehrere Gerte zu testen, bleibt nur, als Ziel
Netzwerk- oder Broadcast-Adressen einzugeben.
Die Werkzeuge Fping und Hping bieten deutlich
mehr Komfort, sind jedoch leider nicht in allen
Distributionen standardmig enthalten. Fping
kann eine ganze Gruppe von Gerten berprfen, Hping ermglicht das Senden von nahezu
beliebigen IP-Paketen. Analog zu einem Netzwerkscanner knnen so ganze Netze nach verfgbaren Diensten durchsucht werden.
Pfadfinder
Wie ping -R nutzt auch traceroute die TTL
der ICMP-Pakete, um die Route zum Zielgert
zu ermitteln. Darber hinaus hilft es bei Problemen mit MTUs und liefert zahlreiche weitere
Informationen. Tracepath berechnet auch die
sogenannte Path MTU, also die MTU ber den
ganzen Netzwerkpfad. Bei Verbindungen, an denen mehrere Carrier beteiligt sind, ergeben sich
dabei ab und zu berraschende Werte.
Die Funktionalitten von Ping und Traceroute
vereint Mtr. Es sammelt Minimal-, Maximalund Durchschnittswerte und stellt diese in einer
bersichtlichen Tabelle dar. Pakete fr die meisten Distributionen stehen unter [1] zur Verfgung.
Erweiterte Optionen
Telnet
Die Option -n schaltet die Namensauflsung

von eingegebenen IP-Nummern ab. Reagiert
der zustndige DNS-Server nicht mehr, dann
verzgern Timeouts die Ausfhrung von Ping;
umgekehrt beschleunigt der Verzicht auf DNS
die Datenerhebung generell.
Der gezielte Einsatz dieser Option liefert auch
konkrete Daten: Ein Vergleich der Ergebnisse
eines Ping auf eine IP-Adresse ohne DNS-Auflsung mit den Daten eines Ping auf den DNSNamen des gleichen Servers liefert Informationen ber Funktion und Performanz des DNSServers.
Das Kommando ping -p ff testet, ob das Textmuster 0xff , beim Transport unerwnschterweise verndert wurde. Ob Pakete zum Host
Telnet, wie Ping standardmig bei allen Distributionen installiert, leistet gute Dienste bei der
berprfung von Serverdiensten. Viele Protokolle, wie HTTP, IMAP oder SMTP lassen sich
ber eine einfache Telnet-Verbindung bedienen. Allerdings ist hierfr die genaue Kenntnis
der entsprechenden Protokollkommandos und
Ablufe Voraussetzung fr die Kommunikation
mit dem Serverdienst. In den meisten Fllen finden sich alle bentigten Informationen dazu in
den jeweiligen RFCs .
Schon der Verbindungsaufbau zum Server bietet
erste Rckschlsse auf einen mglichen Fehler:
Ist das Gert berhaupt unter der angegebenen
Adresse auf dem angegebenen Port erreichbar?
Meldet Telnet ein Connected to..., oder wird
DNS-Werkzeuge
Die DNS-Clients host
und dig sowie das veraltete, aber immer noch
verbreitete nslookup
ermitteln auf der Konsole
Daten von DNS-Servern
wie die IP eines Rechners
oder den zustndigen
Mailserver.
Routing-Tools
route und ip route
show zeigen die eingestellten Routen. ip
kennt Routing Policies,
um Pakete auf unterschiedlichen Wegen ins
Ziel zu bringen.
Projekte
Listen offener Ports/

Sockets
netstat listet offene
Ports, Netzwerkverbindungen und Routing-Tabellen auf, das Perl-Skript
socklist offene Sockets.
Geffnete Dateien, Verzeichnisse und Sockets
zeigt lsof an, whrend
fuser Prozesse identifiziert, die Dateien oder
Sockets belegen.
Ethernet-Karten kontrollieren und konfigurieren
Die Verbindung zu einem Switch prfen kann
mii-diag, einem Duplex-Mismatch kommt
ethtool auf die Spur.
die Kommunikation zum Zielgert etwa durch

eine Firewall oder durch einen Netzwerkdefektunterbunden? Ist der entsprechende Dienst auf
dem Zielgert gestartet, oder wird bereits der
Verbindungsaufbau abgelehnt, etwa mit der
Fehlermeldung telnet: connected to address ...:
Connection refused?
Ein einfaches Beispiel fr den Einsatz von Telnet
zur Netzwerkberwachung ist zum Beispiel der
Test der Kommunikation mit einem Webserver.
Die Verbindung baut der Befehl telnet webserver 80auf, die Eingabe von get fordert die
Indexseite des Servers an. Wenn alles geklappt
hat, werden zahlreiche Zeilen HTML auf der
Befehlszeile ausgegeben.
Auch Mailserver prft Telnet unkompliziert,
wenn der Administrator ein paar Befehle des
SMTP-Prokolls beherrscht. Im Listing 1 lehnt
der Mailserver das Relaying fr test.de ab, er
ist demnach wahrscheinlich kein Open Relay.
Netcat
Wie Telnet kann auch Netcat mit TCP-basierten
Protokollen kommunizieren, kombiniert diese
Fhigkeit aber mit Features, die von dem Befehlszeilentool cat bekannt sind. Netcat bietet
darber hinaus noch weitere ntzliche Features.
Es sendet und empfngt binre Daten ber TCP
oder UDP, kann auf eingehende Verbindungen
lauschen und empfangene Daten in Dateien
umleiten.
Netcat bietet neben einer langen Reihe von
ntzlichen Optionen zwei verschiedene Arbeitsmodi. Als Capturer zeichnet es alle Daten auf,
Listing 1: Per Telnet eine Mail versenden

01
#> telnet mail-server 25
02
Verbinden zum Mail-Server:
03
Trying ...
04
Connected to mail-server.
05
Escape character is '^]'.
06
220 mail-server C=DE ESMTP
07
helo test-server
#Eingabe des HELO
08
250 mail-server C=DE
09
mail from: test@test.de
#Eingabe des Senders
10
250 ok
11
rcpt to: test@test.de
#Eingabe des Empfngers
12
553 sorry, we do not relay for your IP address (#5.7.1)
13
quit
#Ende der Verbindung
14
221 mail-server C=DE
15
Connection closed by foreign host.
16
#>
die an einer Netzwerkschnittstelle ankommen,

und legt diese in einer Datei ab. Mit der Option
-l aufgerufen, bietet der Listener-Modus die
Mglichkeit, Netcat auf einem frei definierbaren
Port lauschen zu lassen. Damit lsst sich dann
ein Serverdienst emulieren und Daten von Clients empfangen und auswerten.
Dieses Vorgehen macht Sinn, wenn an der Funktionsfhigkeit eines Serverdienstes kein Zweifel
besteht, einzelne Clients aber Probleme mit dem
Verbindungsaufbau zu diesem Server haben.
Mit netcat -l -o logdatei -p80 lauscht Netcat
auf dem lokalen Port 80 und protokolliert alle
Verbindungsanfragen fr eine weitere Analyse
in der Datei logdatei.
Umgekehrt liefert ein netcat webserver 80
die entsprechenden Rckgabewerte des Servers webserver: Das Kommando HEAD /
HTTP/1.0 gefolgt von zweimal [Return] veranlasst den Webserver, seinen Header auszuliefern.
Tcpdump
Tcpdump kann komplette Pakete des EthernetProtokolls oder jedes anderen Protokolls auf
OSI-Layer 2 und darber an der lokalen Netzwerkschnittstelle protokollieren. Gerade bei
nicht-trivialen Netzwerkproblemen ist derartiges Packet Sniffing eine gute Alternative.
Tcpdump hilft beispielsweise, den Hintergrnden einer schlechten Netzwerkperformance auf
die Spur zu kommen. Absender, Empfnger,
Ports und Protokolle des gesamten Netzwerkverkehrs werden erfasst. Aus diesem Profil ergibt
sich fast zwangslufig die Anwendung, die den
mglicherweise fehlerhaften Traffic verursacht.
Weil Tcpdump die Herkunft von unbekannten
Paketen anzeigt, ist es auch bei Denial-Of-Service-Angriffen eine groe Hilfe.
Das einfache Werkzeug arbeitet direkt auf der
Ebene der Netzwerkschnittstelle und unterscheidet sich dadurch erheblich von Werkzeugen wie Ping, Telnet, MRTG oder Nagios, die
den OSI-Layer 3 berwachen. Im Gegensatz zu
diesen zeichnet Tcpdump allerdings keine langfristigen Trends auf, sondern liefert einen LiveMitschnitt des aktuellen Netzwerkzustandes, es
eignet sich perfekt zum Netzwerk-Debuggen.
Das folgende Beispiel illustriert den Einsatz von
Tcpdump zur Fehleranalyse: Ein lokaler Webserver antwortet nicht auf Clientanfragen. Der
Administrator startet auf dem Clientrechner
Tcpdump und startet dann eine Anfrage an den
Projekte
Webserver. Alle Schritte, die fr den Aufruf der

Webseite notwendig sind, werden in der Ausgabe von Tcpdump nachvollziehbar: DNS- und
ARP-Auflsung, Anfragen und Antworten der
HTTP-Kommunikation. Mit Tcpdump werden
alle Schritte im Detail verfolgt, der Fehler wird
schnell eingegrenzt.
Promiscuous Mode
Soll das Tool auf der lokalen Netzwerkschnittstelle Daten protokollieren, die nicht fr das lokale Gert bestimmt sind, muss das Netzwerkinterface mit Administratorrechten in den Promiscuous Mode geschalten werden. Alle Pakete
der Collision-Domain werden jetzt auch durch
die lokale Netzwerkkarte angenommen.
Tcpdump bietet umfangreiche Filtermglichkeien, die vor allem im Promiscuous Mode sehr
gute Dienste leisten. Mit diversen Ausdrcken
und Boolschen Operatoren lsst sich der mitgeschnittene Netzwerkverkehr schnell auf die
Pakete mit den gewnschten Eigenschaften einschrnken.
Um auf der Netzwerkschnittstelle eth0 beispielsweise den Netzwerkverkehr von Host A auf Port
22 mitzulesen, dabei aber alle Pakete auszuschlieen, die von oder zu Host B gehen, dient
folgender Befehl:
tcpdump -i eth0 host A and U
not host B and port 22
Hinter Tcpdump steht unter anderem die Bibliothek Libpcap, auf die auch zahlreiche andere
Programme aufsetzen und teilweise eine viel
umfangreichere Funktionalitt bereitstellen.
Wireshark, Nachfolger von Ethereal, bringt eine
grafische Oberflche zur Analyse des Netzwerkverkehrs und eine groe Anzahl bereits vorkonfigurierter Filter mit. Das Programmpaket
Nfsen bietet sehr ausgereifte Mglichkeiten zur
Protokollierung von Paketen auch in greren
Netzen.
Nmap
Netzwerkberwachung umfasst in vielen Fllen
mehr als die fortlaufende Analyse der Verfgbarkeit von Servern oder die Performance der
angebotenen Dienste. Auch die berwachung
von Desktoparbeitspltzen und der dort angebotenen Dienste oder eine berprfung von
neuen Softwareversionen auf Sicherheitslcken
sind potenzielle Anwendungsszenarien fr Monitoring-Tools.
Mit dem Netzwerkscanner Nmap steht ein hervorragendes Werkzeug zur Verfgung, das unkompliziert und mit vielen Optionen eine bersicht der im lokalen Netz angebotenen Dienste
liefert. Es ermglicht dem Administrator auf
der Kommandozeile eine Flle von Scans gegen
ganze Netze und Portbereiche und ist auf allen
Unix-Systemen verfgbar.
Scan Modes
Darber hinaus bietet Nmap verschiedene ScanModi, die eine ganze Palette von Mglichkeiten
erffnen. Fr einen schnellen berblick, welche
Rechner in einem Netz vorhanden und aktiv
sind, bietet sich der List-Scan nmap -sL oder
ein Ping-Scan nmap -sP an.
Im einem zweiten Schritt kommen erweiterte
Scan-Techniken zum Einsatz, mit denen offene
Ports, verwendete Betriebssysteme oder auch
die Versionen der angebotenen Dienste identifiziert werden.
Nmap kann dabei sowohl TCP-Scans in verschiedenen Varianten als auch UDP-Scans
durchfhren. Bei Letzteren sollte aber beachtet
werden, dass diese mglicherweise aufgrund
von Beschrnkungen der ICMP-Pakete etwas
lnger dauern. Drei bis vier Sekunden pro gescanntem Port sind dabei keine Seltenheit, was
einen Scan ber 1000 Ports schnell ber eine
Stunde dauern lsst. Hier helfen dann nur noch
gezielte Abfragen weiter.
Sniffing
iptraf und intop
sammeln Netzwerkdaten
und prsentieren die Daten in konfigurierbaren
Tabellen. Den Traffic auf
dem lokalen Rechner,
einer Firewall oder einem
Router listet der Aufruf
iptables -L -vv -x gezhlt und sortiert nach
den Regelketten einer
installierten Firewall.
Scanner
Neben nmap,ethereal
und wireshark identifizieren auch nessus
und dessen freies Pendant
openVAS angebotene
Services oder Schwachstellen auf Rechnern.
Fazit
In puncto Netzwerkberwachung gibt es auch
auf der Kommandozeile eine groe Anzahl von
ntzlichen Werkzeugen, die im Standardumfang der meisten Distributionen enthalten sind.
Viele alltgliche Probleme lassen sich damit mhelos und ohne Konfiguration lokalisieren und
beheben. Umfangreiche Werkzeuge wie Nagios
oder MRTG haben fr diesen Einsatzzweck ein
eher schlechtes Kosten-Nutzen-Verhltnis, dafr bieten sie aber die Mglichkeit von Langzeitanalysen, optimierten und gut automatisierbaren Vorgehensweisen. Fr einen schnellen Einsatz sind die in diesem Beitrag beschriebenen
Hilfsmittel jedoch oft hervorragend geeignet. Es
muss eben doch nicht immer MRTG oder Nagios sein. (mfe)
nnn
Infos
[1] Mtr: [http://www.bitwizard.nl/mtr]
Der Autor
Christoph Wegener ist
promovierter Physiker
und seit vielen Jahren
mit der wecon.it-consulting (www.wecon.
net) als freier Berater
in den Bereichen Linux
und IT-Sicherheit unterwegs. Darber hinaus
ist er seit Anfang 2005
am europischen
Kompetenzzentrum fr
Sicherheit in der Informationstechnologie
(eurobits) in Bochum
ttig.
Was wre wenn? Mathematische Lastsimulation mit Perl
Berechenbare
Performance
Wer nicht bei einem Monitoring stehen bleiben will,
das nur feststellt, ob ein Dienst verfgbar ist oder
nicht, fr den stellt sich schnell die Frage: Was tun
mit den gesammelten Performancedaten? Man
kann sie interpolieren und mit statistischen Mitteln
Trends ableiten, klebt damit allerdings an den aktuellen Voraussetzungen, die man in die Zukunft
fortschreiben muss. Oder man simuliert auf dieser
Datengrundlage, wie sich beispielsweise eine Aufstockung der Hardware oder auch Lastnderungen
auswirken wrden. Wie das geht, demonstriert dieser Beitrag. Neil J. Gunther
Grundlagen
Drei aufeinander folgende Prozesse machen

Performance-Management aus: Monitoring,
Analyse und Modellierung (Abbildung 1). Das
Monitoring sammelt die Daten, die Analyse erkennt in ihnen wiederkehrende Muster, und das
Modeling sagt auf dieser Grundlage knftige
Ereignisse wie etwa Ressourcenengpsse voraus.
PDQ (Pretty Damn Quick) ist ein QueueingAnalysetool in Gestalt eines Perl-Moduls, das
dazu dient, solche Vorhersagen zu ermglichen.
Einfhrung
Eine passende Monitoring-Lsung ist ausgewhlt, installiert und konfiguriert jetzt luft sie
im Produktivbetrieb. Das aber ist nicht etwa das
Ende, sondern ein neuer Anfang und Ausgangspunkt. Erfolgreiches Performance-Management
umfasst nmlich mindestens drei Phasen: Das
Performance-Monitoring, die PerformanceAnalyse und das Performance-Modeling (Abbildung 1).
Diese Phasen sind eng miteinander verknpft.
So besteht eine wesentliche Voraussetzung zunchst darin, die Leistung zu messen und Performancedaten zu sammeln. Ohne Daten lassen
sich die Leistungseigenschaften der zu berwachenden Systeme und Applikationen nicht
quantifizieren. Dies ist auch die Aufgabe der
Monitoring-Phase.
Allerdings ist das Monitoring auf sich alleine
gestellt so sinnlos wie das bloe Starren auf die
tnzelnden Zeiger des Armaturenbretts eines
Autos. Um die Lage richtig einschtzen zu knnen, muss man durch die Windschutzscheibe
schauen, um andere Fahrzeuge in der Nhe zu
erkennen. Mit anderen Worten: Wer sich ausschlielich auf das Monitoring verlsst, der erhlt lediglich einen kurzfristigen Eindruck des
Systemverhaltens (Abbildung 2).
Der Blick aus dem Fenster erffnet dagegen
die Fernsicht. Doch je weiter weg ein Beobachtungsobjekt ist, desto schwieriger lsst sich mit
Bestimmtheit sagen, wie wichtig es einmal werden knnte.
Um aus Beobachtungswerten spter Prognosen
ableiten zu knnen, muss man die Leistungsdaten aus der berwachungsphase mit Zeitstempeln versehen und sie in einer Datenbank
speichern. Darauf baut die nchste Phase, die
Performanceanalyse auf, die den Admin in die
Lage versetzt, die gewonnenen Daten aus einer
historischen Perspektive zu betrachten, um in
ihnen Muster und Trends zu erkennen.
Auf das Performance-Modeling baut die Leistungsvorhersage auf, die Phase des PerformanceManagements, die einen in die Lage versetzt,
aus dem Fenster und in die Zukunft zu blicken.
Genau wie beim Wetterbericht (um ein weiteres Gleichnis zu bemhen) bentigt man dafr
zustzliche Tools, mit deren Hilfe man die Daten so aufbereitet, dass sie in Leistungsmodelle
eingehen knnen. Dazu ist etwas Mathematik
ntig. Aber es ist ja auch so gut wie unmglich,
das Wetter ohne Instrumente vorherzusagen,
nur indem man auf das Rascheln der Bltter im
Wind hrt.
Statistik versus Warteschlange

Es gibt zwei klassische Anstze fr das Performance-Modeling: die statistische Datenanalyse
und das Warteschlangenmodell. Beide Metho-
Performance monitoring
Performance modeling
Performance analysis
Past
Present
Future
Abbildung 1: Die drei Phasen des Performance-Managements Monitoring, Analyse und Modeling sind eng miteinander verknpft.
den schlieen sich gegenseitig nicht aus. Die

Unterschiede lassen sich wie folgt zusammenfassen: Die statistische Datenanalyse, eine Aufgabe, die jede Buchhaltung kennt, basiert auf
der Berechnung von Trends in den Rohdaten.
Statistiker entwickelten viele schlaue Techniken
und Tools im Laufe der Jahre, und ein Groteil
dieser Intelligenz ist in Form von Open-Source-
Abbildung 2: Ein 24-Stunden-Protokoll der durchschnittlichen Auslastung,

das die Orca-Tools fr Linux [1] auf eine Zeitachse projizieren.
Grundlagen
stalten, wie man aus den bisherigen Ausfhrungen vielleicht vermuten wrde. In Wirklichkeit
ist es oft erstaunlich einfach.
Marschroute
Abbildung 3: Kunden stehen in einem Lebensmittelmarkt Schlange.
Paketen fr das statistische Modeling erhltlich.

Ein Beispiel fr ein mchtiges freies Tool dieser
Art ist R [2].
Dieser Ansatz ist jedoch dadurch begrenzt, dass
er sich ausschlielich auf bestehende Daten
sttzt. Wenn die Zukunft jedoch (angenehme
oder unangenehme) berraschungen bereithlt,
die sich aus den aktuellen Daten nicht erkennen
lassen, leidet die Zuverlssigkeit der Vorhersage.
Und wer sich etwa mit der Brse beschftigt, der
wei, dass dies stndig geschieht.
Warteschlangenmodelle sind von diesen Beschrnkungen nicht betroffen. Das liegt daran,
dass sie per Definition mit Hilfe des QueueingParadigmas vom realen System abstrahieren.
Allerdings verursacht diese Vorgehensweise
einen greren Aufwand als die Trendanalyse
der Rohdaten, und sie setzt voraus, dass die
Queueing-Abstraktion das echte System genau nachbildet. Je strker das Modell von der
Wirklichkeit abweicht, desto hher ist die Ungenauigkeit der Vorhersagen. Wie dieser Artikel
hoffentlich demonstriert, ist es aber bei weitem
nicht so schwer, Warteschlangenmodelle zu ge-
Warteschlange
Neuankmmlinge
Wartende
Kunden
Warum Warteschlangen?
Buffer und Stacks sind in Computersystemen
allgegenwrtig. Beim Buffer handelt es sich um
eine Warteschlange, bei der die Reihenfolge des
Eintreffens von Anforderungen die Reihenfolge
ihrer Abarbeitung diktiert. Man spricht hier
auch von FIFO (first-in, first-out) oder FCFS
(first come, first served). Im Gegenzug dazu bedient ein Stack Anforderungen in LIFO-Reihenfolge (last-in, first-out); es handelt sich um eine
LCFS-Warteschlange (last-come, first served).
Tabelle 1: Interessante Leistungsmetriken
Kassierer
Abgefertigte
Kunden
Kunden
werden bedient
Abbildung 4: Komponenten einer symbolischen Warteschlange.
Zu Anfang dieses Beitrags soll das bekannte

Beispiel der Warteschlange im Lebensmittelgeschft ein paar grundlegende Queueing-Konzepte erklren. Hier gibt es an jeder Kasse eine
einfache Warteschlange. Danach erweitert der
Autor das fundamentale Konzept so, dass sich
damit die Skalierbarkeit einer dreischichtigen ECommerce-Anwendung vorhersagen lsst.
Gegen Ende des Artikels rcken realittsnahe
Erweiterungen der vorgestellten Leistungsmodelle und praktische Ratschlge fr den Aufbau
von Leistungsmodellen ins Blickfeld. Alle Beispiele verwenden Perl und das Open-SourceQueueing-Analysetool Pretty Damn Quick
(PDQ), das der Autor zusammen mit Peter
Harding pflegt. Es steht unter [6] zum Download bereitsteht. Die aktuelle Release von PDQ
untersttzt den Aufbau von Modellen in C, Perl
und Python; die nchste Version von PDQ soll
auerdem noch Java und PHP supporten.
Symbol Metrik
PDQ

S
N
Z
R
R
X

Q
N
Input
Input
Input
Input
Output
Output
Output
Output
Output
Output
Ankunftrate
Bedienzeit
User-Last
Denkzeit
Verweilzeit
Antwortzeit
Durchsatz
Auslastung
Warteschlangenlnge
Optimale Last
Grundlagen
Unter Linux ist der History-Buffer eine bekannte

Warteschlange, welche die krzlich aufgerufenen Shell-Befehle speichert. Genau wie der
History-Buffer, ist jede physikalische Implementierung durch die finite Menge an Speicherplatz
(ihre Kapazitt) beschrnkt. Theoretisch kann
eine Warteschlange jedoch eine unendliche oder
unbegrenzte Kapazitt besitzen, so wie das auch
bei PDQ der Fall ist.
Eine Warteschlange ist eine gute Abstraktion
fr gemeinsam genutzte Ressourcen. Ein sehr
bekanntes Beispiel ist die Kasse im Supermarkt.
Diese Ressource besteht aus Auftrgen (den
Menschen, die Schlange stehen) sowie einer
Bedienstation (der Kassiererin). Wenn man mit
dem Einkaufen fertig ist, will man so schnell
wie mglich den Laden verlassen, das ist das
Performanceziel. Man kann dieses Ziel auch so
formulieren, dass es darauf ankommt, mglichst
wenig Zeit in der Schlange zu verbringen man
spricht hier von der Verweilzeit (R).
Nachdem sich ein Kunde fr eine bestimmte
Kasse entschieden hat und sich anstellt, besteht
seine Verweilzeit aus zwei Komponenten: zum
einen aus der Zeit, die er in der Warteschlange
verbringt bevor er zur Kasse gelangt, und zum
anderen aus der Zeit fr die Bedienung durch
den Kassierer, welche dieser bentigt, um die
Einkufe einzugeben, das Geld anzunehmen
und herauszugeben.
Geht man nun davon aus, dass jede Person in
der Warteschlange mehr oder weniger die gleiche Menge an Artikeln im Einkaufswagen hat,
dann kann man erwarten, dass sich die Bedienzeiten pro Kunde im Schnitt angleichen. Darber hinaus steht die Lnge der Warteschlange
offensichtlich im direkten Bezug zur Anzahl der
Kunden. Wenn der Laden fast leer ist, wird die
durchschnittliche Wartezeit um einiges krzer
sein als zu Stozeiten.
Die Abstraktion der Warteschlange (Abbildung
4) bietet ein leistungsfhiges Paradigma, mit
dessen Hilfe sich (unter anderem) die Leistung
von Computersystemen und Netzwerken ermitteln lsst. Ihr besonderer Vorzug ist, dass sie die
ansonsten unterschiedlichen Leistungsdaten,
die die Monitoring-Tools liefern, in einem Modell zusammenfasst.
Dieser Artikel nimmt immer wieder Bezug auf
eine der Beziehungen zwischen den Metriken in
Tabelle 1 und zwar auf die Beziehung zwischen
der Verweilzeit (R), der Servicezeit (S) und der
Ankunftsrate ():
R=
S
1 S
Man kann Gleichung (1) als sehr einfaches Performancemodell betrachten. Die Eingaben fr
das Modell stehen auf der rechten Seite, die Ausgaben auf der linken. Nach genau demselben
Schema funktionieren auch die Berechnungen
mit PDQ. Durch dieses einfache Modell sieht
man sofort, dass bei geringem Publikumsverkehr, die zum Passieren der Kasse bentigte Zeit
(die Verweilzeit) ausschlielich aus der eigenen
Servicezeit besteht. Wenn keine weiteren Personen eintreffen (= 0), dann fllt nur die Zeit an,
die man selbst bentigt, um die Waren eingeben
zu lassen und zu bezahlen.
Wenn das Geschft jedoch stark frequentiert ist,
sodass fr das Produkt S 1 gilt, dann steigt
auch die Verweilzeit sehr stark an. Das rhrt daher, dass sich die Lnge der Warteschlange aus
der Gleichung
Q = R
berechnet. Mit anderen Worten: Die Verweilzeit

steht im direkten Bezug zur Warteschlangenlnge mal Eintreffrate und umgekehrt.
Gleichung (2) stellt auerdem den Bezug zu
den berwachungsdaten her. Die Daten fr
die durchschnittliche Auslastung in Abbildung
2 sind in Wirklichkeit Echtzeitwerte, gemessen
ber relative kurze Zeitabschnitte, beispielsweise
eine Minute. Fr die Berechnung der Warteschlangenlnge (Q) wird dagegen der Durchschnittswert ber die gesamte Messdauer von 24
Stunden verwendet. Will man sich das bildlich
vergegenwrtigen, so kann man sich Q als Hhe
eines imaginren Rechtecks vorstellen, das die
gleiche Flche hat wie die Kurve der berwachungsdaten ber demselben 24-Stunden-Zeitabschnitt.
Eine dazu analoge Beziehung gilt, wenn man
die Wartezeit aus der Verweilzeit (R) in (2) ausklammert:
= S
Mit anderen Worten: Ersetzt man auf der rechten Seite der Gleichung die Verweilzeit R durch
die Servicezeit S, dann entspricht auf der linken
Seite die Ausgabemenge der Auslastung in Tabelle 1.
E
Instantaneous throughput
Grundlagen
Ramp up
Steady-state
Ramp down
Elapsed time
Abbildung 5: Durchsatzmessungen im stabilen Zustand.
Geschichte der Warteschlangentheorie
theoretische Entwicklungen zu vereinfachten

Algorithmen fr die Berechnung der Leistungsmetriken von Warteschlangensystemen gefhrt.
Diese Algorithmen sind auch in Tools wie PDQ
implementiert. Bei den neuesten Entwicklungen
in der Warteschlangentheorie geht es um Modelle fr den so genannten selbsthnlichen oder
fraktalisierten Paketverkehr im Internet. Diese
Begriffe sprengen zwar den Rahmen dieses Artikels; wenn Sie sich aber fr weiterfhrende Informationen interessieren, so sei Ihnen Kapitel
10 von [4] empfohlen.
Annahmen in PDQ-Modellen
Eine der grundlegenden Annahmen in PDQ ist,
dass sowohl die durchschnittliche Zwischenankunftszeit wie die durchschnittliche Bediendauer beide statistisch zufllig sind. Mathematisch gesehen bedeutet das, dass jede Ankunft
und jedes Bedienereignis zu einem PoissonProzess gehrt. Dann entspricht die Dauer dem
durchschnittlichen oder Mittelwert einer exponentialen Wahrscheinlichkeitsstreuung. Erlang
hat festgestellt, dass sich der Verkehr im Telefonnetz tatschlich dieser Anforderung entsprechend verhlt. Es gibt Methoden [5], mit deren
Hilfe sich feststellen lsst, wie gut gegebene Monitoring-Daten diese Anforderung erfllen.
Wenn diese Monitoring-Daten wesentlich von
den Bedingungen des Exponentials abweichen,
ist es vielleicht sinnvoller, auf einen ereignisbasierten Simulator auszuweichen, wie beispielsweise SimPy [3], mit dessen Hilfe sich eine grere Bandbreite an Wahrscheinlichkeitsstreuungen bercksichtigen lsst. Das Problem dabei
ist, dass die Programmierung und das Debuggen mehr Zeit in Anspruch nehmen (bei jeder
Simulation geht es gleichzeitig um die Programmierung); auerdem bentigen Sie lnger, um
sicherzustellen, dass Ihre Ergebnisse statistisch
gltig sind.
Ein weiterer Aspekt, der bei jeder wie auch immer gearteten Vorhersage strt, sind die Fehler,
die grundlegende Annahmen des Modells verursachen. Annahmen in Modellen verursachen
Die mathematische Theorie der Warteschlangen

ist noch sehr jung; tatschlich gibt es sie seit weniger als 100 Jahren. Agner Erlang hat im Jahre
1917 das erste formale Warteschlangenmodell
entwickelt, um die Leistung des Telefonsystems
(des Internets der damaligen Zeit) zu analysieren. Seine Aufgabe bestand darin, fr Amtsgesprche aus Kopenhagen die Puffergre fr
Vermittlungen festzulegen. Die heutige Terminologie bezeichnet dieses Modell als EinzelWarteschlangenmodell.
Einer der nchsten wesentlichen Schritte in der
Entwicklung der Warteschlangentheorie folgte
1957, als James Jackson die ersten formalen
Lsungen fr die Berechnung eines Netzwerks
oder einer Kette aus Warteschlangen entwickelte. Dieses Ergebnis blieb 20 Jahre lang rein
akademisch, bis man schlielich den Bezug zur
Implementierung des Internets erkannte. Das
Warteschlangenmodell erwies sich dafr als zutreffend mit einer Abweichung von weniger als
fnf Prozent. 1967, etwa fnfzig Jahre nach dem
ersten Modell von Erlang, setzte ein Doktorand
namens Allan Scherr ein Warteschlangenmodell
ein, um die Leistung der CTSS- und MulticsTime-Sharing-Computersysteme zu berechnen, die in vieTabelle 2: PDQ-Funktionen fr Abbildung 4
len Beziehungen die Vorlufer
der Unix- und letztendlich
Physikalisch
Warteschlange
PDQ-Funktion
damit auch der Linux-Rechner
Kunde
Arbeitslast
CreateOpen()
waren.
Kassierer
Bedienknoten
CreateNode()
In den spten 70er und frhen
Buchhaltung
Bedienzeit
SetDemand()
80er Jahren haben einige neue
Grundlagen
tatschlich systematische Fehler im Vorhersageprozess, und daher sollte man sich alle PDQ-Ergebnisse in Wirklichkeit als Streuung plausibler
Werte vorstellen. Was auerdem oft unbercksichtigt bleibt, ist die Tatsache, dass jede Quantifizierung fehlerbehaftet ist. Davon sind auch
die Monitoring-Daten betroffen entgegen der
landlufigen Meinung sind sie nicht gottgegeben. Aber wer kennt schon den exakten Fehlerbereich seiner Monitoring-Daten?
Weil es sich bei allen PDQ-Performance-Einund -Ausgaben um Durchschnittswerte handelt,
ist unbedingt sicherzustellen, dass es sich dabei
um zuverlssige Mittelwerte handelt. Die lassen
sich beispielsweise in der stabilen Phase (steady
state) eines Lasttests messen (Abbildung 5).
Der durchschnittliche Durchsatz im stabilen
Zustand (X) fr eine bekannte Benutzerlast (N)
ergibt sich, indem man Messungen ber einen
lngeren Zeitraum T nimmt und alle Anfahroder Herunterfahrzeiten aus den Daten eliminiert. Eine nominelle Zeit T kann beispielsweise
fnf bis zehn Minuten betragen, je nach Anwendung. Auch bei Industriestandard-Benchmarks
wie SPEC und TPC gilt die Anforderung, dass
alle gemeldeten Durchsatzergebnisse aus einem
stabilen Zustand gemessen stammen.
Eine einfache Warteschlange

in PDQ
Die Beziehung zwischen dem Szenario im Lebensmittelmarkt und den PDQ-Funktionen
fasst Tabelle 2 zusammen.
Nach diesem Schema kann man leicht ein einfaches Modell der Kasse in einem Lebensmittelmarkt nachbilden, wie das folgende Listing fr
die Perl-Variante von PDQ zeigt (Listing 1).
Im PDQ-Code (unten) befinden sich die InputWerte fr die Ankunftsrate () und die Bedienzeit (S):
= 3/ 4
S = 1.0
Wendet man nun die metrische Beziehung (2)

an, ergibt sich die Auslastung der Kasse wie
folgt:
3 *1
= 0.75
4
Analog dazu ergibt sich fr die Verweildauer

durch Anwenden der metrischen Beziehungen
(1) und (2):
1.0
R=
= 4.0 sec onds
3
1 * 1.0
4
So erfhrt man, dass die der Verweildauer an der

Kasse gleich vier durchschnittliche Bedienzeiten
ist, wenn der Kassierer zu 75 % ausgelastet ist.
Die sich daraus ergebende durchschnittliche
Warteschlangenlnge ist:
E
Listing 1: Kassenmodell in PDQ

01
#! /usr/bin/perl
15
pdq::SetTUnit("Sec");
02
# groxq.pl
16
# PDQ Bedienknoten erstellen (KassiererIn)
03
use pdq;
17
$pdq::nodes = pdq::CreateNode($ServerName, $pdq::
04
#------------------------- INPUTS
--------------------05
$ArrivalRate = 3/4; # Kunden je Sekunde
06
$ServiceRate = 1.0; # Kunden je Sekunde
07
$SeviceTime = 1/$ServiceRate;
08
$ServerName = "Cashier";
CEN, $pdq::FCFS);
18
# Die PDQ-Aufgabe mit Ankunftsrate erstellen
19
$pdq::streams = pdq::CreateOpen($Workload,
$ArrivalRate);
20
# Bedienrate je Kunden an der Kasse definieren
21
pdq::SetDemand($ServerName, $Workload,
09
$Workload = "Customers";
10
#------------------------ PDQ Model
------------------11
# Interne PDQ-Variable initialisieren
$SeviceTime);
22
#------------------------ OUTPUTS
---------------------
12
pdq::Init("Grocery Store Checkout");
23
# Das PDQ-Modell lsen
13
# Die von PDQ::Report() genutzten Einheiten
24
pdq::Solve($pdq::CANON);
anpassen
25
pdq::Report(); # einen vollstndigen PDQ-Report
14
pdq::SetWUnit("Cust");
generieren
Grundlagen
Fhigkeit, den Workflow zwischen mehreren

Warteschlangenressourcen abbilden zu knnen,
also die Interaktion zwischen Anforderungen,
die gleichzeitig an Prozessoren, Festplatten und
das Netzwerk gestellt werden. Die nchsten Abschnitte zeigen, wie man diese Aufgabe mithilfe
von PDQ erfllt.
Warteschlangensysteme
Abbildung 6: Ein offenes System mit drei Queueing-Phasen.
Q=
3
= 3.0 customers
4 * 4.0
Aus Platzgrnden kann hier lediglich die Ausgabeseite des generischen PDQ-Reports fr dieses
Modell gezeigt werden (Kasten PDQ-Resultate).
Die berechneten PDQ-Werte stimmen genau
mit den theoretischen Vorhersagen fr den
Durchsatz (X = ), die Auslastung (), die Warteschlangenlnge (Q) und die Verweildauer (R)
berein.
Nachdem die fundamentalen Begriffe bekannt
sind und PDQ als Tool fr die Berechnungen
eingefhrt ist, lassen sich diese Werkzeuge auch
auf Computerprobleme anwenden, etwa auf die
Vorhersage der Leistung individueller Hardwareressourcen wie der Ausfhrungswarteschlange der CPU (siehe Kapitel 4 in [5]) oder
eines Festplattengertetreibers. Die meisten
Lehrwerke zur Warteschlangentheorie bieten
Beispiele auf diesem Niveau.
Wichtiger fr die Vorhersage der Leistung von
echten Computersystemen ist allerdings die
PDQ-Resultate
01
*************************************
02
***** Pretty Damn Quick REPORT ******
03
*************************************
04
*** of : Sun Feb 4 17:25:39 2007
***
05
*** for: Grocery Store Checkout
***
06
*** Ver: PDQ Analyzer v3.0 111904 ***
Tabelle 3: Die aus Tabelle 4 ermittelten Bedienzeiten
07
*************************************
Sws
Sas
Sdb
08
****** RESOURCE Performance
1
2
4
7
10
20
Avg
0.0088
0.0085
0.0087
0.0095
0.0097
0.0103
0.0093
0.0021
0.0033
0.0045
0.0034
0.0022
0.0010
0.0028
0.0019
0.0012
0.0007
0.0005
0.0006
0.0006
0.0009
*******
09
Metric Resource Work Value Unit
10
--------- ------ ---- ----- ---11
Throughput Cashier Customers 0.7500 Cust/Sec
12
Utilization Cashier Customers 75.0000 Percent
13
Queue Length Cashier Customers 3.0000 Cust
14
Residence Time Cashier Customers 4.0000 Sec
Anforderungen, die aus einer Warteschlange

in eine andere flieen, entsprechen einer Warteschlangenkette oder einem Warteschlangennetz .
Erfasst man anstelle der Anzahl der Anforderungen lediglich die Ankunftsrate (), spricht
man von einem offenen System oder Kreis
(Abbildung 6). Ein Beispiel fr eine Situation
dieser Art, die nicht aus der Welt der Computer stammt und sich durch das offene Modell in
Abbildung 6 abbilden liee, wre das Boarding
am Flughafen. Die drei Phasen sind: Warten am
Gate, Schlangestehen auf der Fluggastbrcke,
um ins Flugzeug zu gelangen, und zum Schluss
Schlangestehen im Gang des Flugzeugs beim
Boarding, whrend Passagiere weiter vorn Platz
nehmen.
Die durchschnittliche Antwortzeit (R) ergibt
sich aus den in jeder Warteschlangenphase verbrachten Zeiten, also der Summe der drei Verweildauern. Im Computerkontext liee sich das
auf eine dreistufige Webapplikation anwenden,
von der lediglich die Rate der HTTP-Requests
bekannt ist.
Eine weitere Art von Warteschlangensystemen
wird durch eine finite Menge (N) von Kunden
oder Anforderungen charakterisiert. Genau
diese Situation ergibt sich bei einem Lasttest.
Eine finite Menge von Client-Lastgeneratoren
sendet Anforderungen an das Testsystem, wobei
keine weiteren Anforderungen von auerhalb
Grundlagen
in das isolierte System eintreten

knnen. (Open-Source Lastund Stresstesttools finden Sie
unter [7].)
Darber hinaus wirkt eine Art
Rckkopplungsmechanismus,
weil zu jeder Zeit nicht mehr als
eine Anforderung unbearbeitet
bleiben darf. Mit anderen Worten: Jeder Lastgenerator sendet
erst dann eine weitere Anforderung, wenn die vorherige abgearbeitet worden ist. In der Sprache der Warteschlangentheorie
geht es hier um einen geschlossenen Warteschlangenkreis.
E-CommerceApplikation in PDQ
N clients
Z = 0 ms
Requests
Responses
Dws
Das
Web Server
App Server
Ddb
DBMS Server
Abbildung 7: Ein geschlossener Warteschlangenkreis mit drei Warteschlangenphasen in

Verbindung mit einer speziellen Wartephase (oben), die N Client-seitigen Lastgeneratoren
mit einer durchschnittlichen Bedenkzeit von Z entspricht.
Dieser Abschnitt zeigt, wie sich

das PDQ-Modell des geschlossenen Systems aus durch Performance-Monitore auf jedem der
Abbildung 7 einsetzen lsst, um die Durchsatz- lokalen Server gemessen. Die gemessene Ausleistung der dreistufigen E-Commerce-Archi- lastung () und der Durchsatz (X) in Tabelle
tektur aus Abbildung 8 vorherzusagen. Wegen 4 lassen sich in eine umgestellten Version der
der hohen Kosten solcher Installationen sind Gleichung (3) einsetzen, um die entsprechenden
Lasttests mit einem kleineren Modell der spte- Bedienzeiten fr jede Stufe zu ermitteln:
ren Produktivumgebung die Regel. In unserem
Beispiel soll jeweils ein Server jede Stufe abbil
9
S=
den. Ein Testsystem dieser Art eignet sich sehr
X
gut fr Leistungsmessungen, wie sie fr die Parametrisierung eines PDQ-Modells vonnten Der nchste Abschnitt zeigt, wie der Durchsind.
schnittswert der ermittelten Bedienzeiten (die
Den Durchsatz misst man in HTTP-Gets/Se- letzte Zeile in Tabelle 3) einzusetzen ist, um das
kunde (GPS) und die entsprechende Antwort- PDQ-Modell zu parametrisieren.
E
zeitleistung in Sekunden (s). Aus
Platzgrnden konzentriert sich
dieser Artikel ausschlielich auf
die Nachbildung der DurchsatzLoad
leistung. Wer sich fr AntwortBalancer
zeitmodelle interessiert, findet
dazu Einzelheiten in [5].
Die kritischen Lasttestergebnisse
fr dieses Beispiel fasst Tabelle
4 zusammen. Leider wurden
die Daten nicht mit einer gleich
bleibenden Inkrementierung der
User-Last erzeugt, was fr eine
korrekte Leistungsanalyse nicht
gerade optimal ist, aber dennoch
kein unberwindliches Problem
Load
Web
Application
darstellt. X und R sind SystemDrivers
Servers
Cluster
metriken auf der Clientseite. Die
Auslastung wurde eigenstndig Abbildung 8: Multitier-E-Commerce-Anwendung.
Disk Array
Database
Server
Grundlagen
1
max(Sws , Sas , Sdb )
1
=
0, 0093
= 107.53 GPS
Tabelle 4: Gemessene Leistungsdaten in jeder Stufe

N
(Clients)
X
(GPS)
R
(s)
Sws
(%)
Sas
(%)
Sdb
(%)
1
2
4
7
10
20
24
48
85
100
99
94
0.039
0.039
0.044
0.067
0.099
0.210
21
41
74
95
96
97
8
13
20
23
22
22
4
5
5
5
6
6
Xmax =
Die Bedienzeiten fr jede Last zeigt Tabelle 3 zusammen mit den Durchschnittswerten in der letzten Zeile der Tabelle.
Naives PDQ-Modell
Der erste Versuch, die Leistungscharakteristik von Abbildung 7 nachzubilden, stellt jeden
Anwendungsserver einfach als eigenstndigen
PDQ-Knoten unter Einsatz der durchschnittlichen Bedienzeiten aus Tabelle 3 dar. In Perl::
PDQ wird die Parametrisierung der Warteschlangenknoten so, wie in Listing 2 zu sehen,
codiert.
Ein Diagramm des Durchsatzes, den dieses erste,
sehr einfache Modell vorhersagt, zeigt die Abbildung 9. Man sieht auf den ersten Blick, dass das
naive PDQ-Modell einen Durchsatz prophezeit,
der im Vergleich mit den real gemessenen Daten
der Testumgebung zu schnell absttigt.
Allerdings teilt uns PDQ ebenfalls mit, dass der
bestmgliche Durchsatz fr dieses System auf
Basis der gemessenen Bedienzeiten aus Tabelle
3 etwa 100 GPS betrgt. Diese Leistung wird
durch einen Ressourcenengpass begrenzt (die
Warteschlange mit der lngsten durchschnittlichen Bedienzeit), das ist im Beispiel der Frontend-Webserver. Im muss man lasten, dass der
maximale Durchsatz nicht ber einen Wert
steigen kann, der sich aus der Beziehung (10)
ergibt.
Der
hchstmgliche
Durchsatz
wird, wie sich hier zeigt, in unmittelbarer
Nhe des errechneten optimalen Belastungspunkts
N* erreicht (siehe dazu Tabelle 1):
Sws + Sas + Sdb + Z
max(Sws , Sas , Sdb )

0.00993 + 0.0028 + 0.0009 + 0.0
=
0.0093
= 1.40 clieents
N* =
Der liegt bei 1.40 und nicht 20 Clients. ndern

sich die Bedienzeiten in Zukunft, beispielsweise durch eine neue Release der Anwendung,
kann sich der Ressourcenengpass verschieben;
das PDQ-Modell kann dann die Auswirkung
Durchsatz und Antwortzeiten vorhersagen.
Offensichtlich ist es wnschenswert, den gesamten Datenbestand besser nachzubilden als das
mit dem naiven PDQ-Modell gelang. Eine einfache Methode, um der schnellen Sttigung des
Durchsatzes zu begegnen, wre, die Bedenkzeit
auf einen Wert ungleich Null zu setzen:
Z > 0:
$think = 28.0 * 1e-3; # freier Parameter
...
pdq::Init($model);
$pdq::streams = pdq::CreateClosed(U
Listing 2: Parametrisierung des PDQ-Modells

01
pdq::Init($model);
02
$pdq::streams = pdq::CreateClosed($work, $pdq::
TERM, $users,
03
$think);
$pdq::FCFS);
09
$pdq::nodes = pdq::CreateNode($node3, $pdq::CEN,
$pdq::FCFS);
04
...
10
...
05
# eine Warteschlange fr jede der drei Stufen
11
# Zeitbasis sind Sekunden, die in Millisekunden
erstellen
06
$pdq::FCFS);
07
5
08
ausgedrckt werden
12
pdq::SetDemand($node1, $work, 9.3 * 1e-3);
13
14
Grundlagen
$work, $pdq::TERM, $users,
130
$think);
120
110
Auf diese Art werden neue Anforderungen verlangsamt ins System injiziert. Man spielt hier mit
der Bedenkzeit, als wre sie ein freier Parameter. Der positive Wert von Z = 0.028 Sekunden
stimmt nicht mit den Einstellungen berein,
die beim Lasttest tatschlich verwendet wurden, aber er kann einen Hinweis darauf geben,
in welcher Richtung nach einem verbesserten
PDQ-Modell zu suchen ist.
Wie Abbildung 10 zeigt, verbessert die positive
Bedenkzeit das Durchsatzprofil entscheidend.
0.0093 + 0.0028 + 0.0009 + 0.0028

N*=
0.0093
= 4.41 clients
Der Trick mit der Bedenkzeit verrt uns, dass
weitere Latenzen existieren, die in den Stresstestmessungen keine Bercksichtigung fanden.
Die positive Bedenkzeit erzeugt eine Latenz,
sodass sich die Round-Trip-Time der Anforderung verlngert. Als Nebenwirkung verringert
sich der Durchsatz bei niedriger Last. Aber in
der Praxis betrug die Bedenkzeit whrend der
realen Lastmessungen Null! Wie lst man dieses
Paradoxon?
Versteckte Latenzen
bercksichtigen
Als nchsten Trick fgt man dem PDQ-Modell
aus Abbildung 11 Dummy-Knoten hinzu. Allerdings gibt es Bedingungen, die von den Bedienanforderungen der virtuellen Knoten zu erfllen sind. Die Bedienanforderung eines jeden
Dummy-Knotens ist so zu whlen, dass sie die
Bedienanforderung des Engpassknotens nicht
bersteigt.
Darber hinaus ist die Anzahl der DummyKnoten so zu whlen, dass die Summe der Serviceanforderungen einen Wert von Rmin = R(1)
nicht bersteigt, sofern keine Konkurrenz auftritt, das heit fr eine Einzelanforderung. Wie
sich herausstellt, lassen sich diese Bedingungen
erfllen, wenn man zwlf einheitliche DummyKnoten einfhrt, von denen jeder eine Serviceanforderung von 2,2 ms aufweist. Die nderungen des entsprechenden PDQ-Codes sehen
folgendermaen aus:
use constant MAXDUMMIES => 12;
Throughput (X)
90
80
70
60
50
40
Xpdq
30
Xdat
20
10
0
0
10
12
14
16
18
20
Clients (N)
Abbildung 9: Naives PDQ-Durchsatzmodell

$think = 0.0 * 1e-3; #same as in test rig
$dtime = 2.2 * 1e-3; #dummy service time
# Dummy-Knoten mit Bedienzeiten erstellen
for ($i = 0; $i < MAXDUMMIES; $i++) {
$dnode = "Dummy" . ($i < 10 ? "0$i" :U
"$i");
$pdq::nodes = pdq::CreateNode($dnode,U
$pdq::CEN, $pdq::FCFS);
pdq::SetDemand($dnode, $work, $dtime);
}
Man beachte, dass die Bedenkzeit wieder auf

Null zurckgesetzt ist. Die Ergebnisse dieser
nderungen am PDQ-Modell finden sich in Abbildung 12. Das Durchsatzprofil ist immer noch
fr geringe Lasten (N < N*) passend, wobei
0.0093 + 0.0028 + 0.0009 + 12(0.0022 )

0.0093
= 4.24 clients
N*=
130
120
110
100
Throughput (X)
100
90
80
70
60
50
40
30
20
Xdat
10
Xpdq
0
0
10
12
14
16
18
20
Clients (N)
Abbildung 10: Durchsatzmodell mit positiver Bedenkzeit.
10
Grundlagen
N clients
Z = 0 ms
Requests
Responses
Dws
Das
Web Server
App Server
Ddb
DBMS Server
Dummy Servers
Abbildung 11: Dummy-Knoten bilden versteckte Latenzen ab.
aber der Nachbesserung oberhalb von N* bedarf.
Lastabhngige Server
Bestimmte Aspekte des physikalischen Systems
wurden nicht gemessen, sodass die Validierung
des PDQ-Modells schwer fllt. Bisher haben wir

versucht, die Intensitt der Arbeitslast durch
Einfhrung einer positiven Bedenkzeit anzupassen. Die Einstellung von Z = 0.028 Sekunden
beseitigte das Problem der schnellen Sttigung;
gleichzeitig stimmt der Wert nicht mit dem
Wert von Z = 0 Sekunden berein, der fr die
eigentlichen Messungen eingestellt wurde.
Durch die Einfhrung von Dummy-Warteschlangenknoten ins PDQ-Modell wurde das
Modell fr Szenarien mit geringer Last verbessert, aber dadurch wird dem in den Daten beobachteten Abfall des Durchsatzes nicht Rechnung getragen. Um diesen Effekt nachzubilden,
knnen wir den Webserverknoten durch einen
lastabhngigen Knoten ersetzen. Die allgemeine Theorie der lastabhngigen Server wird
in [5] besprochen. In unserem Beispiel wenden
wir einen etwas einfacheren Ansatz an. Aus der
Bedienzeit (Sws) in Tabelle 4 erkennt man, dass
sie nicht fr alle Clientlasten konstant bleibt.
Es wird also eine Methode bentigt, um diese
Variabilitt auszudrcken. Wenn man ein Diagramm der Messdaten fr Sws erstellt, lsst sich
eine statistische Regressionsanpassung durch-
Listing 5: E-Commerce-Modell
01
#! /usr/bin/perl
02
# ebiz_final.pl
03
use pdq;
04
use constant MAXDUMMIES => 12;
05
# Hash AV pairs: (in vusers laden, durchsatz in
gets/sec)
06
%tpdata = ( (1,24), (2,48), (4,85), (7,100),
(10,99), (20,94) );
07
@vusers = keys(%tpdata);
08
$model = "e-Commerce Final Model";
09
$work = "ebiz-tx";
10
$node1 = "WebServer";
11
$node2 = "AppServer";
12
$node3 = "DBMServer";
13
$think = 0.0 * 1e-3; # wie beim testsystem
14
$dtime = 2.2 * 1e-3; # dummy-bedienzeit
15
# Header fr benutzerspezifischen Report
16
printf("%2s\t%4s\t%4s\tD=%2d\n", "N", "Xdat",
"Xpdq", MAXDUMMIES);
17
foreach $users (sort {$a <=> $b} @vusers) {
18
pdq::Init($model);
19
$pdq::streams = pdq::CreateClosed($work, $pdq::
TERM, $users,
20
$think);
11
21
$pdq::FCFS);
22
$pdq::FCFS);
23
$pdq::FCFS);
24
# Zeitbasis in Sekunden in Millisekunden
ausgedrckt
25
pdq::SetDemand($node1, $work, 8.0 * 1e-3 *
($users ** 0.085));
26
27
28
# Dummy-Knoten mit entsprechenden Bedienzeiten
erstellen ...
29
for ($i = 0; $i < MAXDUMMIES; $i++) {
30
$dnode = "Dummy" . ($i < 10 ? "0$i" : "$i");
31
$pdq::nodes = pdq::CreateNode($dnode, $pdq::CEN,
$pdq::FCFS);
32
pdq::SetDemand($dnode, $work, $dtime);
33
}
34
pdq::Solve($pdq::EXACT);
35
printf("%2d\t%2d\t%4.2f\n", $users,
$tpdata{$users},
36
pdq::GetThruput($pdq::TERM, $work));
37
}
Grundlagen
fhren, wie sie Abbildung 13 zeigt. Die sich daraus ergebende Potenzgesetzgleichung lautet:
Damit wird Node1 des PDQ-Modells wie folgt

parametrisiert:
pdq::SetDemand($node1, $work, U
120
Throughput (X)
Dws ( N ) = 8.0000 N
0.0850
140
100
80
60
40
8.0 * 1e-3 * ($users ** 0.085));
Xdat
Xpdq
Die angepasste Ausgabe des fertigen PDQ-Modells zeigt Tabelle 3. Sie zeugt von einer guten
bereinstimmung mit den gemessenen Daten
fr D = 12 Dummy-PDQ-Knoten.
Die Auswirkung auf das Durchsatzmodell lsst
sich in Abbildung 14 erkennen. Die mit Xpdq2
gekennzeichnete Kurve zeigt den vorhergesagten bersteuerten Durchsatz auf Basis des
lastabhngigen Servers fr das Webfrontend,
und die Vorhersagen liegen locker innerhalb des
Fehlerbereichs der gemessenen Daten.
In diesem Fall bringt es wenig, PDQ fr die Vorhersage einer Last einzusetzen, die oberhalb der
gemessenen Last von N = 20 Clients liegt, weil
der Durchsatz nicht nur gesttigt ist, sondern
auch rckgngig. Nachdem nun ein PDQ-Modell existiert, das mit den Testdaten validiert
wurde, kann man jetzt alle erdenklichen Waswre-wenn-Szenarien durchspielen.
Weitere Forschungen mit PDQ

Das vorherige Beispiel ist bereits ziemlich anspruchsvoll, und hnliche PDQ-Modelle sind
fr die meisten Anwendungsflle vollkommen
ausreichend. Allerdings gibt es auch Situationen,
in denen detailliertere Modelle erforderlich sein
knnen. Zwei Beispiele fr diese Szenarien sind
multiple Server und multiple Aufgaben.
20
SXB
0
0
Xdat
Xpdq D=12
1
2
4
7
10
20
24
48
85
100
99
94
26.25
47.41
77.42
98.09
101.71
96.90
10
12
14
16
18
20
Abbildung 12: Durchsatz bei Z = 0 mit Dummy-Knoten
Servern aus Abbildung 15 nachbilden knnte,

wre das Schlangestehen in einer Bank oder einem Postamt. Im Kontext der Computer-Performance knnte Abbildung 15 als einfaches
Modell eines symmetrischen Mehrprozessorsystems dienen.
Weitere Informationen zu diesem Thema finden
Sie in Kapitel 7 von [5]. Die Antwortzeit in (1)
wird durch folgendes ersetzt:
S
1 m
wobei = S, und m ist die integrale Anzahl

von Servern. Technisch betrachtet handelt es
sich um eine Annherung, aber keine schlechte!
Die genaue Lsung ist komplexer und lsst sich
mit dem folgenden Perl-Algorithmus entdecken
(Listing 3).
E
10.5
10
Service Demand
Tabelle 5: Modellresultate
Clients (N)
Multiple Server
Ein Szenario auerhalb der Computerwelt, das
man mithilfe der Warteschlange mit multiplen
UXB
9.5
y = 8.3437x 0.0645
R2 = 0.8745
9
Data_Dws
8.0 N^{0.085}
8.5
Power (Data_Dws)
8
0
10
15
20
Clients (N)
Abbildung 13: Regressionsanpassung der Webserver-Zeiten
12
Grundlagen
130
120
110
Throughput (X)
100
90
80
70
60
50
Xdat
40
Xpdq1
30
UXB
20
SXB
10
Xpdq2
0
0
10
12
14
16
18
20
Clients (N)
Abbildung 14: Modell des lastabhngigen Durchsatzes
Es handelt sich um genau das Warteschlangenmodell, das Erlang vor 100 Jahren entwickelt
hat. Damals stellte jeder Server eine Hauptleitung im Telefonnetz dar.
Multiple Aufgaben
Was in Wirklichkeit sehr hufig vorkommt, ist,
dass eine einzelne Ressource, etwa ein Datenbankserver, mit verschiedenen Transaktionstypen umgehen muss. Zum Beispiel kann der
Kauf eines Flugtickets oder die Buchung eines
Hotelzimmers im Internet ein halbes Dutzend
unterschiedliche Transaktionen erfordern, bevor das Ticket ausgestellt oder das Zimmer endlich reserviert ist. Situationen dieser Art lassen
sich wie folgt mit PDQ abbilden.
Man betrachte den einfacheren Fall von drei unterschiedlichen Transaktionstypen, die durch
die Farben Rot, Grn und Blau gekennzeichnet werden. Jede dieser eingefrbten Aufgaben
kann auf eine gemeinsam genutzte Ressource
zugreifen, zum Beispiel einen Datenbankserver.
Im Warteschlangenparadigma (Abbildung 16)
wird jede der bunten Aufgaben durch die unter-
Abbildung 15: PDQ-Modell einer Multiserver-Warteschlange
13
schiedlichen Bedienzeiten charakterisiert. Mit

anderen Worten: Die rote Last erhlt eine rote
Bedienzeit, die grne eine grne Bedienzeit und
so weiter. Fr jede Farbe gilt auch eine eigene
Ankunftsrate.
Geht man davon aus, dass sich die Bedienzeiten
unterscheiden, resultiert die tatschliche Auswirkung auf die Warteschlange beim Eintreffen
beispielsweise einer roten Anforderung nicht
mehr allein aus der Anzahl von bereits wartenden Anforderungen (das trifft nur fr eine monochrome Aufgabe zu), sondern aus der Farbkombination der wartenden Anforderungen. In
PDQ lsst sich Abbildung 16 vielleicht so darstellen wie im Kasten Gemischte Workloads.
Natrlich ist der durch multiple Aufgaben generierte PDQ-Report komplexer aufgrund der
vielen mglichen Interaktionen. Auf jeden Fall
wirft er etwas Licht auf die vielfltigen Erweiterungsmglichkeiten von PDQ, um realistische
Computerarchitekturen abbilden zu knnen.
Diese Thematik noch weiter auszufhren, wrde
den Rahmen sprengen, aber man findet weitere
Details in [5].
Richtlinien fr den Einsatz von

PDQ
Modelle jeder Art zu erstellen, ist teils Wissenschaft und teils Kunst, und daher ist es unmglich, ein komplettes Regelwerk oder eine
komplette Sammlung von Algorithmen bereitzustellen, die immer das richtige Modell liefern.
Wie dieser Artikel illustriert, handelt es sich in
Wirklichkeit um einen Prozess der stndigen
Verbesserung. Erfahrung ist durch nichts zu ersetzen, und sie gewinnt man bekanntlich durch
die stndige Wiederholung.
In diesem Sinne folgen nun einige Richtlinien,
die unter Umstnden helfen, wenn man PDQModelle kreiert: .
n Keep it simple: Ein PDQ-Modell sollte so
einfach wie irgend mglich sein, aber auch
nicht einfacher. Es ist kaum zu vermeiden,
dass man umso mehr Details in das PDQModell stopfen mchte, je mehr man ber
die Systemarchitektur wei. Das fhrt jedoch
unausweichlich zu einer berlastung des
Modells.
nEher die Streckenkarte als die U-Bahn im
Hinterkopf behalten: Ein PDQ-Modell verhlt sich zum Computersystem wie eine
Karte der U-Bahn zum physikalischen UBahn-Netz. Eine U-Bahn-Karte ist eine Ab-
Grundlagen
straktion, die kaum etwas mit der physischen

Beschaffenheit des Netzes zu tun hat. Sie bietet gerade ausreichende Details, sodass man
von Punkt A nach Punkt B kommt. Sie enthlt jedoch keine berflssigen Details wie
die Hhe der Bahnhfe ber Normalnull, ja
noch nicht einmal die Entfernung zwischen
ihnen. Ein PDQ-Modell ist eine hnliche Abstraktion.
nDas groe Bild: Im Gegensatz zu vielen Aspekten der Computertechnologie, bei denen
man groe Mengen winziger Details aufnehmen muss, geht es beim PDQ-Modell darum
zu entscheiden, wie viele Details man ignorieren kann!
nSuchen nach dem Operationsprinzip: Wer
das Operationsprinzip nicht in weniger als
25 Worten beschreiben kann, versteht es
wahrscheinlich nicht gut genug, um mit dem
Aufbau eines PDQ-Modells zu beginnen.
Das Operationsprinzip fr ein TimesharingComputersystem lsst sich beispielsweise wie
folgt ausdrcken: Timesharing gibt jedem
Benutzer die Illusion, dass er der einzige aktive Benutzer des Systems ist. Die Hunderte
Zeilen Code in Linux, um Timeslicing zu implementieren, dienen lediglich dem Zweck,
diese Illusion zu untermauern.
nDen schwarzen Peter weitergeben: Beim
PDQ-Modeling geht es auch darum, die Verantwortung zu verteilen. Als Performanceanalyst muss man lediglich das Leistungsproblem aufdecken dann tritt man beiseite und
lsst die anderen es beheben.
nWo anfangen? Oder Spa mit Baukltzen:
Ein mglicher Ausgangspunkt fr ein PDQModell wre ein Diagramm mit Funktionsblcken. Das Ziel dabei ist, zu erkennen, wo
in welcher Phase Zeit fr die Verarbeitung
der zu untersuchenden Aufgabe aufgewandt
wird. Letztendlich wird jeder Funktionsblock in ein Warteschlangensubsystem umgewandelt. Dabei kann man zwischen der
sequenziellen und parallelen Verarbeitung
unterscheiden. Andere, ebenfalls auf Diagrammen basierende Techniken, beispielsweise UML-Diagramme, knnen auerdem
ntzlich sein.
nInput und Output: Beim Definieren eines
PDQ-Modells ist es ntzlich, eine Liste der
Inputs (Messungen oder Schtzungen, die
zum Parametrisieren des Modells eingesetzt
werden) und Outputs (Zahlen, die sich durch
die Berechnung des Modells ergeben) aufzustellen.

nKeine Bedienung, keine Warteschlange: Analog zur Regel frs Restaurant: Keine Schuhe,
keine Bedienung! Nun ja, die Regel fr
PDQ-Modelle lautet: Keine Bedienung, keine
Warteschlange. In PDQ-Modellen ist es sinnlos, Warteschlangenknoten zu erstellen, fr
die es keine gemessenen Bedienzeiten gibt.
Wenn die Messungen des echten Systems
keine Bedienzeit fr einen zu modelllierenden PDQ-Knoten enthalten, dann lsst sich
Abbildung 16: PDQ-Modell einer Warteschlange mit multiplen Aufgaben
der Knoten nicht definieren.

schtzen: Bedienzeiten lassen
sich oft nur schwer direkt messen. Aber oft
lsst sich die Bedienzeit aus anderen Leistungsmetriken ableiten, die sich leichter
berwachen lassen. Siehe dazu Tabelle 4.
nndern der Daten: Wenn die Messungen
nicht zum PDQ-Leistungsmodell passen,
mssen die Messungen wahrscheinlich wiederholt werden.
E
nBedienzeiten
Listing 3: erlang.pl
01
#! /usr/bin/perl
02
# erlang.pl
03
## Input-Parameter
04
$servers = 8;
05
$erlangs = 4;
06
if($erlangs > $servers) {
07
print "Error: Erlangs exceeds servers\n";
08
exit;
09
}
10
$rho = $erlangs / $servers;
11
$erlangB = $erlangs / (1 + $erlangs);
12
for ($m = 2; $m <= $servers; $m++) {
13
$eb = $erlangB;
14
$erlangB = $eb * $erlangs / ($m + ($eb * $erlangs));
15
}
16
## Ausgabe der Ergebnisse
17
$erlangC = $erlangB / (1 - $rho + ($rho * $erlangB));
18
$normdwtE = $erlangC / ($servers * (1 - $rho));
19
$normdrtE = 1 + $normdwtE; # Exact
20
$normdrtA = 1 / (1 - $rho**$servers); # ca.
14
Grundlagen
Gemischte Workloads
01
$pdq::nodes = pdq::CreateNode("DBserver", $pdq::CEN, $pdq::
FCFS);
02
$pdq::streams = pdq::CreateOpen("Red", $ArrivalsRed);
03
$pdq::streams = pdq::CreateOpen("Grn", $ArrivalsGrn);
04
$pdq::streams = pdq::CreateOpen("Blu", $ArrivalsBlu);
05
pdq::SetDemand("DBserver", "Red", $ServiceRed);
06
pdq::SetDemand("DBserver", "Grn", $ServiceGrn);
07
pdq::SetDemand("DBserver", "Blu", $ServiceBlu);
08
...
nOffene
Der Autor
Neil Gunther, M.Sc.,
Ph.D. ist ein international anerkannter
Consultant und
Grnder der Firma
Performance Dynamics Company
(http://www.perfdynamics.com).
Nach einer Ausbildung in theoretischer Physik nahm
er verschiedene
Forschungs- und
Management-Aufgaben wahr, unter
anderem an der
San Jose State University und bei der
NASA (Voyager- und
Galileo- Missionen.)
Dr. Gunther ist Mitglied von AMS, APS,
ACM, CMG, IEEE und
INFORMS.
15
oder geschlossene Warteschlange?

Wenn man berlegt, welches Warteschlangenmodell anzuwenden ist, fragt man sich,
ob die zu verarbeitende Menge an Anforderungen endlich ist. Lautet die Antwort ja
(und das sollte sie beispielsweise fr eine
Lasttestplattform immer tun), dann handelt
es sich immer um ein geschlossenes Warteschlangenmodell. In allen anderen Fllen
benutzt man am besten ein offenes Warteschlangenmodell.
nMessungen im stabilen Zustand: Die Dauer
der Messung im stabilen Zustand sollte in einer Grenordnung liegen, die um den Faktor 100 grer ist als die lngste auftretende
Bedienzeit.
nWelche Zeiteinheit sollte man verwenden?
Am besten benutzt man immer die Zeiteinheit des Messtools. Wenn das Tool also in Sekunden misst, dann verwendet man Sekunden; misst es Mikrosekunden, tut man es ihm
gleich. Wer mehrere Datenquellen zugleich
berwacht, der sollte stets zuerst alle Messwerte auf die gleichen Einheiten umrechnen,
und erst danach mit der Modellierung beginnen.
nAufgaben treten in der Regel in Dreiergruppen auf: In einem gemischten Aufgabenmodell (Multiclass-Streams in PDQ) vermeide
man die Nutzung von mehr als drei gleichzeitigen Aufgabenstreams, wo immer das mglich ist. Davon abgesehen, dass der resultierende PDQ-Report ansonsten ganz bestimmt
unhandlich ist, interessiert man sich in der
Regel lediglich fr die Interaktion zweier
Aufgaben, das heit fr einen Vergleich von
Aufgabenpaaren. Alles andere gehrt zur
dritten Aufgabe (auch unter dem Namen
Hintergrund bekannt). Wenn man nicht
erkennen kann, wie dieses Problem praktisch
zu lsen wre, dann ist man wahrscheinlich
noch nicht soweit, das PDQ-Modell erstellen

zu knnen.
Fazit
Performance-Modeling ist eine anspruchsvolle
Disziplin, die man am besten durch stndige
Wiederholung trainiert. Ein Groteil der Bemhungen kreisen dabei immer wieder um die
Erstellung und Validierung eines Modells der zu
untersuchenden Umgebung und ihrer Anwendungen. Sobald das PDQ-Modell erst einmal
validiert ist, muss es nicht immer wieder aufs
Neue gebaut werden. Im Allgemeinen reicht
dann etwas Tuning und schon lassen sich Performance-nderungen durch Hardwareupgrades oder durch neue Software bercksichtigen.
Die dreistufige E-Commerce-Applikation, die
dieser Beitrag beispielhaft nachgebildet hat, liefert einen recht guten Ausgangspunkt, auf dem
sich aufbauen lsst, um multiple Server und zustzliche Aufgaben zu bercksichtigen.
Eines der erstaunlichsten Ergebnisse des PDQModells ist die Tatsache, dass es den analysierenden Admin bestimmte Effekte etwa versteckte
Latenzen erkennen lsst, die in den berwachten Daten fr ihn sonst nicht ersichtlich waren.
Aber das vielleicht allerwichtigste Resultat des
PDQ-Einsatzes sind gar nicht die Leistungsmodelle an sich, sondern es ist die Tatsache, dass
der PDQ-Modellierungsprozess einen organisatorischen Rahmen fr die Beurteilung aller
Leistungsdaten liefert, in dem Erkenntnisse aus
dem Monitoring bis hin zur Trendvorhersage
zusammenflieen knnen. (jcb)
nnn
Infos
[1] Kenneth Hess, Monitoring Linux performance
with Orca: [http://www.linux-magazine.com/
issue/65/Linux_Performance_Monitoring_With_
Orca.pdf]
[2] R, Open Source statistical analysis package:
[http://www.r-project.org]
[3] SimPy, Open Source simulator written in Python:
[http://sourceforge.net/projects/simpy/]
[4] N. J. Gunther, Guerrilla Capacity Planning,
Springer-Verlag, 2007
[5] N. J. Gunther: Analyzing Computer System Performance with Perl::PDQ, Springer-Verlag, 2005
[6] PDQ Download: [http://www.perfdynamics.
com/Tools/PDQcode.html]
[7] Linux-Stresstesttools: [http://www.
opensourcetesting.org/performance.php]
SNMP
Esperanto der Devices
Ein einfaches Protokoll ermglicht es, von den
verschiedensten Gerten an unterschiedlichen
Orten effizient Status- und Performancedaten
zu sammeln. Auch in eigene Software lsst sich
SNMP leicht einbinden. Robert Leibl, Dirk von Suchodoletz
Grundlagen
Was haben ein WLAN-Router, ein Switch, ein

RAID-System, eine Linux-Workstation, ein
Netzwerkdrucker oder ein vernetztes Embedded Device gemeinsam? Sie sprechen SNMP.
Von diesen Gerten kommen selbst in kleineren
Firmen schnell eine Menge zusammen. Sie befinden sich zudem nicht an einem Ort, sondern
verteilen sich ber Bros, Gebude, Zweigstellen, Stdte, zuweilen sogar Lnder und Kontinente. Sie dabei stets im Blick zu behalten und
unter einem einheitlichen Regime zu verwalten,
ist also nicht trivial.
Das Esperanto der Netzwerkwelt konnte sich
hier aus hnlichen Grnden etablieren, die auch
der internationalen Plansprache zum Erfolg verhalfen: Es ist leicht erlern- respektive implementierbar und neutral und schafft so fr die unterschiedlichsten Gerte an verschiedenen Orten
eine gemeinsame Verstndigungsgrundlage.
Mit dieser Zielsetzung wurden die ersten RFCs
1065-1067 bereits im August 1988 bei der Network Working Group eingereicht: A Simple
Network Management Protocol ist den Netzwerkern, was den Esperantisten das Unua libro, das erste Buch ber die Sprache.
Inzwischen sind eine Reihe von Versionen entwickelt worden. SNMPv2p/u/c verbesserten
vor allem die Sicherheit und Vertraulichkeit der
Kommunikation. Mit der aktuellen Version 3
wurden die Sicherheitsmechanismen noch wei-
ter ausgebaut. Allerdings stieg damit auch die

Komplexitt, und so sind heute bereits neun
RFCs zur Beschreibung ntig (3410-3418).
Manager und Agenten

Die Architektur von SNMP kennt zwei Parteien:
Agenten und Management-Hosts. Agenten arbeiten auf den zu berwachenden Gerten und
sammeln dort Daten. Wie das im Einzelnen abluft, ist vom Gert und der Implementierung
des Agenten abhngig. Nach auen ffnet ein
Agent nur einen Port, blicherweise UDP 161,
ber den er mit der Gegenseite, also einer Management-Station, kommuniziert.
SNMP definiert dabei die Austauschformate
zwischen Management-Host und Agenten sowie
die Form der Namen und Adressen. Darber
hinaus wird bestimmt, welche Daten der Agent
bereitstellen muss, wie diese benannt sind und
welche Syntax zum Ausdruck bestimmter Werte
und Zustnde zum Einsatz kommt. SNMP verfolgt bei all dem einen minimalistischen Ansatz:
Das Set der zugelassenen Operationen ist sehr
beschrnkt, ein paar Befehle sorgen fr die gesamte Funktionalitt.
Nur auf Nachfrage

Um das Netz nicht mit eventuell uninteressanten Daten zu berfluten, arbeitet SNMP passiv.
Das heit: Die Agenten schicken blicherweise
OIDs und MIBs

Welche Daten der Agent reporten kann, welche Bedeutung
sie haben, welche Werte sie annehmen knnen und welche
Operationen auf ihnen erlaubt sind, schreibt SNMP in einer
so genannten Management Information Base, kurz MIB, fest.
So hat ein Paketzhler fr einen Routerport einen Integerwert, der nur lesbar, aber nicht nderbar ist. Eine Variable,
die den Zustand desselben Ports beschreibt, wird dagegen
einen Zustandswert enthalten und les- wie schreibbar sein.
Die Variablen der MIBs sind in einer baumartigen Struktur abgelegt, dem Object Identifier Namespace, der von ISO und
ITU verwaltet wird. Der Aufbau hnelt ein wenig dem Domain Name System. Der Namensraum ist global, alle eingetragenen Zweige sind eindeutig. Subnamensrume lassen
sich jedoch delegieren, so dass der Anwender nicht jeden
neuen Eintrag bei den genannten Organisationen beantragen muss.
Die Wurzel des Baumes ist unbenannt, danach folgen
Zweige fr die verwaltenden Organisationen (ISO, ITU und
ISO plus ITU gemeinsam). Das Trennzeichen zwischen den
Hierarchieebenen ist der Punkt. Ein Pfad entlang der ste
des Baumes wird so durch eine Folge aus Ziffern und Punkten reprsentiert, dem so genannten Object Identifier (OID)
etwa 1.3.6.1.1.2.3. Jedes Gert lsst sich ber einen solchen
Identifier ansprechen, wobei zur Vereinfachung des Zugriffes
auch Namen erlaubt sind. Diese dienen jedoch wie beim
DNS eher der Bequemlichkeit des menschlichen Benutzers.
Der SNMP-Datenraum ist grozgig und universell erweiterbar angelegt. Weite Teile sind fr zuknftige Ergnzungen
reserviert und fr die mgliche Vereinigung mit anderen
baumartigen Datenstrukturen freigehalten, wie sie beispielsweise LDAP definiert.
Die obersten Ebenen des Datenbaumes sind fr die Definition der Berechtigungen einzelner Gruppen reserviert. Der
spannendere Abschnitt des SMI-Trees startet mit OID 1.3.6.1,
die den Namen iso.org.dod.internet trgt. Hier finden sich
die System-, Interface-, TCP/IP-, hostspezifische und weitere
herstellereigene Zweige.
Ansehen kann man sich die MIBs notfalls mit einem Texteditor, wirklich komfortabel wird es jedoch erst mit grafischen
Tools.
Grundlagen
Das Net-SNMP-Paket enthlt eine C-Bibliothek

mit den wesentlichen Funktionen, den Agenten
und Programme zur Datenbeschaffung. Der
Agent ist unter Linux als Daemon implementiert und wird durch das Programm snmpd
reprsentiert. Er kmmert sich um die Datenerhebung im laufenden System und kann dafr Kernel-Schnittstellen abfragen oder externe
Programme verwenden. Die vier SNMP-Standardkommandos set, get, get-next und
trap bilden verschiedene mitgelieferte Kommandozeilenprogramme ab. Die Kommandos
von Net-SNMP gehorchen folgender Syntax:
Programmname [Optionen...] <hostname>
{<community>} [<OID> ...].
Alles im Angebot
Abbildung 1: Die Kommandos snmpnetstat und snmpdf liefern dieselben Werte wie ihre lokalen Namensvettern, jedoch von einem entfernten
Host via SNMP.
nichts von sich aus, sondern warten darauf, dass

die Management-Station bei ihnen vorbeischaut.
Nach der zyklischen Kontaktaufnahme knnen
sie ihre Daten entweder ad hoc beschaffen, oder
sie erheben sie fortwhrend und puffern sie bis
zur Abfrage.
Die so gesammelten Informationen lassen sich
spter grafisch aufbereiten oder weiterverarbeiten. Fr besondere Situationen sind Agenten
auch in der Lage, bestimmte Ereignisse von sich
aus mittels so genannter Traps an die Management-Station zu melden, die hierfr den Port
162 UDP offen hlt.
Linux-SNMP
Das Net-SNMP-Paket bildet derzeit den Standard im Linux-Umfeld. Es ist aus einem Projekt
der University of California in Davis hervorgegangen. Das Paket steht unter der GPL und ist
ber die Projekthomepage auf Sourceforge [1]
beziehbar. Dieser Mhe muss sich ein Benutzer
der Standarddistributionen nur selten unterziehen, da das Paket blicherweise schon mitgeliefert wird. Net-SNMP implementiert die
Funktionalitt von SNMPv3 und ist modular
mittels AgentX erweiterbar. Zur Darstellung der
von SNMP-Agenten gelieferten Werte existieren
eine ganze Reihe von Tools, etwa MRTG [2].
Die wohl bekannteste Monitoring-Suite Nagios
bringt auch eine SNMP-Komponente mit (mehr
dazu in weiteren Artikeln dieses Hefts).
Der Agent snmpd, der auf der zu beobachtenden Maschine luft, wird mittels /etc/
snmp/snmpd.conf konfiguriert und in der Regel durch ein Runlevel-Skript gestartet. Je nach
Distribution kann die installierte Konfigurationsdatei eher sparsam ausfallen, jedoch gibt es
blicherweise im Dokubereich ein ausfhrliches
Beispiel.
SMI und ASN.1

Fr SNMP gibt es ein Regelwerk zum Festlegen
und Identifizieren der MIB-Variablen. Dieses
grundlegende Format heit SMI (Structure of
Management Information). Um das Protokoll
einfach zu halten, legt SMI einige Restriktionen
fr die in den MIBs erlaubten Variablen fest,
bestimmt deren Benennung und die Definition von Variablentypen. Die in SNMP integrierten Mittel der Datendarstellung decken alles
Ntige ab. Es stehen einfache Zahlenwerte,
Strings, Zhler oder Pegelanzeiger (Gauge) zur
Verfgung. Diese Datentypen kann man wiederum zu Tabellen oder Folgen kombinieren.
Zur Benennung der MIB-Variablen und deren
Referenzierung verwendet SMI den ASN.1-Standard (Abstract Syntax Notation der ISO). Hierbei handelt es sich um eine formale Sprache
mit zwei Ausprgungen: einem kompakten
maschinenlesbaren Teil fr die Verwendung
im Kommunikationsprotokoll und einer fr Menschen lesbaren Form der Daten zur Beschreibung in Dokumenten. ASN.1 fordert dabei eine
hohe Przision (zum Beispiel die Angabe des
Wertebereichs einer Variablen), um eine gute
Interoperabilitt zu gewhrleisten.
Grundlagen
Im Kopf der Konfigurationsdatei finden sich

die Abschnitte zur Zugriffssteuerung, wobei zu
berlegen ist, welche Maschinen welche Daten
abrufen drfen. In den meisten Fllen gengt
eine Beschrnkung auf das lokale Subnetz. Der
Agent kann mehrere unterschiedliche AccessRegeln definieren.
Eine solche Regel legt alle Bereiche der MIB fest,
auf die ein bestimmter Nutzer zugreifen darf.
Auerdem bestimmt sie, ob lesende oder auch
schreibende Zugriffe erlaubt sein sollen. Die Gesamtheit der Verwaltungsrechte wird in einem
so genannten Community Profile zusammengefasst.
Anhand des vom Client mitgelieferten Community-Passworts bestimmt der Agent, ob MIBObjekte fr die aktuelle Anfrage sichtbar sind
und ob sie der Anwender modifizieren darf.
Wird das eigene LAN als unsicher eingeschtzt,
lsst sich eine Authentifizierung nach SNMPv3
einstellen. Die Steuerung erfolgt mit den Kommandos snmpusm fr die Benutzer- und
snmpvacm fr die Zugriffsrechteverwaltung.
Jedoch sind Probleme mit Clients zu erwarten,
die kein SNMPv3 beherrschen.
In der Standardkonfiguaration der meisten Distributionen ist der Net-SNMP-Agent nach dem
Start schon sehr gesprchig wenn auch aus
Sicherheitsgrnden nur auf dem LoopbackInterface. Mittels snmpwalk -v2c -c public
127.0.0.1|less verschafft man sich einen ausfhrlichen berblick ber die Maschine. Zum
Standard gehren auch die Netzwerkinformationen zu den konfigurierten Interfaces, etwa Daten zu ARP, ICMP, TCP mit entsprechenenden
Paketstatistiken.
Das Kommando snmpwalk zeigt darber hinaus Informationen zur Speicherausstattung des
Rechners, laufende Prozesse und eine Liste aller
installierten RPMs samt Installationsdatum an.
Damit der Admin sich zentrale Informationen
nicht erst mhsam aus Einzeldaten herausziehen muss, erleichtern snmpdf fr die Anzeige
des freien Speicherplatzes und snmpnetstat
(Abbildung 1) die Arbeit. Sie entsprechen ihren
lokalen Kommandopendants, mssen nun aber
nicht mittels Remote-Shell aufgerufen werden.
Die eben genannten Daten beschafft der
snmpd von ganz alleine. Manchmal jedoch
muss er sich auch helfen lassen. So ermglicht
ihm beispielsweise die Erweiterung AgentX,
auch die populre Software-Telefonanlage Asterisk unter Beobachtung zu stellen.
Abbildung 2: Eine einfache Konfigurationsdatei des SNMP-Daemon mit

AgentX-Support.
Mit der zunehmenden Verbreitung von Voiceover-IP und der Ablsung klassischer Telefonanlagen spielen Asterisk-Server in Unternehmen
und Organisationen eine immer grere Rolle.
Asterisk durch die Hintertr

Die Funktionsbereitschaft solcher Systeme ist
dabei von strategischer Bedeutung. Nun bietet
Asterisk zwar selbst schon ber Konsole und
Logfiles etliche Mglichkeiten der Beobachtung.
Fr den Admin kann es jedoch deutlich komfortabler sein, die Software-Telefonanlage in sein
schon existierendes Beobachtungs-Framework
aufzunehmen. Asterisk bietet dazu zwei Varianten an: Entweder luft der Asterisk-Daemon
als eigener Agent und ffnet hierzu Port 161,
oder er bergibt seine Daten einem schon laufenden snmpd. Die letztgenannte Mglichkeit
erscheint den Autoren deutlich eleganter, da sie
nicht mit dem SNMP-Daemon um den UDPPort konkurriert und die Fhigkeiten von NetSNMP demonstriert.
Fr diese Verbindung beider Dienste ist ein
Asterisk der Version 1.4 erforderlich, der mit
Grundlagen
SNMP-Untersttzung bersetzt wurde. Diese

schaltet man beim Selbstkompilieren mit
configure --prefix=/usr --sysconfdir=/etc
--with-netsnmp=/usr ein. Mit make menuselection sollte man sich berzeugen, dass in
8. Resource Modules der Punkt [*] 15. res_
snmp aktiviert ist.
Anschlieend mssen beide Dienste konfiguriert werden. Die Anpassungen fr Asterisk hneln denen aus Abbildung 2.
/etc/asterisk/res_snmp.conf ;U
Konfigurationsdatei fr res_snmp
[general]
subagent = yes
enabled = yes
Nach Abschluss der Konfiguration startet der

Admin seine Dienste neu. Nun verlngert sich
Listing 1: snmpexample.c
001
#include <net-snmp/net-snmp-config.h>
002
#include <net-snmp/net-snmp-includes.h>
003
#include <string.h>
session.community_len = strlen(session.
community);
004
037
005
/*
038
006 * siehe auch: http://www.net-snmp.org/tutorial/
039
tutorial-5/toolkit/index.html
/*
* Anschlieend die Sitzung ffnen.
040
*/
007 */
041
SOCK_STARTUP;
008
042
ss = snmp_open(&session);
009
int main(int argc, char ** argv)
043
010
{
044
if (!ss) {
011
struct snmp_session session, *ss;
045
snmp_perror("ack");
012
struct snmp_pdu *pdu;
046
snmp_log(LOG_ERR, "Verbindung
013
struct snmp_pdu *response;
014
konnte nicht aufgebaut werden!\n");

047
015
oid anOID[MAX_OID_LEN];
048
016
size_t anOID_len = MAX_OID_LEN;
049
017
050
018
struct variable_list *vars;
019
int status;
020
int count=1;
021
022
023
/* Initialisierung der SNMP Bibliothek

init_snmp("snmpapp");
025
/* Initialisierung der Session */
026
snmp_sess_init( &session );
027
029
/*
* Nach Initialisierung setzt man die
Paramter der Session.

030
/*
* Fr die Datenabfrage ist zunchst ein
Datenpaket mit dem gewnschten

052
* Nachrichtentyp zu erstellen. Danach
053
* Funktion auf ein Standardformat
gebracht und in das Paket
024
028
051
exit(2);
}
wird die OID mit einer
*/
* Dazu gehren Hostname, Version, sowie
Community String, der als
Authentifizierung */
036
054
* geschrieben.
055
* Wir wollen die Beschreibung des
Systems:
056
057
*/
system.sysDescr.0
058
059
pdu = snmp_pdu_create(SNMP_MSG_GET);
060
read_objid(".1.3.6.1.2.1.1.1.0", anOID,
&anOID_len);
061
031
* Passwort benutzt wird.
062
032
*/
063
* andere Mglicheiten sind:
064
033
session.peername = strdup("localhost");
034
session.version = SNMP_VERSION_1;
035
session.community = "public"; /*
/*
get_node("sysDescr.0", anOID,
&anOID_len);
065
read_objid("system.sysDescr.0",
Grundlagen
die Ausgabe von snmpwalk um etliche Zeilen, die mit einem wenig sprechenden Prefix
SNMPv2-SMI::enterprises.22736 anfangen.
Damit sieht der Anfrager zwar schon die Ergebnisse des AgentX mit eingebundenem Asterisk,
denn enterprises.22736 ist einfach der OID
fr die Asterisk-Firma Digium. Diese wiederum
liefert netterweise ihre MIB schon mit. Sie liegt
in den Asterisk-Sourcen unterhalb von doc
und muss zu den anderen MIBs kopiert werden:
cp /tmp/asterisk-1.4.0/doc/asterisk-mib.U
txt/usr/share/snmp/mibs
cp /tmp/asterisk-1.4.0/doc/digium-mib.U
txt/usr/share/snmp/mibs
Sobald damit die MIBs wie beschrieben an den

richtigen Platz gelangt sind, funktioniert auch
ihre bersetzung. Die kann man sich jetzt beispielsweise mit dem Kommando snmptranslate ansehen.
E
Listing 1: snmpexample.c Fortsetzung

anOID, &anOID_len);
066
092
*/
067
068
093
snmp_add_null_var(pdu, anOID, anOID_
len);
/*
071
* Die Anfrage ist jetzt vollstndig und
kann gesendet werden.

072
073
*/
&response);
078
else
097
099
*/
104
/*
for(vars = response->variables;
print_
/*
* eigene Ausgabe von String
Daten
088
109
110
112
/*
113
* Aufraeumen:
114
* 1) Freigeben der Datenstruktur
'response'
*/
115
for(vars = response->variables;
vars; vars = vars->next_variable) {

089
snmp_sess_
111
variable(vars->name, vars->name_length, vars);
087
else
perror("snmpget", ss);
084
086
snmp_
errstring(response->errstat));
108
vars; vars = vars->next_variable)
085
fprintf(stderr,
"Fehler!\nGrund: %s\n",
107
*/
082
083
if (status == STAT_SUCCESS)
105
106
* Erfolg. Anzeigen der
Variablen
081
/*
* Fehler. Anzeigen des Fehlers
*/
if (status == STAT_SUCCESS &&
080
}
} else {
102
103
079
printf("Wert Nr.
101
* Verarbeiten der Antwort vom Server
response->errstat == SNMP_ERR_NOERROR) {
if (vars->type == ASN_
OCTET_STR) {
116
117
char *sp = (char
*)malloc(1 + vars->val_len);
memcpy(sp,
vars->val.string, vars->val_len);
* 2) Schlieen der Session.

*/
if (response)
118
119
090
091
096
100
/*
077
098
status = snmp_synch_response(ss, pdu,
076
free(sp);
095
%d ist kein String!\n", count++);
074
075
printf("Wert Nr.
%d ist ein String: %s\n", count++, sp);

094
069
070
sp[vars->val_
len] = '\0';
snmp_free_pdu(response);
snmp_close(ss);
120
121
SOCK_CLEANUP;
122
return (0);
123
} /* main() */
Grundlagen
erfolgt in der Datei snmpd.conf. Die notwendige Zeile sieht so aus: exec <Pfad> <IDString>
<Befehl> <Parameter>, also zum Beispiel:
exec 1.3.6.1.2.3.4.5 FancyScript U
/path/to/fancyscript.sh /file/as/input
Abbildung 3: bersichtlich, funktionell, einfach zu bedienen: MBrowse [7]

nutzt GTK und Net-SNMP.
Nun lsst sich der Blick auf den SNMP-Baum

zudem gezielt auf die Asterisk-Komponente einschrnken: snmpwalk -v2c -c public 127.0.0.1
asterisk. Einzelne Variablen wie die Uptime des
Dienstes holt:
snmpget -v2c -c public 127.0.0.1U
ASTERISK-MIB::astConfigUpTime.0
ASTERISK-MIB::astConfigUpTime.0 =U
Timeticks: (261119) 0:43:31.19
snmpgetnext -v2c -c public 127.0.0.1 U
ASTERISK-MIB::astConfigUpTime.0
ASTERISK-MIB::astConfigReloadTime.0 =U
Timeticks: (262544) 0:43:45.44
Das zweite Kommando liefert den nchsten

Wert in der Liste.
Kommando-Referenz
Programme wie snmpnetstat, snmpstatus
oder snmpdf vereinfachen wichtige Standardanfragen, beispielsweise nach offenen TCP-Ver-
Makefile fr snmpexample.c
01
CC = gcc
02
03
OBJS = snmpexample.o
04
LIBS = `net-snmp-config --libs`
05
TARGET = snmpexample
06
MIBs erweitern
Standard-MIBs beschreiben eine Vielzahl von
Informationen, doch reicht das oft nicht aus.
Deshalb lassen sich SNMP-Agenten um eigene
MIBs erweitern. Net-SNMP bietet zwei Varianten: QuicknDirty oder langsam aber sauber.
Im ersten Fall kann man Net-SNMP dazu bringen, einen bestimmten Befehl auszufhren, sobald ein bestimmter Pfad (OID) abgefragt wird.
Der Befehl darf eine Zeile Ausgabe erzeugen, die
dann zurckgeliefert wird. Die Konfiguration
Mit dieser Methode lassen sich leicht kleinere

Aufgaben realisieren, etwa ein Report ber
die Zugriffe auf den Webserver in der letzten
Stunde. Der Mechanismus der Werterckgabe
ist allerdings streng festgelegt und oft zu unflexibel fr den Austausch komplexer Daten. Zudem
muss man bei jeder Anfrage das Skript neu ausfhren. Set-Befehle untersttzt diese Methode
nicht.
Das zweite Verfahren, um eigene Daten in den
SNMP-Baum einzufgen, ist sauberer, aber auch
aufwndiger. Dafr erstellt man zuerst eine eigene MIB, die definiert, wie und an welcher
Stelle die Daten abzulegen sind. Anschlieend
wird mit dem Programm mib2c, das aus der
MIB Datei C-Code generiert, ein Gerst fr
das sptere Modul erstellt. Dieser C-Code implementiert nun die Logik, die die definierten
Werte ausfllt. Das fertige Modul benutzt dann
der SNMP-Agent. Dafr ist folgender Eintrag in
der Datei snmpd.conf ntig: dlmod NAME
PFAD>
07
CFLAGS = -I. `net-snmp-config
--cflags`
08
09
all: $(TARGET)
10
11
snmpexample: $(OBJS)
12
$(CC) -o snmpexample $(OBJS)
$(LIBS)
13
clean:
14
rm -f $(OBJS) $(TARGET)
Grundlagen
bindungen und UDP-Ports, dem Gertetyp und

seinen Interfaces oder dem freien Speicherplatz.
Hier braucht man im Gegensatz zu snmpget,
snmpgetnext und snmptable keine OIDs
angeben.
Da es recht aufwndig ist, sich mittels snmpget oder snmpgetnext einen umfassenden
berblick ber die verfgbaren Daten eines
Endgertes oder Netzwerkknotens zu verschaffen, bringt snmpwalk Erleichterung. Dieses
Programm erlaubt es, den gesamten Datenbaum
eines Agenten sukzessive abzufragen oder Unterbume vollstndig abzulaufen. Letzteres geschieht ber die Angabe eines Teils des OID. Je
lnger der Object Identifier wird, desto genauer
wird der abzufragende Teil des Baumes eingegrenzt, und je krzer wird die Ausgabe.
Der wesentliche Vorteil dieser Werkzeuge ist
die komfortable Darstellung der MIBs. Der aufgespannte Baum wird in einer Ordnerstruktur
dargestellt, in der man durch ffnen eines Knotens elegant in die Tiefen das Baumes absteigen
kann. Dadurch entfllt das umstndliche Entlanghangeln an einzelnen Knoten, wie es bei den
Konsolentools ntig wre die Pfade geraten
dabei schnell sehr lang und unbersichtlich.
Die meisten der verfgbaren MIB-Browser dienen gleichzeitig als Wrapper fr die SNMP-Befehle get, set, walk und so weiter. Man
kann sich also zuerst zu den gesuchten Blttern
durchklicken und anschlieend die Werte dort
mit get oder walk lesen beziehungsweise
mit set neu setzen.
C der Standardweg
Abbildung 4: JMibBrowser [8] ist ein in Java programmierter, einfach gehaltener MIB-Browser.
Es hngt von weiteren Perl-Modulen ab. Daher

sollte man es nach Mglichkeit ber die jeweilige Distribution oder eine CPAN-Shell installieren. Um ber ganze Tabellen zu laufen, steht
unter anderem die Methode get_table() zur
Verfgung. Diese nimmt diesmal die Wurzel eines Teilbaums als Parameter. Als Ergebnis erhlt
man eine Hash-Referenz, in der die OIDs mit
den zugehrigen Werten abgelegt sind. In diesem Fall wird die Tabelle ifTable angefordert:
my $baseOID = '1.3.6.1.2.1.2.2';
my $result = $session->get_table(
-baseoid => $baseOID
);
Fr denjenigen, der SNMP in eigene Programme

integrieren mchte, stehen eine Reihe von Modulen und Bibliotheken zur Verfgung.
Fr die Programmiersprache C bietet das NetSNMP Projekt eine eigene API [4] an. Beim
bersetzen sollte man darauf achten, die gleichen Compilerflags und Bibliotheken zu benutzen, die auch Net-SNMP selbst verwendet.
Dafr steht das Skript net-snmp-config zur
Verfgung, das diese Werte ausgibt. Das Beispielskript snmpexample.c (Listing 1) verwendet sein Makefile, um dynamisch Optionen
zu setzen.
Perl und SNMP

Wie in der Perl-Welt blich, existiert im CPAN
[6] ein Modul, welches die SNMP-Funktionen
implementiert. Das Modul heit Net::SNMP [5].
Abbildung 5: Der Java-basierte BlackOwl MIB-Browser [9] bringt einen groen Funktionsumfang und einen eigenen Installer mit.
Grundlagen
ber die Hash-Referenz ist nun der Zugriff auf

die einzelnen Werte mglich:
Die Autoren
Dirk von Suchodoletz
arbeitet derzeit als
Assistent am Lehrstuhl
fr Kommunikationssysteme am Institut fr Informatik der Universitt
Freiburg.
Robert Leibl ist Student
am Institut fr Informatik
an der Universitt Freiburg. Er schreibt dort
derzeit an seiner Diplomarbeit zum Thema USB
over Ethernet.
my %ifTable = %$result;
foreach my $key U
(oid_lex_sort(keys %ifTable)) {
printf( "%s --> %s\n", $key, U
$ifTable{$key});
}
Die Funktion oid_lex_sort() sortiert die

Schlssel des Hash. Um diese Funktion direkt benutzen zu knnen, lsst sie sich mit der
use-Anweisung in den eigenen Namensraum
importieren, zum Beispiel: use Net::SNMP qw/
oid_lex_sort/;.
Alternativ lsst sich eine ganze Reihe von Helfer-Funktionen mit dem :snmp-Tag importieren: use Net::SNMP qw/:snmp/;. Andernfalls kann man die Funktion natrlich auch
ber Net::SNMP::oid_lex_sort() aufrufen.
nnn
(jcb)
Infos
[1] Homepage des NetSNMP-Projekts:
[http://netsnmp.sourceforge.net]
[2] MRTG-Homepage: [http://www.mrtg.org]
[3] IETF-RFCs zu SNMP: unter anderem 1065,
1155, 1157, 1212, 1213, 1215 (Version 1),
1441-46, 1450, 1901 bis 1910 (Version 2)
und 2570 bis 2576 (Version 3), 3410, 3417,
4789
[4] Agent erweitern: [http://www.net-snmp.org/
dev/agent/]
[5] SNMP-Modul im CPAN: [http://search.
cpan.org/~dtown/Net-SNMP-5.2.0/lib/Net/
SNMP.pm]
[6] Repository von Perl-Modulen: [http://cpan.org]
[7] GTK basierter MIB-Browser:
[http://www.kill-9.org/mbrowse/]
[8] Einfacher MIB-Browser: [http://www.dwipal.
com/mibbrowser.htm]
[9] Komfortables Java-Tool: [http://blackowl.
asclep.com]
Listing 2: snmpget.pl
01
#!/usr/bin/perl -w
03
# siehe auch: http://search.cpan.org/~dtown/
Net-SNMP-5.2.0/lib/Net/SNMP.pm
26
# umstndlich aus, wird bei der Abfrage mehrere
Werte jedoch komfortabel, da
27
# eine Array-Referenz auf einen eigenen Array
04
05
use strict;
06
use warnings;
07
08
use Net::SNMP;
09
10
# Verbindung mit dem Server herstellen und die
Session ffnen.
11
# Die Parameterbergabe erfolgt im bekannten
'Dash'-Stil als Hash-Referenz.
12
my ($session, $error) = Net::SNMP->session(
13
-hostname => 'localhost',
14
-community => 'public'
15
);
bergeben werden kann.

28
my $result = $session->get_request(
29
-varbindlist => [$node]
30
);
31
32
if (!defined($result)) {
33
printf "Fehler: %s\n", $session->error;
34
$session->close;
35
exit 1;
36
}
37
38
# Behandlung der empfangenen Werte. Die Werte
sind in einem Hash mit der OID
39
# als Schlssel abgelegt.
16
17
if (!defined($session)) {
25
# Anforderung der Werte. Die bergabe der
gewnschen OIDs sieht zunchst
02
18
printf "Fehler: %s\n", $error;
19
exit 1;
40
printf( "System uptime fuer '%s' ist %s\n",
41 $session->hostname,
42 $result->{$node}
43
);
20
}
44
21
45
$session->close;
22
# Wir wollen den Wert von sysUptime
46
23
my $node = '1.3.6.1.2.1.1.3.0';
47
exit 0;
24
48
__END__

LinuxTechnicalReview02 Monitoring

Hochgeladen von

Dokumentinformationen

Beschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

LinuxTechnicalReview02 Monitoring

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Feature

Windows Event Log

ja (syslog) nativ unter Unix, optional

Tabelle 1: Featurevergleich Fortsetzung

optional (ber SNMP)

Die bestndig wachsende Zahl von Servern und

ITIL und Monitoring

ment (Statusberwachung der IT-Infrastruktur; Sammeln, Verwalten und Bereitstellen von

insbesondere die Trendanalysen, um Engpssen

ser Ausgabe beschftigen, eine sehr ausgereifte

einbarten Zeitraums gewhrleisten. Nach den

Die Zielsetzung des Problem-Managements besteht in der Lokalisierung, Dokumentation und

und Risk Consulting in

Eher vom Band

als durch Bastelei

Warehousing & Reporting

Zu eben diesen Anforderungen, die mit zunehmender Unternehmensgre immer mehr an

tere Aspekte kommen oft hinzu, zum Beispiel

An dieser Stelle kommt unweigerlich auch das

steller kommerzieller Lsungen wie IBM Tivoli,

JMX und ABAP-Programme. Dieser Entwicklungsaufwand ist kaum im nichtkommerziellen

hat sich beispielsweise seit langem IBM Tivoli

Reaktion auf Strungen

verlinken und in der Konsole einblenden. Diese

Anreicherung von Events

Das darf man

Jger und Sammler, so hat sich der Mensch seit

Glserne Mitarbeiter sind kein

werden oder sich eingespielt haben. Betriebliche

Eine Frage der Mitbestimmung

als solche technische Einrichtung gelten. Es

Grundstze der Internationalen Arbeitsorganisation (ILO) zur berwachung

nDie Beurteilung der Leistungen der Arbeitnehmer beruht

nicht allein auf den berwachungsergebnissen.

kann ebenso nichtig sein, wie eine ausdrckliche

Kommunikation ist alles

Betriebsinteresse steht zurck

Eher unbekannt, doch leistungsstark:

Bis vor einigen Monaten war Zabbix [1] nur

weiter. In anderen ist er auch selbststndig ttig

Abbildung 1: Ein bersichtliches Webfrontend bildet die Zabbix-Zentrale, zustndig fr Konfiguration

man sie beispielsweise fr die Kapazittsplanung

Monitoring-Lsung installiert. Dafr legt der

| mysql -u root -p zabbix

$ cat images.sql | mysql -u root -p

Dann kann es losgehen. Weil sich Zabbix im

conf) gelangen leider nicht automatisch nach

Anschlieend starten die Befehle

Abbildung 6: Bildschirmdarstellungen so genannte Screens lassen sich

den Zabbix-Server und seinen Agenten. Das

Konfiguration des Frontends

Tabelle 1: Bentigte Softwarekomponenten

Danach ist ihm die verwendete Datenbank ber

Danach ist das Frontend bereits startklar,

Einschleusen eines Agenten

Abbildung 7: Eine Statusbersicht vermittelt einen raschen berblick.

Die Konfiguration des Zabbix-Agenten vollzieht

Daneben lassen sich die Beobachtungswerte

Ausblick: die Betaversion

Abbildung 10: Beliebige Host-Daten lassen sich

Angaben regelmig mit mehr als 5000 Devices

ja (syslog) nativ unter Unix, optional

nDie Beurteilung der Leistungen der Arbeitnehmer beruht

17 Allow from all

18 Header set Cache-Control no-cache

08 ScriptAlias /cgi-bin/ /home/osmart/cgi-bin/

24 Allow from all

10 Options +ExecCGI +FollowSymlinks

25 Header set Cache-Control no-cache

12 Allow from all

Listing 2: Datenbank-Konfiguration fr MySQL

041

003

015

017

064 <!-- Anwendung des SIMPLE-Adapters fuer

080

123

088

097

136

138

103

143

150 <!-- LOGS Konfiguration wird separat in

04

35 <!-- hier erfolgt die Definition fuer das

20 echo "/proc/cpqfan Status-File ist nicht

21 echo "Sind alle Module geladen?"