Wie sinnvoll ist eine hochdetaillierte Überwachung?

Sollen Systeme oder Applikationen überwacht werden, so kommen komplexe Werkzeuge wie BMC PATROL zum Einsatz. Damit ist es möglich, detaillierte Informationen über Systemzustände zu erhalten und ggf. Warnungen zu erzeugen. Dies erkauft man sich durch einen hohen Konfigurations- und Wartungsaufwand. Es stellt sich die Frage, ob eine hochdetaillierte Überwachung immer angemessen ist.

System- und Applikationsüberwachung mit BMC PATROL

PATROL stellt den Zustand der zu überwachenden Applikation bzw. des zu überwachenden Systems durch sogenannte Parameter dar. Ein Parameter beschreibt einen speziellen Messwert wie zum Beispiel die Auslastung eines bestimmten Dateisystems, die Anzahl gerade vorhandener Prozesse oder die Ausführungszeit eines bestimmten SQL Befehls.

Die Parameter werden in sogenannten Knowledge Modulen („KMs“) zusammengefasst. Jedem Parameter können Schwellwerte zugeordnet werden, so dass bei deren Überschreitung ein Alarm ausgelöst wird.

Customizing unverzichtbar

Philosophie von BMC ist es, in KMs sehr viele Parameter zur Verfügung zu stellen, da es für den Anwender einfacher ist, einen nicht benötigten Parameter zu löschen, als einen notwendigen neu zu entwickeln. Wird ein KM ohne geeignete Anpassungen („Customizing“) installiert, so wird eine große Zahl von Parametern aktiv. Auf einem typischen System können so leicht mehrere hundert Parameter vorhanden sein. Dies hat mehrere Konsequenzen:

• die durch PATROL verursachte Systemlast steigt
• die Übersichtlichkeit und Verständlichkeit wird verringert
• der Konfigurations- bzw. Wartungsaufwand steigt

Es ist also beim Einsatz von PATROL unumgänglich, eine sinnvolle Auswahl von Parametern zu treffen und geeignete Schwellwerte festzulegen.

Weniger ist manchmal mehr

Dass eine größere Anzahl Parameter die Last erhöht, ist klar; das Gegenteil bei PATROL jedoch nicht unbedingt: es wird unterschieden zwischen „Kollektoren“ (Parameter, die tatsächlich Systemzustände ermitteln) und „Konsumenten“ (Parameter, die die ermittelten Werte nur anzeigen und mit Schwellwerten vergleichen).

Die weitaus größte Zahl von Parametern sind Konsumenten - sie zu löschen hat wenig Einfluss auf die erzeugte Last, die im wesentlichen von den Kollektoren erzeugt wird. Da diese wiederum jeweils für viele Konsumenten „zuständig“ sind (also auch für erwünschte), können sie kaum sinnvoll gelöscht werden.

Mögliche Lösungen sind eine weniger häufige Ausführung der Kollektoren („Scheduling“) oder die Verschlankung des entsprechenden Programmcodes, wovon aber hinsichtlich Wartungs- und Migrationsproblemen stark abzuraten ist.

Ein sinnvoller Ansatz bei der Auswahl der Parameter hinsichtlich der Übersichtlichkeit und Verständlichkeit ist, nur die wirklich aussagekräftigen zu nutzen und nur dort Alarmierungen zu ermöglichen, wo im Falle eines Alarms auch reagiert werden kann. Es nutzt zum Beispiel wenig, alarmiert zu werden, dass „zu viele“ Dialogprozesse vorhanden sind: welcher Prozess sollte denn abgebrochen werden?

Auch stellt sich die Frage, ob sehr spezielle Parameter wirklich benötigt werden (etwa Parameter wie SMPSpinRdWr: die Anzahl der nicht im ersten Versuch zugeteilten Locks im Symmetric Multi Processing).

Außerdem verringert eine große Zahl von Parametern die Übersichtlichkeit der Darstellung, da die Anzahl der dargestellten Icons wächst und die erforderliche Dokumentation an Volumen (und damit erforderlicher Zeit zum Lesen und Nachschlagen) zunimmt. Auch das Wiederfinden von Parametern in einer Flut von mehrfach geschachtelten Ebenen von Icons wird mühsamer.

Bei der Auswahl der Parameter sollte übrigens nicht der Fehler begangen werden, eine Liste mit allen verfügbaren Parametern vorzulegen: zu groß ist die Gefahr, diese komplett angekreuzt zurückzuerhalten frei nach dem Motto „das hab ich immer schon mal wissen wollen ...“

Konfigurationsaufwand

Wie bereits angesprochen, muss PATROL den jeweiligen Anforderungen und Umgebungen angepasst werden. Sind viele Parameter vorhanden, so müssen dafür auch geeignete Schwellwerte eingestellt werden. Dies macht sich sowohl bei der Erstinstallation als auch bei Migrationen oder Portierungen durch erhöhten Aufwand bemerkbar.

Darüber hinaus zeigt die Erfahrung, dass auch im „normalen“ Betrieb häufig Änderungswünsche entstehen. Diesen Wünschen bei einer großen Anzahl von Rechnern (etwa mehreren hundert) zeitnah Rechnung zu tragen, kann mehrere Personen allein für diese Aufgabe binden. Ein geeignetes Konzept zur Konfigurationsautomatisierung ist unabdingbar.

Konfigurationsstrategien

PATROL unterscheidet zwischen globalen und lokalen Schwellwerten, die beide in KM-Dateien kodiert werden. Globale Schwellwerte sind allgemeine Voreinstellungen, die genutzt werden, solange keine lokalen Schwellwerte definiert werden, die dann z. B. nur für bestimmte Rechner die Voreinstellungen überschreiben. Sollen lokale Schwellwerte genutzt werden, so stehen zwei Ansätze zur Wahl:

1. ein einziges KM mit lokalen Schwellwerten für alle Rechner und Instanzen
2. ein individuelles KM pro Rechner

Beide Ansätze haben Vor- und Nachteile, auf die hier nicht näher eingegangen werden soll. In jedem Fall muss aber bei änderungen eines einzigen Parameterschwellwertes eine Datei zu dem jeweiligen Rechner übertragen werden. Dies stellt in heterogenen Umgebungen (kein ftp auf NT) oder bei instabilen Netzwerkverbindungen oft Probleme dar.

Eine Alternative bietet PATROL seit Version 3.3 durch die Möglichkeit, Schwellwerte in Konfigurationsvariablen abzulegen.

Dieses Feature war ursprünglich dazu vorgesehen, auch Operatoren die Möglichkeit zu geben, Schwellwerte zu ändern, kann aber auch sehr sinnvoll zur allgemeinen Verwaltung von Schwellwerten genutzt werden.

Wird dieses Verfahren genutzt, so verringert sich der Konfigurationsaufwand erheblich, da nur eine zentrale Tabelle mit sämtlichen Schwellwerten gepflegt werden muss, deren Daten dann per Skript extrahiert, umformatiert und mittels des Werkzeugs pconfig direkt an die Agenten übertragen werden.

Verständliche Parameter

Zu guter Letzt hat die Nutzung von wenigen, aussagekräftigen Parametern auch den Vorteil, dass gemeldete Alarme unmittelbar verstanden werden und über die Bedeutung bzw. Relevanz eines Parameters keine Unklarheiten entstehen können.

Umsetzung in die Praxis

Das bisher Gesagte kann in wenige Regeln zusammengefasst werden, die sich in der Praxis bewährt haben:

• Nur wirklich erforderliche, aussagekräftige Parameter werden benutzt, alle anderen werden entfernt
• Es werden nur dann Alarme erzeugt, wenn danach eine spezifische Handlung vorgesehen ist
• Lokale Schwellwerte werden nur eingesetzt, wenn unbedingt nötig
• Eine geeignete Konfigurationsstrategie wird genutzt

So kann zum Beispiel im Oracle KM eine Auswahl von etwa 10 bis maximal 20 Parametern (von etwa 200) für eine sinnvolle Überwachung der Datenbank durchaus ausreichend sein.

In vielen PATROL Installationen ist leider zu beobachten, dass die genannten Empfehlungen nicht beherzigt werden. Insbesondere werden zu oft Alarme eingerichtet.

Was dann eintritt ist der „Weihnachtsbaum-Effekt“: auf der PATROL Console blinkt fast jeder Rechner. Hier wird oft spöttisch vom „viel Blinken für´s Geld“ geredet, aber das Problem ist ernster: das Werkzeug verliert an Akzeptanz. Dies ist auch verständlich: wenn PATROL während des normalen störungsfreien Betriebes Alarme meldet, ist die Aussage „die Alarme haben keine Bedeutung“ in der Tat richtig.

Wenn dann tatsächlich einmal kritische Alarme gemeldet werden, werden sie nicht mehr ernst genommen oder gehen schlicht im allgemeinen unwesentlichen Blinken unter und werden übersehen.

Zusammenfassung

Eine Überwachung sollte so schlank wie irgend möglich sein. Nur in seltenen Fällen ist es erforderlich, hochspezielle Systemgrößen - im Sinne der Alarmerzeugung - zu überwachen. Für statistische Zwecke können solche Größen durchaus überwacht werden, sollten aber nicht in einer PATROL Console auftauchen und schon gar keine Alarme erzeugen. Weiterhin sollte bei größeren Rechnerzahlen eine geeignete Konfigurationsstrategie genutzt werden.

Dr. Christof Born info@ordix.de.