Einleitung

In diversen Literaturen, die es auf dem Markt zum Thema Monitoring gibt, wird man genug Lösungen dazu finden, wie z.B. Datenbanken, Applikationen usw. überwacht werden können. Anders sieht es aber bei der Frage aus, wie überwache ich meine Applikation richtig und auf Verfügbarkeit? Es kann heute fast alles überwacht werden. Da sind den Möglichkeiten und Fantasien fast keine Grenzen gesetzt. Doch was sind wirklich relevante Informationen? Und welche können z.B. für einen Service Level Agreement (SLA) herangezogen werden? Gerade im Bereich des Outsourcings und Outtaskings, ist das Reporten bzw. der Nachweis einer Einhaltung eines SLAs sehr wichtig. Doch wie realisiert man soetwas?

Im Rahmen meiner Diplomarbeit habe ich dazu Ideen zu einem Monitoring-Schichtenmodell entwickelt, welche ich in diesem Beitrag vorstellen möchte. Die Aufteilung einer Applikation in die Elemente Server, Komponenten und Applikation ist in dem Unternehmen in dem ich tätig bin, gang und gebe und somit nicht neues. Allerdings wird es nicht direkt in Schichten betrachtet, sondern eher als eine Aufteilung in Elemente. In diesem Schichtenmodell finden sich desweiteren auch die Clients einer Applikation in einer optionalen Schicht wieder. In der Präsentationsschicht. Diese Schicht ist wichtig für die Messung von SLA relevanten Daten.

Die Fragen die sich natürlich stellt, wozu ein Monitoring-Schichtenmodell?

• Übersichliche Darstellung einer Applikation für die Einrichtung eines Monitorings
• Abgrenzung des Monitorings auf Intressenträger und somit Vermeidung von überflüssigen Überwachungen und sammeln nicht benötigter  Information bzw. Daten
• Eventuelle Reduzierung von Fehlalarmen
• Schaffen von Motivation und Vertrauen der Mitarbeiter gegenüber dem Monitoring
• Reduzierung von Kosten und Aufwenden eines Monitorings und effizientere Nutzung von Ressourcen eines Monitoring-Systems

1. Grundlegendes

Bevor ich näher auf das Monitoring-Schichtenmodell eingehe, möchte ich noch ein paar grundlegende Dinge erläutern.

1.1 Abgrenzung

Zum ersten möchte ich eine kurz Abgrenzungen treffen. In diesem Beitrag beziehe ich mich zur Erläuterung des Monitoring-Schichtenmodells konkret auf die Applikation SAP-Portal. Ich denke diese Appliaktion wird den meisten vertraut sein. Natürlich kann diese Monitoring-Schichtenmodell auch auf andere Systeme bzw. Applikationen angewendet werden.

Monitoring-Tool Icinga

In diesem Beitrag beziehe ich mich auf das Monitoring-Tool Icinga. Das hier vorgestellte Monitoring-Schichtenmodell lässt sich natürlich auf alle anderen Monitoring-Tools anweden. Ich möchte hier nicht beschreiben, wie eine Applikation im genaueren überwacht werden könnte, sondern abstrakt anhand des Monitoring-Schichtenmodell erläutern, was bei einem Monitoring z.B. im Bezug auf SLA's beachtet werden sollte.

Messpunkte

Desweiteren gehe ich nicht genauer auf Messpunkte ein. Natürlich sei an dieser stelle angemerkt, dass dieses ein sehr wichtiger Punkt ist, aber Hauptthema dieses Beitrages ist und soll das Monitoring-Schichtenmodell sein.

Schnittstellen

Ein weiterer wichtiger Punkt sind Schnittstellen zwischen den einzelnen Schichten. Diese sind natürlich nicht vergessen. Diese werden allerdings nur grob in dem ersten Teil dieses Beitrages behandelt. Mehr ist in dem zweiten Teil dieses Beitrages zu finden.

1.2 Die Sicht

Doch zuerst sollte die Frage gestellt werden, wen interessieren überhaupt die Informationen die aus dem Monitoring entstehen? Ich möchte  das Ganze hier auf drei Intressensträger abgrenzen:

Sicht des Kunden oder der Umwelt:

Zu der  Umwelt gehören z.B. Benutzer oder Mitarbeiter einer Applikation. Für einen Kunden beispielsweise ist in der Regel von Interesse, ob seine Applikation verfügbar ist und eventuell die Performance seiner Applikation. Desweiteren möchte ein Kunde von seinem IT-Dienstleister bei einem Ausfall früh genug darüber informiert werden. Es sollte nicht sein, das ein Kunde den IT-Dienstleister über einen Ausfall seiner Applikation informiert.

Sicht der Geschäftsführung:

Für die Geschäftsführung oder dem Management eines IT-Dienstleister ist zwar auch die Verfügbarkeit von Interesse. Aber noch wichtiger ist, ob z.B. ein im Vertrag definierter SLA für eine Applikation mit dem Kunden eingehalten wurde oder nicht. Desweiteren sind eventuell noch abzusehende Trends, wie z.B. die Zunahme von Festplattennutzung wichtig für Verhandlungen bei Vertragsanpassungen oder Vertragsverlängerungen.

Sicht des Administrator/en:

Eine ganz andere Sicht hingegen haben Administratoren bzw. der Verantwortliche einer Applikation. In erster Linie ist hier von Interesse, wo das Poblem bei einem Ausfall liegt bzw. bei einem drohenden Ausfall schon im Vorfeld Informiert werden. Hier sollte das Monitoring bei drohenden Ausfällen oder bei der Fehlersuche und -analyse unterstützten, um z.B. die Ausfallzeit möglichst gering zu halten oder dem Geschäftsführer bzw. Kunden über notwendige Maßnahmen zu Informieren.

1.3 Die Metriktypen 

Betrachtet man diese Sichten genauer, wird man erkennen das sich hieraus zwei elementare Metriktypen von Daten ergeben. Die Status- und Performancedaten. Die Abbildung 1.1 zeigt einen Auschnitt einer Festplattenüberwachung aus der Überwachung von Icinga. Hier sind zum einem die Statusdaten (Current Status) und zum anderen die Performancedaten (Performance Data) wiederzufinden.

Abbildung 1.1: Auschnitt aus der Icinga Statusübersicht

Statusdaten:

Statusdaten spiegeln, wie der Name schon sagt, lediglich einen Status wieder. Diese können z.B. Warning, Critical oder Ok sein. Diese geben also in der Regel nur Informationen darüber, ob ein voher definierter Schwellwert im Monitoring erreicht bzw. überschritten wurde. Statusdaten geben aber keine Informationen darüber, wie z.B. die Gesamtkapazität einer Festplatte ist und eignen sich somit auch nicht für eine Trendanalyse. Diese Daten können aber zur Darstellung einer Verfügberkeit in einem SLA herangezogen werden.

Performancedaten:

Die Performancedaten hingegen geben mehr Informationen über die Performance. Diese können beispielsweise sein, der Füllgrad und die Gesamtkapazität einer Festplatte und die dazu definiert Schwellwerte. Die Performancedaten lassen sich somit besser für z.B. eine Trendanalysen heranziehen.

2. Das Monitoring-Schichtenmodell

In dem Monitoring-Schichtenmodell werden zwischen vier Schichten unterschieden. Der Server-, Komponeten-, Applikationsschicht und Präsentationsschicht, wie in Abbildung 2.1 zu sehen. 

Abbildung 2.1: Monitoring-Schichtenmodell

Serverschicht:

Die Serverschicht ist die erste Schicht des Monitoring-Schichtenmodells und stellt die Basis für die Komponenten- und Applikationsschicht dar. Sie ist somit immer vorhanden und kann auch mehrfach in einer Darstellung auftauchen. Sie ist allerdings nach außen hin z.B. für einen Kunden nicht sichtbar. In dieser Schicht ist der Server mit seinem Betriebsystem zu finden. Hierbei kann es sich um einen physikalischen oder virtualisierten Server handeln. Abbilung 2.2.1 zeigt eine Verfeinerung der Serverschicht.

Abbildung 2.2.1: Verfeinerung der Serverschicht

Die Serverschicht kann aber auch weiter in ihre Umgebung hin unterteilt werden, wie die Abbildung 2.2.2 zeigt. So gehören dazu z.B. die Stromversorung oder auch Klimatisierung. Je nachdem wie genau man ins Detail gehen möchte und was einem wichtig was Monitoring der Serverschicht erscheint. Hier sind den Möglichkeiten keine Grenzen gesetzt. 

Abbildung 2.2.2: Verfeinerung der Serverschicht in ihre Umgebung

Abbildung 2.3 zeigt eine Darstellung eines Clusters. Hier ist es wichtig, das die Applikationsadresse des Clusters als eigener Server dargestellt wird. Bei einer Überwachung ist z.B. nicht immer bekannt, auf welchem Node gerade die Applikation läuft. Desweiteren würde ein Ausfall eines Nodes nicht unbedingt zu einer Störung der Applikation führen. Daher ist es gerade bei der Überwachung einer Verfügbarkeit einer Applikation wichtig, die Applikationsadresse als eigenen Server darzustellen.

Abbildung 2.3: Darstellung eines Clusters auf der Serverschicht

Komponentenschicht:

Die Komponentenschicht ist die zweite Schicht des Monitoring-Schichtenmodells und liegt zwischen der Server- und Applikationsschicht. Auch diese Schicht kann mehrfach in einer Darstellung auftauchen. In der Komponentenschicht sind die Komponenten der Applikation zu finden. Diese Komponenten stellen einen Teil der gesamten Applikation dar und ist auch nach außen hin nicht sichtbar. Nicht jede Applikation muß zwingend eine Komponente haben.

Applikationschicht:

Die Applikationsschicht ist die dritte und die oberst Schicht des Monitoring-Schichtenmodells. Diese Schicht ist nach außen hin immer sichtbar und immer nur einmal in einer Darstellung vorhanden. Diese Schicht ist z.B. relevant für die Überwachung eines SLAs, da diese die Sicht des Kunden repräsentiert. Die Applikationsschicht setzt entweder auf die Server- oder Komponentenschicht auf.

Präsentationsschicht:

Die Präsentationsschicht ist eine optionale Schicht und findet Anwendung in einer Client/Server-Architektur einer Applikation. In dieser Schicht befindet sich Bespielsweise Clients wie ein Broswer oder eine GUI mit Hilfe dieser auf einer Applikation gearbeitet werden kann.

2.1 Sicht auf das Monitoring-Schichtenmodell

Abbildung 2.4 zeigt eine gesamte Darstellung des Monitoring-Schichtenmodell und den sichten der Intressensträger.

Abbildung 2.4: Monitoring-Schichtenmodell aus verschiedenen sichten

2.2 Monitoring der einzelnen Schichten

Die Abbildung 2.5 zeigt ein Beispiel, wie ein SAP-Sytem im Monitoring-Schichtemodell abgebildet werden kann. In diesem Beispiel wird davon ausgegangen, das alles auf einem Server läuft.

Abbildung 2.5: Monitoring-Schichtenmodell am Beispiel SAP

In der Serverschicht ist der Server mit seinem Betriebssystem zu finden. Die Komponenten Datenbank und SAP liegen in der Komponentenschicht und sind nach außen hin, wie die Serverschicht, für den Kunden nicht sichbar. Das SAP-Portal stellt dabei die eigentliche Applikation dar, womit der Kunde arbeitet und welches nach außen hin für diesen sichtbar ist. In der Päsentationsschicht befinden sich der Client bzw. Browser, womit der Kunde auf die Applikation zugreift. Je nachdem was mit dem Kunden in einem SLA-Vertrag vereinbart wurde, findet ein SLA-Monitoring auf der Applikations- oder Präsentationsschicht statt.

Natürlich könnte auch die Komponente Datenbank z.B. auf einem anderen Server laufen. Klar sollte allerdings hierbei sein, das die Serverschicht immer als Basis vorhanden ist. D.h. fällt ein Server aus irgendeinem Grund aus, ist somit auch immer eine Komponente oder Applikation davon betroffen die auf dem Server läuft. Ein Ausfall einer Komponente bedeutet dabei aber nicht zwingend einen Ausfall der Applikation.

In wie weit man ein Applikation in dem Monitoring-Schichtmodell abbildet, ist jedem selber überlassen. Dabei sei aber angemerkt, je genauer die Verfeinerung der Komponenten, wie z.B. das einbeziehen von Netzwerkelemente (Switch, Router, etc.) ist, je schwieriger und unübersichtlicher kann es werden. Auch werden damit die Schnittstellen in einer solchen Darstellung in der Regel mehr. Es sollten daher also wirklich nur die relevante Dinge einer Applikation dargestellt werden. 

Die Abbildung 2.6 zeigt die Anwendung des Monitoring-Schichtenmodells auf eine grössere Umgebung mit mehreren Servern unter Einbeziehung der Sicht. 

Abbildung 2.6: Anwendung des Monitoring-Schichtenmodells auf eine grössere Umgebungen

Wie deutlich zu sehen ist und bereits auch schon weiter oben erwähnt, stellt der Server immer die Basis dar, auf welche eine Komponente oder Applikation aufsetzt. Zum anderen kann man erkennen, welche Verbindungen (Schnittstellen) es unter den Servern, Komponenten, Applikationen und Client gibt. Desweiteren wird jetzt deutlich, welche Sicht auf die Applikation z.B. ein Administrator gegenüber dem Kunden hat.

3. Monitoring von SLAs

Wie bereits erwähnt, wird in dem Monitoring-Schichtenmodell ein SLA immer auf der Applikations- oder Präsentationsschicht überwacht und ist immer nur eine Überprüfung (Check). Wichtig bei einer solchen Überwachung ist allerdings, das auch das Zusammenspiel der Komponenten mit der Applikation bzw. Client überprüft wird. Damit ist nicht gemeint, das Komponente einzeln überprüft werden und diese dann alle zu einer Überprüfung zusammenfasst werden, sondern ob die Applikation zusammen mit den Komonenten arbeitet. Auch bringt es sehr wenig zu prüfen, ob z.B. ein TCP-Port vom SAP-Portal erreichbar ist. Denn fällt beispielsweise die Komponente Datenbank aus, so ist eventuell der überwachte TCP-Port des SAP-Portals immer noch erreichbar. Auch würde z.B. eine fehlerhafte Berechtigungen innerhalb der Datenbank nicht unbedingt eine Störung der Komponente bedeuten. Somit würde eine solche Überwachung keine ausreichende Aussage über die Verfügbarkeit geben und wäre somit beispielsweise für einen SLA unbrauchbar. Es muss also eine Überprüfung sein, welche die gesamte Funktionalität der Applikation zusammen mit den Komponenten überprüft. Dieses könnte z.B. ein Login in das SAP-Portal mit einem Browser sein. Wie soetwas im genaueren z.B. mit Sahi realisert werden kann, beschreibt Gerhard Laußer in seinem Buch Nagios - Das Praxisbuch: Open Source-Monitoring im Unternehmen. 

4. Fazit

Wie mit Hilfe des Monitoring-Schichtenmodell zu sehen ist, lässt sich übersichtlich Abbilden, wie eine Applikation mit seinen Komponenten, Server und eventuell Client aufgeteilt und überwacht werden kann. Genau wie in der Regel ein Konzept zur Installation, Einrichtung und Einführung einer neuen Applikation erstellt wird, sollte dieses auch mit dem Monitoring für eine Applikation geschehen. Das Monitoring-Schichtenmodell bietet dabei eine Unterstützung zur Erstellung eines Monitoring-Konzeptes unter Berücksichtigung aller Interessensträger. Zum anderen wird wirklich auch nur das überwacht, was relevant ist. Dieses führt dazu, das unnötige Daten bzw. Informationen erst gar nicht gesammelt und somit Kosten und Ressourcen eines Monitoring-Sytems geschont werden. Auch werden eventuell durch die nicht Überwachung nicht benötiger Dinge, die Fehlalarme reduziert.

Hier geht es weiter zum zweiten Teil dieses Beitrages.

Download Teil 1 und Teil 2 als PDF