end-2-end monitoring / servicemonitoring bei der …...• definition laut wikipedia: end to end...

© gkv informatik - Veröffentlichungen, auch auszugsweise, nur mit schriftlicher Genehmigung.

End-2-End Monitoring / Servicemonitoring

bei der gkv informatik

amasol Anwenderforum 2016, 20.4.2016

Carsten Hausmann

Betriebsüberwachung


End-2-End Monitoring / Servicemonitoring bei der gkv informatik

Agenda

1. Agenda

2. Was ist „End to End“ Monitoring?

3. Synthetic Client (simuliertes Benutzerverhalten)

4. Der Synthetic Client bei der gkvi

5. Real User Monitoring (aufgezeichnetes Benutzerverhalten)

6. Einführung und Betrieb des Real User Monitorings bei der gkvi

7. Der Weg vom „End to End“ zum Servicemonitoring

24. & 25.02.2016 2 End-2-End Monitoring / Servicemonitoring bei der gkv informatik | Carsten Hausmann | BS-BUW



Agenda


1. Agenda









Was ist „End to End“ Monitoring?

• Definition laut Wikipedia:

End to End (E2E) Monitoring bedeutet die zyklische Überwachung der Performance

geschäftskritischer Anwendungen aus Sicht der Nutzer, die

mit den Anwendungen arbeiten. Damit zielt End to End Monitoring auf Qualitätssicherung von IT-

Services aus der Nutzerperspektive

• Häufig haben Anwender Performanceprobleme obwohl die Einzelkomponen-ten der IT-Servicekette

wie Datenbanken, Applikationsserver usw. in einer isolierten Betrachtung keine Fehlermeldung

erzeugen

• Die Monitoringlösungen nach der E2E Definition basieren daher darauf, entweder das

Benutzerverhalten zu simulieren oder das Benutzerverhalten aufzuzeichnen

• Dabei werden an definierten Messpunkten Werte erzeugt, die zum proaktiven Systemmanagement

genauso genutzt werden können wie zum Service Level Monitoring




Agenda


1. Agenda









Synthetic Client (simuliertes Benutzerv.) I

• Synthetic Clients (oder auch Roboter, Bots) sind Werkzeuge, die das Benutzerverhalten auf

verschiedenste Arten nachstellen können

• Die einfachste und günstigste Lösung ist wohl ein Power Shell Script, auch AutoIt erfüllt seinen

Zweck

• Komfortabler sind dann diverse Makrotools, die es sowohl als Freeware oder auch als

kostenpflichtige Pakete gibt. WinTask ist hier zum Beispiel ein leicht zu erlernendes und

anzuwendendes Werkzeug

• Komplexe Business Lösungen unterstützen darüber hinaus die Verwaltung von hunderten solcher

Roboter. Die Messwerte werden hier in Datenbanken abgelegt und stehen dann für Reports,

Alarmierungen usw. zur Verfügung. Eine Lösung ist Servicetrace, die darüber hinaus ein leicht

verständliches Tool Set zur Makroerstellung zur Verfügung stellt. Simulierte Mausbewegungen,

Bilderkennungen und Timerfunktionen sind hier selbstverständlich

• Alle genannten Werkzeuge stehen hier nur stellvertretend für eine große Auswahl am Markt. Alle

haben Vor- und Nachteile und sollten für die jewei-ligen Anforderungen genau geprüft werden

• Nachfolgend der Mitschnitt eines Power Shell Scripts, keine 30 Zeilen lang




Synthetic Client (simuliertes Benutzerv.) II




Synthetic Client (simuliertes Benutzerv.) III

• Ein Timer wird gestartet und eine Webseite aufgerufen, die Anmeldedaten werden in die jeweiligen Felder

eingetragen und der Login Button geklickt

• Die Homepage der Anwendung erscheint und eine weitere URL zum

„System Status“ wird aufgerufen

• Der komplette HTML Code der Seite wird heruntergeladen, in eine Variable eingelesen, der Internet

Explorer beendet und der Timer gestoppt

• Während des Scripts kommen immer wieder Kontrollfunktionen zur Anwen-dung die sicherstellen, dass die

Webseiten vollständig geladen wurden

• Nachdem im ersten Teil des Scripts die gewünschte Webseite aufgerufen und die Daten eingelesen

wurden, wird im zweiten Teil ein ganz bestimmter Datensatz in der Variable gesucht, formatiert und in ein

Textfile ausgegeben

• Der erzeugte Eintrag für eine Datenbankabfrage sieht dann so aus:

Date |Time |res. Platz |gen. Platz| - Zusatzinfo Timer

25.01;10:04;591507,25;31858,73; - Dauer IE Abfrage: 0m:7s:809ms



• „Zusatzinfo Timer“ kann z.B. für einen Performance Chart genutzt werden




Agenda


1. Agenda









Der Synthetic Client bei der gkvi

• Bei der gkvi kommt das Programmpaket zum Einsatz

• Ca. 25 physikalische Rechner stehen an diversen Standorten, wobei die in den Workflows

verwendeten Kennwörter verschlüsselt hinterlegt wurden

• Mit dem GUI-basierten Workflow Editor wurden Workflows erstellt, um das Userverhalten auf SAP-

Systemen und im Citrix Umfeld nachzustellen

• Auf jedem Rechner laufen mehrere Workflows parallel in unterschiedlichen Sitzungen (Multitracer),

um Kennzahlen diverser Anwendungen zu ermitteln

• Die von den Robotern ermittelten Werte stehen dann für Dashboards, Alerting und Reporting zur

Verfügung

• Weiterhin erfüllen Sie die Aufgabe für die Verfügbarkeitsmessungen ständige Transaktionen in den

Systemen zu gewährleisten.



ServiceTrace E2E Client Messungen



Der Synthetic Client bei der gkvi




Agenda


1. Agenda









Real User Monitoring (aufgezeichnetes Bv.)

• Real User Monitoring ist ein passives Monitoringverfahren. Die überwachte Anwendung wird nicht

„benutzt“ wie bei einem Roboter. Oftmals kann es schwierig sein, für einen Roboter ein

Benutzerkonto zu erhalten. Schreibende Zugriffe auf ein System können auch zu einem Problem

werden. Bei solchen Einschränkungen ist oftmals ein RUM-System die Lösung

• Im Gegensatz zu dem simulierten Benutzerverhalten werden bei dieser Methode die Interaktionen

des Anwenders mit einer Webseite oder speziellen Anwendungen wie SAP nur aufgezeichnet. Dazu

werden meistens Netzwerk-pakete „eingefangen“ und vom RUM-System analysiert. Die

gesammelten Daten können dann ebenfalls für Dashboards, Alerting und Reporting verwendet

werden

• Für spezielle Monitoringaufgaben können RUM-Systeme auch ausführbaren Code mit der

Anwendung oder Webseite ausliefern, der dann auf dem Client ausgeführt wird und Daten an das

Messsystem liefert. An dieser Stelle ist der Übergang zum Application Performance Management

aber fließend




Agenda


1. Agenda









Einführung und Betrieb RUM bei der gkvi I

• RUM wurde für die gkvi interessant, da mit den Robotern schnell Grenzen erreicht wurden, die nicht

zu überschreiten waren:

- Benutzerkonten für die Roboter waren nur schwer oder gar nicht zu erhalten

- Eine hohe Anzahl unterschiedlicher SAP Systeme, damit zuviele Roboter

- Die Anforderung nach genauen Performancedaten etlicher Transaktionen

- Es sollten nach Möglichkeit Daten aller Standorte zur Verfügung stehen

- Informationen der Citrix-Farmen konnten nur schwer erfasst werden

• Nach einer längeren Testphase fiel die Wahl auf das RUM System der Firma Dynatrace, bei dem

einige Features besonders überzeugen konnten

• Der SAP Analyzer bietet neben den globalen Systemdaten auch sehr genaue Informationen zu

einzelnen Transaktionen und Applikationsservern

• Darüber hinaus bietet die Integration von Citrix Umgebungen und detaillierten Netzwerkdaten einen

hohen Informationsgehalt in den Dashboards




Einführung und Betrieb RUM bei der gkvi II

• Die erste Herausforderung bei der Implementierung eines RUM-Systems ist es, die erforderlichen

Daten vollständig aus dem Datenstrom vom Client bis zur letzten Instanz im Datacenter auszuleiten





• Hier können sogenannte Netzwerk-TAP´s (Test Acces Port) zum Einsatz kommen. Diese gibt es

sowohl für Kupfer- als auch Glasfaserinfrastruktur. Problematisch bei dem Einsatz von TAP´s ist

allerdings, dass die produktive Verkabelung aufgetrennt werden muss. Das Thema TAP ist eine

Wissen-schaft für sich und soll hier nicht weiter behandelt werden – siehe Google ;-)





• Diverse Gründe sprachen bei uns gegen den Einsatz solcher TAP´s. Wir haben uns dafür

entschieden, an strategischen Netzwerkkomponenten sogenannte SPAN-Ports (Switch Port

Analyzer) zu verwenden und dort die benötigten Mirror-Sessions einzurichten





• SPAN-Ports haben aber auch Nachteile, sie belasten den Switch-Prozessor auf dem die Mirror-

Session läuft. Das kann soweit gehen, dass bei hoher Last auf dem Switch die Mirror Session

beendet wird und keine Daten mehr an das RUM-System geliefert werden können





• Im Regelbetrieb wird eine Kopie des RX und des TX Kanals in einen Datenfluss gewandelt und an

den SPAN-Port weitergeleitet





• Vom SPAN-Port werden die Datenpakete dann an die Netzwerkprobes des RUM Systems gesendet.

SPAN-Ports oder TAP´s nehmen keine Datenpakete entgegen, daher gibt es keine Möglichkeit vom

RUM-System aus die produktive Umgebung zu beeinflussen





• Eine AMD konnte bis vor kurzem nur eine Bandbreite von etwas über 1Gb/s verarbeiten. Der von

unseren Netzwerkkomponenten generierte Datenstrom hatte aber eine Bandbreite von 4Gb/s. Wir

haben uns entschlossen, einen Netzwerkpaketfilter/Matrixswitch vor die Netzwerkprobes (AMDs) zu

schalten





• Mit solchen speziellen Systemen kann der Datenstrom durch entsprechende Filter gezielt reduziert

und sehr flexibel wieder ausgegeben werden. Mittler-weile sind hier nicht nur die AMDs

angeschlossen, sondern auch ein NetScout Netzwerk Analysesystem und Intrusion Detection

Systeme





• Zusätzliche Daten liefert das Thin Client Analysis Modul (TCAM), ohne das die Transaktion nicht

über die Citrix Server hinaus bis zum Thin Client nachvollziehbar wäre





• Die AMDs erfassen die Datenpakete und Informationen des TCAM von den Citrix Servern,

korrelieren diese und senden die relevanten Informationen an die Reportserver. Diese erstellen

letztlich die Dashboards, Reports und Alerts





• Die Skalierbarkeit des Systems durch die Verwendung mehrerer AMD´s und Reportserver ermöglicht

es zum einen, ein differenziertes Bild des Daten-stroms vom Anwender zur Anwendung zu erstellen

und es kann schnell und effektiv auf die wachsende Infrastruktur im Datacenter reagiert werden




Einführung und Betrieb RUM bei der gkvi III


SAP Core System – Detaildaten

• Übersicht aller Applikationsserver

• Lastverteilung, Applikation, Netzwerk



Einführung und Betrieb RUM bei der gkvi IV


SAP Core System – Detaildaten

• Standorte, Transaktionen



Agenda


1. Agenda









Der Weg v. „End to End“ z. Servicemon. I

• Nach den Detailinformationen zu einem SAP-System sind für die gkvi auch die Kennzahlen des

Gesamtsystems wichtig

• Diese werden für Alarmierungen, SLAs und Kundeninformationen genutzt

• Weiterhin wird der IT-Leitstand mit Echtzeitdaten aller SAP-Systeme versorgt

• Die Metriken „Operations“ und „Operation Time“ werden aktiv vom RUM-System überwacht und bei

Schwellwertverletzungen werden Alarme an das übergeordnete Event Management System

generiert

• Die nächsten Folien zeigen die vom RUM-System generierten, dynamischen Baselines, den Korridor

in dem sich die Ist-Werte bewegen können und die Ist-Werte. Weiterhin stellen wir unseren Kunden

über ein Portal ausgewählte Dashboards in Echtzeit zur Verfügung mit denen ich den Vortrag

beenden möchte




Der Weg v. „End to End“ z. Servicemon. II


• Metrik „Operation Time“ – Baseline, Korridor, Ist-Wert



Der Weg v. „End to End“ z. Servicemon. III


• Metrik „Operations“ – Baseline, Korridor, Ist-Wert



Der Weg v. „End to End“ z. Servicemon. IV


• Korrelierte Informationen „Synthetic Client“ und „Real User Monitoring“ im Event Management

System - LeuTek ZIS



Der Weg v. „End to End“ z. Servicemon. V


• Kundeninformationssystem – Dynatrace Enterprise Portal



Agenda


- Ende des Vortrags -

Vielen Dank für Ihre Aufmerksamkeit

end-2-end monitoring / servicemonitoring bei der …...• definition laut wikipedia: end to end...

Documents