In dem ersten Teil dieses Beitrages lag der Focus auf dem Monitoing-Schichtenmodell. In dem zweiten Teil möchte ich nun genauer auf die Schnittstellen zwischen den Schichten eingehen, sowie den Messpunkt und Messintervalle.
Eine Schnittstelle dient zur Kommunikation zwischen den Schichten. Dabei müssen die Schichten nichts voneinanderen wissen. Lediglich wie eine Schicht die andere ansprechen muss, also über welche Schnittstelle.
In der Abbildung 5.1 sind die Schnittstelle anhand gelber Punkte gekennzeichnet. Hier sei angemerkt, das es sich hier nur um ein Beispiel von möglichen Schnittstellen handelt. Jede Schicht kann auch mehrere Schnittstellen zu verfügung stellen und über mehrere kommunizieren.
![]() Abbildung 5.1: Schnittstellen im Monitoring-Schichtenmodell |
In der Regel kommuniziert eine Schnittstelle über das Netzwerk. Das kann auch beispielsweise über das Internet sein. Natürlich gibt es auch andere Möglichkeiten mit einer Schnittstelle zu kommunizieren. Dieses kann z.B. der Austausch von Dateien sein. Schnittstellen können dabei auf verschiedenste weise angesprochen werden. Entweder mit einem Client oder auch direkt.
Nicht jede Schnittstelle ist allerdings für ein SLA-Monitoing geeignet. Hier sollte sollte genau hingeschaut werden. Auch das zusammenfassen von verschiedenen Monitoringergebnissen von Schnittstellen, stellt in der Regel kein zufriedenstellenendes Ergebnis dar. Es sollte, wie schon im ersten Teil dieses Beitrages (Punkt 3) erwähnt, darauf geachtet werden, daß das Monitoring einer Schnittstellen alle darunterliegenden Schnittstellen der Schichten mit einbezieht. Allerdings kann das überwachen von einzelnen Schnittstellen beispielsweise für ein Business-Process Monitoring bzw. Geschäftsprozess-Monitoring wichtig sein oder auch unterstützten.
Hier ein weiteres Beispiel für ein Schnittstellen-Monitoring bzw. SLA-Monitoing.
![]() Abbildung 6.1: Messen von SLA's an der richtigen Schnittstelle |
Abbildung 6.1 zeigt einen Cluster. Geht man nun davon aus, das auf jedem Server ein Webserver als Komponente läuft und in diesen ein CMS als Applikation und diese Applikation ist über einen Loadbalancer erreichbar. So würde es wenig Sinn machen jede Schnittstelle (Messpunkt 2) der Webserver zu überwachen und diese als ein Ergbenis zusammenzufassen, da hier der Loadbalancer z.B. nicht mit einbezogen werden würde. Natürlich könnte noch eine weitere Überwachung des Loadbalancer hinzugefügt werden. Macht aber wenigi Sinn. Viel wichtiger ist es hier das zusammenspiel aller Schichten mit dessen Schnittstellen zu Überwachen. In diesem Fall wäre es richtig einen Seitenaufruf von dem Messpunkt 1 zu machen und somit die Verfügbarkeit der Applikations CMS zu überprüfen. Fällt ein Webserver aus bedeutet dieses nicht die Beeinträchtigung der Verfügbarkeit der Applikation CMS.
Eine wichtige Rolle spielt auch der Messintervall. Eine Messung soll regelmäßig und in gleich bleibenden Zeitabständen durchgeführt werden. Wie oft und in welchen Zeitabständen eine Messung durchgeführt werden muss, ist von Fall zu Fall verschieden. So kann z.B. eine Messung der Festplattenkapazität im Intervall von 5 Minuten wichtig sein, weil viele Daten geschrieben bzw. abgelegt werden. Bei einer Festplatte hingegen, auf der sehr wenig Daten abgelegt werden, ist eine Messung im 5 Minuten Intervall nur wenig sinnvoll. Hier könnte je nach Daten auf kommen z.B. einmal täglich gemessen werden.
Zu bedenken ist, je häufiger gemessen wird, desto höher ist das Datenaufkommen und die durch die Messung verursachten System- und Netzwerklast. Dieses kostet System- und Netzwerkperformance, Plattenplatz und erzeugt letztendlich Kosten in monetärer Form.
Bei einer Verfügbarkeitsmessung hingegen muss häufiger gemessen werden. In der Regel ist ein Intervall von 5 Minuten ein guter Richtwert. Eine häufige Messung ist deshalb notwendig, um bei einem Ausfall oder einer Störung, so genau wie möglich die Dauer bestimmen zu können. Hier können unter Umständen schon einzelne Minuten über die Zahlung einer im SLA vereinbarten Strafe entscheiden.
Auch wenn zahlreiche Parameter gemessen werden können, muss für SLA relevante Messungen das Augenmerk immer auf die Verfügbarkeit eines IT-Services gelegt werden. Ein IT-Dienstleister wird dennoch in der Regel mehr Parameter messen als nur die Verfügbarkeit, denn zusätzliches proaktives Monitoring liegt in seinem eigenen Interesse. Außer der Messung der Verfügbarkeit von Komponenten werden standardmäßig noch Messungen von Parametern wie Festplattenkapazität, Speicher- und CPU-Auslastung etc., hinzukommen. Diese Messwerte dienen dann eher der Trendanalyse oder als proaktives Monitoring, um Störungen schon im Vorfeld zu erkennen und ab zu wenden.
Wie man erkennen kann, kann es oft sehr schwierig sein, eine Applikation auf ihr Verfügbarkeit hin zu überwachen. Schon bei der definition der einzelnen Schnittstellen wird es meist schwierig und unübersichtlich. Denn oft hat jeder ein anderes Verständnis für eine Schnittstelle und deren Messpunkte. Problematischer wird es dann noch, wenn die Applikation stetig wächst und nicht dokumentiert wird. Dieses macht eine Erweiterung des Monitoring nur schwierig.
Anregungen, Kritik, Verbesserungsvorschläge können jederzeit hier als Kommentar hinterlassen werden oder in meinen Portal. Auch wenn ich diesen Beitrag schon 100 mal Korrektur gelesen, sieht mal als letztes die Fehler einfach nicht mehr. Also falls noch Fehler entdeckt werden, bitte bscheid geben.
| Datum | Änderungen | Dank |
|---|---|---|
| 27.01.2011 | Die Präsentationsschicht in Kapitel 2 als eine weitere Schicht hinzugügt. | Dank hier an Lefty aus dem Nagios-Portal für diese Anregung |
| 23.02.2011 | Erweitungen des Serverschicht in Kapitel 2 um die Umwelt des Servers | Dank hier an Daniel Mahrenholz für diese Anregung. |
Comments
Thanks for this helpful
Thanks for this helpful article. Will sure be coming here on your blog in future.