Zusammenfassung Der Betrieb von softwareintensiven, geschäftskritischen Informationssystemlandschaften benötigt ein Performance-Monitoring um die Überwachung und Analyse von Laufzeitverhaltens zu ermöglichen. Während die rein technische Implementierung von Performance-Monitoring eher unproblematisch ist, bietet sich bisher kein Vorgehensmodell für den systematischen, zielgerichteten Einsatz in komplexen Systemen an. Somit haben die in der Praxis anzutreffenden „ad-hoc”-Realisierungen oftmals eine mangelhafte Effektivität und Wartbarkeit zur Folge. Aus diesem Grund wird in diesem Artikel ein Monitoring-Ansatz vorgestellt, dessen Kern aus einem Vorgehensmodell für die Planung und Integration eines Performance-Monitoring besteht. Damit zusammenhängend wurde eine wiederverwendbare Infrastruktur entwickelt, die die Monitoringdatenintegration für verteilte Systeme leistet. Der vorgestellte Ansatz wurde in einem Telekommunikationsunternehmen evaluiert und die dementsprechend umgesetzte Monitoring-Lösung befindet sich seit Mai 2006 im operativen Betrieb.
zahlreiche Standards (SNMP, WBEM/-CIM) und proprietäre Produkte (HP OpenView, MS Operations Manager, IBM Tivoli) für die Überwachung und das Management von Systemlandschaften, Netzwerken und Hardware existieren, sind Lösungen und insbesondere Vorgehensmodelle für das Monitoring auf Softwareapplikationsebene Mangelware. Da jedoch Informationssystemlandschaften immer softwareintensiver werden, ist es nicht mehr zeitgemäß, Softwareapplikationen als monolithischen Block zu beobachten, sondern eine innere Betrachtung nötig, um präzisere Diagnosen zu erhalten. Auch in der Lehre und Ausbildung bleiben die Aspekte des Softwarebetriebs und im speziellen Monitoring und dessen zielgerichteter Einsatz bislang weitestgehend unbeachtet.
Da in der Praxis oft das Bewusstsein existiert, dass ein Monitoring auf Softwareapplikationsebene benötigt wird, aber da kein ganzheitlicher Ansatz zur Verfügung steht, lässt sich vielerorts ein selbst entwickeltes, wenig dokumentiertes, „ad-hoc” Monitoring vorfinden. Das ad-hoc Monitoring stellt den naivsten Monitoring-Ansatz dar. Hierbei wird „aus dem Stegreif”, per Hand der Applikationscode um Standardausgabebefehle oder Aufrufe von Logging-Frameworks erweitert. Es ist nicht selten, dass weder eine Trennung des Logging-Codes von der restlichen Anwendungslogik vorgenommen wird, noch systematisch geplant und dokumentiert wird, wo, zu welchem Zweck, wie und was überhaupt mit dem Monitoring erfasst werden soll. Somit ist die Effektivität und Wartbarkeit, wie bei auch jeder anderen unsystematischen Softwareentwicklung, üblicherweise mangelhaft.
Um die Probleme des “ad-hoc” Monitorings zu vermeiden ist ein ganzheitlicher Monitoring-Ansatz nötig. Der in diesem Artikel beschriebene Monitoring-Ansatz zum Performance-Monitoring besteht aus: – einem Monitoring-Vorgehensmodell als Anleitung für die phasenweise, zielgerichtete und Planung, Implementierung und Integration eines Performance-Monitoring und – einer Monitoring-Infrastruktur als vorimplementiertes Framework aus Standardkomponenten des Monitorings für verteilte Java EE-basierte Systeme. Der Beitrag des Monitoring-Vorgehensmodells ist, dass ein zielgerichtetes Vorgehen angeboten und als Folge das Risiko einer Eigenentwicklung vermindern wird. Weiterhin wird eine spätere Rekonstruktion des Entwicklungsprozesses eines Monitorings und der zu Grunde liegenden Entscheidungen ermöglicht. Zuletzt soll es auf Grund von erhöhter Systematik einheitlichere Ergebnisse erzielen lassen, welches speziell bei großen Systemen wichtig ist, bei denen mehrere Entwickler an der Realisierung eines Monitorings beteiligt sind. Die Monitoring-Infrastruktur kapselt allgemeine Elemente des Monitorings in wiederverwendbaren Komponenten, um den Entwicklungsaufwand zu reduzieren.
Der Artikel ist wie folgt aufgebaut: Zunächst wird der aus dem Vorgehensmodell und der Infrastruktur bestehende Monitoring-Ansatz (Abschnitt 2 und 3) vorgestellt, wobei der Schwerpunkt auf den Phasen des Vorgehensmodells liegt. In Abschnitt 4 wird die Anwendung in einem realen System eines Telekommunikationsunternehmens beschrieben. Zum Ende dieses Artikels (Abschnitt 5) erfolgt eine Zusammenfassung sowie ein Ausblick über zukünftige Erweiterungen.
Vorgehensmodelle organisieren Entwicklungsprozesse, indem empfohlene Methoden und Techniken in Phasen gegliedert werden. Ein spezielles Vorgehensmodell für Performance-Monitoring kann im Gegensatz zu allgemeinen Softwareentwicklungsmodellen (z.B. Spiralmodell, Wasserfallmodell), die typischen Fragestellungen gezielter und somit effizienter adressieren als ein allgemeines Softwareentwicklungsmodell. Zusätzlich vermag es Entwicklungsfehler zu vermeiden, indem es als Checkliste dient. Abbildung 1 zeigt das Vorgehensmodell mit seinen fünf Phasen für den Entwurf, die
Abbildung 1. Vorgehensmodell für ein Performance-Monitoring Implementierung und die Integration von einem Performance-Monitoring in ein bestehendes Softwaresystem. Die Phasen werden in den folgenden Unterabschnitten im Detail beschrieben werden. Es ist noch zu erwähnen, dass Rückschritte und Iterationen bei der Anwendung des Vorgehensmodells möglich sind, da das Monitoring gegebenenfalls angepasst werden muss, wenn sich die Systemarchitektur oder die MonitoringAnforderungen ändern oder konkretisieren. Insbesondere sind Anpassungen nach der ersten Erprobungsphase zu erwarten, da vielmals erst anhand von ersten Messergebnissen festgestellt werden kann, welche Messpunkte und Metriken sich zum effizienten Erreichen der spezifizierten Ziele eignen. Daher sollte die Implementierung eine hohe Wartbarkeit besitzen, um Anpassungen des Monitorings zu unterstützten. 2.1
Die Datenerfassung für ein effektives und effizientes Monitoring muß zielgerichtet erfolgen. Dafür müssen die Ziele klar spezifiziert und dokumentiert werden. Zudem ist dies wichtig, um Nachvollziehbarkeit zu gewährleisten und um die Wartbarkeit des Softwaresystems nicht zu gefährden.
Bei der Identifikation der Monitoring-Ziele (z.B. Überwachung, Optimierung), können beispielsweise Unternehmensziele, Systemanforderungen oder Architekturvorgaben als Grundlage dienen. Zu späteren Zeitpunkten sollte stets überprüft werden, ob die Ziele erreicht wurden. 2.2
Im zweiten Schritt werden Performance-Metriken mit der
Goal-Question-Metric-Methode (GQM) [
Wir verstehen unter einem Messpunkt den Ort in der Anwendungsarchitektur, der für die Datenerfassung mit Anwendungscode erweitert wird.
Die Systemarchitekturbeschreibungen können markante Architekturpunkte als Kandidaten für Messpunkte oft schon erkennen lassen. Genauere Architekturanalysen können in Kombination mit Benutzerverhaltensprofilen erfolgen, indem Vorhersageverfahren für die Zuverlässigkeit oder Performance für eine Sensibilitätsanalyse benutzt werden, um kritische Architekturelemente zu finden.
Alternativ können auch Techniken wie Lasttests oder Profiling uninteressante
Punkte für Performancemessungen ausschließen, insbesondere da erfahrungsgemäß
lediglich ein kleiner Teil des Programmcodes für den Großteil der Gesamtausführungszeit
einer Software-Anwendung verantwortlich ist (vgl. [
In dieser Phase wird die Programmlogik für das Monitoring implementiert und mit der
zu überwachenden Applikation auf technischer Ebene verbunden. Grundsätzliche
lassen sich für das Verbinden zwei Klassen von Verfahren unterscheiden: (1.) Verfahren
die den Quellcode der Applikation erweitern (empfohlen z.B. Aspektorientierte
Programmierung (AOP) [
Nachdem der Messcode mit der Applikation verbunden ist, erfolgt noch eine Integration der Messpunkte in eine Monitoring-Infrastruktur. Diese ist dafür verantwortlich, die einzelnen Messdaten von den verteilten Messpunkten zusammenzubringen und zu verwalten. Dies kann beispielsweise so aussehen, dass ein zentrales, separates System alle Messpunkte regelmäßig abgefragt, die Daten persistent speichert und für Drittapplikationen zur Verfügung stellt (z.B. für Langzeitanalysen, Alarmierungen).
Die Monitoring-Infrastruktur setzt sich zum einen aus einem Performance-Monitor und zum anderen aus einer Integrationsanwendung zusammen. Der Performance-Monitor stellt dabei eine Komponente dar, die vom Applikationsserver aufgerufen wird, um Monitoring auf Applikationsebene zu aktivieren. Das Monitoring erfolgt dabei automatisch an durch Annotationen definierten Messpunkten in der zu überwachenden Applikation.
Die Integrationsanwendung stellt eine entkoppelte Anwendung dar, die die Performance-Daten der auf mehreren Servern verteilten Performance Monitore verbindet. Weiterhin ist sie in der Lage, die Performance Monitore in regelmäßigen Abständen zu kontaktieren und dessen Daten persistent zu speichern, um sie möglichen Drittanwendungen bereitzustellen. Letztere können diese Daten beispielsweise für Alarmierungen oder Langzeitanalysen weiterverwenden.
Bei der Implementierung des Performance Monitors kam die aspektorientierte JavaErweiterung AspectJ sowie die Management-Erweiterung JMX zum Einsatz. Mit Hilfe von AspectJ wird an den definierten Messpunkten zusätzliche Funktionalität „eingewebt”, welche die Performance-Messungen durchführt. 4
Im Rahmen der Evaluationsphase wurde der entwickelte Monitoring-Ansatz bestehend aus dem Vorgehensmodell und der Infrastruktur an einem Java-basierten Portalsystem für rund 277.000 Kunden (Stand: 31.12.2005) des im norddeutschen Raum tätigen Telekommunikationsunternehmens EWE TEL getestet. Als eines der größten regionalen TK-Unternehmen Deutschlands bietet EWE TEL eine hohe Vielfalt an Sprach-, Internet- und Datendiensten. Zu EWE TEL gehört ebenfalls die Bremer Marke nordCom.
Im Evaluationsszenario wurde der Servlet Container Apache Tomcat 5.5.12 sowie der Applikationsserver Bea WebLogic 9.1 eingesetzt. Bei dem angesprochenen Kundenportalsystem handelte es sich um eine verteilte Anwendung, bei der Messpunkte in Applikationen gesetzt wurden, die auf unterschiedlichen Applikationsservern installiert waren. Der Messcode wurde dabei in einem ersten Evaluationsszenario zur Laufzeit mit Hilfe des so genannten Load-time Weaving (LTW) von AspectJ eingewebt. In einem weiteren Szenario kam Compile-time Weaving (CTW) zum Einsatz, bei dem Messcode bereits während des Build-Prozesses eingewebt wurde, da LTW in Kombination mit RMI-Kommunikation, aufgrund eines bis dahin ungelösten konzeptionellen Problems von AspectJ 1.5.0, massive Speicherprobleme zutage brachte.
Der Monitoring-Ansatz mit Integration der Messpunkte durch CTW befindet sich seit Anfang 2006 erfolgreich im operativen Betrieb und liefert Performance-Daten, die zur Langzeitüberwachung, Alarmierung und Ressourcenbedarfsplanung genutzt werden. 5
In diesem Artikel wurde ein Vorgehensmodell sowie eine Implementierung in Form
einer Infrastruktur für ein Performance-Monitoring von
Informationssystemlandschaften vorgestellt. Im Vorfeld dieser Arbeit konnte kein adäquates Vorgehensmodell für
die systematische Integration eines Performance-Monitoring in der Literatur gefunden
werden. Sicherlich gibt es zahlreiche Vorgehensmodelle, die für die
Softwareentwicklung eingesetzt werden (Wasserfallmodell, Spiralmodell), welche aber nicht auf
kritische Aspekte von Monitoring eingehen. Daher wurde ein konkretes
Vorgehensmodell für Performance-Monitoring entwickelt, welches vorgefertigte Phasen für die
Einwicklung eines Monitorings anbietet. Im Gegensatz zum Vorgehensmodell lassen sich
in der Literatur einige ähnliche Monitoring-Infrastruktur- Architekturen finden (z.B.
[
Das in diesem Artikel vorgestellte Vorgehensmodell sowie die Infrastruktur
konnte sich im Praxiseinsatz bewähren und werden in einem großen Kundenportalsystem
eines regionalen TK-Unternehmens zur Langzeitüberwachung, Alarmierung und
Ressourcenbedarfsplanung eingesetzt. Eine Erweiterung des Ansatzes um eine
Protokollierung von Fehlernachrichten ist in der Entwicklung. Als Langzeitvision sind zudem
einfache Selbstheilungsmechanismen denkbar, wie sie z.B. von IBMs Autonomic
Computing Kampagne [