-
GEBIET DER ERFINDUNG
-
Diese Erfindung betrifft ein Verfahren und ein System zum Überwachen von Anforderungen an einen Codesatz.
-
HINTERGRUND
-
In vielen Datenverarbeitungsumgebungen kann durch einen Computer eine sehr große Anzahl von Anweisungen in einem kurzen Zeitraum abgewickelt werden. Zum Beispiel wird ein Server, der eine Webseite für ein großes Unternehmen, wie beispielsweise eine Bank, betreibt, jede Sekunde eine sehr große Anzahl von Anforderungen und Transaktionen abwickeln, die sich oftmals auf tausende pro Sekunde belaufen. Solch ein Datenverarbeitungssystem muss eine sehr komplexe Software ausführen, um akzeptable Sicherheits- und Belastungsniveaus aufrechtzuerhalten. In solch einer komplexen Datenverarbeitungsumgebung ist eine Fehlererkennung und -Überwachung von höchster Wichtigkeit. Viele unterschiedliche Techniken werden in solchen Umgebungen verwendet, von denen eine als Ablaufverfolgen (Trace) bekannt ist.
-
In der Softwareentwicklung handelt es sich bei „Tracing“ um einen spezialisierten Typ von Protokollieren, um Informationen über ein Ausführen eines Programms aufzuzeichnen. Diese Informationen können durch Programmierer für Fehlerbeseitigungszwecke und zusätzlich, abhängig von dem in einem Trace-Protokoll enthaltenen Informationstyp und - detail, durch erfahrene Systemadministratoren oder Personal eines technischen Supports und Softwareüberwachungswerkzeuge verwendet werden, um allgemeine Probleme bei der Software zu diagnostizieren. Mehr Informationen siehe zum Beispiel en.wikipedia.org/wiki/Tracing (software).
-
In einer Umgebung mit großen Datenmengen (big data), in der viele Anforderungen an einen Server gerichtet werden, ist es oftmals unpraktisch, Trace zu aktivieren, um ein Problem zu erfassen. Trace kann viele Gigabyte an Daten erzeugen, weil so viele Transaktionen oder Anforderungen parallel ausgeführt werden. Support der Ebene 3 (der höchsten Ebene von Support in einem dreischichtigen Modell für Technischen Support, die für ein Abwickeln der schwierigsten oder hochentwickeltsten Probleme zuständig ist) muss jedoch oftmals Trace verwenden, um herauszufinden, warum ein Problem aufgetreten ist. Solch eine Umgebung könnte die IBM MQ Messagesight Appliance, die viele tausende von Anforderungen parallel abwickelt, oder der IBM CICS Transaction Server sein, der tausende von Transaktionen pro Sekunde abwickelt. (IBM und CICS sind eingetragene Marken der International Business Machines Corporation in vielen Rechtsprechungsgebieten).
-
In diesem Zusammenhang sind bereits Dokumente veröffentlicht worden. Das Dokument
US 2009 / 0 320 021 A1 beschreibt ein Event-Verfolgungssystem um Kerngründe für Anomalien von Applikationen herauszufinden. Dabei werden Traces von System-Events bei Inter-Thread-Interaktionen gesammelt, aus denen dann Inter-Thread-Abhängigkeitsmuster gebildet und untersucht werden.
-
Das Dokument
US 2010 / 0 083 237 A1 beschreibt zusätzlich ein Verfahren zum Kompilieren von Computerprogrammen, um eine Trace-Effizient zu verbessern. Dabei werden Trace-Informationen aus intermediärem Code des transformierten Computerprogramms und einer nachgelagerten Analyse gewonnen. Es werden auch einige der Trace-Informationen mit modifizierten Trace-Informationen ersetzt.
-
Eine zugrunde liegende Aufgabe für das hier vorgestellte Konzept kann darin gesehen werden, sinnvolle Auswertungen bzw. Analysen von Trace-Daten zu ermöglichen, ohne die üblichen riesigen Mengen von Trace-Daten erfassen zu müssen.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Diese Aufgabe wird durch die Gegenstände der unabhängigen Ansprüche gelöst Weitere Ausführungsformen sind durch die jeweilig abhängigen Ansprüche beschrieben.
-
Gemäß einem ersten Teilaspekt der vorliegenden Erfindung wird ein Verfahren zum Überwachen von Anforderungen an einen Codesatz bereitgestellt, wobei das Verfahren die Schritte eines Empfangens einer Anforderung an den Codesatz, Erzeugens einer Trace für die Anforderung, wobei die Trace den Pfad der Anforderung durch den Codesatz definiert, Zugreifens auf eine Mehrzahl von gespeicherten Trace-Mustern, wobei jedes gespeicherte Trace-Muster einen akzeptablen Pfad einer Anforderung durch den Codesatz definiert, Vergleichens der erzeugten Trace mit den gespeicherten Trace-Mustern und Speicherns der erzeugten Trace, wenn sie nicht mit einem der gespeicherten Trace-Muster übereinstimmt, aufweist. Weitere ergänzende Verfahrensschritte sind im nachfolgenden Dokument beschrieben.
-
Gemäß einem zweiten Teilaspekt der vorliegenden Erfindung wird ein System zum Überwachen von Anforderungen an einen Codesatz bereitgestellt, wobei das System einen Prozessor aufweist, der so eingerichtet ist, dass er eine Anforderung an den Codesatz empfängt, eine Trace für die Anforderung erzeugt, wobei die Trace den Pfad der Anforderung durch den Codesatz definiert, auf eine Mehrzahl von gespeicherten Trace-Mustern zugreift, wobei jedes gespeicherte Trace-Muster einen akzeptablen Pfad einer Anforderung durch den Codesatz definiert, die erzeugte Trace mit den gespeicherten Trace-Mustern vergleicht und die erzeugte Trace speichert, wenn sie nicht mit einem der gespeicherten Trace-Muster übereinstimmt. Weitere ergänzende Systemeigenschaften sind im nachfolgenden Dokument beschrieben.
-
Gemäß einem dritten Teilaspekt der vorliegenden Erfindung wird ein Computerprogrammprodukt auf einem computerlesbaren Datenspeichermedium zum Überwachen von Anforderungen an einen Codesatz bereitgestellt, wobei das Produkt Anweisungen zum Empfangen einer Anforderung an den Codesatz, Erzeugen einer Trace für die Anforderung, wobei die Trace den Pfad der Anforderung durch den Codesatz definiert, Zugreifen auf eine Mehrzahl von gespeicherten Trace-Mustern, wobei jedes gespeicherte Trace-Muster einen akzeptablen Pfad einer Anforderung durch den Codesatz definiert, Vergleichen der erzeugten Trace mit den gespeicherten Trace-Mustern und Speichern der erzeugten Trace, wenn sie nicht mit einem der Trace-Muster übereinstimmt, aufweist. Weitere ergänzende Elemente des Computerprogrammproduktes sind im nachfolgenden Dokument beschrieben.
-
Dank der Erfindung ist es möglich, ein Verfahren bereitzustellen, durch das nützliche Trace-Daten erfasst werden, die Menge an erfassten Daten jedoch verglichen mit einer wahllosen Verwendung von Trace stark verringert ist. Die Idee liegt darin, Trace-Muster zu erfassen, die den Pfad zeigen, den eine Anforderung durch Codesätze nimmt. Diese Muster werden verwendet, um anzugeben, welche Pfade für das System normal sind und so zu erlauben, dass abnormale Pfade während der Ausführung identifiziert werden. Solche Muster führen vorzugsweise detailliert aus, welche Codemodule und Funktionen aufgerufen werden, optional mit den Inhalten der Eintritts- und Verlassensparameter, jedoch ohne weiteres Detail. In einer bestimmten Ausführungsform wird die Trace in den Speicher erfasst, während Trace für ein System aktiviert ist, und die Trace wird in Intervallen, wie beispielsweise dass eine Anforderung abgeschlossen wird oder ein Puffer gefüllt ist, mit diesen Mustern verglichen. Wenn die Anforderung mit einem normalen Muster übereinstimmt, wird für jede Anforderung/jeden Thread die Trace vernichtet und belegt keinen Platz auf einer Platte (disk) oder einem Speicher. Wenn das Muster ungewöhnlich ist, wird die Trace aufbewahrt und kann dem Support bereitgestellt werden. Eine Anforderung kann in der Umgebung definiert sein, zum Beispiel handelt es sich in einem CICS Transaction Server bei einer Anforderung um Aktivitäten während der Lebensdauer einer Transaktion, wohingegen es sich in einem Webserver bei der Anforderung um Aktivitäten von einem Hereinkommen einer HTTP-Anforderung bis zu einem Bereitstellen einer HTTP-Antwort handelt.
-
In einer alternativen Ausführungsform können die normalen Muster verwendet werden, um Trace-Aufrufe für eine Anforderung zu ignorieren, die einen normalen Pfad ausführt. Wenn diese Anforderung dann von dem Pfad abweichen würde, würden die Trace-Aufrufe dazu führen, dass Trace-Daten aufgezeichnet werden. Dies würde die Datenspeicherbelegung für Trace verringern und es für die Person, die Trace-Ausgaben analysiert, einfacher machen, die eine oder zwei Anforderungen zu identifizieren, die nicht wie erwartet ausgeführt werden. In der vorstehend beschriebenen ersten Ausführungsform wird die Trace zuerst auf eine Platte erfasst, dann gelöscht. In dieser alternativen Ausführungsform wird Trace nicht auf eine Platte erfasst, sondern auf eine Platte geschrieben, wenn sie ungewöhnlich ist.
-
Eine weitere optionale Erweiterung liegt darin, ein teilweises Muster zu verwenden, das mit dem anfänglichen Fluss durch Module übereinstimmt, wobei jede Anforderung, die mit diesem teilweisen Muster übereinstimmt, mittels Trace verfolgt und mit guten Mustern verglichen wird, wohingegen jede Anforderung, die nicht mit der Trace übereinstimmt, vernichtet wird. Auf diese Weise ist es möglich, einen spezifischen, mittels Trace zu verfolgenden Codepfad vorzusehen und alle anderen Pfade auszuschließen, wodurch nicht für jeden möglichen Codepfad ein Muster bereitgestellt werden muss. Dies kann in einer Umgebung verwendet werden, in der viele Anforderungen pro Sekunde ausgeführt werden, um eine Trace von einem speziellen schlechten Pfad aufzunehmen. Zum Beispiel kann ein Kunde einen Fehler mit einer Stapel-Trace bereitstellen, die zeigt, in welche Module eingetreten wurde und welche Module verlassen wurden, bevor der Fehler geschah. Ein Stellvertreter der Ebene 3 könnte ein Trace-Muster dieses Pfades erheben und es dem Kundensystem bereitstellen und diesen in diesem Abschnitt beschriebenen Modus einschalten. Das Kundensystem würde dann nicht jede Anforderung/Transaktion mittels Trace verfolgen, sondern nur diejenige Anforderung, die den Fehler erzeugt hat. Daher ist es selbst in einem System mit tausenden von Anforderungen pro Sekunde möglich, Trace für einen einzigen schlechten Pfad durch den Code zu erfassen. Wenn auf solch einem System eine normale Trace aktiviert wäre, würde sich das Trace-Protokoll rasch füllen, und es wäre schwierig, die Trace für die schlechte Anforderung nachzuverfolgen, ohne eine Trace von mehreren Gigabyte oder mehr aufzunehmen und eine Nachbearbeitung daran vorzunehmen.
-
Eine weitere optionale Erweiterung liegt darin, in der Lage zu sein, das System zu überwachen und die Anzahl von angetroffenen „schlechten“ Mustern anzugeben oder die Anzahl von jedem gefundenen Muster zu zählen, um dem Benutzer des Systems nützliche Maßzahlen bereitzustellen. Wenn viele schlechte Muster auftreten, könnte dies irgendein Problem im System anzeigen. Solche schlechten Muster könnten durch Sicherheitsangriffe oder ein Verwenden, eine Inaktivität oder eine Unzuverlässigkeit anderer Systeme erzeugt werden. Der Vorteil liegt darin, dass einem Systemadministrator statt Aktivieren von Trace ein hochzuladendes teilweises Muster zum Ermöglichen einer Trace-Analyse bereitgestellt werden kann. Er/Sie lädt dies und sein/ihr System wird Trace nur erfassen, wenn die angegebenen Module oder Funktionen ausgeführt werden. Alternativ dazu wird dem Benutzer ein Satz von guten Mustern bereitgestellt, und wenn er dann Trace aktiviert, werden nur von Anforderungen, die schlecht aussehen, eine Trace erfasst und gespeichert.
-
Figurenliste
-
Nun werden in lediglich beispielhafter Weise bevorzugte Ausführungsformen der vorliegenden Erfindung unter Bezugnahme auf die folgenden Zeichnungen beschrieben, in denen:
- 1 eine schematische Darstellung eines Datenverarbeitungssystems zeigt,
- 2 eine schematische Darstellung eines Codesatzes zeigt,
- 3 eine schematische Darstellung eines Servers und einer Datenbank zeigt,
- 4 einen Ablaufplan eines Verfahrens zum Überwachen von Anforderungen an den Codesatz zeigt, und
- 5 einen Ablaufplan eines Verfahrens zum Überwachen von Anforderungen unter Verwendung von teilweisen Trace-Mustern zeigt.
-
DETAILLIERTE BESCHREIBUNG DER ZEICHNUNGEN
-
1 zeigt einen Netzwerkadministrator 10, der ein Desktop-Computersystem 12 verwendet, um die Leistung eines komplexen Codesatzes zu überwachen. Das Computersystem 12 weist eine Anzeigeeinheit 14, einen Prozessor 16 und eine Benutzereingabeeinheit (eine herkömmliche Tastatur) 18 auf. Der Prozessor 16 ist mit der Anzeigeeinheit 14 und der Benutzereingabeeinheit 18 verbunden. Der Prozessor 16 führt ein Betriebssystem aus, mit dem der Benutzer 10 über eine graphische Benutzeroberfläche des Betriebssystems interagieren kann, die durch die Anzeigeeinheit 14 angezeigt wird. Eine CD-ROM 20 ist gezeigt, die verwendet werden kann, um eine Kopie eines Computerprogrammproduktes zu speichern, das durch den Prozessor 16 ausgeführt wird.
-
Eine zusätzliche Benutzerschnittstelleneinheit 22 ist zudem gezeigt, bei der es sich um eine herkömmliche Maus 22 handelt. Der Benutzer 10 benutzt die Tastatur 18 und die Maus 22, um mit dem Betriebssystem und durch den Prozessor 16 ausgeführten Anwendungen zu interagieren. Der Codesatz, der überwacht wird, kann auch durch das Datenverarbeitungssystem 12 ausgeführt werden oder wird, was wahrscheinlicher ist, durch einen oder mehrere verbundene Server ausgeführt, die sich entfernt vom Datenverarbeitungssystem 12 befinden. Bei dem Codesatz könnte es sich um ein Unternehmenscomputersystem handeln, wie es durch ein Finanzinstitut wie beispielsweise eine Bank verwendet wird, um eine Webseite bereitzustellen, um es Kunden der Bank zu erlauben, online auf ihre Konten zuzugreifen und Transaktionen durchzuführen.
-
Der Codesatz wickelt viele tausende von Anforderungen pro Sekunde ab, und ein Überwachen wird durch Verwenden einer Trace-Funktion an manchen der, obwohl nicht allen, Anforderungen bereitgestellt, die durch den Codesatz empfangen werden. Der Codesatz ist so konfiguriert, dass nur eine bestimmte Menge von Trace-Daten erfasst wird, um dem Netzwerkadministrator 10 eine ausreichende Rückmeldung bereitzustellen, ohne einen sehr großen Datenspeicheraufwand zu erfordern, um alle Trace-Daten zu speichern, die ansonsten erzeugt würden, wenn Trace bei jeder einzelnen Anforderung an den Codesatz aktiviert wäre. Bei Tracing handelt es sich um einen spezialisierten Typ von Protokollieren, der Informationen über das Ausführen des Codesatzes aufzeichnet, wenn Anforderungen nach einem Empfang verarbeitet werden.
-
Um die Menge von aufbewahrten Trace-Daten zu verringern, ist es notwendig, Trace-Muster zu verwenden, um zwischen einer „guten“ Trace und einer „schlechten“ Trace zu unterscheiden. Eine gute Trace kann als ein normaler Pfad einer Anforderung durch einen Codesatz betrachtet werden, wohingegen es sich bei einer schlechten Trace um einen unerwarteten Pfad einer Anforderung durch einen Codesatz handelt, der dazu neigt, eher einen Fehler in der Verarbeitung anzuzeigen. Um solch eine Unterscheidung vorzunehmen, ist es zuerst notwendig, akzeptable Trace-Muster zu erzeugen. 2 veranschaulicht das Konzept, dass eine Anforderung 24 durch einen Codesatz 26 empfangen wird, der eine Antwort 28 erzeugt, während er auch eine Trace 30 für die spezifische Anforderung 24 erzeugt.
-
Um Muster zu erzeugen, wird zuerst die Trace 30 für die Anforderung 24 erfasst. Dann wird ein Werkzeug 32 verwendet, um diese Trace 30 in ein Muster 34 umzuwandeln. Dann wird dieses Muster als ein normales Anforderungsmuster in das System geladen. Dieser Prozess wird für jedes Anforderungsmuster wiederholt, dass als gut bewertet wird. Bei einem Muster 34 handelt es sich um eine Folge von Verfahrensaufrufen in Modulen oder Klassen. Zum Beispiel kann in einer Servlet-Umgebung ein Muster wie folgt lauten (wobei sich das Symbol > auf einen Eintritt in das benannte Modul bezieht und sich das Symbol < auf ein Verlassen des benannten Moduls bezieht):
- >MyServlet.init()
- <MyServlet.init()
- >MyServlet.get()
- >MySupportCode.doLogic()
- <MySupportCode.doLogic()
- >MySupportCode.doMoreLogic()
- <MySupportCode.doMoreLogic()
- <MyServlet.get()
-
Das Muster 34 kann komplexer sein und kann optional die eingesendeten oder ausgegebenen Parameter enthalten, einschließlich des spezifischen Typs eines Parameters. Eine bestimmte Verwendung hierfür liegt darin, dass im Fall, dass es ein Ausnahmeabwicklungsverfahren gibt, das eine Ausnahme-Superklasse braucht, das Muster festlegen kann, dass in dieses Verfahren mit einer konkreten Ausnahme-Teilklasse, wie beispielsweise UserErrorException eingetreten werden sollte. Somit werden nur Fehler analysiert und mittels Trace verfolgt, bei denen dieser erwartete Ausnahmefehler nicht auftritt. Traces 30, die als normal bezeichnet werden und während einer Testoperation des Codesatzes 26 erzeugt werden, werden verwendet, um die zulässigen Muster 34 zu erzeugen, die dann zur Verwendung bereit gespeichert werden, wenn sich der Codesatz 26 in Normalbetrieb befindet.
-
Wenn es normal arbeitet, ist Trace beim System zum Schreiben auf eine Platte aktiviert. Das System muss eine Anforderung identifizieren und die Trace auf einzelne Anforderungen aufteilen. Die Trennung könnte entweder erfolgen, wenn eine Anforderung einen Trace-Aufruf vorgenommen hat, oder durch das System in einer zweiten Phase, in der eine Trace-Ausgabe verarbeitet wird. Diese zweite Phase könnte durch eine Systemaufgabe realisiert werden, die Traces in separate Dateien je Anforderung aufteilt, zum Beispiel besitzt in manchen Anwendungsservern ein Trace-Eintrag eine Thread-ID, weshalb die Trace-Ausgabe nach Thread-IDs in separate Dateien aufgeteilt werden kann. Gleichermaßen besitzt für andere Typen von Transaktionsservern jede Transaktion eine Aufgabennummer, und diese Kennung kann verwendet werden, um die Trace-Ausgabe aufzuteilen.
-
Die Verwendung der gespeicherten Muster stellt ein Verfahren bereit, durch das nützliche Trace-Daten erfasst werden, die Menge an erfassten Daten jedoch verglichen mit einer wahllosen Verwendung von Trace stark verringert ist. Die gespeicherten Trace-Muster werden verwendet, um anzugeben, welche Pfade für das System normal sind, und so zu erlauben, dass abnormale Pfade während der Ausführung identifiziert werden. Wie vorstehend beschrieben, führen solche Muster vorzugsweise detailliert aus, welche Codemodule und Funktionen aufgerufen werden, optional mit den Inhalten der Eintritts- und Verlassensparameter, jedoch ohne weiteres Detail. 3 zeigt einen Server 36, der Zugriff auf eine Datenbank 38 besitzt, in der Trace-Muster gespeichert sind, die akzeptable Pfade von Anforderungen durch den Codesatz definieren.
-
In einer bestimmten Ausführungsform wird die Trace in einen Speicher erfasst, während Trace für das durch den Server 36 ausgeführte System aktiviert ist, und die Trace wird in Intervallen, wie beispielsweise wenn eine Anforderung abgeschlossen ist oder ein Puffer gefüllt ist, mit den gespeicherten Mustern in der Datenbank 38 verglichen. Wenn die Anforderung mit einem normalen Muster übereinstimmt, wird die Trace vernichtet und belegt daher keinen Platz auf einer Platte oder einem Speicher. Wenn das Muster ungewöhnlich ist und mit keinem gespeicherten Trace-Muster übereinstimmt, wird die ursprüngliche Trace aufbewahrt und kann dem Support bereitgestellt werden. Auf diese Weise werden nur diejenigen Traces durch das System gespeichert, die nicht mit Trace-Mustern übereinstimmen, die als „gut“ betrachtet werden.
-
4 fasst das Verfahren zum Überwachen von Anforderungen an den Codesatz zusammen. Das Verfahren weist die folgenden Schritte auf: als Erstes Schritt S4.1, der ein Empfangen einer Anforderung an den Codesatz aufweist, als Zweites Schritt S4.2, der ein Erzeugen einer Trace für die Anforderung aufweist, wobei die Trace den Pfad der Anforderung durch den Codesatz definiert, als Drittes Schritt 4.3, der ein Zugreifen auf eine Mehrzahl von gespeicherten Trace-Mustern aufweist, wobei jedes gespeicherte Trace-Muster einen akzeptablen Pfad einer Anforderung durch den Codesatz definiert, als Viertes Schritt S4.4, der ein Vergleichen der erzeugten Trace mit den gespeicherten Trace-Mustern aufweist, und schließlich Schritt S4.5, der ein Speichern der erzeugten Trace aufweist, wenn sie nicht mit einem der gespeicherten Trace-Muster übereinstimmt.
-
In einer alternativen Ausführungsform können die gespeicherten Muster verwendet werden, um Trace-Aufrufe für eine Anforderung zu ignorieren, die einen normalen Pfad ausführt. Wenn diese Anforderung dann von dem Pfad abweichen würde, würden die Trace-Aufrufe dazu führen, dass Trace-Daten aufgezeichnet werden. Dies verringert den Datenspeicherbedarf für die Trace-Daten und macht es für die Person, welche die Trace-Ausgabe analysiert, einfacher, die eine oder zwei Anforderungen zu identifizieren, die nicht wie erwartet ausgeführt werden. In der vorstehend beschriebenen ersten Ausführungsform werden die Trace-Daten zuerst auf eine Platte erfasst und dann gelöscht. In dieser alternativen Ausführungsform werden die Trace-Daten nicht auf eine Platte erfasst, sondern auf eine Platte geschrieben, wenn sie ungewöhnlich sind.
-
In dieser alternativen Ausführungsform, in der Trace-Aufrufe ignoriert werden, wenn die Anforderung mit einem normalen Pfad übereinstimmt, werden die Muster idealerweise im Speicher gehalten. Aus Leistungsgründen kann dies durch Zusammenführen dieser Muster in einen Graphen erreicht werden, und eine Anforderungsposition im Graphen wird verfolgt, wenn eine Anforderung einen Trace-Aufruf vornimmt, und falls dieser Aufruf mit einem zulässigen nächsten Knoten für die Anforderung übereinstimmt, wird der Ort der Anforderung in dem Graphen aktualisiert und nichts wird mittels Trace verfolgt. Wenn der Aufruf nicht mit einem zulässigen nächsten Knoten übereinstimmt, wird die letzte gute Position der Anforderung im Muster zusammen mit den Werten im aktuellen Trace-Aufruf in die Trace-Ausgabe geschrieben, und der Ort im Graphen für die Anforderung wird auf eine „Keine Übereinstimmung“-Position aktualisiert, was dazu führt, dass alle nachfolgenden Trace-Aufrufe für die Anforderung geschrieben werden.
-
Teilweises Musterabgleichen kann als Vorläufer für ein Entscheiden verwendet werden, ob Trace-Daten zu behalten sind, wobei nur diejenigen Anforderungen mittels Trace verfolgt werden, die mit einem teilweisen Muster übereinstimmen, wobei entweder verwendet wird, dass eine Hintergrundaufgabe einer zweiten Phase die Trace überwacht, oder ein speicherinterner Graph ähnlich der vorstehend beschriebenen vorherigen Ausführungsform verwendet wird. Wenn eine Anforderung abgeschlossen ist, verwendet die Hintergrundaufgabe dieselbe Logik wie das vorstehende Werkzeug, um die Trace in ein Muster umzuwandeln. Dann wird dieses Muster mit teilweisen Mustern verglichen, was anzeigen kann, dass die Trace zu analysieren ist. Falls ja, wird das Muster mit bekannten guten Mustern verglichen. Falls eine Übereinstimmung gefunden wird, wird die Trace von der Platte gelöscht. Falls keine Übereinstimmung gefunden wird, wird die Trace auf der Platte belassen, und der Analysierer kann einen Protokolleintrag schreiben, um anzugeben, dass ein schlechtes Muster erkannt wurde. Der speicherinterne Graph verfolgt die aktuellen Anforderungen, und entweder stimmen sie mit dem Muster überein und besitzen einen geschriebenen Trace-Eintrag, oder ihr Ort im Graphen wird so aktualisiert, dass es sich um einen „Keine Trace“-Knoten handelt.
-
Zum Beispiel kann ein teilweises Trace-Muster lauten:
-
So werden Aufrufe auf andere Servlets nicht analysiert. Aufrufe auf MyServlet, die GET verwenden, werden jedoch analysiert. Ein schlechtes Muster würde lauten;
- >MyServlet.init()
- >MyServlet.get()
- > MySupportCode.doLogic()
- >MySupportCode.handleError()
- >ServletContainer.handleRuntimeException()
- <ServletContainer.handleRuntimeException()
-
Hier gab es einen Fehler des Codes bei „get“, und er hat eine nicht abgewickelte Ausnahme ausgeworfen, mit welcher der Servlet-Container umgehen muss. 5 veranschaulicht den grundlegenden Grundgedanken in diesem Prozess. In Schritt S5.1 wird eine Überprüfung vorgenommen, um zu sehen, ob die Trace mit einem teilweisen Muster übereinstimmt. Falls sie nicht übereinstimmt, wird die Trace verworfen. Falls sie übereinstimmt, wird in Schritt S5.2 eine Überprüfung vorgenommen, um zu sehen, ob die Trace mit einem gespeicherten Muster übereinstimmt. Falls sie übereinstimmt, wird die Trace verworfen, und nur falls es keine Übereinstimmung mit einem gespeicherten (vollständigen) Muster gibt, wird die Trace in Schritt S5.3 gespeichert. Im Wesentlichen arbeitet dieser Prozess durch Fokussieren auf einen bestimmten Bereich des Codesatzes (der durch das teilweise Muster definiert ist) und speichert nur diejenigen Traces, die nicht mit Trace-Mustern übereinstimmen, die bereits als „gut“ definiert sind.
-
In Hinsicht darauf, wie ein Trace-Punkt aus einem Muster mit einer laufenden Trace verglichen wird, finden sich nachstehend zwei Beispiel-Traces-Anweisungen aus IBM WebSphere Application Server (WebSphere ist eine eingetragene Marke der International Business Corporation in vielen Rechtssprechungsgebieten):
- [06/01/14 15:17:22:101 GMT] 00000084 util > com.ibm.sr.sdo.helper.impl.BSRSDOHelperlmpl addProperty ENTRY com.ibm.serviceregistry.governance.sdo.impl.Subscriptionlmpl@1f28465a (classificationU-Rls: [], bsrURI: d413bbd4-62e8-48db.ba6f.f1d294f16fed, name: Subscription to „Account creation service ?(1.0)?“, namespace: , version: , description: , owner: admin, lastModified: 1369235510163, creationTimestamp: 1369235510163, lastModifiedBy: admin) (subscribedTransitions: null, subscribedOperations: [update], targetClassifications: null, emailAddress: null, locale: en, targetBsrURI: 9afa319a-bf21-4102.a24d.1fbfb71f4d67, targetName: null, targetNamespace: null, targetVersion: null) _expiryStartTime 1369235510139
- [06/01/14 15:17:22:101 GMT] 00000084 util < com.ibm.sr.sdo.helper.impl.BSRSDOHelperlmpl addProperty RETURN
-
Die verschiedenen Parameter ignorierend lautet die Eintrittsanweisung:
- [06/01/14 15:17:22:101 GMT] 00000084 util > com.ibm.sr.sdo.helper.impl.BSRSDOHelperlmpl addProperty ENTRY
-
Der Zeitstempel kann aus Sicht des Abgleichens ignoriert werden, nur die Reihenfolge relativ zu anderen Trace-Punkten spielt eine Rolle. Die Thread-ID 0000084 kann wiederum ignoriert werden, kann jedoch verwendet werden, wenn Trace aus einer einzigen Aufgabe gesammelt wird, sodass alle Trace-Punkte auf derselben Thread-ID für eine einzige Aufgabe sind. Der Bestandteil „util“ kann ignoriert werden. Der Klassenname, der aufgerufen wurde, lautet „com.ibm.sr.sdo.helper.impI.BSRSDOHelperlmpl“, und dies bildet einen Anteil des Trace-Musters und muss mit demjenigen im Muster übereinstimmen (auch in Graphenform). Der Verfahrensname lautet „addProperty“, und dies bildet einen Anteil des Musters und muss übereinstimmen. Schließlich wird der Typ (Eintritt oder Verlassen) als „ENTRY“ (Eintritt) angezeigt, und dies bildet einen Anteil des Musters und muss übereinstimmen.
-
In dieser Weise können Trace-Rohdaten auf Grundlage der Module und Funktionen, in die eingetreten wurde, von überflüssigen Informationen befreit und in ein Muster umgewandelt werden, sobald eine Anforderung durch einen Codesatz empfangen wurde. Durch Filtern der Trace-Daten mit den Trace-Mustern werden nur ungewöhnliche und unerwartete Trace-Daten erfasst, und dies wird die Menge von Datenspeicher verringern, der erforderlich ist, um die Trace-Daten abzuwickeln, macht jedoch auch die Aufgabe des Netzwerkadministrators einfacher, da weniger Daten vorhanden sind. Die gespeicherten Trace-Daten weisen nach dem Filtern nur diejenigen Traces auf, die nicht mit gespeicherten Trace-Mustern übereinstimmten, und werden per Definition unerwartete Traces sein, für die es wahrscheinlicher ist, Fehlern oder ungewöhnlichen Operationen innerhalb des Codesatzes zugehörig zu sein, und die so im Falle, dass Support bereitgestellt werden muss, in Hinsicht auf den Codesatz untersucht werden können.
-
Das Trace-Filtern kann auch verwendet werden, um Systemmaßzahlen zu erwerben. Das System kann überwacht werden, um die Anzahl von angetroffenen „schlechten“ Mustern (d.h. diejenigen, die nicht mit gespeicherten Trace-Mustern übereinstimmen) anzugeben oder die gefundene Anzahl von jedem Muster zu zählen, um dem Benutzer des Systems einige nützliche Maßzahlen bereitzustellen. Wenn eine Menge schlechter Muster aufzutreten beginnt, könnte dies irgendein Problem im System anzeigen. Solche schlechten Muster könnten durch Sicherheitsangriffe oder ein Verwenden, eine Inaktivität oder eine Unzuverlässigkeit anderer Systeme erzeugt werden. Ein bestimmter Vorteil liegt darin, dass einem Systemadministrator statt Aktivieren von Trace ein hochzuladendes teilweises Muster zum Ermöglichen einer Trace-Analyse bereitgestellt werden kann. Der Administrator lädt dies und sein/ihr System wird nur Trace erfassen, wenn die angegebenen Module oder Funktionen ausgeführt werden. Alternativ dazu wird dem Benutzer ein Satz von guten Mustern bereitgestellt, und wenn er dann Trace aktiviert, wird nur von Anforderungen, die schlecht aussehen, eine Trace erfasst und gespeichert.
-
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein computerlesbares Datenspeichermedium (oder -medien) mit darauf befindlichen computerlesbaren Programmanweisungen beinhalten, um einen Prozessor zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
-
Bei dem computerlesbaren Datenspeichermedium kann es sich um eine gegenständliche Einheit handeln, die Anweisungen zur Verwendung durch eine Einheit zum Ausführen von Anweisungen aufbewahren und speichern kann. Bei dem computerlesbaren Datenspeichermedium kann es sich zum Beispiel, ohne auf diese beschränkt zu sein, um eine elektronische Datenspeichereinheit, eine magnetische Datenspeichereinheit, eine optische Datenspeichereinheit, eine elektromagnetische Datenspeichereinheit, eine Halbleiterdatenspeichereinheit oder eine beliebige geeignete Kombination des Vorhergehenden handeln. Eine nicht abschließende Liste von spezifischeren Beispielen des computerlesbaren Datenspeichermediums beinhaltet das Folgende: eine transportable Computerdiskette, eine Festplatte, einen Speicher mit wahlfreiem Zugriff (random access memory (RAM)), einen Nur-Lese-Speicher (read-only memory (ROM)), einen löschbaren programmierbaren Nur-Lese-Speicher (erasable programmable read-only memory (EPROM) oder Flash-Speicher), einen statischen Speicher mit wahlfreiem Zugriff (static random access memory (SRAM)), einen transportablen Compact-Disc-Nur-Lese-Speicher (portable compact disc read-only memory (CD-ROM)), eine „Digital Versatile Disk“ (DVD), einen Speicherstick, eine Floppydiskette, eine mechanisch codierte Einheit, wie beispielsweise Lochkarten oder erhabene Strukturen in einer Rille mit darauf aufgezeichneten Anweisungen, und jede geeignete Kombination des Vorhergehenden. Ein computerlesbares Datenspeichermedium, wie es hierin verwendet wird, ist nicht als flüchtige Signale per se aufzufassen, wie beispielsweise Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, sich durch einen Wellenleiter oder eine anderes Übertragungsmedium ausbreitende elektromagnetische Wellen (z.B. Lichtimpulse, die ein Lichtwellenleiterkabel durchlaufen) oder durch einen Draht übertragene elektrische Signale.
-
Hierin beschriebene computerlesbare Programmanweisungen können von einem computerlesbaren Datenspeichermedium auf entsprechende Rechen- /Verarbeitungseinheiten oder über ein Netzwerk, zum Beispiel das Internet, ein lokales Netzwerk (local area network), ein Weitverkehrsnetzwerk (wide area network) und/oder ein kabelloses Netzwerk, auf einen externen Computer oder eine externe Datenspeichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, kabellose Übertragung, Router, Firewalls, Switches, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder eine Netzwerkschnittstelle in jeder Rechen-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen vom Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Datenspeichermedium innerhalb der entsprechenden Rechen-/Verarbeitungseinheit weiter.
-
Bei computerlesbaren Programmanweisungen zum Ausführen von Operationen der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, „Instruction-set-Architecture‟(ISA)-Anweisungen, Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmwareanweisungen, Zustandseinstellungsdaten oder jeden Quellcode oder Objektcode handeln, der in irgendeiner Kombination aus einer oder mehreren Programmiersprachen geschrieben ist, einschließlich einer objektorientierten Programmiersprache, wie beispielsweise Smalltalk, C++ oder Ähnliches, und herkömmlicher prozeduraler Programmiersprachen, wie beispielsweise die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als ein eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers über jede beliebige Art von Netzwerk, einschließlich ein lokales Netzwerk (local area network (LAN)) oder ein Weitverkehrsnetzwerk (wide area network (WAN)), verbunden sein, oder die Verbindung kann zu einem externen Computer (zum Beispiel mittels eines Internetdienstanbieters durch das Internet) hergestellt werden. In manchen Ausführungsformen können elektronische Schaltungen einschließlich zum Beispiel programmierbare Logikschaltungen, feldprogrammierbare Gatteranordnungen (field-programmable gate arrays (FPGA)), oder programmierbare Logikanordnungen (programmable logic arrays (PLA)), die computerlesbaren Programmanweisungen ausführen, indem Zustandsinformationen der computerlesbaren Programmanweisungen verwendet werden, um die elektronische Schaltung zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
-
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Darstellungen von Ablaufplänen und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Darstellungen von Ablaufplänen und/oder den Blockschaubildern durch computerlesbare Programmanweisungen realisiert werden können.
-
Diese computerlesbaren Programmanweisungen können einem Prozessor eines universellen Computers, eines zweckbestimmten Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine so zu erzeugen, dass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel zum Realisieren der im Block oder in den Blöcken des Ablaufplans und/oder Blockschaubildes angegebenen Funktionen/Handlungen erzeugen. Diese computerlesbaren Programmanweisungen können auch in einem computerlesbaren Datenspeichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten anleiten kann, auf eine bestimmte Weise zu funktionieren, sodass das computerlesbare Datenspeichermedium mit darin gespeicherten Anweisungen ein Herstellungsprodukt einschließlich Anweisungen aufweist, welche Aspekte der im Block oder in den Blöcken des Ablaufplans und/oder des Blockschaubildes angegebene Funktion/Handlung realisieren.
-
Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder der anderen Einheit durchzuführenden Operationsschritten hervorzurufen, um einen computerrealisierten Prozess so zu erzeugen, dass die auf dem Computer, der anderen programmierbaren Vorrichtung oder der anderen Einheit ausgeführten Anweisungen die im Block oder in den Blöcken des Ablaufplans und/oder des Blockschaubildes angegebenen Funktionen/Handlungen realisieren.
-
Die Ablaufplan- und Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und die Arbeitsweise möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block in den Ablaufplan- oder Blockschaubildern für ein Modul, ein Segment oder einen Abschnitt von Anweisungen stehen, das oder der eine oder mehrere ausführbare Anweisungen zum Realisieren der angegebenen logischen Funktion oder Funktionen aufweist. In manchen alternativen Realisierungen können die im Block festgehaltenen Funktionen in einer anderen als der in den Figuren festgehaltenen Reihenfolge auftreten. Zum Beispiel können zwei aufeinander folgend gezeigte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal abhängig von der betreffenden Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es wird ebenfalls angemerkt, dass jeder Block der Blockschaubilder und/oder der Darstellung eines Ablaufplans und Kombinationen von Blöcken in den Blockschaubildern und/oder der Darstellung eines Ablaufplans durch zweckbestimmte hardwaregestützte Systeme realisiert werden kann, welche die angegebenen Funktionen oder Handlungen durchführen oder Kombinationen aus zweckbestimmter Hardware und Computeranweisungen ausführen.
