Monitoring

1 Einleitung / 1.1 Was ist Monitoring ?

Unter Monitoring versteht man das sammeln, interpretieren und präsentieren von Informationen über die unter Beobachtung stehenden Hard- und Software Komponenten. Es wird zum debuggen von fehlerhaften Elementen, testen von nicht optimal arbeitenden Komponenten, visualisieren von Strukturen und zur Animation von dynamischen Prozessen verwendet. Die dabei aufgearbeiteten Informationen kann der Systemverwalter verwenden um Entscheidungen zu treffen und steuernd in das verwaltete System einzugreifen. Monitoring ist daher ein passiver Prozeß der einzig zur Beobachtung dient und keinen Einfluß auf das zu verwaltende System nehmen sollte. Weiterhin müssen diese Informationen konsistent sein - d.h. zeitliche Abhängigkeiten dürfen nicht verdreht werden. Es ergibt sich folgende Einordnung in das Management Model:



1.2 Probleme und Lösungsansätze

Um die Voraussetzung, keinen Einfluß auf das System auszuüben und ein konsistentes Bild zu liefern, zu erfüllen führt zu vielen Problemen. Wie soll man zeitliche Abhängigkeiten exakt darstellen, wenn es keine globale Zeit gibt und eine Uhrensynchronisation den Austausch von Nachrichten und damit eine Veränderung der Netzlast bedeuten würde, was der Anforderung widerspricht, keinen Einfluß auf das System auszuüben. Der Aufbau eines parallelen Netzwerkes ist keine zufriedenstellende Lösung, weil die Kosten unverhältnismäßig hoch sind und weil auch dieses Netzwerk gemanagt werden muß und das Problem damit nur verlagert würde.

Ein weiters Problem ist die Größe des zu verwaltenden Systems, was zu einer Unmenge von Informationen führt die dann zu einer zentralen Management Station geleitet werden müssen und damit das Netzwerk unnötigerweise überlastet werden würden. Da nicht alle Details zum treffen von Entscheidungen benötigt werden, ist eine mögliche Lösung, die Informationen frühzeitig und in der nähe der betrachteten Objekte zu filtern und zusammenzufassen. Dadurch entstehen neue Probleme, da es schwierig ist, vor Beginn der Beobachtung zu wissen, welche Informationen nicht benötigt werden und daher verworfen werden können.

Es ist daher offensichtlich, daß man die Probleme nicht vollständig lösen kann, da jede Messung ein dynamisches System beeinflußt und damit das Meßergebnis verfälscht. Man muß die Ansprüche an ein Monitoring System reduzieren und sich im klaren sein, daß selbst die beste Lösung zumindest geringfügige Einflüsse auf das System hat.

2 Die Konzepte

2.1 Sammeln der Monitoring Informationen

Zum sammeln der Informationen wird der Zustand der Objekte hier als Status-Vektor bezeichnet - beobachtet und ausgewählte Zustände / Zustandsänderungen in einem Statusbericht / Ereignisbericht zusammengefaßt. Statusmeldungen können periodisch oder auf Anfrage erfolgen. Die Ereignis Erkennung kann sowohl von dem zu beobachteten Objekt selbst - also direkt bei jeder Statusänderung - oder von einem externen Agent, der in regelmäßigen Abständen den Status erfragt, durchgeführt werden. Status- und Ereignisberichte werden zu einem Monitoring-Bericht zusammengefaßt. Die Monitoring Berichte werden gesammelt und in einem Trace zusammengefaßt. Ein Trace enthält alle Informationen, die bisher angefallen sind und kann daher gut zur post-mortem Analyse eingesetzt werden. Eine weitere Anwendung für Traces sind Analysen des Systems die in Echtzeit nicht durchführbar sind, da die dazu nötige Rechenleistung nicht vorhanden oder zu teuer ist.


2.2 Verarbeitung der Monitoring Informationen

Die bisher zusammengetragen Informationen sind sehr detailliert, enthalten aber vieles was nicht benötigt wird, doppelt verzeichnet ist oder in kompakte Aussagen umgewandelt werden kann. Unterschiedliche Beobachter benötigen auch unterschiedliche Informationen oder dürfen nicht alles erfahren. Es ist daher wichtig Traces zusammenzufassen und neue vereinfachte Traces zu erzeugen.

Die in einem Zeitabschnitt ankommenden Traces der beobachteten Stationen werden zu einem globalen Trace verschmolzen. Dabei können die einzelnen Traces nicht einfach aneinander gehängt werden weil sonst die zeitliche Ordnung verloren ginge.

Die eingegangen Traces und der globale Trace werden nach Fehlern untersucht und entsprechend korrigiert. Fehler können hierbei z.B. unmögliche kausale Abhängigkeiten sein, die aufgrund schlecht synchronisierter Uhren auftreten können. Alle aufgetretenen Fehler werden zu einem Bericht zusammengefaßt, der auch zur Analyse des Systems herangezogen werden kann, weil ja auch das Auftreten von Fehlern in Traces eine Ursache haben muß und es ratsam ist diese Ursache zu finden und zu beheben.

Die in dem globalen Trace aufgeführten Informationen können nun zusammengefaßt werden, um den Abstraktionsgrad zu erhöhen. In Verbindung mit Filtern wird der Beobachter damit von überflüssigen Informationen befreit und kann sich auf das Wesentliche beschränken. Die Definition zum Zusammenfassen beschreiben neue abstraktere Ereignisse oder Zustände und die Regeln nach denen sie aus weniger abstrakten Ereignissen zusammengefaßt werden können.

Das Filtern muß als getrennter Vorgang betrachtet werden, da beim Zusammenfassen zwar Details verlorengehen, diese aber durch neue Informationen ersetzt werden. Filtern vernichtet Informationen die falsch sind oder nicht benötigt werden. Nach dem Filtern erhält man einen neuen Monitoring-Bericht.

Im letzten Schritt werden diese Monitoring-Berichte entsprechender der Bedürfnisse der verschiedenen Beobachter untersucht und an jeden nur die für ihn interessanten oder zugänglichen Informationen weitergegeben.


2.3 Präsentation der Monitoring Informationen

Die bisher gesammelten und verarbeiteten Informationen müssen nun noch in für den Anwender verständlicher und überschaubarer Weise dargestellt werden. Als Problem erweisen sich die große Menge und die unterschiedlichen Abstraktionsebenen der gesammelten Informationen. Auch ist die Ankunftsrate sehr hoch und die Parallelität der Ereignisse für einen menschlichen Beobachter nur schwer zu überblicken. Es gibt viele Möglichkeiten zur Darstellung von Informationen. Die einfachste Art ist die textuelle Darstellung, allerdings sind dabei die Möglichkeiten sehr eingeschränkt. Zeitdiagramme sind eine weitere Möglichkeit, zeigen sie doch kausale Zusammenhänge am besten, allerdings sind die Strukturen des Netzes sehr schlecht darstellbar. Animationen erlauben es Zustandsänderungen direkt darzustellen (Router ausgefallen Symbol brennt)

Die beste Lösung ist es alle anderen zu vereinigen und es dem Anwender zu überlassen wie er die benötigten Informationen darstellen will (Position und Inhalte). Eine hierarchische Darstellung erlaubt es, zuerst nur einen groben Überblick zu erhalten und bei Bedarf die Details zu betrachten.



2.4 Realisierungsmöglichkeiten


2.4.1 Hardware Monitore

Hardware Monitore haben einen minimalen Einfluß auf das beobachtete System, da sie auf getrennten Ressourcen abgearbeitet werden. Mit ihnen ist es möglich direkt auf Register des beobachteten Systems zuzugreifen ohne das System zu beeinflussen. Allerdings sind die Informationen, die von Hardware Monitoren geliefert werden, sehr speziell (Low Level) und müssen noch nachbearbeitet werden. Weiterhin sind Hardware Monitore nicht (oder nur schlecht) durch den Endanwender erweiterbar, da alle Funktionalität in Hardware gegossen ist die Änderungen beinahe unmöglich macht.

Da Hardware Monitore zusätzliche Hardware benötigen sind sie unverhältnismäßig teuer und sollten nur dann verwendet werden, wenn man auf die speziellen Vorteile, also die geringe Beeinflussung des Systems, nicht verzichten kann.


2.4.2 Software Monitore

Demgegenüber benötigen Software Monitore keine zusätzliche Hardware und können entsprechend preiswert sein. Sie liefern sehr abstrakte (High Level) Informationen die \"leicht\" interpretiert werden können. Sie sind durch Skriptfähigkeit oder ein modifizierbares Regelwerk auch für Endanwender erweiterbar. Diesen Vorteilen steht aber die hohe Beeinflussung des Systems gegenüber.

Software Monitore sollten dann verwendet werden, wenn die Beeinflussung des Systems nicht allzu störend ins Gewicht fällt oder Hardware Monitore zu teuer sind.


2.4.3 Hybrid Monitore

Hybrid Monitore vereinen die Vorteile beider Realisierungen. Sie haben eine direkte Hardwareschnittstelle zu den beobachteten Elementen sind aber durch Software konfigurierbar und können daher auch High Level Informationen liefern. Wie stark Hybrid Monitore ein System beeinflussen hängt davon ab, wie die Kommunikation zwischen den Agenten abläuft.

3 Existierende Systeme

3.1 ZM4

ZM4 ist eine Hybride Realisierung. Dabei sind mehrere \"Monitor Agents\" (MA) über Ethernet (TCP/IP) an einen \"Control and Evaluation Computer\" (CEC) angeschlossen. Die MA\'s sind IBM kompatible PC die mit bis zu vier \"Dedicated Probe Units\" (DPU) ausgestattet sind. Eine DPU ist eine Erweiterungskarte die es den MA\'s erlaubt, direkt auf das beobachtete System zuzugreifen. Weiterhin sind sie über einen \"Tick Channel\" untereinander verbunden um sich exakt zu synchronisieren, so das Fehler, die auf falsch synchronisierten Uhren beruhen praktisch nicht auftreten können. Dieser \"Tick Channel\" wird von einem \"Measure Tick Generator\" (MTG) mit einer Auflösung von 100ns gespeist und ist vom Restlichen Netzwerk physikalisch getrennt um die Beeinflussung gering zu halten.
Die MA\'s halten die von ihnen erzeugten Traces auf einer lokalen Festplatte, was für die post-mortem Analyse von Vorteil ist.

Den Software-Teil des Monitorings übernimmt SIMPLE, ein Toolkit das sowohl für UNIX als auch MS-DOS zur Verfügung steht. Es entspricht weitgehend den in Kapitel 2 dargestellten Konzepten. Die Programmierung erfolgt in den Sprachen TDL (Trace description language) und FDL (Filter description language). Man ist damit unabhängig von den Vorgaben des Systems (besonders von (nicht)vorhanden Compilern / Betriebsystemen)


3.2 ISOIOSI

Im OSI Modell kommunizieren Manager und Agent über das CMIP Protokoll. Damit ist eine sichere Kommunikation gewährleistet. Es existieren eine Reihe vordefinierter Ereignisberichte, die z.B. beim Erzeugen und Löschen von MO\'s oder im Fehlerfall weitergeleitet werden.

Die von den MO\'s erzeugten Meldungen werden zu Ereignis Berichten zusammengefaßt und von den \"Event Forwarding Discriminators\" aussortiert und die jeweiligen Empfänger weitergeleitet.

EFD\'s haben einen eindeutigen Identifikator, Regeln zur Weiterleitung, können deaktiviert werden und haben einen fest zugeordneten Empfänger und Alternativen falls der primäre Empfänger nicht erreichbar ist.



3.3 SCO TTY BONES TKINED

Eine weitere Realisierung kommt von der TU Braunschweig und wurde im Rahmen eines Forschungsprojektes zum Thema Netzwerkmanagement entwickelt. Die Grundkomponenten sind SCOTTY und TKINED. Alle Komponenten sind reine Softwarelösungen


3.3.1 SCOTTY

basiert auf TCL und wird zur Realisierung sowohl von Agenten als auch von Managern verwendet (diese Form von Agenten nennt man auch Mid-Level Manager). Die Erweiterungen beschränken sich auf RPC, TCP/IP, SNMP und CMIP Zugriffsmöglichkeiten. TCP/IP Erweiterungen werden benötigt um z.B. den Zustand von Verbindungen zu überprüfen. Die SNMP und CMIP Erweiterungen werden zur Kommunikation mit SNMP/CMIP fähigen Endgeräten verwendet. Skripts können über SNMP in eine MLM-MIB (Mid-Level Manager MIB) eingeladen werden. Dort werden auch die gerade in Ausführung befindlichen Skripts und deren Parameter und Ergebnisse gespeichert.


3.3.2 BONES

stellt die Schnittstelle zu einer Datenbank (gdbm GNU) dar und kann z.B. zur Speicherung von Traces und Berichten verwendet werden. Allerdings ist BONES weit mehr als nur eine Datenbankschnittstelle, allerdings betreffen die weiteren Möglichkeiten nicht die Aspekte des Monitoring da sie aktiv in das System eingreifen (z.B. bei der Benutzerverwaltung).

Der Inhalt der Datenbank wird in regelmäßigen Abständen vom \"Updater\" an alle Klienten verteilt (so das sich z.B. ein neuer Benutzer in kürzester Zeit auf allen Rechnern, auch wenn diese nicht von derselben Architektur sind, anmelden kann). Diese Kommunikation erfolgt über das SMP Protokoll, einer kryptographischen Erweiterung von SNMP. Der \"Checker\" überprüft regelmäßig den Inhalt der Datenbank auf Inkonsistenzen (z.B. zwei Accounts mit der selben User ID)


3.3.3 TKINED

ist die Graphische Benutzungsoberfläche für SCO\'ITY und BONES basiert auf TCL/TK. TKINED verwaltet NODE Objekte die Netzwerkknoten (z.B. Rechner, Bridges, ...) und NETWORK Objekte die das Kommunikationsmedium (Ethernet, X.25, Funkstrecken) repräsentieren. Verbindungen zwischen Objekten werden durch LINK Objekte dargestellt.

Weitere Objekte sind GROUP und REFERENCE, die zum Aufbau komplexen Strukturen verwendet werden können. Zur graphischen Gestaltung stehen TEXT, IMAGE, STRIPCHART und BARCHART Objekte zur Verfügung.

Dies war nur eine sehr eingeschränkte Beschreibung der Fähigkeiten von TKINED. Eine weitergehende Beschreibung würde den Rahmen dieses Artikels sprengen.

Die Wahl fiel auf TCL/TK weil diese, oder ähnliche Kommandosprachen fast jedem Computerbenutzer mehr oder weniger vertraut sind und außerdem leicht erlernbar ist. Die weite Verbreitung von TCL/TK war ein weiterer Grund.

Der Entwickler von Agents muß die in Kaptitel 2 beschriebenen Konzepte der Trace Generierung, Verschmelzung, Filterung, .... selbst realisieren. Die Vorgehensweise kann er dabei selbst wählen und wird nicht in ein festes Raster gezwängt, so das die jeweils optimale Methode realisiert werden kann.

Die einheitliche Programmierumgebung von Manager, Mid-Level Manager und Agent ermöglicht es Funktionalität nach Bedarf zu verlagern. Es ist prinzipiell möglich über diese Verlagerung dynamisch zu entscheiden.

Die Sicherheitsaspekte dürfen nicht vernachlässigt werden ! BONES kommuniziert über SMP, sollte also sicher gegenüber Angriffen, wie z.B. der Verfälschung von Informationen, sein. Bei SCO\'ITY sind aber keine Sicherheitsvorkehrungen bei der Kommunikation zwischen Agenten vorhanden, benutzt man aber die MIB zum Austausch, so sollte es zumindest so sicher sein wie das zugrundeliegende System (also SNMP oder CMIP). Es steht dem Anwender natürlich frei eigene kryptographische Verfahren zu verwenden um die Absicherung beliebig gut zu machen.


3.4 Weitere Existierende Systeme

Die hier erwähnten kommerziellen Systeme sind keine reinen Monitoring Produkte, vielmehr ist Monitoring hierbei nur ein kleiner Bestandteil der Fähigkeiten dieser Programmpakete. Diese Liste erhebt keinen Anspruch auf Vollständigkeit !

Cabletron Spectrum, DECpacketprobe, DEC PolyCenter, HP OpenView, IBM NetView, SunNet Manager, Sun Solstice Enterprise Manager

Public Domain & Shareware und andere nicht kommerzielle Systeme erfüllen meist nur Teilaspekte des Monitorings, verdienen aber dennoch (nicht zuletzt wegen des günstigen Preises) eine kurze Erwähnung.

Argus(Carnegie Mellon University), Courtney, Gabriel (Los Altos Technologies), HNMS (NASA), lwatch, NetLog (Texas A&M University), NETMAN (Curtin University)