2018-11-01 07:47:37

Durch Monitoring dem Fehler auf der Spur

In den meisten Unternehmen werden die geschäftskritischen Prozesse heute mit Hilfe von Business-Software bereitgestellt. Eine hohe Verfügbarkeit der Applikationen sowie der zugrundeliegenden IT-Infrastruktur gehört heute zu einem der Erfolgsfaktoren moderner Unternehmenskonzepte.

Die Harmonisierung und Integration aller Geschäftsprozesse in einem Unternehmen erfordern Konzepte für den verlässlichen Betrieb komplexer IT-Landschaften. Es gilt die Ausfallzeiten für unternehmenskritische Systeme möglichst zu vermeiden bzw. klein zu halten. Doch die Steuerungsfähigkeit setzt Wissen voraus. Die Unternehmen müssen wissen, welche Services, zu welchem Zeitpunkt und an welchem Standort und für welche Benutzer die geforderten Leistungen (Geschwindigkeit, Verfügbarkeit, Qualität) erbringen. Gleichgültig um welche Art des Service es sich handelt. Nur dann können sie die Gesamtqualität einzelner Services und das Zusammenspiel der verschiedenen Services und Dienstleister beurteilen und ihre Konsequenzen daraus ziehen.

Ein Ansatz hierfür ist die Überwachung und Langzeitanalyse von Laufzeitverhalten. Hierdurch können automatisch Fehler oder Performance-Probleme entdeckt und schnell Hinweise auf dessen Ursachen ermitteln werden. Das Monitoring der Performance (insbesondere Laufzeiteffizienz) liefert somit wertvolle Daten, um unternehmenskritische Systeme hoch verfügbar halten zu können. Eine solche Überwachung wird auch als Ende-zu-Ende Monitoring bezeichnet. Die Aufgabe des Ende-zu-Ende Monitorings besteht in der Möglichkeit einer permanenten Überwachung der Leistung geschäftskritischer Anwendungen.

Die Verfügbarkeit der Infrastruktur ist aber nicht gleichzusetzen mit der Verfügbarkeit und Qualität der Services bei den Anwendern. Aus dieser Erkenntnis und dem hohen Druck, der auf dem Business liegt, entstand in den letzten Jahren zunehmend die Forderung nach einer Überwachung der Servicequalität aus Sicht der Endanwender.

Die elektronische Geschäftsabwicklung erfordert die Gestaltung durchgängig IT-gestützter Prozessketten, die von den Lieferanten der Unternehmen bis zu den Endkunden reichen. Voraussetzung hierfür sind effizient und reibungslos ablaufende Teilprozesse, da sich durch deren Kopplung Störungen häufig sofort auf den gesamten Geschäftsprozess auswirken. Dies gilt insbesondere dann, wenn die IT-gestützte Steuerung der Geschäftsprozesse zu einer Just-In-Time-Produktion genutzt wird. Im Fall einer Störung muss schnell geklärt werden, welches Element der Servicekette den Fehler verursacht, und welche Person auf welchen Weg welche Information erhalten muss, um den Fehler zeitnah zu finden und zu beheben.

Das Ende-zu-Ende Monitorings beruht auf dem Konzept, dass man eine Reduzierung der Qualität einer Anwendung nur vollständig am Ort dessen Nutzung erkennt. Eine Qualitätskontrolle der Einzelkomponenten der Lieferkette (beispielsweise Datenbank, Server, Netzwerk, usw.) liefert immer nur Teilaspekte. Selbst wenn die Server und Prozesse auf den ersten Blick fehlerfrei arbeiten, können Workflows stehen bleiben oder Konvertierungen abbrechen und damit die ordnungsgemäße Abwicklung der Geschäftsprozesse verhindern, ohne dass dies vom System gemeldet wird. Eine der Ursachen ist beispielsweise, dass eine reibungslose Zusammenarbeit einzelner Übertragungselemente nicht gewährleistet ist. Dies führt letztendlich zu schlechterer Performance und einer wahrnehmbar niedrigen Servicequalität der Anwendung. Im schlimmsten Fall kommt es dazu, dass die Anwendung immer weniger genutzt wird.

Applikationsspezifische Fehler lassen sich nie ganz vermeiden! Umso wichtiger ist es, dass diese zeitnah erkannt und behoben werden. Denn Ausfallzeiten verursachen enorme Kosten, weil sie Geschäftsprozesse verzögern und zu hoher Ressourcenbindung im IT-Betrieb führen.

In der Praxis ist es wichtig, dass die Datenerfassung für das Ende-zu-Ende Monitoring zielgerichtet erfolgen. Dafür müssen die Ziele klar spezifiziert und dokumentiert werden. Hierzu müssen die Performance-Metriken und die jeweiligen Messpunkte bestimmt werden. Besonders wichtig ist die Zusammenstellung deutlicher Anhaltspunkte für die Qualitätsmessung. Historische Performance Metriken haben sich dabei als wertvolle Benchmarks für eine detaillierte Analyse erwiesen. Sie geben aussagekräftige Indikatoren in der Kommunikation zwischen Anwendungen und stellen Verzögerungen oder Fehler in der Kommunikation klar dar. Das Ende-zu-Ende Monitoring überprüft dabei auch, ob und wie performant Services beim Endnutzer ankommen, wie viel Bandbreite im Netz er benötigt und wie er sich auf den Ressourcen des Clients auswirkt bezüglich CPU, Speicher und Festplatte.

Aber auch die Unterschiede in der Netzgeschwindigkeit, die Wiederholungsübertragung (Re-Transmission) von TCP-Pakten oder http-Error-Codes sind eine ausgezeichnete Basis für diese Analyse. Als Performance Metriken eignen sich erfahrungsgemäß die folgenden Kriterien:


  • Verzögerung der Applikation im Server
  • Verzögerung zwischen Server und Netzwerk
  • Verzögerung zwischen Client und Netzwerk
  • Ladezeit einer Web-Seite oder einer Anwendung auf dem Client
  • Anzahl der übermittelten Pakete
  • Anzahl der übermittelten Bytes
  • Anzahl fragmentierter IP-Pakete
  • TCP Sendewiederholungen

Eine der großen Probleme der Netzwerk- bzw. der Fehleranalyse besteht darin, dass die Probleme der Nutzer immer im Nachhinein gemeldet werden. Meist stehen solche Daten jedoch nicht zur Verfügung. Die Firma Allegro Packets hat genau für diesen Anwendungsfall ein System entwickelt, welches den Zugriff auf ältere Daten (mit Hilfe einer Back-in-Time-Funktion) ermöglicht. Zur Aufzeichnung der Daten wird ein sogenannter Paketringpuffer genutzt, auf dem der gewünschte bzw. der gesamte Datenverkehr abgelegt wird. Durch zusätzliche Filter lässt sich auch kontrollieren, welche Pakete im Ringpuffer gespeichert werden. Eine Capture-Funktion greift auf die Inhalte des Ringpuffers zu und extrahiert somit die Datenverkehre der Vergangenheit. Hierzu wählt man einfach eine bestimmte Zeitspanne in einem beliebigen Diagramm der Benutzeroberfläche. Die Start- und Endzeit des abzuspeichernden Zeitraums lassen sich über das Datums- und Zeit-Popup-Fenster ändern.

Sollen nur die Daten eines Geräts bzw. einer Gruppe von Geräten bzw. Anwendungen aufgezeichnet und im Ringpuffer abgelegt werden, lassen sich hierfür folgende Filterfunktionen nutzen

  • Es soll nur bestimmte Teile des Datenstroms aufgezeichnet werden.
  • Die Daten eines Geräts bzw. einer Anwendung sollen aufgezeichnet werden und im Ringpuffer abgelegt werden. Für die Analyse bzw. die weitere Verarbeitung sind nur die unteren drei Schichten des Datenstroms notwendig.

Im ersten Fall verhindert das Regelwerk, dass bestimmte Pakete im Paketringpuffer gespeichert werden. Dies sorgt auch für eine Feinabstimmung, wie viele Paketdaten in dem Paketringpuffer geschrieben werden müssen. 

Im zweiten Anwendungsfall können Regeln konfiguriert werden, die die Aufzeichnungslänge der im Paketringpuffer abzuspeichernde Pakete festlegen. In diesem Fall bleiben die Informationen über die ursprüngliche Länge eines Pakets in den Captures weiterhin erhalten. Bei dem Erstellen einer Ringpuffer-Filterregel werden folgende Optionen bereitgestellt:

  • Regelbedingnung: Alle Pakete oder eine bestimmte MAC- oder IP-Adresse, TCP/UDP-Port, ein VLAN-Tag oder einer Schnittstelle entsprechen einem bestimmten Wert.
  • Negieren: Eine zuvor festgelegte Einschränkung wird umgekehrt überprüft (also z.B. anstatt Aufzeichnung einer bestimmten IP-Adresse nun Ausschluss einer bestimmten IP-Adresse). 
  • Aktion: Definiert, was mit den passenden Paketen gemacht werden soll:
  • Aufzeichnungslänge: Das Paket wird mit der im Eingabefeld angegebenen maximalen Länge erfasst. Ist das Paket größer, werden die restlichen Bytes verworfen.
  • Verwerfen: Das ganze Paket wird nicht aufgezeichnet.
  • Volle Länge: Das gesamte Paket wird aufgezeichnet.

Header: Nur der Paket-Header wird aufgezeichnet. Wird der Wert "L3" ausgewählt, werden die Layer-2- und Layer-3-Header gespeichert, also MAC- und IP-Informationen. Bei Auswahl von "L4" werden die Layer 2, 3 und 4 gespeichert, also auch inklusive TCP oder UDP-Headern.

Beispielsweise wird ein voll ausgelasteter 10G-Link analysiert. Die angeschlossene Festplatte ist dafür aber nicht schnell genug, es sind jedoch auch nicht alle Daten notwendig. Es soll stattdessen nur ein SIP-Server und dessen Verbindungen aufgezeichnet werden. Hierzu werden die folgenden zwei Regeln für den Ringpuffer festgelegt:

  • Regel 1: IP-Adresse vom SIP-Server -> volle Paketlänge,
  • Regel 2: alle (anderen) Pakete werden nicht aufzeichnet.

Der Vorteil dieser Regeln besteht darin, dass der Ringpuffer höhere Linkbandbreiten verarbeiten und damit länger rückwirkend puffern kann.

Im zweiten Schritt kann die Regel 2 so abgeändert werden, dass nur die Daten bis zum Layer 4 gespeichert werden. Damit ist die gesamte Kommunikation bis einschließlich L4-Header verfügbar und erlaubt es mit einer deutlich geringeren Bandbreite auf den Speicher zu schreiben. Bei einer mittleren Paketgröße von 700 Bytes beträgt hier die Reduktion der Datenrate ca. 80 - 90 Prozent und erlaubt es auf einer relativ langsamen USB3-HDD auch Links mit mehr als 1GBit/s zu analysieren.

log

Druckversion