Einführung in das Real-User-Monitoring

Als Verantwortlicher für den technischen Support bei Dreams without Limits weiß Scott aus Erfahrung, dass es schwierig sein kann, die Grundursache oder den Engpass von Leistungsproblemen zu identifizieren. Dies gilt insbesondere für systemübergreifende Geschäftsprozesse: Bei Dreams ohne Limits umfasst der Prozess „Einstellung bis zum Ruhestand" Systeme und Cloud-Services wie SAP SuccessFactors, SAP S/4HANA Cloud und SAP Master Data Integration. Scott weiß auch, dass Benutzer häufig eine andere Laufzeit für ihre Anfragen erleben als der IT-Support in einzelnen Komponenten messen kann, da Netzwerkzeiten oder Frontend-Zeiten oft schwer zu messen sind.

In einem seiner nächsten regelmäßigen Meetings mit Carl fragt Scott Carl, wie SAP Cloud ALM für den Betrieb ihm bei der Lösung dieses Problems helfen kann.

Carl gibt an, dass SAP Cloud ALM Real-User-Monitoring anbietet. Er fährt fort, dass das Real-User-Monitoring dazu dient, Transparenz über die Verwendung (d.h. Ausführungen) und die Performance (d.h. die Antwortzeiten) von Benutzerinteraktionen zu schaffen. Dies wird erreicht, indem Messungen sowohl auf Frontend- als auch auf Serverseite durchgeführt werden, um die eigentliche Grundursache von Performanceproblemen zu ermitteln. Die Verwendung der SAP-Passport-Technologie ermöglicht dann die Korrelation von Monitoring-Daten, die am Frontend, im Cloud-Service und/oder auf Systemseite gemessen werden, um End-to-End-Benutzeranforderungsflüsse zu analysieren.

Scott ist aufgeregt und möchte mehr darüber erfahren. Er bittet Carl deshalb, näher einzugehen.

Carl gibt an, dass es mit SAP Cloud ALM nicht erforderlich ist, Agenten auf den SAP-Systemen oder auf dem Frontend zu installieren.

Anschließend beginnt er mit der detaillierten Erläuterung des Prozessablaufs:

• Immer wenn ein Benutzer eine Anforderung auslöst, wird der Datenstrom (z.B. http) mit einem SAP Passport angereichert. Dieser SAP Passport ist dann Teil jeder Kommunikation zwischen den verschiedenen beteiligten SAP-Systemen und dem Benutzer.

  Notiz

  SAP Passport ist in diesem Kontext ein Korrelationsmechanismus, der Performance-Daten aus mehreren technischen Komponenten eindeutig mit einer End-to-End-Anforderung korreliert.

• Wenn die Anforderung von einem SAP-System (z.B. einem SAP-Gateway-System) verarbeitet wird, kann das System die Informationen aus SAP Passport lesen, Informationen lokal speichern und während der Ausführung der Anforderung zusätzliche Informationen hinzufügen.

  Hinweis

  Beispiele für lokal gespeicherte Informationen sind der Zeitstempel oder die eindeutige ID aus dem SAP Passport. Beispiele für Zusatzinformationen sind Statistiksätze oder welches System als nächstes aufgerufen wird.

  Notiz

  Im Fall von SAP S/4HANA Cloud Public Edition wird auch der SAP Passport verwendet, und Informationen aus der Ausführung der Anforderung können über APIs und Web-Services abgerufen werden.

• Sowohl die Passinformationen als auch die performancerelevanten Informationen werden häufig aus den SAP-Systemen und aus den Cloud-Services gesammelt. Die Informationen werden entweder über die Softwarekomponente ST-A/PI (für On-Premise-Systeme) oder Web-Services und API (für Cloud-Systeme) an SAP Cloud ALM gesendet.
• Mithilfe der SAP-Passport-Technologie können die Daten in SAP Cloud ALM aus der einzelnen Anforderung in den gesamten Anforderungsausführungsablauf korreliert werden. SAP Cloud ALM kann die Daten auch aggregieren, was es ermöglicht, sie für einen längeren Zeitraum verfügbar zu machen und historische Daten auf der Benutzungsoberfläche (UI) der realen Benutzerverwaltung anzuzeigen. Diese UI-Daten können für Scott als IT-Analyst nützlich sein, um die Grundursache eines bestimmten Performanceproblems zu finden, das der Benutzer festgestellt hat. Aus den Daten können Scott und Anna (die nach dem Produktivstart als Systemadministrator fungieren) auch analysieren, welche Schritte der Anfragen auf welcher technischen Komponente ausgeführt werden.

Scott ist aufgeregt und stellt fest, dass er bald mit Anna sprechen muss. Er möchte jedoch einige Beispiele dafür erhalten, wie Real User Monitoring bei Dreams ohne Limits verwendet werden kann.

Carl erläutert ein Anwendungsszenario für Real-User-Monitoring:

1. Scott kann die Übersichtsseite verwenden, um Services oder Anforderungsarten mit schlechter Performance zu identifizieren. Dazu bietet diese Seite einen Überblick über die Performance-Metriken für die Services, die im Umfang enthalten sind, indem der Apdex (Application Performance Index) verwendet wird.
2. Dann kann Scott zur Sicht Anforderungen wechseln, um die einzelnen Anwendungen mit schlechter Performance oder hoher Nutzung zu identifizieren.
3. Von dort aus kann er zu den Anfragedetails wechseln, um den Zeitraum zu ermitteln, in dem die einzelnen Anfragen mit schlechter Performance ausgeführt wurden.

4. Schließlich kann Scott den Request-Flow eingeben, um eine Analyse des Einzel-Request-Flows einschließlich aller Komponenten durchzuführen, die an der Ausführung beteiligt sind.

   

Carl fährt fort, dass zusätzlich die Frontend-Übersicht und die Backend-Übersicht die wichtigsten Frontend- (oder Backend-)Nutzungs- und Performance-Metriken enthalten:

Abschließend bemerkt er, dass Scott auch die Sicht Services/Systeme verwenden kann, um den Status verschiedener Anfragearten gruppiert nach Services und Systemen anzuzeigen, um Entitäten zu identifizieren, die eine schlechte Performance aufweisen.