DE112017000881T5

DE112017000881T5 - Identifizieren der Grundursache von einem Problem, das während einer Ausführung einer Anwendung beobachtet wird

Info

Publication number: DE112017000881T5
Application number: DE112017000881.6T
Authority: DE
Inventors: Lewis Karl Cirne; Etan Lightstone; Jason SNELL
Original assignee: New Relic Inc
Current assignee: New Relic Inc
Priority date: 2016-02-18
Filing date: 2017-02-15
Publication date: 2018-10-31
Also published as: WO2017141176A1; US20170242773A1; AU2017220066A1; JP2019507454A; US20200050526A1; US10459818B2; US11169897B2

Abstract

Ein Überwachen von Anfragen an und von Komponenten einer Anwendung erzeugt eine Anwendungsanalyse-Engine einen Interkomponenten-Graph für eine Anwendung, der identifiziert, wie die verschiedenen Komponenten in der Anwendung verbunden sind. Wenn ein Leistungsproblem in Verbindung mit der Anwendung detektiert wird, und ein Traversierungsmodul den Interkomponenten-Graphen traversiert, um sämtliche Ausführungspfade zu bestimmen, welche die Ursache des detektieren Problems hätten sein können. Das Traversierungsmodul übermittelt Anfragen an das Korrelationsmodul, um die Metrikzeitreihen der unterschiedlichen Komponenten in dem Ausführungspfad mit dem detektierten Problem zu vergleichen. Das Korrelationsmodul vergleicht Metrikzeitreihen mit der Problemmetrik, um Korrelationen zwischen Ausführungsmustern zu identifizieren. Die Ergebnisse der Korrelation können in einem Bericht dargestellt werden, welcher die Grundursache des detektierten Problems visuell identifiziert.

Description

Hintergrund
Diese Offenbarung bezieht sich allgemein auf ein Überwachen von Anwendungen und insbesondere auf ein Identifizieren der Grundursache von einem Problem, das während einer Ausführung einer Anwendung beobachtet wird.
In der heutigen komplexen softwareabhängigen Dienstumgebung ist es oft schwierig und zeitraubend die Grundursache eines Problems zu finden, welches Endbenutzer einer Anwendung beeinträchtigt. Typischerweise wird, wenn eine Anwendung überwacht wird, ein großes Volumen von Leistungsdaten für die Anwendung gesammelt. Ein Sichten des überwältigenden Betrags von Daten, um die exakte Ursache von einem Problem zu finden, welches in einer Komponente sein kann, die viele Schichten entfernt von dem in Erscheinung getretenen Problem ist, ist eine zeitraubende und oft in hohem Maße eine manuelle Aufgabe.
Figurenliste

1 veranschaulicht eine Systemumgebung zum Überwachen einer Anwendung gemäß einer Ausführungsform.
2 ist ein Blockdiagramm, das verschiedene Komponenten in dem Überwachungsserver gemäß einer Ausführungsform veranschaulicht.
3 veranschaulicht einen beispielhaften Interkomponenten-Graph, der durch die Anwendungsanalyse-Engine gemäß einer Ausführungsform erzeugt wird.
4 veranschaulicht eine beispielhafte Intrakomponenten-Hierarchie einer einzelnen Komponente Q von 3 gemäß einer Ausführungsform.
5 ist ein Flussdiagramm von Verfahrensschritten zum Bestimmen der Grundursache von einem Problem, das in Verbindung mit einer Anwendung, die ausgeführt wird, detektiert wird, gemäß einer Ausführungsform.
6A und 6B veranschaulichen eine beispielhafte Traversierung durch das Traversierungsmodul des Interkomponenten-Graphs und der Intrakomponenten-Hierarchie gemäß einer Ausführungsform.
7A und 7B veranschaulichen beispielhafte Visualisierungen von Metrikzeitreihen von unterschiedlichen Komponenten der Anwendung und wie diese Metrikzeitreihen mit einem detektierten Problem korreliert sind, gemäß einer Ausführungsform.

Die Figuren bilden verschiedene Ausführungsformen der vorliegenden Offenbarungen lediglich zum Zwecke der Veranschaulichung ab. Ein Fachmann wird aus der nachfolgenden Diskussion sofort erkennen, dass alternative Ausführungsformen der Strukturen und Verfahren, die hierin veranschaulicht sind, angewendet werden können, ohne von den Prinzipien der Offenbarung, die hierin beschrieben sind, abzuweichen.
Zusammenfassung
Durch ein Überwachen von Anfragen an und von Komponenten einer Anwendung erzeugt eine Anwendungsanalyse-Engine einen Interkomponenten-Graph für eine Anwendung, der identifiziert, wie die verschiedenen Komponenten in der Anwendung verbunden sind. Wenn ein Leistungsproblem in Verbindung mit der Anwendung detektiert wird, traversiert ein Traversierungsmodul den Interkomponenten-Graph, um die möglichen Ausführungspfade zu bestimmen, welche die Ursache für das detektierte Problem hätten gewesen sein könnten.
Das Traversierungsmodul überträgt Anfragen an das Korrelationsmodul, um die Metrikzeitreihen der unterschiedlichen Komponenten in dem Ausführungspfad mit dem detektierten Problem zu vergleichen. Insbesondere vergleicht das Korrelationsmodul Metrikzeitreihen mit der Problemmetrik, um Korrelationen zwischen Ausführungsmustern zu identifizieren. Die Ergebnisse der Korrelation können in einem Bericht präsentiert werden, welcher die Grundursache des detektierten Problems visuell identifiziert. Der Bericht kann den Ausführungspfad von dem Niveau identifizieren, wo das Problem zu der Grundursache detektiert wurde.
Detaillierte Beschreibung
1 veranschaulicht eine Systemumgebung zum Überwachen einer Anwendung gemäß einer Ausführungsform. In einer Ausführungsform beinhaltet die Umgebung die Anwendungslaufzeit 110, eine Clientvorrichtung 130 und einen Überwachungsserver 140, der über ein Netzwerk 150 kommuniziert.
Die Clientvorrichtung 130 beinhaltet eine oder mehrere Computervorrichtungen, die sowohl in der Lage sind, eine Benutzereingabe zu empfangen als auch in der Lage sind, Daten über das Netzwerk 150 zu senden und/oder zu empfangen. In einer Ausführungsform ist eine Clientvorrichtung 130 ein herkömmliches Computersystem, wie beispielsweise ein Desktop oder ein Laptop-Computer. Alternativ kann eine Clientvorrichtung 130 eine Vorrichtung sein, die eine Computerfunktionalität aufweist, wie beispielsweise ein persönlicher digitaler Assistent (Personal Digital Assistant, PDA), ein Mobiltelefon, ein Smartphone oder an eine andere geeignete Vorrichtung. Eine Clientvorrichtung 130 ist konfiguriert, um über das Netzwerk 150 zu kommunizieren. In einer Ausführungsform führt eine Clientvorrichtung 130 eine Anwendung aus, welche es einem Benutzer der Clientvorrichtung 130 erlaubt, mit der Anwendungslaufzeit 110 zu interagieren. Zum Beispiel führt eine Clientvorrichtung 130 eine Browser-Anwendung aus, um eine Interaktion zwischen der Clientvorrichtung 130 und der Anwendungslaufzeit 110 über das Netzwerk 150 zu ermöglichen. In einer anderen Ausführungsform interagiert eine Clientvorrichtung 130 mit der Anwendungslaufzeit 110 durch eine Anwendungsprogrammierschnittstelle (Application Programming Interface, API), die auf einem nativen Betriebssystem der Clientvorrichtung 130, wie beispielsweise IOS® oder ANDROID™, ausgeführt wird. Obwohl eine einzelne Clientvorrichtung 31 in 1 gezeigt ist, kann jede Anzahl von Clientvorrichtungen 130 mit der Anwendungslaufzeit 110 über das Netzwerk 150 interagieren.
Die Clientvorrichtung 130 ist konfiguriert, um mit der Anwendungslaufzeit 110 über das Netzwerk 150, welches jede Kombination von einem lokalen Netzwerk und/oder einem Weitverkehrsnetzwerk umfassen kann, unter Verwendung von verdrahteten und/oder drahtlosen Kommunikationssystemen, zu kommunizieren. In einer Ausführungsform verwendet das Netzwerk 150 Standardkommunikationstechnologien und/oder Protokolle. Zum Beispiel beinhaltet das Netzwerk 150 Kommunikationsverbindungen unter Verwendung von Technologien, wie beispielsweise Ethernet, 802.11, Worldwide Interoperability for Microwave Access (WiMAX), 3G, 4G, Code Division Multiple Access (CDMA), Digital Subscriber Line (DSL), usw. Beispiele von Netzwerkprotokollen, die zum Kommunizieren mit dem Netzwerk 150 verwendet werden, beinhalten Multi Protocol Label Switching (MPLS), Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP) und File Transfer Protocol (FTP). Daten, die über das Netzwerk 150 ausgetauscht werden, können unter Verwendung von jedem geeigneten Format dargestellt werden, wie beispielsweise Hypertext Marker Language (HTML) oder Extensible Marker Language (XML). In einigen Ausführungen können alle oder einige der Kommunikationsverbindungen des Netzwerks 150 unter Verwendung von irgendeiner geeigneten Technologie oder Technologien verschlüsselt sein.
Die Anwendungslaufzeit 110 betreibt eine Anwendung 115 und einen Agenten 120. Die Anwendung 115 kann irgendeine von einer Mannigfaltigkeit von Typen von mobilen Anwendungen oder Webanwendungen sein und kann eine Untermenge von Operationen einer Client-Server Anwendung darstellen. Die Anwendung 115, die durch die Anwendungslaufzeit 110 betrieben wird, beinhaltet beliebige serverseitige Prozesse von einer Client-Server Anwendung, wie beispielsweise ein Beziehen und ein Speichern von Datenbankinhalt, ein Erzeugen von Benutzerschnittstellen zum Rendern bei der Clientvorrichtung 130, ein Durchführen von Funktionen, die bei der Clientvorrichtung 130 angefragt werden und ein Kommunizieren von Inhalt an die Clientvorrichtung 130 (zum Beispiel über das Netzwerk 150), während die clientseitigen Prozesse der Anwendung Prozesse wie beispielsweise ein Anzeigen von Inhalt an einen Benutzer und ein Kommunizieren von Anfragen an die Anwendungslaufzeit 110 beinhalten. Die Anwendungslaufzeit 110 dient zum Beispiel als eine Webseite einer Clientvorrichtung 130 zum Anzeigen an einen Benutzer. Obwohl eine einzelne Anwendungslaufzeit 110 in 1 gezeigt ist, kann die Anwendungslaufzeit 110 eine oder mehrere Computervorrichtungen umfassen, welche die Funktionen der Anwendung 115 ausführen, und die Umgebung kann jede Anzahl von Webservern beinhalten, die eine beliebige Anzahl von Anwendungen 115 betreiben.
In einer Ausführungsform ist die Funktionalität der Anwendung 115 in eine oder mehrere Transaktionen quantisiert. Jede Transaktion ist eine Reihe von Anwendungskomponenten, die durch die Anwendungslaufzeit 110 in Antwort auf eine Anfrage ausgeführt werden, welche von einer Clientvorrichtung 130 empfangen wurde. In einer Ausführungsform ist der Start einer Transaktion definiert als eine Zeit, zu welcher die Anwendungslaufzeit 110 eine Anfrage von einer Clientvorrichtung 130 empfängt (zum Beispiel eine Anfrage, einen Teil von einer Webseite zum Anzeigen an die Clientvorrichtung 130 zu senden), während das Ende der Transaktion definiert ist als eine Zeit, zu welcher die Anwendungslaufzeit 110 eine Antwort auf die Anfrage zurückgibt (zum Beispiel die Webseite an die Clientvorrichtung 130 sendet). Das Ende der Transaktion kann eine Zeit sein, zu welcher die Anwendungslaufzeit 110 damit beginnt, die Antwort zusenden, eine Zeit, zu welcher die Anwendungslaufzeit 110 ein Senden der Antwort beendet, oder sie kann anders relativ zu der Antwort definiert sein. In einer anderen Ausführungsform sind der Start und das Ende der Transaktion spezifische Punkte innerhalb der Anwendung 115 und nicht notwendigerweise relativ zu einer Anfrage und einer Antwort definiert.
Jede Komponente der Transaktion wird innerhalb eines Ausführungs-Threads ausgeführt, welcher durch die Anwendungslaufzeit 110 aufrechterhalten wird. Innerhalb jeder Komponente führt die Anwendungslaufzeit 110 ein oder mehrere Verfahren aus. Ein Transaktionsverfahren stellt eine Gruppe von Softwareanweisungen oder Befehlen dar, die zusammen eine diskrete Operation der Anwendung 115 darstellen. Zum Beispiel kann ein Transaktionsverfahren der Anwendung 115 eine Datenbankabfrage sein, während ein anderes Transaktionsverfahren eine Berechnung unter Verwendung der Daten, die von der Datenbank bezogen wurden, durchführt.
Die Anwendungslaufzeit 110 kann die Komponenten asynchron ausführen, so dass mehrere Verfahren gleichzeitig oder während überlappenden Zeitperioden ausgeführt werden können. Einige dieser Verfahren können auch durch andere Verfahren der Transaktion aufgerufen werden oder diese aufrufen. Ein erstes Verfahren, das ein zweites Verfahren der Transaktion aufruft, wird als ein „Parent“ des zweiten Verfahrens bezeichnet, während das zweite Verfahren als ein „Child“ des ersten Verfahrens bezeichnet wird. Als ein Child des erstens Verfahrens wird das zweite Verfahren nicht ausgeführt bis das erste Verfahren das zweite Verfahren aufruft (zum Beispiel nachdem das erste Verfahren abgeschlossen ist), selbst wenn das erste Verfahren innerhalb eines anderen Threads als das zweite Verfahren ausgeführt wird. Einige Verfahren können Komponenten der Transaktion auch blockieren, so dass die Ausführung der Komponente angehalten wird, während das Blockierungsverfahren ausgeführt wird. Eine erste Transaktionskomponente beinhaltet zum Beispiel ein erstes und ein drittes Verfahren und eine zweite Transaktionskomponente beinhaltet ein zweites Verfahren, wobei das erste Verfahren das zweite Verfahren aufruft und das zweite Verfahren das dritte Verfahren aufruft. Während das zweite Verfahren ausgeführt wird, ist die erste Komponente blockiert: auf dem ersten Thread werden keine Verfahren ausgeführt, während das zweite Verfahren ausgeführt wird. Wenn die Ausführung des zweiten Verfahrens abgeschlossen ist, wird das dritte Verfahren auf dem ersten Thread ausgeführt.
Der Agent 120 überwacht die Leistung der Anwendung 115 einschließlich der Prozesse, die auf der Anwendungslaufzeit 110 ausgeführt werden, Antwortzeiten der Anwendung 115, Transaktionen in der Anwendung 115, den Effekt von Backendprozessoren auf die Leistung der Anwendung 115 bei Benutzervorrichtungen und/oder andere Informationen. Der Agent 120 ist ein Satz von Softwaremodulen, die durch die Anwendungslaufzeit 110 zusammen mit der Anwendung 115 ausgeführt werden und er überwacht die Anwendung 115, indem Code in die Anwendung 115 injiziert wird. Der injizierte Code wird durch die Anwendungslaufzeit 110 ausgeführt, wenn ausgewählte Verfahren der Anwendung 115 ausgeführt werden. Die Verfahren, die durch den Agenten 120 überwacht werden, können manuell durch einen Entwickler der Anwendung 115 oder einen Administrator der Anwendung 115 ausgewählt werden, oder sie können automatisch durch den Agenten 120 ausgewählt werden. Der Agent 120 kann zum Beispiel jedes Verfahren der Anwendung 115 überwachen. Wenn ausgeführt, erzeugt der injizierte Code Metriken, die für jedes überwachte Verfahren folgendes spezifizieren: eine Kennung des Verfahrens, eine Dauer der Ausführung des Verfahrens, Children und/oder Parents des Verfahrens und ob das Verfahren irgendeine andere Anwendungskomponente von der Ausführung blockiert.
Der Überwachungsserver 140 überwacht eine Leistung der Anwendungslaufzeit 110. Der Überwachungsserver 140 kann durch einen Anwendungsüberwachungsdienstanbieter gehostet werden und kann eine Leistung von irgendeiner Anzahl von App-Servern überwachen. In einer Ausführungsform wird der Überwachungsserver 140 durch New Relic® Inc. gehostet und führt NEW RELIC® APM aus. Um die Anwendungslaufzeit 110 zu überwachen, stellt der Überwachungsserver 140 der Anwendungslaufzeit 110 den Agenten 120 bereit und empfängt von dem Agenten 120 Daten. Der Überwachungsserver 140 empfängt Berichte von dem Agenten 120 und formatiert Daten in den Berichten zur Analyse durch einen Administrator der Anwendungslaufzeit 110, wodurch es dem Administrator ermöglicht wird, jedwelche Leistungsprobleme in der Anwendung 115 anzugehen.
Der Überwachungsserver 140 erzeugt zum Beispiel Plots, welche Ausführungszeiten von Verfahren auf einem kritischen Pfad in einer Transaktion veranschaulichen. Das Berichten der Ausführungszeit der Verfahren auf dem kritischen Pfad ermöglicht es dem Administrator Verfahren mit langen Ausführungszeiten zu identifizieren und Verfahren zu bestimmen, um darauf zu zielen, die Transaktionszeit zu verringern.
2 ist ein Blockdiagramm, welches verschiedene Komponenten in dem Überwachungsserver 140 gemäß einer Ausführungsform veranschaulicht. Wie gezeigt beinhaltet der Überwachungsserver 140 eine Anwendungsanalyse-Engine 210, einen Interkomponenten-Graph-Speicher 220, einen Intrakomponenten-Hierarchie-Speicher 240, einen Metrik-Speicher 250 und eine Grundursachen-Detektions-Engine 260.
Der Graph-Speicher 220, der Hierarchie-Speicher 240 und der Metrik-Speicher 250 können eine oder mehrere Tabellen, eine oder mehrere relationale Datenbanken und/oder eine oder mehrere multidimensionale Datenwürfel sein oder beinhalten. Ferner, obwohl als eine einzelne Komponente veranschaulicht, kann jeder von dem Graphen-Speicher 220, dem Hierarchie-Speicher 240 und dem Metrik-Speicher 250 eine Vielzahl von Datenbanken, wie beispielsweise ein Datenbank-Cluster sein, welcher auf einer einzelnen Computervorrichtung implementiert sein kann, oder zwischen einer Anzahl von Computervorrichtungen oder Speicherkomponenten verteilt sein kann. Ferner können die verschiedenen Module und Datenspeicher, die in dem Überwachungsserver 140 beinhaltet sind, physisch innerhalb eines Computersystems kollokiert sein oder, alternativ, über mehrere Computersysteme verteilt sein.
Die Anwendungsanalyse-Engine 210 erzeugt Interkomponenten-Graphen für unterschiedliche Anwendungen, die durch den Überwachungsserver 140 überwacht werden, und sie ist ein Mittel um dies so zu tun. Im Betrieb können Anwendungen, wie beispielsweise die Anwendung 115, mehrere Komponenten aufweisen, die in Verbindung miteinander arbeiten. Die Anwendungsanalyse-Engine 210 verfolgt ausgehende und eingehende Anfragen zu jeder dieser Komponenten, um einen Interkomponenten-Graph für eine Anwendung zu erzeugen, der identifiziert, wie die verschiedenen Komponenten verbunden sind.
In einer Ausführungsform fügt der Agent 120 einen Satz von eindeutigen Kopfzeilen zu ausgehenden Hypertext Transfer Protocol (HTTP)-Anfragen von den Komponenten der Anwendung 115, wie beispielsweise Browsen und Backend-Diensten, hinzu. Der Agent 120 überwacht eingehende Anfragen auf anderen Komponenten bezüglich dieser eindeutigen Kopfzeilen. Wenn eine von den eindeutigen Kopfzeilen, die zu einer ausgehenden Anfrage von der Komponente A hinzugefügt wurde, in einer eingehenden Anfrage an die Komponente B identifiziert wird, überträgt der Agent 120 eine Nachricht an die Anwendungsanalyse-Engine 210, die anzeigt, dass die Komponente A mit der nachgeschalteten Komponente B verbunden ist. Die Anwendungsanalyse-Engine 210 verarbeitet diese Nachrichten, um einen Interkomponenten-Graph der Anwendung 115 aufzubauen, der die verschiedenen Verbindungen und die assoziierte Richtung der Verbindung zwischen Komponenten der Anwendung anzeigt. Der Interkomponenten-Graph erstreckt sich von einer auf einen Benutzer gerichteten Komponente, wie beispielsweise ein Browser oder eine Benutzerschnittstelle, zu einer Backendienstkomponente, wie beispielsweise eine Zahlungsverarbeitung und letztlich zu Backendspeicherschichten, wie beispielsweise Cashing und Datenbanken. Die Anwendungsanalyse-Engine 210 speichert die Interkomponenten-Graphen in dem Interkomponenten-Graph-Speicher 220 (hierin auch als der „Graph-Speicher 220“ bezeichnet).
3 veranschaulicht einen beispielhaften Interkomponenten-Graphen, der durch die Anwendungsanalyse-Engine 210 gemäß einer Ausführungsform erzeugt wurde. In dem Interkomponenten-Graph sind die Komponenten, welche mit „W“ markiert sind, Webschnittstellen-Komponenten. Die Komponenten, welche mit „P“ und „Q“ markiert sind, sind Dienste mit Anwendungsprogrammierschnittstellen, welche durch die „W“-Komponenten aufgerufen werden, die Rohdaten an die Datenbanken liefern oder Daten darauf speichern, wobei die Datenbanken als „Backend A“, „Backend B“ und „Backend C“ markiert sind. In einer Ausführungsform kann P eine Benutzerinformationskomponente und Q kann eine Einkaufskatalogkomponente sein. Jede API-Komponente, wie beispielsweise die Komponenten P und Q, weisen oft ihre eigenen Datenspeicher auf. Die Schicht 1, zuoberst auf dem Stapel, stellt Daten, Dienste, Schnittstellen, usw. dar, die Menschen konsumieren können, die Schicht 2, die Mitte des Stapels, stellt Maschinen-Verbrauchsmaterial (oder APIs) dar, und die Schicht 3, zuunterst auf dem Stapel, stellt Speicher und andere Backend-Dienste dar.
Wieder mit Bezug zur 2, die Metriksammel-Engine 230 aggregiert Metriken, die durch den Agenten 120 bei verschiedenen Granularitätsniveaus gesammelt wurden und ist ein Mittel, um dies so zu tun. Der Agent 120 empfängt Metriken für jede Komponente der Anwendung 115 und ferner für jedes Verfahren oder jede Betriebseinheit innerhalb dieser Komponenten. Diese Metriken können die Ausführungsdauer beinhalten, die in Zeiteinheiten gemessen wurde, und jeden Fehler, welcher während einer Ausführung aufgetreten ist. Die Metriksammel-Engine 230 aggregiert die Metriken, um zu bestimmen, welche Verfahren in einer Komponente während einer Transaktion aufgerufen wurden, um die Anzahl zu bestimmen, wie oft jedes Verfahren aufgerufen wurde, und um die Gesamtdauer von jedem Verfahren zu bestimmen, wenn es ausgeführt wurde. Der Agent 120 kann auch eine exklusive Ausführungszeit von jedem Verfahren bestimmen, das eines oder mehrere Children aufweist, welches den Zeitbetrag des ausgeführten Parent-Verfahrens darstellt, ohne die Ausführungszeit der Child-Verfahren oder den Zeitbetrag des Parent-Verfahrens zu betrachten, während dieses blockiert war, während die Child-Verfahren ausgeführt wurden.
Die Metriksammel-Engine 230 aggregiert die empfangenen Metriken, um Metrikzeitreihen für jede Komponente und Subkomponente der Anwendung 150 zu erzeugen. Eine Metrikzeitreihe spezifiziert, für eine gegebene Metrik, den Wert der Metrik für die assoziierte Komponente/Subkomponente zu vorbestimmten Zeitintervallen. Die Metriksammel-Engine 230 speichert die Metrikzeitreihe in dem Metrikspeicher 250. Die Metriksammel-Engine 230 erzeugt auch eine Intrakomponenten-Hierarchie für jede Komponente der Anwendung 115. Insbesondere identifiziert die Intrakomponenten-Hierarchie für eine Komponente, wie die verschiedenen Betriebseinheiten, zum Beispiel Verfahren, Datenspeicherdienste, usw., in der Komponente verbunden sind. Die Metriksammel-Engine 230 speichert die Intrakomponenten-Hierarchien in dem Intrakomponenten-Hierarchiespeicher 240.
4 veranschaulicht eine beispielhafte Intrakomponenten-Hierarchie von einer einzelnen Komponente Q von 3 gemäß einer Ausführungsform. In der Intrakomponenten-Hierarchie beinhaltet die Komponente Q viele Betriebseinheiten 402 auf oberstem Niveau einschließlich „externe Dienste“, „Datenspeicherdienste“ und einen „HTTP-Dispatcher“. Die Betriebseinheiten 402 auf oberstem Niveau weisen ferner oft Betriebseinheiten auf niedrigerem Niveau auf, die durch die Metriksammel-Engine 230 identifiziert werden. In der Veranschaulichung sind zum Beispiel die „externen Dienste“ ferner zusammengesetzt aus einem „Katalogdienst“, einem „Benutzerdienst“, einem „Kontodienst“ und einem „Benutzerdatenspeicher“. Die Intrakomponenten-Hierarchie erfasst die Beziehungen unter den Betriebseinheiten 402 auf obersten Niveau und den Betriebseinheiten 404 auf dem niedrigeren Niveau.
Wieder mit Bezug zu 2, die Grundursachen-Detektions-Engine 260 detektiert Probleme, die während der Ausführung der Anwendung 115 aufgetreten sind und bestimmt probabilistisch die Grundursache dieser Probleme, und sie ist ein Mittel um dies so zu tun. Die Grundursachen-Detektions-Engine 260 beinhaltet ein Problem-Detektions-Modul 262, ein Traversierungsmodul 264, ein Korrelationsmodul 266, und ein Berichtsmodul 268.
Das Problem-Detektions-Modul 262 überwacht Metriken, die in dem Metrikspeicher 250 gespeichert sind, um potentielle Probleme mit der Ausführung der Anwendung 115 zu identifizieren, und es ist ein Mittel, um dies so zu tun. Ein Problem kann detektiert werden, wenn eine Metrik einen Schwellwert überschreitet, der in dem Problem-Detektions-Modul 262 definiert ist. Der Schwellwert kann ein konfigurierbarer Schwellwert sein, der basierend auf einer historischen Leistung der Anwendung und/oder von Komponenten der Anwendung bestimmt wird. In einer Ausführungsform detektiert das Problem-Detektions-Modul 262 ein Problem, wenn eine Ausführungszeit der Anwendung oder einer Komponente einer Anwendung einen Schwellwert überschreitet. In einer anderen Ausführungsform detektiert das Problem-Detektions-Modul 262 ein Problem, wenn die Anzahl von Fehlern, die während einer gegebenen Ausführungszeit der Anwendung oder einer Komponente der Anwendung aufgetreten ist, einen Schwellwert überschreitet. Wenn das Problem-Detektions-Modul 262 ein Problem detektiert, löst das Problem-Detektions-Modul 262 einen Alarm an das Traversierungs-Modul 264 aus. Der Alarm identifiziert die Anwendung und/oder die Komponente der Anwendung, für welche das Problem detektiert wurde.
Das Traversierungs-Modul 264 traversiert den Interkomponenten-Graph und Intrakomponenten-Hierarchien, die mit der Anwendung assoziiert sind, um die Grundursache des Problems zu identifizieren, welches durch das Problem-Detektions-Modul 262 detektiert wurde, und es ist ein Mittel, um dies so zu tun. Im Betrieb horcht das Traversierungs-Modul 264 nach Alarmen, die durch das Problem-Detektions-Modul 262 ausgelöst wurden. Wenn ein Alarm ausgelöst wurde, identifiziert das Traversierungs-Modul 264 die Anwendung, für welche das Problem detektiert wurde und bezieht den Interkomponenten-Graphen und die Intrakomponenten-Hierarchien, die mit der Anwendung assoziiert sind von dem Graph-Speicher 220 und dem Hierarchie-Speicher 240. Für ein gegebenes Problem traversiert das Traversierungsmodul 264 den Interkomponenten-Graphen und die Intrakomponenten-Hierarchien, um die möglichen Ausführungspfade zu bestimmen, welche die Ursache des detektierten Problems hätten gewesen sein können. Das Traversierungs-Modul 264 überträgt Anfragen an das Korrelations-Modul 266, um die Metrikzeitreihen der unterschiedlichen Komponenten in dem Ausführungspfad mit dem detektierten Problem zu vergleichen. In einer Ausführungsform ruft das Traversierungs-Modul 264 Metrikzeitreihen der Komponenten und Subkomponenten, die in dem Ausführungspfad identifiziert sind, basierend auf den Ergebnissen des Vergleichs durch das Korrelationsmodul 266, iterativ ab.
Das Korrelationsmodul 266 vergleicht Metrikzeitreihen mit der Problemmetrik, um Korrelationen zwischen Ausführungsmustern zu identifizieren, und es ist ein Mittel, um dies so zu tun. In einer Ausführungsform wird der Pearson-Produktmoment-Korrelationskoeffizient verwendet, um diese zwei Zeitreihen zu vergleichen. Es sei angenommen, dass die Problem-Antwortdauer-Metrikzeitreihe der Datensatz {x1, ..., xn}, der n Werte enthält, und eine mögliche Subkomponentendauer-Metrikzeitreihe der Datensatz {y₁, ..., yn} sei, der auch n Werte enthält. Die Formel für den Korrelationskoeffizienten r ist definiert als: $r = r_{x y} = \frac{\sum_{i = 1}^{n} (x_{i} - \bar{x}) (y_{i} - \bar{y})}{\sqrt{\sum_{i = 1}^{n} {(x_{i} - \bar{x})}^{2}} \sqrt{\sum_{i = 1}^{n} {(y_{i} - \bar{y})}^{2}}}$
wobei x und y jeweilige Abtastmittel sind. Ein r-Wert von 1,0 repräsentiert eine perfekte Korrelation, 0,0 repräsentiert keine Korrelation und -1,0 repräsentiert eine perfekte negative Korrelation. Dieselbe Gleichung kann auf Fehlerratenmetriken angewendet werden, indem die Dauer-Metrikzeitreihen mit der Anzahl von Fehlern, die pro Zeiteinheit beobachtet werden, ersetzt werden. Wenn eine Subkomponente eine hohe Korrelation mit der Problemmetrik liefert, wiederholt sich der Algorithmus indem die Korrelationen zwischen den Children der Subkomponente und der Problemmetrik berechnet wird.
Das Berichtsmodul 268 erzeugt Berichte für Administratoren der Anwendung 115, welche die Grundursache des detektierten Problems visuell identifizieren, und es ist ein Mittel, um dies so zu tun. Diese Berichte können den Ausführungspfad von dem Niveau, wo das Problem detektiert wurde, zu der Grundursache identifizieren. Die Berichte können auch ein Vertrauensniveau spezifizieren, das die identifizierte Grundursache tatsächlich die Grundursache des Problems ist.
5 ist ein Flussdiagramm von Verfahrensschritten zum Bestimmen der Grundursache von einem Problem, das in Verbindung mit einer ausführenden Anwendung gemäß einer Ausführungsform detektiert wurde. Andere Ausführungsformen können die Schritte des Verfahrens, welches in der 5 veranschaulicht ist, in unterschiedlichen Reihenfolgen durchführen und können unterschiedliche, zusätzliche und/oder wenige Schritte beinhalten. Der Prozess kann durch jede geeignete Entität, wie beispielsweise die Grundursachendetektions-Engine 260 durchgeführt werden.
Die Grundursachendetektions-Engine 260 bestimmt 502, dass ein Problem in Verbindung mit einer Anwendung während einer Laufzeit detektiert wurde. In einer Ausführungsform kann ein Problem detektiert werden, wenn eine Metrik mit Bezug zu der Leistung der Anwendung einen Schwellwert überschreitet, der in der Grundursachen-detektions-Engine 260 definiert ist. Der Schwellwert kann ein konfigurierbarer Schwellwert sein, der basierend auf einer historischen Leistung der Anwendung und/oder von Komponenten der Anwendung bestimmt wird.
Die Grundursachendetektions-Engine 260 ruft 504 von dem Metrik-Speicher 250 Metrikzeitreihen ab, die mit der Anwendung assoziiert sind, für welche das Problem detektiert wurde (bezeichnet als „die Anwendungsmetrikzeitreihe“). Die Anwendungsmetrikzeitreihe zeigt den Wert einer gegebenen Metrik zu verschiedenen Zeitpunkten an. Die Antwortzeitmetrikzeitreihe zeigt zum Beispiel die Anwendungsantwortzeit zu verschiedenen Zeitpunkten an. In einer Ausführungsform manifestiert sich das detektierte Problem typischerweise als eine Aberration in der Metrikzeitreihe, die mit der Anwendung assoziiert ist.
Die Grundursachendetektions-Engine 260 bezieht 506 Metrikzeitreihen auf oberstem Niveau, die mit Komponenten der Anwendung assoziiert sind, für welche das Problem detektiert wurde. Die Grundursachendetektions-Engine 260 analysiert insbesondere den Interkomponenten-Graphen, der mit der Anwendung assoziiert ist, um Komponenten auf oberstem Niveau der Anwendung zu bestimmen, welchen das Problem zugeordnet werden kann. Wie oben diskutiert identifiziert der Interkomponenten-Graph für eine Anwendung, wie verschiedene Komponente in der Anwendung verbunden sind.
Die Grundursachendetektions-Engine 260 korreliert 508 die Anwendungsmetrikzeitreihen der Anwendung mit den Metrikzeitreihen auf oberstem Niveau, die mit Komponenten der Anwendung assoziiert sind. Die Grundursachendetektions-Engine 260 wählt 510 die Komponenten, welche eine Metrikzeitreihe auf oberstem Niveau aufweisen, welche die höchste Korrelation mit der Anwendungsmetrikzeitreihe aufweisen.
Die Grundursachendetektions-Engine 260 ruft 512 von dem Metrik-Speicher 250 Metrikzeitreihen auf niedrigerem Niveau ab, die mit der ausgewählten Komponente assoziiert sind. Die Ursachendetektions-Engine 260 analysiert insbesondere die Intrakomponenten-Hierarchie, die mit der ausgewählten Komponente assoziiert ist, um Betriebseinheiten der Anwendung zu bestimmen, welchen das Problem zugeordnet werden kann. Wie oben diskutiert, identifiziert die Intrakomponenten-Hierarchie für eine Komponente, wie verschiedene Betriebseinheiten, zum Beispiel Verfahren, Datenspeicherdienste, usw., in der Komponente verbunden sind.
Die Grundursachendetektions-Engine 216 korreliert 514 die Anwendungsmetrikzeitreihe der Anwendung mit den Metrikzeitreihen auf niedrigerem Niveau, die mit den Betriebseinheiten der ausgewählten Komponente assoziiert sind. Die Grundursachendetektions-Engine 260 identifiziert 516 die Betriebseinheit als die Grundursache, welche eine Metrikzeitreihe auf niedrigerem Niveau aufweist, welche die höchste Korrelation mit der Anwendungsmetrikzeitreihe aufweist.
In einer Ausführungsform kann eine Betriebseinheit der Komponente eine Anwendung sein, die mit ihrem eigenen Interkomponenten-Graph und ihren eigenen Intrakomponenten-Hierarchien assoziiert ist. In solch einer Ausführungsform führt die Grundursachendetektion-Engine 260 die Schritte 506 bis 514 iterativ aus, bis eine Grundursache identifiziert ist. Ferner, wenn eine Metrikzeitreihe auf oberstem Niveau oder auf niedrigerem Niveau nicht mit der Anwendungsmetrikzeitreihe korreliert werden kann, dann kann die Grundursachendetektions-Engine 260 nach Korrelationen zwischen Metrikzeitreihen suchen, die mit Webtransaktionen, Datenspeichern oder anderen Betriebskomponenten und Abhängigkeiten von der Anwendung assoziiert sind.
Die 6A und 6B veranschaulichen eine beispielhafte Traversierung durch das Traversierungsmodul 264 des Interkomponenten-Graphs und der Intrakomponenten-Hierarchie gemäß einer Ausführungsform. Im Speziellen veranschaulicht die Traversierung, die in den 6A und 6B veranschaulicht ist, die unterschiedlichen Ausführungspfade, die veranlassen können, dass ein Problem bei der Komponente 602 detektiert wird, welches als „W“ markiert ist. Das Traversierungsmodul 264 traversiert den Interkomponenten-Graphen, welcher durch die Anwendungsanalyse-Engine 210 erzeugt wurde, iterativ, um einen Satz von Komponenten auf niedrigeren Schichten des Anwendungsstapels zu identifizieren, die mit der Komponente 602 verbunden sind. Der Satz von Komponenten beinhaltet die drei „Q“-Komponenten auf der Schicht 2 des Anwendungsstapels und die Backend „C“-Komponente auf der Schicht 3 des Stapels. Die Grundursachendetektions-Engine 260 bezieht Metrikzeitreihen auf oberstem Niveau, die mit Komponenten in dem Satz von Komponenten assoziiert sind. In dem veranschaulichten Beispiel korreliert die Grundursachendetektions-Engine 260 die Metrikzeitreihe der Komponente 602 mit den Metrikzeitreihen auf oberstem Niveau, die mit den Komponenten in dem Satz assoziiert sind, und wählt eine Komponente 604 als die Komponente, welche eine Metrikzeitreihe auf oberstem Niveau mit der höchsten Korrelation mit den Metrikzeitreihen aufweist.
Wie in 6B gezeigt beinhaltet die Komponente Q viele Betriebseinheiten auf oberstem Niveau einschließlich „externe Dienste“, „Datenspeicherdienste“ und einen „HTTP-Dispatcher“. Die Grundursachendetektions-Engine 260 bezieht iterativ Metrikzeitreihen auf niedrigerem Niveau, die mit Komponenten der Betriebseinheiten assoziiert sind. Die Grundursachendetektions-Engine 260 korreliert die Metrikzeitreihen von der 604 mit den Metrikzeitreihen auf niedrigerem Niveau, die mit den Betriebseinheiten assoziiert sind, und wählt die Betriebseinheit, welche eine Metrikzeitreihe auf oberstem Niveau mit der höchsten Korrelation mit den Metrikzeitreihen aufweist als die Grundursache des Problems. In dem veranschaulichten Beispiel bestimmt die Grundursachendetektions-Engine 260, dass der Benutzerdatenspeicher 602 die Grundursache des Problems ist.
Die 7A und 7B veranschaulichen beispielhafte Visualisierungen von Metrikzeitreihen von unterschiedlichen Komponenten der Anwendung 115 und wie diese Metrikzeitreihen mit einer Problemmetrik gemäß einer Ausführungsform assoziiert sind. Die Visualisierung 701 der Metrikzeitreihen zeigt eine Anomalie in den Werten der Metrik um 10:30 Uhr. Solch eine Anomalie wird einem Problem 702 in der Leistung der Anwendung zugeordnet. Die Visualisierung 704 bis 712 stellen verschiedene Metrikzeitreihen dar, die mit Komponenten und Subkomponenten der Anwendung 115 assoziiert sind. Wie in der Visualisierung 708 gezeigt, kann das detektierte Problem 702 mit der Datenbankleistung korreliert sein. Die Grundursachendetektions-Engine 260 evaluiert die Zeitreihen, die mit den Subkomponenten der Datenbank assoziiert sind, um eine Transaktion A zu identifizieren, die durch die Zeitreihe 712 als die Grundursache des Problems 702 dargestellt wird.
Die vorhergehende Beschreibung der Ausführungsformen der Offenbarung wurde zum Zwecke der Veranschaulichung präsentiert; es ist nicht beabsichtigt abschließend zu sein oder die Offenbarung auf die präzisen offenbarten Formen zu begrenzen. Ein Fachmann wird anerkennen, dass viele Modifikationen und Variationen im Lichte der obigen Offenbarung möglich sind.
Einige Teile diese Beschreibung beschreiben die Ausführungsformen der Offenbarung mit Bezug zu Algorithmen und symbolischen Darstellungen von Operationen auf Informationen. Diese algorithmischen Beschreibungen und Darstellungen werden gewöhnlich durch Fachleute in der Kunst der Datenverarbeitung verwendet, um den Gehalt ihrer Arbeit effektiv anderen Fachleuten zu vermitteln. Diese Operationen, während sie funktional, rechnerisch oder logisch beschrieben sind, werden verstanden, als wären sie in Computerprogrammen oder äquivalenten elektrischen Schaltungen, in Mikrocode oder dergleichen implementiert. Weiterhin hat es sich zuweilen auch als bequem erwiesen, diese Anordnungen von Operationen als Module zu bezeichnen, ohne die Allgemeinheit zu beschränken. Die beschriebenen Operationen und ihre assoziierten Module können in Software, in Firmware, in Hardware oder irgendeiner Kombination davon verkörpert sein.
Jeder oder jede der Schritte, Operationen oder Prozesse, die hierin beschriebenen sind, können mit einem oder mit mehreren Hardware- oder Softwaremodulen durchgeführt oder implementiert sein, alleine oder in Kombination mit anderen Vorrichtungen. In einer Ausführungsform ist ein Softwaremodul mit einem Computerprogrammprodukt implementiert, welches ein computerlesbares Medium umfasst, welches Computerprogrammcode enthält, welcher durch einen Computerprozessor vom Durchführen von irgendeinem oder allen von den Schritten, Operationen oder beschriebenen Prozessen ausgeführt werden kann.
Ausführungsformen der Offenbarung können sich auch auf eine Vorrichtung zum Durchführen der hierin beschriebenen Operationen beziehen. Diese Vorrichtung kann speziell für die erforderten Zwecke konstruiert sein oder sie kann eine Computervorrichtung für allgemeine Zwecke umfassen, die wahlweise aktiviert oder durch ein Computerprogramm, das in dem Computer gespeichert ist, rekonfiguriert werden kann. Solch ein Computerprogramm kann in einem nichtflüchtigen computerlesbaren Speichermedium oder irgendeinem Typ von Medium, der zum Speichern von elektronischen Anweisungen geeignet ist und an ein Computersystem-Bus gekoppelt ist, gespeichert sein. Weiterhin kann jedes Computersystem, auf welches die vorliegende Spezifikation Bezug genommen hat, einen einzelnen Prozessor beinhalten oder kann Architekturen beinhalten, welche mehrere Prozessordesigns für erhöhte Rechenfähigkeiten anwenden.
Ausführungsformen der Offenbarung können sich auf ein Computerdatensignal beziehen, welches in einer Trägerwelle verkörpert ist, wobei das Computerdatensignal irgendeine Ausführungsform von einem Computerprogrammprodukt oder anderen Datenkombinationen, die hierin beschrieben werden, beinhaltet. Das Computerdatensignal ist ein Produkt, das in einem nichtflüchtigen Medium oder einer Trägerwelle dargestellt ist und moduliert ist oder anderweitig in der Trägerwelle codiert ist, welche nichtflüchtig ist und gemäß jedem geeigneten Übertragungsverfahren übertragen werden kann.
Letztlich wurde die in dieser Spezifikation verwendete Sprache vornehmlich zum Zwecke der Lesbarkeit und der Unterrichtung ausgewählt und sie könnte nicht ausgewählt worden sein, um den erfinderischen Gegenstand zu skizzieren oder zu umschreiben. Es ist daher beabsichtigt, dass der Umfang der Offenbarung nicht durch die detaillierte Beschreibung begrenzt ist, sondern vielmehr durch alle Ansprüche, die auf der Basis der Anwendung ausgegeben wurden. Demgemäß trägt die Offenbarung der Ausführungsformen der Offenbarung die Absicht in sich veranschaulichend aber nicht begrenzend für den Umfang der Erfindung zu sein.

Claims

Verfahren zum Identifizieren einer Grundursache eines Ausführungsproblems mit Bezug zu einer Softwareanwendung, das Verfahren umfassend: Identifizieren einer Verschlechterung einer Leistungsmetrik in einer gegebenen Zeitperiode während einer Ausführung einer Softwareanwendung, wobei die Softwareanwendung mit einem Anwendungsstapel assoziiert ist, der eine Vielzahl von hierarchisch organisierten Schichten aufweist, die jede eine oder mehrere Komponenten beinhaltet; Traversieren eines Interkomponenten-Graphs, der der Softwareanwendung entspricht, um eine Hierarchie von Komponenten zu identifizieren, die während der Ausführung instanziiert waren, wobei der Interkomponenten-Graph Verbindungen zwischen unterschiedlichen Komponenten der Softwareanwendung darstellt, wobei die Hierarchie von Komponenten eine erste Komponente und eine zweite Komponente in einer ersten Schicht des Anwendungsstapels beinhaltet; Korrelieren der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen, die mit jeder von der ersten Komponente und der zweiten Komponente assoziiert sind, wobei die Metrikzeitreihen jede, für eine gegebene Metrik, einen oder mehrere Werte der Metrik für die assoziierte Komponente während der Zeitperiode spezifizieren; Auswählen der ersten Komponente als Ursache der Verschlechterung der Leistungsmetrik basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen; und Berichten der ersten Komponente als die Ursache der Verschlechterung der Leistungsmetrik.
Verfahren nach Anspruch 1, wobei die Verschlechterung ein Ausführungsproblem anzeigt, welches während einer Laufzeit der Softwareanwendung auftritt.
Verfahren nach Anspruch 1, wobei das Verfahren ferner ein Überwachen von Anfragen umfasst, welche von den unterschiedlichen Komponenten der Softwareanwendung herrühren, um den Interkomponenten-Graphen aufzubauen.
Verfahren nach Anspruch 1, wobei die Verschlechterung der Leistungsmetrik als eine Ausführungszeitreihe dargestellt wird und wobei die Korrelation der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen ein Vergleichen von Werten in der Ausführungszeitreihe mit Werten der Metrikzeitreihen umfasst.
Verfahren nach Anspruch 1, wobei das Verfahren ferner ein Traversieren eines Intrakomponenten-Graphs umfasst, welcher der ersten Komponente entspricht, um eine Hierarchie von Subkomponenten zu identifizieren, die während der Ausführung instanziiert worden sind, wobei der Intrakomponenten-Graph Verbindungen zwischen unterschiedlichen Subkomponenten der ersten Komponente darstellt, wobei die Hierarchie von Komponenten eine erste Subkomponente und eine zweite Subkomponente der ersten Komponente beinhaltet.
Verfahren nach Anspruch 5, ferner umfassend: Korrelieren der Verschlechterung der Leistungsmetrik mit Metrikzeitreihen auf niedrigerem Niveau, die mit jeder von der ersten Subkomponente und der zweiten Subkomponente assoziiert sind, wobei die Metrikzeitreihen auf niedrigerem Niveau jede, für eine gegebene Metrik auf niedrigerem Niveau, einen oder mehrere Werte der Metrik auf niedrigerem Niveau für die assoziierte Subkomponente während der Zeitperiode spezifizieren; und Auswählen der ersten Subkomponente als eine Grundursache der Verschlechterung der Leistungsmetrik basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen auf niedrigerem Niveau.
Verfahren nach Anspruch 1, wobei die Hierarchie von Komponenten eine dritte Komponente und eine vierte Komponente in einer zweiten Schicht des Anwendungsstapels beinhaltet, die jede mit der ersten Komponente verbunden ist.
Verfahren nach Anspruch 7, wobei des Verfahren ferner ein Korrelieren der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen, die mit jeder von der dritten Komponente und der vierten Komponente assoziiert sind, umfasst, wobei die Metrikzeitreihen jede, für eine gegebene Metrik, einen oder mehrere Werte der Metrik für die assoziierte Komponente, während der Zeitperiode, spezifizieren, und Auswählen der dritten Komponente als eine Ursache der Verschlechterung der Leistungsmetrik auf niedrigerem Niveau basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen, die mit jeder von der dritten Komponente und der vierten Komponente assoziiert sind.
Verfahren nach Anspruch 7, wobei die erste Schicht des Anwendungsstapels eine Benutzerschnittstellenschicht des Anwendungsstapels ist und die zweite Schicht des Anwendungsstapels eine Anwendungsprogrammierschnittstelle ist.
Verfahren nach Anspruch 1, wobei das Berichten der ersten Komponente das Veranschaulichen eines Graphen umfasst, welcher die Verschlechterung der Leistungsmetrik darstellt, und eines zweiten Graphen, welcher die Metrikzeitreihe veranschaulicht, welche mit der ersten Komponente assoziiert ist.
Computerprogrammprodukt zum Speichern von Anweisungen zum Identifizieren einer Grundursache eines Ausführungsproblems mit Bezug zu einer Softwareanwendung, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen zum: Identifizieren einer Verschlechterung einer Leistungsmetrik in einer gegebenen Zeitperiode während einer Ausführung einer Softwareanwendung, wobei die Softwareanwendung mit einem Anwendungsstapel assoziiert ist, der eine Vielzahl von hierarchisch organisierten Schichten aufweist, die jede eine oder mehrere Komponenten beinhaltet; Traversieren eines Interkomponenten-Graphs, der der Softwareanwendung entspricht, um eine Hierarchie von Komponenten zu identifizieren, die während der Ausführung instanziiert waren, wobei der Interkomponenten-Graph Verbindungen zwischen unterschiedlichen Komponenten der Softwareanwendung darstellt, wobei die Hierarchie von Komponenten eine erste Komponente und eine zweite Komponente in einer ersten Schicht des Anwendungsstapels beinhaltet; Korrelieren der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen, die mit jeder von der ersten Komponente und der zweiten Komponente assoziiert sind, wobei die Metrikzeitreihen jede, für eine gegebene Metrik, einen oder mehrere Werte der Metrik für die assoziierte Komponente während der Zeitperiode spezifizieren; Auswählen der ersten Komponente als Ursache der Verschlechterung der Leistungsmetrik basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen; und Berichten der ersten Komponente als die Ursache der Verschlechterung der Leistungsmetrik.
Computerprogrammprodukt nach Anspruch 11, wobei die Verschlechterung ein Ausführungsproblem anzeigt, welches während einer Laufzeit der Softwareanwendung auftritt.
Computerprogrammprodukt nach Anspruch 11, wobei das Computerprogrammprodukt ferner ein Überwachen von Anfragen umfasst, welche von den unterschiedlichen Komponenten der Softwareanwendung herrühren, um den Interkomponenten-Graphen aufzubauen.
Computerprogrammprodukt nach Anspruch 11, wobei die Verschlechterung der Leistungsmetrik als eine Ausführungszeitreihe dargestellt wird und wobei die Korrelation der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen ein Vergleichen von Werten in der Ausführungszeitreihe mit Werten der Metrikzeitreihen umfasst.
Computerprogrammprodukt nach Anspruch 11, wobei das Verfahren ferner ein Traversieren eines Intrakomponenten-Graphs umfasst, welcher der ersten Komponente entspricht, um eine Hierarchie von Subkomponenten zu identifizieren, die während der Ausführung instanziiert worden sind, wobei der Intrakomponenten-Graph Verbindungen zwischen unterschiedlichen Subkomponenten der ersten Komponente darstellt, wobei die Hierarchie von Komponenten eine erste Subkomponente und eine zweite Subkomponente der ersten Komponente beinhaltet.
Computerprogrammprodukt nach Anspruch 15, wobei das Computerprogrammprodukt ferner umfasst: Korrelieren der Verschlechterung der Leistungsmetrik mit Metrikzeitreihen auf niedrigerem Niveau, die mit jeder von der ersten Subkomponente und der zweiten Subkomponente assoziiert sind, wobei die Metrikzeitreihen auf niedrigerem Niveau jede, für eine gegebene Metrik auf niedrigerem Niveau, einen oder mehrere Werte der Metrik auf niedrigerem Niveau für die assoziierte Subkomponente während der Zeitperiode spezifizieren; und Auswählen der ersten Subkomponente als eine Grundursache der Verschlechterung der Leistungsmetrik basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen auf niedrigerem Niveau.
Computerprogrammprodukt nach Anspruch 11, wobei die Hierarchie von Komponenten eine dritte Komponente und eine vierte Komponente in einer zweiten Schicht des Anwendungsstapels beinhaltet, die jede mit der ersten Komponente verbunden ist.
Computerprogrammprodukt nach Anspruch 17, wobei des Computerprogrammprodukt ferner ein Korrelieren der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen, die mit jeder von der dritten Komponente und der vierten Komponente assoziiert sind, umfasst, wobei die Metrikzeitreihen jede, für eine gegebene Metrik, einen oder mehrere Werte der Metrik für die assoziierte Komponente während der Zeitperiode spezifizieren, und Auswählen der dritten Komponente als eine Ursache der Verschlechterung der Leistungsmetrik auf niedrigerem Niveau basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen, die mit jeder von der dritten Komponente und der vierten Komponente assoziiert sind.
Computerprogrammprodukt nach Anspruch 17, wobei die erste Schicht des Anwendungsstapels eine Benutzerschnittstellenschicht des Anwendungsstapels ist und die zweite Schicht des Anwendungsstapels eine Anwendungsprogrammierschnittstelle ist.
Computersystem, umfassend: einen Speicher, der Anweisungen speichert; und einen Prozessor, der konfiguriert ist, um die Anweisungen auszuführen zum: Identifizieren einer Verschlechterung einer Leistungsmetrik in einer gegebenen Zeitperiode während einer Ausführung einer Softwareanwendung, wobei die Softwareanwendung mit einem Anwendungsstapel assoziiert ist, der eine Vielzahl von hierarchisch organisierten Schichten aufweist, die jede eine oder mehrere Komponenten beinhaltet; Traversieren eines Interkomponenten-Graphs, der der Softwareanwendung entspricht, um eine Hierarchie von Komponenten zu identifizieren, die während der Ausführung instanziiert waren, wobei der Interkomponenten-Graph Verbindungen zwischen unterschiedlichen Komponenten der Softwareanwendung darstellt, wobei die Hierarchie von Komponenten eine erste Komponente und eine zweite Komponente in einer ersten Schicht des Anwendungsstapels beinhaltet; Korrelieren der Verschlechterung der Leistungsmetrik mit den Metrikzeitreihen, die mit jeder von der ersten Komponente und der zweiten Komponente assoziiert sind, wobei die Metrikzeitreihen jede, für eine gegebene Metrik, einen oder mehrere Werte der Metrik für die assoziierte Komponente während der Zeitperiode spezifizieren; Auswählen der ersten Komponente als Ursache der Verschlechterung der Leistungsmetrik basierend auf der Korrelation zwischen der Verschlechterung der Leistungsmetrik und den Metrikzeitreihen; und Berichten der ersten Komponente als die Ursache der Verschlechterung der Leistungsmetrik.