|
|
|
»manage
it«
als
|
Analyse von Performance-Problemen in SOA Die richtige Spur finden Wenn sich Software-Nutzer über schlechte Antwortzeiten beschweren, gibt es dafür in verteilten und serviceorientierten Anwendungen eine unübersehbare Zahl von möglichen Ursachen. Es werden deshalb Verfahren benötigt, die zeigen, welche Informationen überhaupt für die Fehlersuche relevant sind.
erteilte und serviceorientierte Anwendungen (J2EE, .NET, Webservices usw.) haben ein Problem: treten Performance-Mängel auf, ist es zum Teil sehr schwer herauszufinden, wo die Ursachen dafür liegen. Das zeigt das Beispiel einer Hotelkette, die eine Java-basierende Anwendung für betriebswirtschaftliche Kernprozesse wie Buchhaltung und Zimmerverwaltung nutzt. Immer am Monatsende klagten die Anwender in den Hotels vor Ort über schlechte Antwortzeiten. Der Server-Administrator sah auf seinem Monitor, dass die Prozessor-Auslastung des Applikationsservers zu dieser Zeit bei 80 Prozent lag. Die Anzahl der User und der getätigten Transaktionen war aber nicht ungewöhnlich hoch, daher musste es eine andere Ursache für das Problem geben. Nach Analyse einer Reihe von Metriken zeigte sich, dass zur selben Zeit ein bestimmtes Servlet und ein Enterprise Java Bean (EJB) ebenfalls ungewöhnlich hohe Antwortzeiten aufwiesen. Ein Gespräch mit dem Datenbank-Administrator ergab zudem, dass auch der Prozessor des Datenbank-Servers stark ausgelastet war. Nach Stunden der Suche und Analyse entdeckte man schließlich, dass eine durch das EJB aufgerufene ineffiziente Datenbank-Abfrage die Wurzel des Übels darstellte – die Auslastungsphänomene waren reine Symptome. Durch eine Umprogrammierung des SQL-Statements konnte das Problem schließlich behoben werden. Komplexität reduzieren Das Beispiel zeigt eine Reihe von typischen Schwierigkeiten bei der Performance-Analyse in verteilten Anwendungen und serviceorientierten Architekturen (SOA): · Probleme äußern sich oft durch mehrere zusammenhängende Symptome auf mehreren System- und Anwendungsschichten (so genannte »Tiers«). · Erst das Finden und Analysieren der abhängigen Phänomene ermöglicht es dem Administrator, Symptome von Ursachen zu unterscheiden. · Man braucht Informationen von allen Tiers, um die Problemursache zu identifizieren. · Häufig überwachen unterschiedliche Abteilungen mit unterschiedlichen Monitoring-Tools die einzelnen Tiers. Die verantwortlichen IT-Mitarbeiter leiden in solchen Situationen nicht an Informations-Mangel, genau das Gegenteil ist der Fall. Denn mit dem Übergang auf serviceorientierte Programmierkonzepte hat sich die Anzahl der zu überwachenden Einheiten vervielfacht – der Administrator hat es heute mit tausenden von Metriken zu tun, die ihn permanent über CPU- und Speicherauslastung, Antwortzeiten von Servlets und Java Server Pages oder über die Länge der Warteschlangen für eine .NET-Laufzeitumgebung auf dem neuesten Stand halten. Er sieht also in der Regel ausgiebig und genau, was passiert. Deshalb weiß er noch lange nicht, warum es passiert. Benötigt wird somit ein Verfahren, das Komplexität reduziert und dem Administrator erst einmal eine Richtung für die Fehlersuche vorgibt. Für diese Aufgabe hat der Netz- und Systemmanagementspezialist OPNET Technologies die Software »Panorama« entwickelt. Das Funktionsprinzip: Zwischen das Monitoring, wo Auslastungen und Antwortzeiten gemessen werden, und dem Dashboard, das die Reports anzeigt, wird eine Analyse-Schicht gelegt, die die gesammelten Daten automatisch analysiert, selektiert und korreliert. Im Endeffekt erhält der Troubleshooting-Verantwortliche nur die Metriken, die für das Finden der Fehlerursache zielführend sind. In dieser Zwischenschicht wird eine Reihe von Analysetechniken eingesetzt. Zwei davon sollen hier näher beleuchtet werden. Dabei geht es um folgende zwei Fragen: Was ist überhaupt unnormal? Und: Treten gleichzeitig an mehreren Stellen zusammenhängende Phänomene auf?
Abbildung:
Eine Analyseschicht zwischen Monitoring und Reporting filtert die
problemrelevanten Metriken heraus und analysiert ihre Zusammenhänge.
Was ist überhaupt unnormal? Ein erster Schritt zur Reduktion von Komplexität ist das Herausfiltern derjenigen Messwerte, die von einer normalen Variation abweichen. Das hört sich einfacher an als es ist. Denn am Quartalsende, wenn die Vertriebsmitarbeiter ihre Reports einpflegen, die Buchhaltung den Quartalsabschluss erstellt und die Personalabteilung die Gehälter abrechnet, ist ein anderer Wert normal als Mitte des Monats an einem Freitagabend um 19:30 Uhr. Viele Tools bieten die Möglichkeit, statische Schwellenwerte für einzelne Metriken zu definieren. Werden diese übertreten, bekommt der Administrator automatisch einen Warnhinweis. Dieses Verfahren ist aber für Java- oder .NET-Anwendungen erstens unpraktikabel, weil kein Administrator für die Masse der Metriken Schwellenwerte anlegen und pflegen kann. Zweitens ist die Aussagekraft dieses Überwachungssystems zwangsläufig teils falsch und teils lückenhaft. Falsch, weil Spitzenwerte durchaus normal sein können. Lückenhaft, weil in »ruhigen« Zeiten auch ein geringes Ausschlagen eines Messwerts alarmierend sein kann, obwohl es den Schwellenwert nicht übertritt. Dieses Problem lässt sich durch dynamische Schwellenwerte lösen. Das heißt: Die Software ermittelt für unterschiedliche Tages-, Wochen- und Monatszeiten eine durchschnittliche Auslastungsbandbreite, die sie als Maßstab für ihre Abweichungsanalysen heranzieht. Der Schwellenwert passt sich somit der jeweils charakteristischen Auslastung an. Das kann zum Beispiel bedeuten, dass eine Prozessor-Auslastung von 75 Prozent am Quartalsende als Normalfall gebucht, ein Anstieg auf 15 Prozent am Freitagabend aber einen Alarm auslöst. Der Administrator ist somit über die wirklich relevanten Abweichungen – und nur über diese – informiert. Wie hängen die Messwerte zusammen? Aber dann steht man vor einem zweiten Problem, denn es handelt sich immer noch um isolierte Messwerte. Angenommen, der Administrator erhält Nachricht über einen Verstoß gegen ein Service Level Agreement und sieht gleichzeitig elf Metriken rot aufblinken, die den Bereich der normalen Abweichung überschritten haben. Es ist aber noch offen, ob diese etwas miteinander zu tun haben oder nicht. Typische Fragen, die der Administrator an dieser Stelle hat, sind beispielsweise: · Gibt es einen Zusammenhang zwischen CPU-Auslastungsspitzen und der Ausführung bestimmter EJB oder Servlets? · Welche Datenbankmetriken reagieren am stärksten, wenn die Transaktionen pro Sekunde zunehmen? · Hängt die Speicherauslastung mit einer spezifischen Aktivität bestimmter Servlets zusammen? Hier greift eine zweite Analysetechnik, die Korrelation. Diese vergleicht permanent das Verhalten aller Metriken aller Tiers unter Fehlerbedingungen miteinander und filtert diejenigen heraus, deren Verhalten darauf schließen lässt, dass sie zu demselben Problem gehören. Das hört sich im ersten Moment trivial an. Lineare Entwicklungen sind in der Tat relativ leicht zu vergleichen. Die Auslastung von Systemressourcen entwickelt sich aber in der Regel nicht linear, sondern exponentiell. Daher bedarf es leistungsfähiger Algorithmen, um echte Korrelationen zu identifizieren und falsche Korrelationen auszuschließen – und zwar auch dann, wenn es sich um tausende von Vergleichswerten handelt, die laufend variieren. Die Software wendet die Korrelationsanalyse permanent auf Messwerte an, die im Sekundentakt im laufenden Produktionsbetrieb erhoben werden. Somit erhält der Administrator im Fehlerfall zwei Korrelationen: die eine basiert rein auf der Zeitgleichheit der Ereignisse, die andere zeigt die statistischen Abhängigkeiten. Zusammenhängende Metriken können dann automatisch synchronisiert und übereinander angeordnet. Der Troubleshooting-Verantwortliche sieht somit die Zusammenhänge auf einen Blick, zur weiteren Analyse kann er per Drill-Down-Technik weitere Details anzeigen lassen. Resümee Die beschriebenen Verfahren schließen die Lücke zwischen den zwei Fragen »Läuft etwas schief?« und »Wie kann ich das Problem lösen?«, indem sie Zahl der möglichen Fehlerquellen radikal einschränkt und Ursache-Wirkungs-Zusammenhänge transparent macht. Anstatt mit 2000 hat es der Troubleshooting-Verantwortliche vielleicht nur noch mit 25 Metriken zu tun. Für den letzten Schritt – das Beheben der Problemursache – ist dann jedoch Fachkenntnis und Erfahrung vonnöten. Außerdem können weitere Werkzeuge nützlich sein, beispielsweise für die Code-Analyse von Java- oder .NET-Programmen. Wenn es schließlich um das Optimieren, Tunen und Debuggen geht, stellt der Markt eine Fülle weiterer Lösungen zur Verfügung. Sie alle können ihre Wirksamkeit jedoch erst dann entfalten, wenn klar ist, wo sie überhaupt eingesetzt werden sollen. Sonst bleibt der Administrator alleingelassen mit einem Wust von Metriken einerseits und mit einem Kasten voller Optimierungswerkzeuge andererseits. Dr. Martin Klapdor ___________________________________________________________ Dr. Martin Klapdor, Senior Applications Engineer, Central & East Europe, OPNET Technologies, mklapdor@opnet.com, www.opnet.com
|
|
