Die Fokussierung auf Geschäftsprozesse in Unternehmen, ihre Standardisierung (ISO 9001) und Automatisierung ist untrennbar mit dem Siegeszug serviceorientierter Architekturen (SOA) verbunden. Dabei entstehen in der IT verteilte Systeme, die Informationen unterschiedlicher Drittsysteme bündeln. Auf diese greifen wiederum verschiedene Services zu, die jedoch eigene Strukturen beinhalten.
Die Verknüpfung einzelner Systeme mit den Services eines Unternehmens, z. B. die Kundendatenbank, ist sehr tief in die SOA-Strukturen integriert. So muss etwa die Buchhaltung auf Kundendaten ebenso zugreifen, wie der Vertrieb, der Support oder das Marketing. Die Anforderungen an solche Systeme hinsichtlich Verfügbarkeit und Performance wachsen kontinuierlich.
Mit den immer größer werdenden Bandbreiten steigen auch die Datenmengen, die die Systeme zu verarbeiten haben. Durch die Einbindung immer weiterer Prozesse nimmt auch die Zahl der Anfragen zu. Dies kann zu Performanceeinbrüchen führen, die sich in verlängernden Verarbeitungszeiten und Antwortzeiten einzelner Systeme äußern. Performanceprobleme eines einzelnen Systems im Systemverbund können dabei Auswirkungen auf die Performance und Funktionalität anderer Verbundsysteme und damit auch anderer Services haben z. B. aufgrund von auftretenden Timeouts, wie folgendes Beispiel zeigt:
Die Adressdatenbank eines Unternehmens ist im Laufe der Zeit kontinuierlich gewachsen. Die Marketingabteilung plant eine Kampagne, die alle Kunden einbeziehen soll. In diesem Kontext wird unter anderem ein Serienbrief mit einem personalisierten Anschreiben erstellt. Dazu wird zur Abfrage der Anreden und Adressen aller Kunden auf die Kundendatenbank zugegriffen. Das die Kundendatenbank beherbergende System kann durch eine derart umfangreiche Anfrage so stark ausgelastet sein, dass Anfragen von anderen Systemen erst mit einem merklichen Zeitverzug bedient werden. Oder - im ungünstigsten Fall - sogar gar nicht. Die Folgen zeigen sich aber erst durch die Unzuverlässigkeit anderer Services, die die Kundendatenbank zum gleichen Zeitpunkt abfragen mussten. Unter Umständen braucht der entsprechende Prozess erheblich länger als sonst, oder schlägt fehl.
Häufig ist es sehr schwierig in komplexen Systemstrukturen aus dem auftretenden Fehlerbild auf die eigentliche Fehlerursache ("Root Cause") zu schließen. Die Folge: Der Prozess der Fehlerbehebung wird sehr zeit- und kostenintensiv. Es ist also nötig, Netzwerke engmaschig zu überwachen.
Viele Probleme werden durch die Protokollierung von Kenndaten der unteren Protokolllayer ("Transport Schicht") erkannt. Dazu zählen unter anderem die Round Trip Time (RTT), Retransmits und Fragmentierung.
Diese etablierten Methoden stellen sicher, dass die vorhandene Infrastruktur verfügbar und eine Kommunikation zwischen den Komponenten des Systemverbundes grundsätzlich möglich ist. Informationen über den eigentlichen "Nutzverkehr" werden jedoch nicht geliefert, da dieser auf den höheren Layer ("Application Layer") übertragen wird. Viele Fehlersituationen oder Performance Probleme lassen sich aber nur sinnvoll analysieren, wenn auch der Application Layer ausgewertet wird.
Grundsätzlich liefern die auf den Systemen laufenden Applikationen in ihren Log Dateien Informationen über den Nutzverkehr und aufgetretene Fehler. Die Auswertung von Log Dateien stellt damit ein weiteres Instrument zur Überwachung von Diensten dar. Hierbei gibt es aber grundsätzlich 2 Problemfelder:
Zum einen werden nicht alle notwendigen Informationen von den Applikationen vollständig geloggt bzw. nicht alle Fehlersituationen können durch Log Meldungen komplett abgebildet werden.
Zum anderen wirkt sich die Erhöhung des Log-Levels negativ auf die Leistungsfähigkeit der jeweiligen Systeme aus. Aus Performancegründen muss daher oft auf ein ausführliches Logging verzichtet werden. In diesem Fall haben Betreiber solcher Systeme oft gar keine richtige Möglichkeit an Informationen über den "Nutzverkehr" zu gelangen, um ggf. eine Fehleranalyse durchzuführen.
Die Lösung für die oben genannten Probleme heißt: Passives Logging. Passives Logging bedeutet, dass Log Dateien auf Basis des Netzwerkverkehrs ohne Beeinflussung der Systeme und Services erstellt werden. Dabei macht man sich zunutze, dass Netzwerk-Services eine genau spezifizierte Schnittstelle benutzen und die Kommunikation über das Netzwerk genau diesem Protokoll folgen muss. Das Mitschneiden des Netzwerkverkehrs eines zentralen Dienstes eines Unternehmens (z. B. der Kundendatenbank) versetzt das Trace-System in die Lage, die komplette Kommunikation zwischen den Systemen auf der Applikationsschicht zu erfassen. Hieraus können dann alle relevanten in den Requests/Responses enthaltenen Informationen oder auch Fehlerfälle geloggt werden. Es können aber auch nahezu beliebige Performance Daten generiert werden (Response Zeiten, Execution Zeiten, Anzahl Requests/sec ...), ohne dabei Einfluss auf die eigentliche Funktionalität und Leistungsfähigkeit des Netzwerkes und des Dienstes zu nehmen. Auf diese Weise kann der Dienst unabhängig von seinem Hersteller lückenlos protokolliert werden. Die Logging-Lösung kann damit genauso mitwachsen, wie der Dienst - selbst wenn der Hersteller einmal gewechselt wird.
Auf Grundlage der Antwortzeit auf jede einzelne Anfrage kann die Leistungsfähigkeit genauso berechnet werden wie die Fehlerhäufigkeit. Bei unternehmenskritischen Anwendungen kann - wo sinnvoll - auch das Auslösen eines Alarms implementiert werden; entweder als SMS-Benachrichtigung an einen Administrator oder indem ein zentrales System etwa per SNMP-Trap alarmiert wird. Grundvoraussetzung für die korrekte Funktion eines solchen Trace-Systems ist das verlustfreie Mitschneiden des Netzwerkverkehrs. Um Applikationsdaten überhaupt nutzen zu können, müssen die je nach Protokoll über mehrere Pakete verteilten Daten wieder korrekt und lückenlos zusammengesetzt werden. Bereits ein einziges verlorenes Paket kann sich zu einem "false positive" auswirken, also zu einem Alarm führen, der fälschlicherweise ausgelöst wird. In Hochgeschwindigkeitsnetzen stellt dies besondere Anforderungen an die Hardware des Trace-Systems, um den gesamten Netzwerkverkehr komplett (ohne Paketverlust) und vollständig (komplette Payload) erfassen und auf die Platte schreiben zu können.
Wird diese Lösung in mehrfacher Ausführung in einem Unternehmen an mehreren Stellen eines verteilten Systems eingesetzt, kann die Kombination der einzelnen Informationen aus den Loggern - etwa durch eine speziell für diese Aufgabenstellung vorgesehene Appliance - ein wertvolles Plus an Informationen bieten. Dies leistet unter anderem bei der Fehlersuche und der Performance-Optimierung sehr nützliche Dienste, die eine isolierte Betrachtung von Einzelsystemen nicht liefern kann. So können die Durchlaufzeiten der einzelnen Services zueinander in Beziehung gesetzt werden. Dadurch lässt sich die aktuelle Performance des gesamten verteilten Systems beurteilen, die sich nicht zwangsläufig aus der Summe der Einzelsysteme bildet. Zudem kann auf diese Weise vermieden werden, dass die Optimierung eines einzelnen Systems andere Systeme in Mitleidenschaft zieht und dadurch die Gesamtperformance des verteilten Systems sinkt.
Heutige Computersysteme zeichnen sich durch einen hohen Grad an Serviceorientierung aus. Monitoring-Systeme sollten diesem Umstand angepasst werden und Services direkt im Applikation Layer protokollieren und nicht nur die Transportschicht betrachten, um damit die Betreibkarkeit von komplexen Systemlandschaften deutlich zu verbessern.
Die Verknüpfung einzelner Systeme mit den Services eines Unternehmens, z. B. die Kundendatenbank, ist sehr tief in die SOA-Strukturen integriert. So muss etwa die Buchhaltung auf Kundendaten ebenso zugreifen, wie der Vertrieb, der Support oder das Marketing. Die Anforderungen an solche Systeme hinsichtlich Verfügbarkeit und Performance wachsen kontinuierlich.
Mit den immer größer werdenden Bandbreiten steigen auch die Datenmengen, die die Systeme zu verarbeiten haben. Durch die Einbindung immer weiterer Prozesse nimmt auch die Zahl der Anfragen zu. Dies kann zu Performanceeinbrüchen führen, die sich in verlängernden Verarbeitungszeiten und Antwortzeiten einzelner Systeme äußern. Performanceprobleme eines einzelnen Systems im Systemverbund können dabei Auswirkungen auf die Performance und Funktionalität anderer Verbundsysteme und damit auch anderer Services haben z. B. aufgrund von auftretenden Timeouts, wie folgendes Beispiel zeigt:
Die Adressdatenbank eines Unternehmens ist im Laufe der Zeit kontinuierlich gewachsen. Die Marketingabteilung plant eine Kampagne, die alle Kunden einbeziehen soll. In diesem Kontext wird unter anderem ein Serienbrief mit einem personalisierten Anschreiben erstellt. Dazu wird zur Abfrage der Anreden und Adressen aller Kunden auf die Kundendatenbank zugegriffen. Das die Kundendatenbank beherbergende System kann durch eine derart umfangreiche Anfrage so stark ausgelastet sein, dass Anfragen von anderen Systemen erst mit einem merklichen Zeitverzug bedient werden. Oder - im ungünstigsten Fall - sogar gar nicht. Die Folgen zeigen sich aber erst durch die Unzuverlässigkeit anderer Services, die die Kundendatenbank zum gleichen Zeitpunkt abfragen mussten. Unter Umständen braucht der entsprechende Prozess erheblich länger als sonst, oder schlägt fehl.
Häufig ist es sehr schwierig in komplexen Systemstrukturen aus dem auftretenden Fehlerbild auf die eigentliche Fehlerursache ("Root Cause") zu schließen. Die Folge: Der Prozess der Fehlerbehebung wird sehr zeit- und kostenintensiv. Es ist also nötig, Netzwerke engmaschig zu überwachen.
Viele Probleme werden durch die Protokollierung von Kenndaten der unteren Protokolllayer ("Transport Schicht") erkannt. Dazu zählen unter anderem die Round Trip Time (RTT), Retransmits und Fragmentierung.
Diese etablierten Methoden stellen sicher, dass die vorhandene Infrastruktur verfügbar und eine Kommunikation zwischen den Komponenten des Systemverbundes grundsätzlich möglich ist. Informationen über den eigentlichen "Nutzverkehr" werden jedoch nicht geliefert, da dieser auf den höheren Layer ("Application Layer") übertragen wird. Viele Fehlersituationen oder Performance Probleme lassen sich aber nur sinnvoll analysieren, wenn auch der Application Layer ausgewertet wird.
Grundsätzlich liefern die auf den Systemen laufenden Applikationen in ihren Log Dateien Informationen über den Nutzverkehr und aufgetretene Fehler. Die Auswertung von Log Dateien stellt damit ein weiteres Instrument zur Überwachung von Diensten dar. Hierbei gibt es aber grundsätzlich 2 Problemfelder:
Zum einen werden nicht alle notwendigen Informationen von den Applikationen vollständig geloggt bzw. nicht alle Fehlersituationen können durch Log Meldungen komplett abgebildet werden.
Zum anderen wirkt sich die Erhöhung des Log-Levels negativ auf die Leistungsfähigkeit der jeweiligen Systeme aus. Aus Performancegründen muss daher oft auf ein ausführliches Logging verzichtet werden. In diesem Fall haben Betreiber solcher Systeme oft gar keine richtige Möglichkeit an Informationen über den "Nutzverkehr" zu gelangen, um ggf. eine Fehleranalyse durchzuführen.
Die Lösung für die oben genannten Probleme heißt: Passives Logging. Passives Logging bedeutet, dass Log Dateien auf Basis des Netzwerkverkehrs ohne Beeinflussung der Systeme und Services erstellt werden. Dabei macht man sich zunutze, dass Netzwerk-Services eine genau spezifizierte Schnittstelle benutzen und die Kommunikation über das Netzwerk genau diesem Protokoll folgen muss. Das Mitschneiden des Netzwerkverkehrs eines zentralen Dienstes eines Unternehmens (z. B. der Kundendatenbank) versetzt das Trace-System in die Lage, die komplette Kommunikation zwischen den Systemen auf der Applikationsschicht zu erfassen. Hieraus können dann alle relevanten in den Requests/Responses enthaltenen Informationen oder auch Fehlerfälle geloggt werden. Es können aber auch nahezu beliebige Performance Daten generiert werden (Response Zeiten, Execution Zeiten, Anzahl Requests/sec ...), ohne dabei Einfluss auf die eigentliche Funktionalität und Leistungsfähigkeit des Netzwerkes und des Dienstes zu nehmen. Auf diese Weise kann der Dienst unabhängig von seinem Hersteller lückenlos protokolliert werden. Die Logging-Lösung kann damit genauso mitwachsen, wie der Dienst - selbst wenn der Hersteller einmal gewechselt wird.
Auf Grundlage der Antwortzeit auf jede einzelne Anfrage kann die Leistungsfähigkeit genauso berechnet werden wie die Fehlerhäufigkeit. Bei unternehmenskritischen Anwendungen kann - wo sinnvoll - auch das Auslösen eines Alarms implementiert werden; entweder als SMS-Benachrichtigung an einen Administrator oder indem ein zentrales System etwa per SNMP-Trap alarmiert wird. Grundvoraussetzung für die korrekte Funktion eines solchen Trace-Systems ist das verlustfreie Mitschneiden des Netzwerkverkehrs. Um Applikationsdaten überhaupt nutzen zu können, müssen die je nach Protokoll über mehrere Pakete verteilten Daten wieder korrekt und lückenlos zusammengesetzt werden. Bereits ein einziges verlorenes Paket kann sich zu einem "false positive" auswirken, also zu einem Alarm führen, der fälschlicherweise ausgelöst wird. In Hochgeschwindigkeitsnetzen stellt dies besondere Anforderungen an die Hardware des Trace-Systems, um den gesamten Netzwerkverkehr komplett (ohne Paketverlust) und vollständig (komplette Payload) erfassen und auf die Platte schreiben zu können.
Wird diese Lösung in mehrfacher Ausführung in einem Unternehmen an mehreren Stellen eines verteilten Systems eingesetzt, kann die Kombination der einzelnen Informationen aus den Loggern - etwa durch eine speziell für diese Aufgabenstellung vorgesehene Appliance - ein wertvolles Plus an Informationen bieten. Dies leistet unter anderem bei der Fehlersuche und der Performance-Optimierung sehr nützliche Dienste, die eine isolierte Betrachtung von Einzelsystemen nicht liefern kann. So können die Durchlaufzeiten der einzelnen Services zueinander in Beziehung gesetzt werden. Dadurch lässt sich die aktuelle Performance des gesamten verteilten Systems beurteilen, die sich nicht zwangsläufig aus der Summe der Einzelsysteme bildet. Zudem kann auf diese Weise vermieden werden, dass die Optimierung eines einzelnen Systems andere Systeme in Mitleidenschaft zieht und dadurch die Gesamtperformance des verteilten Systems sinkt.
Heutige Computersysteme zeichnen sich durch einen hohen Grad an Serviceorientierung aus. Monitoring-Systeme sollten diesem Umstand angepasst werden und Services direkt im Applikation Layer protokollieren und nicht nur die Transportschicht betrachten, um damit die Betreibkarkeit von komplexen Systemlandschaften deutlich zu verbessern.
