DDM im Detail

10.02.2007 von Martin Kuppinger

Probes legen Einzelheiten zu Überprüfungen fest, die auf Servern ausgeführt werden. Der vorliegende Beitrag befasst sich zunächst mit den wichtigsten vordefinierten Probes und wendet sich dann der Erstellung neuer Probes und der Bearbeitung von Probes zur Anpassung an die speziellen Anforderungen zu. Schließlich wird der Umgang mit Probes, die Informationen vom Server-Betriebssystem ermitteln, sowie die zeitliche Steuerung von Probes näher betrachtet.

In der Monitoring Configuration-Datenbank gibt es immerhin 47 vorkonfigurierte Probes, die direkt eingesetzt werden können. Sie sind in folgende Kategorien eingeteilt:

Application Code: Probes, die die Ausführung von Code und hier konkret von Agenten überwachen. Es gibt beispielsweise Probes, mit denen die Ausführung von Agenten entsprechend der CPU- und Speichernutzung ausgewertet werden kann.
Database: Hier finden sich Probes für allgemeine Aktivitäten auf Datenbanken. Interessant sind vor allem die Probes, mit denen die Ausführung von Komprimierungsvorgängen (Compact) und die Fehlerüberwachung überprüft werden.
Directory: Hier gibt es verschiedene Probes für die Analyse des Domino Directory. Interessant ist beispielsweise die Überprüfung der Verfügbarkeit. Aber auch die regelmäßige Ausführung der LDAP Search Response Probe zur Ermittlung der Antwortzeiten für LDAP-Abfragen kann hilfreich sein.
Messaging: Hier sind die meisten Probes definiert. Sie überprüfen das Funktionieren der Messaging- Funktionen. Mit den Probes lässt sich beispielsweise das Funktionieren des Router- und SMTP-Dienstes testen.
Operating System: Hier sind einzelne Probes auf Betriebssystemebene vorkonfiguriert, mit denen der Status von Prozessor, Hauptspeicher oder Festplatten ermittelt werden kann.
Replication: Diese Probes analysieren den Replikationsstatus. Zu ihnen gehört beispielsweise die Prüfung nach Replikationsfehlern.
Security: Diese Probes analysieren die Sicherheitskonfiguration. Besonders interessant ist hier
die Security Best Practices-Probe, die die Konfiguration verschiedener Sicherheitseinstellungen überprüft.
Server: Hier gibt es standardmäßig nur eine Probe. Sie prüft, ob es Fehler bei der Ausführung verschiedener AdminP-Anforderungen gibt.
Web: In diesem Bereich gibt es zwei Probes, die Konfigurationseinstellungen überprüfen. Auch hier kann das Einhalten von Best Practices analysiert werden.

Die Standard-Probes müssen gegebenenfalls noch angepasst werden. So wird man beispielsweise nicht immer dem Verständnis von Lotus bezüglich der Best Practices folgen. In diesem Fall kann man bestimmte Prüfungen deaktivieren (Bild 1). Außerdem wird man in den meisten Fällen auch die Targets einschränken müssen. Darauf wurde bereits im ersten Teil der Serie eingegangen.

Bild 1: Die vorkonfigurierten Probes lassen sich anpassen.

Die Erstellung von Probes

Zusätzlich zu diesen vordefinierten Probes können in allen Kategorien auch eigene Probes erstellt werden. Dazu wird in der Monitoring Configuration- Datenbank die Schaltfläche New DDM Probe und anschließend die Kategorie ausgewählt. Abhängig vom gewählten Typ werden in der Maske unterschiedliche Optionen angezeigt. So können bei Database-Probes beispielsweise die Untertypen

Database Compact
Database Design
Database Error Monitoring
Scheduled Database Checks

ausgewählt werden. Darunter muss nun zunächst der Gültigkeitsbereich der Probe definiert werden, also die Server, gegen die diese Analyse durchgeführt werden soll.

Im unteren Bereich können Sie schließlich die spezifischen Festlegungen vornehmen. Dazu gehört immer die Severity, also der Schweregrad, wenn entsprechende Fehler auftreten. Bei einer Probe für das Database Error Monitoring finden sich darunter Fehlercodes, die ignoriert werden sollen (Bild 2). Diese Liste kann ergänzt oder gekürzt werden. Beim Hinzufügen weiterer zu ignorierender Fehlermeldungen kann auf eine vordefinierte Liste der Codes zugegriffen werden.

Ähnlich gestaltet sich auch die Erstellung anderer Probes. In praktisch allen Situationen kann auf umfassende Listen vorkonfigurierter Daten zugegriffen werden, soweit das Sinn macht. Es ist also beispielsweise nicht erforderlich, alle Fehlercodes zu kennen und diese manuell einzutragen. Es gibt aber auch Grenzen. So kann die Ausführung einer Probe zwar auf definierte Server, aber nicht auf einzelne Datenbanken auf diesen Servern beschränkt werden. Die Probe liest beispielsweise Fehlerinformationen aus dem Serverprotokoll. Eine weitere Eingrenzung ist nicht möglich, so dass bei der Analyse von Warnungen und Fehlern genau betrachtet werden muss, was eigentlich das gemeldete Problem ist.

Die Bearbeitung von Probes

Wie oben schon angesprochen, lassen sich sowohl die vordefinierten Probes als auch eigene Probes anpassen. Die wichtigste Anpassung ist die Festlegung der Targets. Aber auch die Anpassung beispielsweise von vordefinierten Fehlercodes und Schwellwerten nimmt einen wichtigen Raum ein. Etwas bedauerlich ist, dass Probes nicht kopiert werden können. Das wäre nützlich, um eine vorhandene Probe beispielsweise mit modifizierten Schwellwerten für verschiedene Server zu konfigurieren. In diesem Fall muss eine zweite Probe mit der gleichen Funktionalität, aber einer angepassten Konfiguration angelegt werden.

Die zeitliche Steuerung

Für alle Probes lässt sich auch ein Zeitplan konfigurieren (Bild 3), und zwar im Register Schedule einer Probe. Dort legen Sie die Ausführungszeit fest. Falls eine Probe mehrmals pro Tag ausgeführt werden soll, ist auch die Startzeit wichtig. Die Einstellung bei Missed Probes muss nur gesetzt werden, wenn Probes nicht mehrfach täglich ablaufen. In diesem Fall bietet sich die Option Run missed probe at startup an. Bei der Konfiguration der Zeitpläne muss darauf geachtet werden, dass insbesondere die lastintensiven Aktivitäten nicht alle zeitgleich stattfinden. Hier gilt es auch die vordefinierten Probes zu überprüfen, um zu verhindern, dass beispielsweise sehr viele Probes am Ersten eines Monats ablaufen.

Bild 3: Die Festlegung des Zeitplans für eine Probe.

Probes mit Systeminformationen

Ein besonders interessanter Bereich sind die Operating System Probes. Mit ihnen können für das Betriebssystem, die Festplatte, den Hauptspeicher und die Netzlast Schwellwerte definiert werden. Für jeden Untertyp gibt es wiederum mehrere Werte, die beobachtet werden können. Dabei muss zunächst konfiguriert werden, auf welchen Betriebssystemen die Überwachung erfolgen soll. Abhängig von den Betriebssystemen gibt es jeweils auch unterschiedliche Parameter. So kann bei Windows nur die Prozessorauslastung, bei AIX dagegen auch die Länge der Warteschlange in die Analyse einbezogen werden. Bei diesen Probes ist vor allem darauf zu achten, dass sinnvolle Werte gewählt werden. Wenn beispielsweise ein Schwellwert für die Prozessorauslastung definiert wird, ist zu beachten, dass dieser kurzfristig durchaus einmal 100% erreichen darf. Er darf aber nicht regelmäßig ganz hoch sein.

Wie geht es weiter?

Der dritte und letzte Teil der Artikelserie wird sich mit der Konfiguration von Serverhierarchien befassen, mit denen Informationen in einem mehrstufigen Modell über mehrere Server hinweg eingesammelt werden können. Außerdem wird es um die Analyse der Informationen gehen, die über DDM gesammelt werden können.