Das Domino Domain Monitoring ist für Domino-Administratoren kein völliges Neuland. Die Basis bilden die bisherigen Monitoring-Funktionen, die über die Monitoring Configuration-Datenbank (events4.nsf) konfiguriert werden können.
Die wesentliche Erweiterung liegt darin, dass sich nun sehr viel besser als bisher Informationen von verschiedenen Domino-Servern konsolidieren lassen. Damit verschafft sich der Administrator einen schnellen, zentralen Überblick über Probleme auf verschiedenen Servern.
Im Rahmen dieses Workshops zeigen wir Ihnen, wie Sie die Monitoring-Funktion von Domino effizient und sinnvoll einsetzen.
Probes und Monitoring
Für das Verständnis von DDM ist der Begriff der Probes von zentraler Bedeutung. Probes sind Analysen, mit denen definierte Fehlersituationen und Verhaltensweisen eines oder mehrerer Server überprüft werden. Es gibt viele vordefinierte Probes, zusätzlich aber die Möglichkeit, auch eigene Probes zu erstellen.
Dadurch, dass das DDM eng mit anderen Überwachungsfunktionen integriert ist, kann man auch keine isolierte Betrachtung nur dieser Funktionalität vornehmen. Viele der Funktionen gibt es auch für das Management einzelner Server.
Für die Nutzung von DDM und den zugrunde liegenden Überwachungsfunktionen gibt es mehrere wichtige Datenbanken und Schnittstellen:
-
Im Domino Administrator finden sich Informationen über Ereignisse, die auf einem Server protokolliert wurden, im Bereich Analysis und dort unterhalb von Events.
-
Die Konfiguration wichtiger Einstellungen zum Monitoring kann im Bereich Configuration des Domino Administrator erfolgen. Dort gibt es den Abschnitt Monitoring Configuration, in dem unter anderem DDM-Filter und DDM-Probes definiert werden können.
-
Die Schnittstelle für das Management von DDM-Ereignissen ist die DDM-Datenbank. Dort können Ereignisse, beispielsweise zur Bearbeitung, einzelnen Administratoren zugewiesen werden, so dass sich nachvollziehen lässt, welche Probleme gelöst sind und welche noch nicht.
-
Die Konfiguration kann alternativ zum Domino Administrator auch über die bereits erwähnte Monitoring Configuration-Datenbank erfolgen.
-
Einen Überblick über alle protokollierten Ereignisse liefert die Monitoring Results-Datenbank.
Der Umgang mit Ereignissen
Schon in der Standardkonfiguration von DDM werden einige Probes durchgeführt und entsprechend potenziell auch Fehlersituationen protokolliert. In der DDM-Datenbank kann man auf diese zugreifen.
Alle protokollierten Fehler und Warnungen sind mit einem Datum und einer beschreibenden Nachricht versehen. Diese Nachricht hilft häufig bereits dabei, das Problem zu lösen oder gibt zumindest gute Hinweise, um die Ursache für die generierte Meldung zu suchen.
Zunächst einmal ist es grundsätzlich empfehlenswert, mit DDM zu arbeiten, um Domino-Infrastrukturen zu überwachen, Fehler zu erkennen und diese gezielt und strukturiert abzuarbeiten. Das setzt aber auch voraus, dass man klare Regeln und Verantwortlichkeiten für diese Abarbeitung von erkannten Problemsituationen definiert, also insbesondere die Funktionen für die Zuweisung von Ereignissen zu bestimmten Administratoren nutzt.
Die Schaltflächen im Detail
Falls man mehr Server und größere Listen hat, kann man diese über die Auswahloptionen auf der linken Seite nach Bedarf strukturieren. Noch wichtiger sind aber die Schaltflächen im oberen Bereich.
Mit Assign kann man dort eine Zuordnung eines Ereignisses zu einem Benutzer vornehmen. Man kann also klar regeln, wer für die Lösung welches technischen Problems verantwortlich ist. Über die Auswahl von By Assignment auf der linken Seite kann man später schnell prüfen, wer welche Ereignisse noch nicht bearbeitet hat.
Mit Comment lassen sich ergänzende Kommentare definieren, um beispielsweise die Problemlösung direkt zu dokumentieren oder Hinweise für die Lösung bei einem Ereignis zu hinterlegen. Da man auf eine Liste aller Ereignisse zugreifen kann, wird die DDM-Datenbank so auch zu einer „Knowledge Base“ mit gespeicherten Erfahrungen zur Fehlerbehebung.
Mit Change State kann ein Eintrag schließlich als gelöst bezeichnet werden. Er ist dann nur noch bei All Events zu sehen.
DDM Probes
Die Menge der erfassten Ereignisse beim DDM hängt davon ab, welche Probes definiert und aktiviert sind. Es gibt etliche vorkonfigurierte Probes, die man nutzen kann. Die Bearbeitung erfolgt am besten in der Monitoring Configuration-Datenbank. Dort kann man sich die vorkonfigurierten Probes anschauen.
Auch hier finden sich wieder mehrere Ansichten mit einer unterschiedlichen Strukturierung der Informationen. Die Ansicht By Type ist für den Einstieg am besten geeignet, da die Probes dort nach ihrer Funktionalität geordnet sind.
Wenn man die Probes betrachtet, wird deutlich, dass die meisten Probes als deaktiviert markiert sind. Diese müssen also manuell aktiviert sein. Dazu wird die Schaltfläche Enable Probes oberhalb der Liste verwendet.
Gut erkennbar ist in dieser Liste auch, ob es schon selbst erstellte Probes gibt. Alle standardmäßig definierten Probes haben als Autor Lotus Notes Template Development. Bei eigenen Probes wird dagegen der jeweilige Benutzername als Autor angezeigt.
Gezielte Analyse statt Unmengen von Daten
Bevor man nun in Masse Probes aktiviert, sollte man einerseits überprüfen, welche Funktion diese überhaupt haben und dann überlegen, ob man sie wirklich benötigt. Immerhin verursacht jede Probe auch zusätzliche Last im System, so dass es keineswegs Sinn macht, alle Probes zu aktivieren. Details zu den Probes erhält man, wenn man das jeweilige Probe-Dokument durch einen Doppelklick öffnet. Bei jeder vordefinierten Probe finden sich umfassende Informationen zu der Funktion.
Auch wenn eine Probe vielleicht auf einem Server sinnvoll ist, heißt das noch lange nicht, dass sie generell eingesetzt werden sollte. Man muss also zudem die Liste der Server überprüfen. Und wenn man schon dabei ist, sollte man gleich analysieren, ob alle Detailfunktionen von Probes benötigt werden. Häufig lassen sich einzelne Events auch deaktivieren.
Eigene Probes erstellen
Die Details kann man natürlich bei der Erstellung eigener Probes modifizieren, neue legen Sie mit New DDM Probe an. Im ersten Schritt muss man eine der neun vordefinierten Kategorien wie Database oder Security auswählen. Für jede Kategorie gibt es wiederum Subtypes, also untergeordnete, vorkonfigurierte Typen. Das Erstellen eigener Typen ist nicht möglich, Sie sind auf die von Lotus definierten Typen und Subtypen angewiesen.
Im Register Basics kann neben der Festlegung des Subtyps eine Beschreibung eingegeben werden. Außerdem wird dort das Ziel der Probe definiert, also die Server, auf denen die Probe ausgeführt werden soll und die Server, die überprüft werden sollen. Ein Server kann also auch Analysen auf anderen Servern durchführen.
Dieser Konfigurationsschritt ist einer der wichtigsten, weil man damit die durch das Monitoring erzeugte Last maßgeblich beeinflusst. Während beispielsweise Sicherheitsanalysen auf allen Servern erfolgen sollten, sind andere Bereiche wie Directory oder Web nur für die Server relevant, auf denen die entsprechenden Tasks ausgeführt werden.
Weitere wichtige Einstellungen finden sich im Register Specifics. Dort kann man gezielt auswählen, welche Teilanalysen ausgeführt werden sollen. Falls für verschiedene Server verschiedene Teilbereiche getestet werden sollen, kann man auch mehrere Probes erstellen, in denen unterschiedliche Festlegungen in diesem Register getroffen werden.
Schließlich kann im Register Schedule noch ein Zeitplan für die Ausführung von Probes konfiguriert werden. Hier gilt es wieder, einen Kompromiss zwischen Aktualität und umfassender Erkennung von Problemen auf der einen Seite und der durch Probes entstehenden Last auf der anderen Seite zu finden.
Hierarchien und Filter
Wichtig beim DDM sind auch die Hierarchien und Filter. Letztere sind einfach zu erklären: Ein Filter legt fest, welche Ereignisse verarbeitet werden sollen. Damit kann gesteuert werden, dass beispielsweise weniger kritische Ereignisse nicht übernommen werden. Das ist vor allem in komplexeren Infrastrukturen von Bedeutung, in denen Ereignisse von Dutzenden oder Hunderten von Servern eingesammelt werden, um eine Überfrachtung mit Detaildaten zu verhindern.
Die Hierarchien steuern dagegen, wie Daten gesammelt werden. Wenn man DDM mit nur wenigen Servern an einem Standort einsetzt, braucht man sich darüber keine großen Gedanken zu machen. Es bietet sich in diesem Fall an, einen Server für die Sammlung der Daten zu definieren, der Informationen von allen anderen Servern in der Domäne einsammelt.
Wenn man aber viele Server hat, die sich auch an anderen Standorten befinden, kann man manuell eine Hierarchie erstellen, in der festgelegt ist, welche gesammelten Informationen an welche Server weitergeleitet werden. Diese Hierarchie kann auch mehrstufig sein. Damit lassen sich beispielsweise zunächst Daten von einem Standort konsolidieren und anschließend an einen zentralen Server weiterleiten.
Hier gilt, wie in allen anderen Bereichen des DDM: Die Kunst liegt darin, einerseits die kritischen Situationen auf Servern zu erkennen und andererseits nicht zu viele Daten zu sammeln. Denn zum einen bedeutet jede Probe zusätzliche Last und zum anderen muss man die Ereignisse auch auswerten und erkannte Probleme lösen. Deshalb sollte man zunächst gründlich planen, wofür man DDM nutzen möchte, bevor man beispielsweise anfängt, alle vorkonfigurierten Probes zu aktivieren. (mja)