Continuous Application Performance Management Ein Whitepaper von dynatrace

Transkript

1 Ein Whitepaper von dynatrace Thema dieses Whitepapers sind die neuen Anforderungen für Application Performance Management (APM)* angesichts der immer schneller wachsenden Komplexität in Anwendungsentwicklung, architekturellem Design und Produktionsumgebungen. Tatsache ist, dass Anwendungen immer geschäftsentscheidender werden. Sie sind sozusagen Waffen, mit denen wir unsere Marktposition verteidigen bzw. ausbauen müssen. Sie sind stärker nach außen gerichtet als jemals zuvor und haben Auswirkungen auf Kunden, Geschäftspartner und Lieferketten - und sie werden in immer größerem Umfang ein Antrieb für das Geschäft. Diese geschäftskritischen Anwendungen müssen nicht nur rund um die Uhr verfügbar sein, sondern auch für alle Anwender eine optimale Performance bieten. Sie müssen flexibler sein als jemals zuvor und immer mehr Anwender unterstützen, die immer mehr Transaktionen durchführen. Wir optimieren sie, ändern sie und verbessern sie immer weiter - und das öfter als jemals zuvor. Während all dies im Vordergrund geschieht, integrieren wir außerdem immer mehr Programmteile von Drittanbietern oder Open Source Code, setzen unsere Anwendungen global verteilt ein und verlagern den Schwerpunkt von physischen Produktionsumgebungen auf virtuelle. (Fortsetzung folgt)

2 Zusammenfassung Thema dieses Whitepapers sind die neuen Anforderungen für Application Performance Management (APM) 1 angesichts der immer schneller wachsenden Komplexität in Anwendungsentwicklung, architekturellem Design und Produktionsumgebungen. Tatsache ist, dass Anwendungen immer geschäftsentscheidender werden. Sie sind sozusagen Waffen, mit denen wir unsere Marktposition verteidigen bzw. ausbauen müssen. Sie sind stärker nach außen gerichtet als jemals zuvor und haben Auswirkungen auf Kunden, Geschäftspartner und Lieferketten - und sie werden in immer größerem Umfang ein Antrieb für das Geschäft. Diese geschäftskritischen Anwendungen müssen nicht nur rund um die Uhr verfügbar sein, sondern auch für alle Anwender eine optimale Performance bieten. Sie müssen flexibler sein als jemals zuvor und immer mehr Anwender unterstützen, die immer mehr Transaktionen durchführen. Wir optimieren sie, ändern sie und verbessern sie immer weiter - und das öfter als jemals zuvor. Während all dies im Vordergrund geschieht, integrieren wir außerdem immer mehr Programmteile von Drittanbietern oder Open Source Code, setzen unsere Anwendungen global verteilt ein und verlagern den Schwerpunkt von physischen Produktionsumgebungen auf virtuelle. Die Anbieter traditioneller APM-Lösungen versuchen, mit dieser Entwicklung Schritt zu halten. Trotz größeren Investitionen in APM-Tools im Laufe der Jahre werden schwerwiegende Probleme oft erst in der Produktion erkannt, für deren Diagnose und (erhoffte) Lösung man dann ganze Teams benötigt. Immer wieder überraschen uns Skalierbarkeitsprobleme zu den ungünstigsten Zeitpunkten. Regressionen schleichen sich ein und hindern uns am Fortkommen. Wir sehen uns der ständigen Herausforderung gegenübergestellt, neue Funktionen online zu bringen, und das in einer verlässlichen Art und Weise. Und trotz all der Investitionen und der besten Köpfe die daran arbeiten ändert sich nichts schnell genug zum Guten. Meistens wird es sogar schlimmer. Und es gibt einen einfachen Grund, warum dies so ist - Ihre Anwendungen sind so komplex geworden, dass Ihre Tools beim Management dieser Anwendungen an ihre Grenzen stoßen. Das ist ein unhaltbarer Zustand für ein Unternehmen, das von seinen Softwareanwendungen abhängig ist - sowohl im Bezug auf das Geschäft als auch auf die IT-Experten, die Ergebnisse vorweisen müssen. Daher ist es Zeit für einen innovativen Ansatz, um uns der neuen Anwendungsrealität zu stellen - einen Ansatz, mit der wir uns den heutigen Herausforderungen stellen können - und auch den Herausforderungen von morgen. Die Grenzen der herkömmlichen APM-Ansätze, kombiniert mit der schnell steigenden Komplexität unserer Anwendungsentwicklung, Anwendungsarchitektur und der Produktionsumgebungen zeigen ganz klar: Ein neuer Ansatz für APM ist unerlässlich. Dieser Ansatz muss: Innovation in Technologie UND Ansatz kombinieren. von Grund auf transaktionszentriert und für kontinuierlichen, unterbrechungsfreien Einsatz konzipiert sein, so dass eine schnelle und verlässliche Problemlösung in einem Bruchteil der sonst nötigen Zeit möglich ist. den gesamten Entwicklungslebenszyklus unterstützen, um Probleme proaktiv identifiziren und veremeiden zu können, bevor diese die Produktion erreichen. sich wiederholende, zeitraubende Aufgaben automatisieren, während die hoch dynamische Natur von fortschrittlichen Anwendungen automatisch unterstützt wird. sich leicht in bestehende Systeme und Business-Prozesse integrieren lassen, damit der Wert bereits getätigter Investitionen in Application Management erhöht wird. 1 APM bedeutet im Zusammenhang mit dynatrace "Application Performance Management", nicht "Application Performance Monitoring". Dies ist eine wichtige Unterscheidung, wenn man die Unterschiede zwischen herkömmlichen APM-Tools (Schwerpunkt auf Monitoring) und aktuellen, hoch entwickelten APM-Systemen (Schwerpunkt auf Management) bedenkt. Man muss wissen, dass APM oft ein verwirrender Bereich ist, da so viele Unternehmen mit ganz verschiedenen Zielen alle unter der Bezeichnung "APM" firmieren. Noch verwirrender ist, dass viele Anbieter die gleichen Begriffe für unterschiedliche Dinge verwenden. Auch wenn es nicht das ausgesprochene Ziel dieses Whitepaper ist, alle Begriffsprobleme zu klären, haben wir doch einige Erläuterungen eingefügt, um dem Leser zu helfen, besser zu verstehen, auf was sie bei der Einschätzung von verschiedenen APM-Lösungen achten müssen. dynatrace software 2009

3 INHALT 1 DIE KONVERGENZ DER KOMPLEXITÄT DIE GRENZEN DES TRADITIONELLEN APM DIE ERSTE GRENZE: KOMPONENTEN-MONITORING - NUR DURSCHNITTSWERTE DIE ZWEITE GRENZE: NUR REAKTIVES TROUBLESHOOTING - EINFACHE ANWENDUNGEN DIE DRITTE GRENZE: ISOLIERTE TOOLS - KEIN INTEGRIERTER LEBENSZYKLUS- ANSATZ DIE VIERTE GRENZE: ALTE ARCHITEKTUR - NUR STATISCHE ANWENDUNGEN DIE FÜNFTE GRENZE - SCHWIERIGE INTEGRATION IN BESTEHENDE UMGEBUNGEN DIE NEUEN APM-ANFORDERUNGEN ANFORDERUNG 1: TRANSAKTIONSZENTRIERT ANFORDERUNG 2: KONTINUIERLICHER UNTERBRECHUNGSFREIER BETRIEB ANFORDERUNG 3: IM GESAMTEN LEBENSZYKLUS INTEGRIERT ANFORDERUNG 4: HOCH AUTOMATISIERT ANFORDERUNG 5: WERTSTEIGERUNG BESTEHENDER INVESTIONEN DIE DYNATRACE-LÖSUNG PUREPATH GLOBAL TRANSACTION TRACING LEICHTGEWICHTIGER AGENT MIT SKALIERBARER SERVER-COLLECTOR- ARCHITEKTUR INTEGRIERTER LIFECYCLE-ANSATZ MIT INTEGRIERTEM COLLABORATION SYSTEM AUTOMATISIERTE DIAGNOSE UND SMART AGENT AUTOMATION MIT DYNAMISCHEM ON-THE-FLY PROVISIONING OSGI PLUGIN-MODELL FÜR OFFENE INTEGRATION UND ERWEITERBARKEIT FAZIT dynatrace software 2009

4 WER KANN VON DIESEM WHITEPAPER PROFITIEREN? Jede wichtige Interessengruppe im Anwendungsentwicklungsprozess - Entwicklungsleiter, Softwareoder Systemarchitekten, Performance-Spezialisten oder IT Betriebsleiter. Ebenfalls Teil dieses Whitepapers: Diskussion über APM im Kontext agiler Softwareentwicklung, Continuous Integration, Applikationen bzw. Programmcodes von Drittanbietern, Global SOA, virtualisierte Datencenter/Cluster und Cloud Computing. Weitere Informationen zu dynatrace-produkten, Lösungen und Kunden-Fallstudien finden Sie auf der dynatrace-website, 1 DIE KONVERGENZ DER KOMPLEXITÄT Vor 15 Jahren, zur Anfangszeit des Application Performance Managements, waren nach außen gerichtete Geschäftsanwendungen noch recht simpel. Sie bestanden oft aus zwei Ebenen oder Tiers, Datenbank und Front-End, beides wurde intern entwickelt, für ein Zielpublikum von max. ein paar Tausend Anwendern. Der Fokus lag auf dem Netzwerk, der Datenbank und dem regelmäßigen "Anpingen" der Anwendung, um festzustellen, ob sie "verfügbar" ist. Unternehmen wie Tivoli (übernommen von IBM), Quest und BMC konnten diese ersten Anforderungen der ersten Generation erfüllen. Im Jahr 2000 wurde das Internet immer mehr zur neuen, populären Anwendungsplattform, und um den Bedarf nach weiterentwickelten verteilten Anwendungen zu unterstützen, entstand eine dritte Ebene, oftmals in Java geschrieben, in der eine komplexere Geschäftslogik eingebettet war. Java- Anwendungsserver breiteten sich schlagartig in der Szene aus. Typische Webanwendungen mussten jetzt flexibel genug für Tausende gleichzeitig agierende Anwender sein. Diese Anwendungen wurden immer noch intern erstellt, aber von einer steigenden Anzahl von Java-Entwicklern. Die Komplexität stieg und die APM-Anbieter reagierten mit einer zweiten Generation von Produkten. Diese zweite Generation kam, wie erwartet, von damals neuen Wegbereitern der Szene, Mercury Software (2006 von HP übernommen), die synthetische Lasttests als grundlegende Voraussetzung für die Freigabe zur Produktion etablierten, und synthetisches Monitoring der Enduser Experience zur Messung der Anwendungsverfügbarkeit und der Response Time (Reaktionszeit)-SLAs; und Wily (2005 von CA übernommen), die Monitoring von Java-Komponenten und die Problemisolierung im Javacode etablierten. Aber die Komplexität der Anwendungen hat nicht abgenommen. Im Gegenteil - in den letzten fünf Jahren ist die Komplexität extrem gestiegen. Sie hat nicht nur bezüglich des Umfangs, des Entwicklungsstands und der Systemarchitektur der Anwendungen zugenommen, sondern auch im Hinblick auf Entwicklungstechniken, Produktionsumgebungen und Erwartungen an die Performance. Anwendungen mit beliebig vielen Ebenen (Tiers) oder mit globaler Verteilung sind inzwischen weit verbreitet. Service-orientierte Umgebungen mit Komponenten von Drittanbietern, einschließlich kommerzieller Software und Open Source-Anwendungen, sind jetzt keine Seltenheit mehr. Agile Entwicklungstechniken und Continuous Integration werden kombiniert, um den immer kürzer werdenden Release-Zyklen gerecht zu werden. Produktionsumgebungen werden von segmentierten, physikalischen Umgebungen in virtuelle Cluster umgewandelt, in denen mehrere Anwendungen gleichzeitig in einer gemeinsam genutzten Umgebung laufen. Die nächsten Innovationen sind private Clouds und "Cloud Bursting" für Peakload-Anforderungen. Man darf auch nicht vergessen, dass SLAs (Service Level Agreements) immer anspruchsvoller werden, und die Anwender erwarten eine immer kürzere Reaktionszeit. Für Software- oder Systemarchitekten sind diese Änderungen einzeln vielleicht zu bewältigen. Aber wenn all diese Änderungen gleichzeitig berücksichtigt werden müssen, können die Anforderungen schnell zu komplex und überwältigend werden. Und für das IT-Management kann das, was zunächst wie eine großartige Chance auf kürzere Markteinführungszeiten, reduzierte Entwicklungskosten und geringere Betriebs- und Wartungskosten aussieht, schnell zu einem Albtraum für Anwendungsperformance, Skalierbarkeit und Stabilität werden. Diese Konvergenz der Komplexität, die sich über Entwicklung, Architektur und Produktion erstreckt, hat traditionelle APM-Ansätze nutzlos gemacht. Trotz der Investitionen, die im letzten Jahrzehnt in APM-Lösungen getätigt wurden, gibt es immer noch schwerwiegende Probleme in der Produktion. Immer noch werden ganze Teams zusammengerufen, um Fehler in der Performance, der Skalierbarkeit und der Stabilität zu beseitigen. Testzyklen werden weiterhin gekürzt und Testbereiche reduziert, trotz des steigenden Wertes der Anwendungen. Es werden immer kürzere dynatrace software

5 Markteinführungszeiten verlangt, da die Unternehmen immer mehr hoch entwickelte Software herausbringen müssen, um im Geschäft zu bleiben und sich auf dem Markt behaupten zu können. Diese Herausforderungen werden nicht nur bestehen bleiben, sondern auch noch größer werden, da die Komplexität der Anwendungen weiterhin steigt. Um auf diese immer größer werdenden Herausforderungen zu reagieren, brauchen wir eine innovative Herangehensweise einen Ansatz der dritten Generation, mit dem wir nicht nur die aktuellen, unmittelbaren Probleme lösen, sondern auch den Herausforderungen von morgen vorgreifen. Eine Herangehensweise, mit der wir proaktiv, also vorausschauend verhindern, dass Probleme mit der Performance, Skalierbarkeit und Stabilität bis in die Produktion gelangen. Ein Ansatz, mit dem das Lösen von Problemen in Applikationen auch wenn sie erst im laufenden Betrieb entdeckt werden, was immer vorkommen wird von Tagen, Wochen (oder nie) auf nur Minuten verkürzt wird. Eine Herangehensweise, die eine größere Testabdeckung in der halben Zeit ermöglicht. Eine Lösung, die im gesamten Lebenszyklus einer Anwendung genutzt werden kann, die Effizienz der Entwickler steigert, die Wartungskosten reduziert und die Qualität der Anwendungsnutzung für Kunden, Angestellte und Partner erhöht. Die Notwendigkeit dieses Ansatzes der dritten Generation wurde von Bernd Greifender, dem CTO von dynatrace, vorhergesehen, als er das Unternehmen im Jahr 2005 gründete. Prevent Proactively avoid problems Monitor Gain Visibility Resolve Reduce resolution time Continuous APM: Ein Ansatz der dritten Generation für Application Performance Management dynatrace software

6 2 DIE GRENZEN DES TRADITIONELLEN APM Um den Wert eines idealen Ansatzes der dritten Generation besser zu verstehen, ist es unerlässlich, sich die Grenzen des traditionellen APMs im Kontext der Komplexität heutiger Anwendungen vor Augen zu führen. Traditionelle QA- und APM-Ansätze für Probleme vor der Produktion, einschließlich Lasttests, konzentrierten sich bisher auf die Identifizierung von Problemen - vor 10 Jahren war das ein Durchbruch. Software für synthetische Lasttests wurde entwickelt, um die Lastanforderungen von Endbenutzern an eine neue Anwendung zu simulieren, um potentielle lastabhängige Probleme identifizieren und einzukreisen zu können. Produktions-Monitoring-Software wurde entwickelt, um Anwendungskomponenten zu beobachten. Wenn die durchschnittlichen Reaktionszeiten unter eine vorab definierte Grenze fielen, wurde ein Alarm ausgegeben, dass ein potentielles Problem in einer Anwendung besteht. In beiden Fällen unterlag es dann dem Entwicklungsteam, sobald die Test- oder Produktionsteams das Problem eingekreist und die Anwendungsebene als mögliche Ursache identifiziert hatten, herauszufinden, ob das potentielle Problem ein echtes war. Die Entwickler versuchten dann endlos, das fragliche Problem zu reproduzieren - und das nur mit Beschwerden über die Symptome und wenig oder keinen Informationen über die genauen Abläufe und Zustände innerhalb der Applikation. Wenn sie Glück hatten und das Problem reproduzieren konnten, dann würden sie sich zur Diagnose der Ursache hangeln (wieder ohne nützliche Diagnoseinformationen) und vielleicht das Problem lösen. Bei weniger "Glück" würden die Entwickler Debug-Berichte und Log Statements zu Hilfe nehmen, in der Hoffnung, dass diese zusätzlichen Informationen Hinweise darauf geben, was denn die Ursache des Problems sein könnte. Heutzutage werden viele Anwendungs-Performance- oder Skalierbarkeits-Probleme in Tests gefunden, bevor sie in die Produktion gelangen; außerdem ist das Einkreisen von Problemen in der Produktion einfacher geworden. Das sind die positiven Entwicklungen. Aber der Zeitaufwand der Entwicklungsabteilung für die Reproduktion, Diagnose und Lösung der Probleme bezüglich Performance und Skalierbarkeit ist erheblich gestiegen. Tatsächlich verbringen Entwickler nach aktuellen Untersuchungen % ihrer Zeit mit dem Beheben von Anwendungsfehlern, die in Tests und in der Produktion auftreten. Damit wird eine unakzeptabel große Menge an R&D-Zyklen verbraucht, die der Entwicklung dann für das Erstellen neuer Features zur Unterstützung der Geschäftsziele fehlt. Seit die Komplexität in Entwicklung, Architektur und Produktion zugenommen hat, leisten diese traditionellen APM-Ansätze nicht mehr genug, um Performance, Skalierbarkeit und Stabilität der heutigen hoch entwickelten, verteilten Anwendungen managen zu können. Das setzt die System- und Entwicklungsteams noch mehr unter Druck. Nachfolgend sind die wichtigsten Grenzen der traditionellen APM-Tools in der neuen Anwendungsrealität aufgelistet und erklärt. 2.1 DIE ERSTE GRENZE: KOMPONENTEN-MONITORING - NUR DURSCHNITTSWERTE Wie oben beschrieben können aktuelle Lösungen potentielle Probleme in den Komponenten einer Anwendung identifizieren. Einige können das besser als andere. Bytecode-Instrumentierung hat sich als der effizienteste Weg herausgestellt, detaillierte Informationen über eine Instanz oder eine Komponente einer Anwendung zu bekommen. Obwohl sie Zugriff auf Anwendungsdetails haben, geben alle traditionellen Komponenten-Monitoring-Systeme nur durchschnittliche Performance- Messwerte, wie beispielsweise Reaktionszeiten, aus. Durchschnittswerte sind schon per Definition keine echten Daten, sondern eine statistische Anhäufung von Daten. Diese Systeme korrelieren dann die Durchschnittswerte, um eine grobe Schätzung dessen abzugeben, was eventuell in einer 2 The Business Case for Better Problem Resolution, Nov von Forrester und The State of Application Performance Management, eine Umfrage bei IT-Profis, durchgeführt zwischen Juni und September 2009, beauftragt von dynatrace Software. dynatrace software

7 Anwendung passieren könnte. Und diese statistischen, korrelierten Daten, basierend auf Durchschnittswerten, werden dazu verwendet, um potentielle Performance-Probleme zu identifizieren, und diese Korrelation von Durchschnittswerten wird dann dazu benutzt, Performance bezüglich SLA- Konfirmität zu validieren. Keines von beidem bietet den Grad an Genauigkeit, der den heutigen Anforderungen entspricht (siehe auch Kapitel 3), und da die Komplexität der Anwendungen weiter wächst, kann das mehr und mehr zu einem ernsten Problem werden. Denken Sie nur an die Herausforderungen beim Troubleshooting. Wenn Sie ein Software-Architekt oder Performance-Spezialist sind, der statistische, korrelierte Daten für das Troubleshooting verwenden muss, dann haben Sie ein Problem. Sie versuchen beispielsweise gerade, eine spezifische Codezeile oder eine Schwachstelle in der Architektur zu isolieren, die/der ein Problem in einer spezifischen Situation oder Transaktion bewirkt. Sie suchen nach der sprichwörtlichen Nadel im Heuhaufen. Wenn Sie wissen, welche Anwendungskomponente vielleicht ein Problem sein könnte, haben Sie schon mal den richtigen Heuhaufen, aber Sie müssen immer noch die Nadel finden. Und wenn Sie gar nicht erst den richtigen Heuhaufen finden immerhin haben Sie nur geschätzt, basierend auf Durchschnittswerten und Korrelationen - was dann? Allzu oft findet man sich wieder über Stapel von Logs brütend, um den nächsten vielversprechenden Heuhaufen herauszufiltern, den man untersuchen muss. Die Granularität und die Genauigkeit von Anwendungsdaten und der Kontext indem das Problems auftritt sind, speziell bei wachsender Komplexität, essentiell für eine schnelle, konsistente Lösung. It works in my enviroment. I cannot reproduce the problem. Come back when you can reproduce it or get more details. We got performance alert at 2AM for the checkout transaction. What more do you want? I gave you everything that the system gave me. This Problem has been there for 1 month! Fix it now! Only if QA/Ops will hire someone who can program! If only, the developers had a clue about what the real enviroment is like. Anwendungs-Performance: Viele Interessengruppen, verschiedene Fähigkeiten, verschiedene Abteilungen Was die SLAs angeht: Die meisten Service Level Agreements basieren heutzutage nicht mehr auf "durchschnittlichen Reaktionszeiten". Sie beziehen sich eher auf "absolute" Reaktionszeiten, wie sie der Endanwender erfährt, Transaktion für Transaktion. Außerdem können sich SLAs für die gleiche Komponente auch je nach Transaktionstyp unterscheiden. Daher werden traditionelle Grenzwert- Methoden, die auf Durchschnittswerten von Infrastruktur und Anwendungskomponenten basieren, zunehmend nutzlos. Dies ist einer der Gründe, warum einige Unternehmen begonnen haben, sich dem "Enduser Monitoring" zuzuwenden, das verspricht, die tatsächliche Performance aus der Sicht des Endanwenders zu beobachten. Das Versprechen: Echte Daten auf Transaktionslevel für jede Anwender-Interaktion. Da die SLA-Anforderungen immer größer werden und vom Endanwender-Level bis zu individuellen Services/Komponenten gehen - bis zu echten Daten auf Transaktionslevel für jede Interaktion - müssen traditionelle Komponenten-Monitoring-Lösungen Platz machen für einen neuen Ansatz. 2.2 DIE ZWEITE GRENZE: NUR REAKTIVES TROUBLESHOOTING - EINFACHE ANWENDUNGEN Einige der weiterentwickelten Monitoring-Systeme der zweite Generation und Lasttest-Produkte bieten so genannte "Diagnose"-Funktionen an. Einige behaupten, dass ihre Diagnoseverfahren "komplette dynatrace software

8 Transaktionen" nachverfolgen können (Transaction Tracing), damit die Entwicklungsabteilung schneller herausfinden kann, was mit einer Anwendung nicht stimmt. Tracing auf Transaktionsebene ist tatsächlich der richtige Ansatz. Der Erfolg bei der Ausführung dieser Strategie ist bei den traditionellen Tools allerdings beschränkt, da aus den einzelnen Transaktionen letztendlich nur Traces berechnet werden, die auf Durchschnittswerten basieren. Die wenigen Produkte der zweiten Generation, die behaupten verteilte Anwendungen zu unterstützen, liefern eigentlich nur Performance- Durchschnittswerte die nur wenig Brauchbares für Diagnosezwecke oder SLA-Performance bieten. Die Hauptbeschränkungen dieser Ansätze der zweiten Generation bezüglich der Application Performance sind folgende: Erstens sind diese Diagnosefunktionen meist Add-Ons, und nicht im Kern der eigentlichen Monitoring- oder Lasttest-Systeme enthalten, und daher schlecht integriert und nicht leicht anzuwenden. Zweitens sind all diese Diagnoselösungen reaktiv - sie werden erst aktiviert, wenn das Problem schon aufgetreten ist. Dies ist offensichtlich ein Problem, denn die Reproduktion eines Problems ist oft ein langer und sehr herausfordernder Prozess. Drittens verursachen diese Diagnose- Lösungen einen Overhead von 20-50% 3 oder mehr, wenn ihre Transaktions-Tracing-Funktionen aktiviert werden. Daher werden sie nur im Notfall und nur auf reaktiver Basis in einer Produktionsumgebung eingesetzt, und nur selten in Test- und Performance-Centern. Viertens erfordern diese Systeme, dass die Entwicklung ihre Tätigkeiten unterbricht und auf die Produktionssystem-Datenbanken zugreift, oder maßgeschneiderte Methoden zur Problemisolierung entwickelt. Die Systeme sind nicht automatisch aktiviert, um Probleme automatisch aufzuspüren. Und schließlich sind diese Systeme sehr schwer zu installieren und die gesammelten Daten sind, auch wenn sie besser als nichts sind, kaum von Wert, wenn Sie eine schnelle Problemlösung wollen. Business Tier JEE Server Data Tier RDBMS Mainframe Presentation Tier.NET Server External Web services Transaction Tracing muss unterbrechungsfrei, 24x7 laufen, um sporadisch auftretende Probleme erfassen zu können Jetzt stellen Sie sich diesen reaktiven, belastenden Ansatz für die heutigen global verteilten dynamischen Anwendungen mit mehreren Ebenen/Tiers vor, in denen meist noch jede Menge an Drittanbieter-Code steckt. Erstens: Für ein Transaction Tracing müssen mehrere Ebenen (Tiers) übergreifend untersucht werden. Dies war vor zehn Jahren, als die traditionellen APM-Diagnosetools erstellt wurden, weder erforderlich noch vorhersehbar. Außerdem ist für Tracing über global verteilte Anwendungen WAN Support für Remoting erforderlich, was auch keine Anforderung für traditionelle APM-Lösungen war - und daher nicht vorhanden ist. Drittens: Da die heutigen Anwendungen dynamischer als jemals zuvor sind, kann man das Tracing nicht einfach nach dem Auftreten eines Problems aktivieren. Das Verhalten einer Anwendung und die zugrunde liegende Infrastruktur ist vielleicht niemals die gleiche und die Symptome eines Problems können sich ändern oder auf andere 3 Der Overhead-Prozentsatz zeigt hier den Anteil der gesamten Systemressourcen an, die während des Transaction Tracing- Prozesses des APM-Systems verbraucht werden Das heißt, dass ein APM-System, das einen Overhead von 50% verursacht, die Hälfte der gesamten Systemressourcen verbraucht, sodass nur noch die andere Hälfte der Systemressourcen zur Verarbeitung der Transaktionen bleibt. dynatrace software

9 zugrunde liegende Anwendungsprobleme hinweisen. Und schließlich sind diese traditionellen APM- Diagnosetools nicht entwickelt worden, um mit Drittanbieter-Code zu arbeiten, ein blinder Fleck, wenn man an die heutigen service-orientierten Anwendungen denkt, an Off-Shore-Anwendungsentwicklung und Frameworks von Drittanbietern. Traditionelle APM- und Preproduction-Diagnosetools, die für die Anwendungsentwicklungs- und Troubleshooting-Anforderungen vor zehn Jahren entwickelt wurden, sind vielleicht für einfache Anwendungen, statische Produktionsumgebungen und interne Entwicklungsteam ausreichend. Aber für alle, die Änderungen gegenüber aufgeschlossen sind und sich einer steigenden Komplexität gegenüber gestellt sehen, ist ein neues APM-System notwendig. 2.3 DIE DRITTE GRENZE: ISOLIERTE TOOLS - KEIN INTEGRIERTER LEBENSZYKLUS-ANSATZ In fast allen Fällen haben die Anbieter von traditionellen APM-Lösungen mehrere Tools zusammengestellt, die für diverse Aufgaben von verschiedenen Interessengruppen im gesamten Anwendungsentwicklungs-Lebenszyklus verwendet werden können. Unglücklicherweise sind diese Tools nur selten gut integriert, so dass Architekten, Entwickler und Performance-Spezialisten viel Energie einsetzen und sich trotzdem auf Vermutungen stützen müssen, um die Resultate untereinander zu korrelieren. Dieser personelle Faktor und die dürre Faktenlage führen oft zu gegenseitigen Schuldzuweisungen und verschwendeter Zeit bei der Frage, wo man mit der Reproduktion und der Diagnose wichtiger Anwendungsprobleme beginnen soll. Egal, ob dies in der Test- oder Produktionsphase passiert, die verschwendete Zeit kostet echtes Geld in Form von Ausfallzeiten, Verzögerungen bei der Markteinführung und mangelnder Effizienz bei Entwicklungsund Testprozessen. Für die Produktion werden hauptsächlich Application Monitoring Tools für APM angeboten. Einige haben zusätzliche Tools zum Überprüfen der Vorgänge zwischen Enduser-Browser und der Webanwendung selbst, um eine bessere Genauigkeit als nur die der Durchschnittswerte anzubieten. Lasttest-Anbieter argumentieren, dass ihre virtuellen User Monitoring Tools ebenfalls in der Produktion verwendet werden sollten, um potentielle Engpässe (sogenannte Bottlenecks) in der Produktion vorauszusehen. Andere bieten Monitoring für Hardware und Betriebssysteme an. Einige behaupten, dass ihre Network Monitoring Tools dabei helfen können, langsam laufende Anwendungen aufzuspüren. Und viele IT-Schmieden bieten ihre selbst entwickelten Tools und Scripts an, die man hier und dort verwenden kann. All diese Tools und ihre Ergebnisse bieten teilweise Einblicke in die Produktionsanwendungs-Umgebung - aber intelligente, menschliche Eingriffe sind immer noch erforderlich, um herauszufinden, was das alles bedeutet. Nehmen Sie etwas mehr Komplexität, mehr Anwendungen, höhere SLA-Ansprüche - und die Herausforderung für das Management steigt exponentiell. Obwohl bekannt ist, dass es fünfzig bis hundert Mal mehr kostet, wenn man Probleme erst in der Produktion identifizieren kann und nicht schon in der Test- oder Entwicklungsphase, können traditionelle APM-Tools die Lücke zwischen Produktion und der Entwicklung nicht füllen. Proaktive, d.h. vorausschauende und präventive Fähigkeiten fehlen traditionellen, Die meisten Probleme entstehen in frühen Entwicklungsphasen, werden aber erst später bei Tests oder in der Produktion gefunden [NIST2002] produktionsorientierten APM- Tools völlig. Letztere beobachten zwar Umgebungen während der Produktion unterbrechungsfrei, aber zur Prävention notwendig sind ganz andere Tools, die für Interessengruppen gemacht sind, die schon vor der Produktion Fehler suchen. Leider blockiert die ewige Trennung zwischen der Produktion und Testphase in voneinander dynatrace software

10 unabhängige Silos weiterhin Strategien für eine effiziente, proaktive Vermeidung von Problemen. Das kostet uns nicht nur Zeit und Geld, sondern auch Kundenzufriedenheit. Man muss darauf hinweisen, dass es eine entscheidende Phase im Anwendungs-Lebenszyklus gibt, in dem es kaum Performance-Tests oder Reviews der Runtime-Architektur gibt, und das ist die Entwicklung selbst. Vor einem Jahrzehnt lautete eine Empfehlung bestimmter Entwicklungsmethoden, die Entwicklungs- von der Testphase zu trennen, aber diese Philosophie ändert sich nun rasch mit den so genannten agilen Ansätzen und der Continuous Integration. Der Bedarf an neuen Anwendungsfunktionen und -fähigkeiten, die uns einen Wettbewerbsvorteil verschaffen und uns geschäftlich nach vorne bringen sollen, bewirkt immer schnellere Release-Zyklen. Simultan erhöht sich der Druck bezüglich Qualitäts- und Testanforderungen durch die steigende Komplexität der Architektur und dem Erfordernis, die Produktion entsprechend anzupassen. Trotz aller Bemühungen, besseren Code zu schreiben, bleibt die Tatsache, das mehr als 50% aller Anwendungsprobleme, die in der Produktion entdeckt wurden, ebenso während der Entwicklung hätten gefunden und gelöst hätten werden können - wenn die richtigen APM-Lösungen im Einsatz gewesen wären. Und mit der Zunahme von Virtualisierung und Cloud Computing müssen Architekten die Betriebsumgebung schon berücksichtigen, wenn sie ihre Anwendungen entwickeln. Sie müssen sich Auswirkungen und Strategien überlegen, wie sie ihre Anwendungen gut validieren wollen, bevor sie ausgerollt werden. Obwohl es enorm wertvoll und wichtig wäre, APM schon in der Entwicklung einzuführen, gibt es erstaunlicherweise nur wenige "Visibility"-Tools, nämlich Profiler und Debugger. Aber Debugger sind keine APM-Tools, denn sie sollen dazu dienen, funktionelle Probleme zu lösen. Sie werden Zeile um Zeile ausgeführt und bringen die Anwendung so zum Anhalten. Genauso wenig sind Profiler wirkliche APM-Tools, da sie nicht unter Last und in verteilten Umgebungen laufen können. Diese Beschränkungen bedeuten, dass diese Tools Skalierbarkeitsprobleme nicht diagnostizieren können, die unter Last in verteilten Systemen auftreten. Entwicklungsmanager benötigen proaktives Performance-Management, und nur ein kontinuierliches Feedback zwischen Entwicklern und automatisierten Tests kann die Denkweise und das Verhalten dementsprechend verlagern. Nur ein Ansatz, der die Performance, die Skalierbarkeit und die Stabilität während des gesamten Lebenszyklus berücksichtigt, kann mit den aktuellen, aggressiven Anwendungsentwicklungs-Prozessen mithalten,weshalb es notwendig ist, die Entwicklung bei Entscheidungen über zukünftigen APM-Lösungen miteinzubeziehen. 2.4 DIE VIERTE GRENZE: ALTE ARCHITEKTUR - NUR STATISCHE ANWENDUNGEN Da Anwendungen immer komplexer und dynamischer geworden sind, können Architekten das genaue Laufzeitverhalten ihrer Anwendungen nicht mehr vorhersagen. Sie wissen, was ihre Anwendungen leisten müssen, aber keiner weiß, wie sie sich wirklich verhalten und wie Transaktionen unter Last tatsächlich verarbeitet werden. Das liegt zum Teil daran, dass immer mehr Services verwendet werden und an der weit verteilten Natur der heutigen Multi-Tier-Anwendungen. Zusätzlich gibt es immer mehr dynamischen Code, der mit Programmen und Frameworks von Drittanbietern (Open Source oder gekauft) gekoppelt ist. Der dynamische Code wird nur unter Last ausgeführt und das Verhalten von Codeteilen und Frameworks von Drittanbietern ist oft unmöglich vorherzusagen, selbst dann, wenn die Applikation schon im Produktivbetrieb läuft. In einem Cluster- oder in einer virtualisierten Produktionsumgebung, in der Ressourcen gemeinsam genutzt und/oder dynamisch weitergegeben werden, gibt es nun plötzlich keine zwei Transaktionen mehr, die den gleichen Pfad nehmen. Wie kann ein APM-Tool, das nur durchschnittliche Reaktionszeiten misst und das nur eingesetzt werden kann nachdem ein Fehler bereits aufgetreten ist um dann "Schätzungen" vorzunehmen, mehr nutzen als nur dazu, ihnen zu sagen, dass sie irgendwo in ihrer Anwendung ein Problem haben? Mit dem Aufkommen von virtualisierten Datencentern und Cloud Computing, dynamischer Ressourcenbereitstellung und dynamischen Anwendungsverhalten werden die traditionellen APM- Ansätze, die für frühere, statischere Umgebungen erstellt wurden, nutzlos. Traditionelle APM-Ansätze stellen Agenten zur aktiven Datensammlung in der Zielapplikation bloß statisch (manuell) bereit - VM für VM, Serverinstanz für Serverinstanz - und eine dynamische Bereitstellung beschränkt sich daher auf identische Instanzen, die auf identischer Hardware laufen. Außerdem könnte, wenn Diagnose- Tracing überhaupt jemals aktiviert und verwendet wird, die Installation und die Einrichtung eine solch dynatrace software

11 große Herausforderung darstellen, dass dies die Risiken und den Wert der Ergebnisse in einer dynamischen Umgebung überwiegt. Die Anbieter von Virtualisierungs-Lösungen bieten dynamische Lösungen für ihre eigenen Layer des Applikationsstacks, wie das etwa VMWare mit AppSpeed macht, um eine Visibilität in ihren eigen Hypervisor-Layer hinein zu ermöglichen. APM-Lösungen für virtuelle Umgebungen müssen daher sämtliche Agenten vollständig dynamisch je nach gerade aktiven virtuellen Serverinstanzen bereitstellen und eine echte Einsicht in den Application Layer, einschließlich Transaction Tracing für eine schnelle Ursachenanalyse, Mapping für Abhängigkeiten bis hinunter in die einzelnen Services, und mit unterbrechungsfreiem Monitoring bieten. Das ist notwendig für einen effizienten und wertbringenden Einsatz in diesen sich ständig ändernden Umgebungen. Dynamically deployed server to process increased load Virtualized Back-end Services Virtualized Front-end Services Ausführungspfade ändern sich "on the fly" aufgrund von bedarfsorientierten Deployment virtualisierter Services 2.5 DIE FÜNFTE GRENZE - SCHWIERIGE INTEGRATION IN BESTEHENDE UMGEBUNGEN Jedes Unternehmen hat in Prozesse und Tools für die Softwareentwicklung und deren Betrieb investiert. Bei vielen waren dies beträchtliche Investitionen. Keine Umgebung ist homogen mit nur einheitlicher Hardware, Anwendungsserver-Instanzen, Entwicklungsprozessen und Applikationsarchitekturen. Da sich die IT immer mehr an die individuellen Erfordernisse jeder Geschäftseinheit anpasst, steigt diese Vielfalt. Daher muss man APM-Tools einfach in schon vorhandene Systeme integrieren können, und zwar selbstverantwortlich mithilfe automatisierter Interfaces, passend zu bestehenden Prozessen, und gut erweiterbar zur Anpassung an zukünftige Erfordernisse. Auf traditionelle APM-Tools trifft das wohl kaum zu. Tatsächlich bedürfen traditionelle APM-Tools oft einer intensiven Unterstützung mit Professional Services. Und dies ist nicht nur für Installation und Schulungen erforderlich, sondern auch für Integration, Konfiguration von Scripts und Workflows und das Schreiben des Glue-Code, damit die Tools in einer bereits bestehenden Umgebung überhaupt funktionieren. Load test control and analysis to uncover problems Load Controller Tatsächlich sind einige der Eine Integration in bestehende Kontrollsysteme ist oft sehr schwierig populärsten Application Monitoring-Systeme so schwierig zu verwenden und zu konfigurieren, dass professionelle Hilfe notwendig ist, nur um eine Anwendung zu instrumentieren. Wenn irgendeine Änderung in der Architektur oder Produktion erforderlich ist, werden wieder Professional Services benötigt, um die Instrumentierung wieder anzupassen. Schon die Integration von Datenerfassung in Dashboards und andere Application Management-Konsolen ist oft ein Job für Professional Services. Das ist ein sehr kostspieliges und ineffizientes Arrangement, das außerdem den negativen Effekt hat,? Log Log Log Log Application data collection control and problem diagnostics Log dynatrace software

12 dass sowohl Anpassungsfähigkeit als auch Agilität ausgebremst werden. Das konnte man vielleicht vor zehn Jahren tolerieren, jetzt jedoch nicht mehr. Interessant ist auch, dass die meisten Anbieter von traditionellen APM-Lösungen ihre "Suites" durch Akquisitionen zusammengefügt haben. Diese Tool- Akquisitionen bringen zwar viele Häkchen in der Angebotsbeschreibung, bleiben aber eher schlecht integrierte Lösungen. Manchmal ist das einfach Nachlässigkeit, manchmal weist es aber auch auf ein strukturelles Problem hin, nämlich dass die Tools eigentlich nicht kompatibel sind und daher entweder nur sehr schwer oder einfach gar nicht miteinander integriert werden können. Anstatt die aufwändigen Arbeiten zu übernehmen, die für eine vernünftige Integration erforderlich wären, verlassen sich die traditionellen Anbieter lieber darauf, dass ihre Professional Service-Agenturen vor Ort etwas zusammenstricken. Wenn eine Suite mit einer umfangreichen Komponente für Professional Service ausgeliefert wird, ist das schon ein eindeutiges Zeichen dafür, dass die "Suite" vielleicht nicht gut integrierbar ist, und das ihre Nutzung bei jeder erforderlichen Änderung in der Anwendungsumgebung mehr und mehr Geld für professionelle Services verschlingt. Da erweist sich dann das, was eben in der PowerPoint- Präsentation noch so gut aussah, in der Praxis schnell als kostspielige und einschränkende Lösung. Dev DB Test DB Production DB APM-Suites aus mehreren übernommenen Tools sind schwer zu integrieren Wenn man all diese Grenzen der traditionellen APM-Ansätze betrachtet, speziell im Licht der schnell steigenden Anwendungskomplexität, wird klar, dass eine neue Herangehensweise an APM dringend erforderlich ist. Der neue Ansatz muss sowohl die oben beschriebenen Grenzen berücksichtigen, als auch zukünftige Erfordernisse wie etwa für virtualisierte Datencenter, Cloud Computing, global verteilte service-orientierte Anwendungen, steigenden Einsatz von Programmen und Codeteilen von Drittanbietern und agile Entwicklungstechniken. dynatrace software

13 3 DIE NEUEN APM-ANFORDERUNGEN Ein APM-Ansatz der dritten Generation beginnt mit einem anderen Schwerpunkt als traditionelle Ansätze. Die Problemidentifizierung ist immer noch wichtig, aber nicht mehr das einzige Ziel. Eine schnelle Lösung und proaktive Vermeidung von Anwendungsproblemen sind die neuen Schwerpunkte, die von den meisten, einschließlich der Analysten Gartner und Forrester, für viel wichtiger und wertvoller als die reine Problemidentifizierung angesehen werden. Außerdem hat APM der dritten Generation das Konzept der "Tools Suites" längst überholt und bietet einen integrierten, systemischen Ansatz über den ganzen Applikations-Lebenszyklus. Trennmauern und Silodenken zwischen und in den einzelnen Abteilungen wird beseitigt und Abläufe durch Automatisierung beschleunigt. Die Systeme der dritten Generation müssen die dynamischen Abläufe in Anwendung unter Last für IT-Experten zur genauen Analyse detailiert aufzeichnen können, die Performance von kritischen Business Transaktionen für Manager auf geschäftlicher Ebene visualisieren und zuguterletzt auch einfach in existierende Umgebungen integrierbar sein - und das alles mit der geringst möglichen TCO (Total Cost of Ownership). Diese neuen Systeme müssen die heutigen Herausforderungen bezüglich Application Performance und Skalierbarkeit ebenso lösen wie die der zukünftigen. Die Eckpfeiler der APM-Lösungen der dritten Generation sind nachfolgend genauer ausgeführt. Zusammengenommen verringern sie die Zeit und Ressourcen, die man benötigt, um Anwendungen über ihren gesamten Lebenszyklus zu erstellen, testen und zu managen erheblich. Die Entwicklungszeit wird optimiert, ebenso wie die Testzeit. Produktionsprobleme und Wartungskosten werden minimiert. Die Markteinführungszeit für neue und verbesserte Anwendungen wird kürzer. Die generierten Werte können enorm sein und die Investitionen amortisieren sich erstaunlich schnell. 3.1 ANFORDERUNG 1: TRANSAKTIONSZENTRIERT Die einzigen Daten, die wirklich Einblick in die Anwendungs-Performance geben, sind die echten Transaktionsdaten die im normalen Betrieb, also etwa unter voller Last, pro Aufruf gesammelt werden. Diese Transaktionsdaten müssen echte einzelne Traces (= Abläufe) über physikalische und logische Grenzen hinweg sein, die selbst entfernte Hops, vom Webbrowser zur Datenbank und wieder zurück inkludieren. Nicht nur Timing-Daten müssen beobachtet und erfasst werden, sondern auch der Kontext der Transaktion - Methodenargumente und Rückgabewerte, SQL-Statements und Verbindungswerte, Nachrichten, Remoting-Parameter, Exceptions, Logs, Synchronisation, Prozessorauslastung, Memory und so weiter. Mit echten Transaktionsdetails, einschließlich des Kontexts eines jeden Aufrufs, wird eine ganz neuer APM-Ansatz ermöglicht. Wir müssen uns nicht länger auf Durchschnittswerte und Korrelationen verlassen, sondern arbeiten jetzt mit den tatsächlichen Transaktionsdaten. Es gibt keine groben Schätzungen mehr. Die Fakten sind klar. Beim Troubleshooting können wir jetzt ausgehend von verdächtigen Tracing von Transaktionen über System- und Technologie-Grenzen hinweg Transaktionen - zu langsam, zu viele Exceptions, zu viele SQL-Statements etc. - oder von Alarmmeldungen beim Überschreiten eines Grenzwerts - bis hinunter in die Codeebene und zu den Laufzeitabhängigkeiten gehen. Hier können wir die Nadeln im Heuhaufen in Minutenschnelle finden. Und mit der Integration in IDEs wie etwa Eclipse und Visual Studio wird letztendlich auch die mittlere Reperaturzeit (Mean Time to Repair) noch weiter reduziert. Beim Management von SLAs können wir jetzt dedizierte Antwortzeiten gewährleisten, nicht bloß durchschnittliche. Für jede problematische Transaktion können wir jetzt Details für die Ursachen der "Ausreißer" analysieren und den Grund auf Codelevel identifizieren was Voraussetzung für eine schnelle Lösung ist. Zusätzlich können wir auch, mit den Transaktionsdetails und dem Kontext, Transaktionen nach bestimmten Anwendern oder Kunden gruppieren, um genau zu sehen, welche dynatrace software

14 Antwortzeiten diese Gruppe in einer beliebigen Zeitspanne bekommt eine sehr wichtige Funktionalität für fortgeschrittenes SLA-Management. Die Einsicht in das echte Laufzeitverhalten sogar hoch komplexer Anwendungen wird erheblich verbessert. Die Visualisierung der dynamischen Abläufe einer Anwendung unter Last durch ein UML- Diagramm, das eine Detailansicht jeder beliebigen VM, der Ebenen (Tiers) oder Services ermöglicht, kann sehr aufschlussreich sein, speziell für Architekten. Modeling ist gut, aber Visualisierung und Monitoring des echten Laufzeitverhaltens auf Transaktionsebene bietet die sonst fehlenden Details für eine Validierung der Architektur und für das erahnen zukünftiger Schwierigkeiten mit der Skalierbarkeit- und Stabilität der Anwendung, bevor diese für den Anwender Störungen verursachen. Im Fall von Programmteilen von Drittanbietern kann ein Service, Framework oder eine ganze Anwendung transparent gemacht werden, ohne dass jedes Detail verstanden werden muss. Das gibt Architekten und Performance-Testern die Fähigkeit zum ersten Mal diese Programmteile so zu verstehen, so dass die Visualisierung des Laufzeitverhaltens der Anwendung Visibilität und die Testabdeckung dramatisch verbessert werden. Alle Vorgänge von der Anwendungsvalidierung bis hin zur Ursachenanalyse werden beschleunigt. Bewaffnet mit echten Transaktionsdetails und deren Kontext gibt es mit den Herstellern dieser Programmteile keine Streitereien mehr darüber, wessen Problem es ist, wenn ein Bug aufgespürt oder eine Schwachstelle in der Anwendungsarchitektur aufgedeckt wird. Schließlich ist ein transaktionszentrierter APM-Ansatz, wenn man Virtualisierung oder Cloud- Computing berücksichtigt, der einzige Weg, der echtes Monitoring, echte Diagnose und Visibilität auf Anwendungsebene bietet. Sogar dann muss das APM-System sowohl physische als auch virtuelle Timing-Parameter genau analysieren, um eine genaue Problemdiagnose zwischen Gast- Betriebssystem, Hypervisor und der Anwendung selbst zu ermöglichen. Mit virtualisierten Umgebungen erreicht die Komplexität des Application Management eine neue Ebene. Nur transaktionszentrierte APM-Systeme, die diese Virtualisierungsschicht auch herausfiltern, bieten die erforderliche Transparenz, die benötigt wird, um die Application Performance und die Skalierbarkeit in diesen hochdynamischen Umgebungen sicherzustellen. 3.2 ANFORDERUNG 2: KONTINUIERLICHER BETRIEB RUND UM DIE UHR Ein transaktionszentrierter Ansatz ist am wertvollsten, wenn die Lösung unterbrechungsfrei 24x7 laufen kann. In der Produktion sollten alle Transaktionen akkurat erfasst werden, so dass Problemsituationen zur genauen Problemdiagnose nicht mehr nachgstellt werden müssen. Während der Test- oder Staging-Phase sollte ein transaktionszentriertes APM-System zusammen mit jedem Lasttest laufen, um alle echten dynamischen Abläufe unter Last genau analysieren zu können. Die entsprechenden Detaildaten müssen sofort für eine Analyse und einen Drill-Down (eine detailliertere Untersuchung) verfügbar sein. Zusätzlich kann in der Produktion das Applikationsverhalten erfasst und anschließend modeliert werden, um es in hoch entwickelte Testsuites in der Test und Stagingphase zu integrieren, so dass Services von Drittanbietern dann für Testszenarien verfügbar sind, was sonst nicht möglich ist. Die Abdeckung der Testbereiche wird so enorm erhöht, ebenso der Realismus, so dass Regressionen in der Entwicklung nun oft gar nicht erst bis in die Produktion gelangen. Ein kontinuierlicher Ansatz, der APM-Systeme der dritten Generation in Produktion, Test und Entwicklung rund um die Uhr einsetzt, erlaubt mit der detialierten ständig aktiven Transaktionsanalyse weit mehr als nur reaktives Troubleshooting: eine proaktive, also vorausschauende Problemidentifizierung, Lösung und Vermeidung. dynatrace software

15 Systeme der dritten Generation, die unterbrechungsfrei im 24x7 Betrieb laufen, bieten eine unübertroffene Detailgenauigkeit und damit eine neue Ebene von BTM (Business Transaction Management), die bisher nicht erreicht werden konnte. Die IT kann Managern aus Fachabteilungen jetzt Echtzeit-Dashboards für wichtige Geschäftstransaktionen bieten. Solche Transaktionen können beispielsweise Online-Angebote, neue Nutzerkonten, Downloads, eine Suche oder Top- Kundenbestellungen sein. Jede Transaktionsgruppe, die performance- oder skalierbarkeits-sensitiv ist, kann beobachtet werden, und wenn Probleme auftauchen, werden diese sofort analysiert, diagnostiziert und korrigiert, oft bevor sie von den Anwendern selbst bemerkt werden. Es gibt andere Anbieter, die sich nur auf BTM-Lösungen spezialisiert haben, jedoch beobachten sie Probleme nur so wie auch traditionellen APM-Tools. Wenn Probleme auftreten, muss immer noch ein Troubleshooting-Team gebildet werden, Logs müssen analysiert werden, und dann beginnt die mühsame Aufgabe der Problem-Reproduktion und der Diagnose. In der Zwischenzeit leiden die Anwender darunter und der geschäftliche Erfolg leidet. BTM ist eine wichtige neue Anforderung für die APM- Systeme der dritten Generation. Service Login VU London Service Credit Tenant #243 Service Booking Tenant #123 Slow! Fails! Das Business Transaction Management verbindet Echtzeit-Business-Dashboards mit tief gehenden Diagnoseansichten Vielleicht noch wichtiger ist aber die Tatsache, dass dynamische Anwendungsumgebungen - wie Multi Application Cluster, virtualisierte Datencenter und Clouds - kontinuierliches 24x7 Monitoring auf Transaktionsebene für ein APM-System erfordern, um überhaupt zur Wertschöpfung beitragen zu können. Da keine zwei Transaktionen notwendigerweise den gleichen Pfad unter den gleichen Umständen nehmen, ist die Verbindung zwischen Symptom und Ursache viel schwieriger, manchmal unmöglich, zu finden, ohne die echten, globalen Transaktionsdetails für jede einzelne Transaktion zu kennen. Wenn Sie also die noch steigende Komplexität zukünftiger Anwendungen einplanen wollen, ist ein APM-System der dritten Generation eine Grundvoraussetzung für die Sicherstellung der Performance, Skalierbarkeit und Stabilität. Wie zuvor beschrieben können die Transaktions-Tracing-Add-Ons traditioneller APM-Systeme, nur kurzfristig, etwa wenn in der Produktion ein Problem augetreten ist, laufen. Auch bei Lasstests sollen sie daher nur sparsam eingesetzt werden. Die Systembelastung ist einfach zu groß, um eine andauernde und unterbrechungsfreie Verwendung zuzulassen. Um diese Limitierung zu überwinden, sind APM-Systeme der dritten Generation schlank genug, um mit sehr wenig Overhead zu laufen, meist nur um 3-5%. Um dies zu erreichen, ist ein neuer architektonischer Ansatz notwendig, bei der innovatives Agent-Design mit einer hoch skalierbaren Server-Collector-Architektur kombiniert wird. Die Datenverarbeitung muss vom Agenten zum Server übergeben werden, und Datensammlung und - Transfer sollten von Agents und wenn nötig Collectors übernommen werden. Diese elegante Architektur kann, wenn sie effizient implementiert wird Millionen von Transaktionen pro Minute in global verteilten Anwendungen nachverfolgen und aufzeichnen. dynatrace software

16 Java.NET Database WAN Agent Agent Collector WAN Analysis Server Verarbeitung der Transaktionsdaten an einem zentralen Server ermöglicht unterbrechungsfreies Transaktions-Tracing rund um die Uhr mit produktionstauglichen Overhead 3.3 ANFORDERUNG 3: IM GESAMTEN SOFTWARE LEBENSZYKLUS INTEGRIERT Darauf haben viele jahrelang gewartet: Ein einzelnes, integriertes APM-System, das Produktion, Test und Entwicklung unterstützt. Ein solches System liefert die Grundlage für eine proaktive Problemlösung und Vermeidung von Problemen und verspricht, die TCO (Total Cost of Ownership) für eine Anwendung über deren Lebensdauer von Jahren erheblich zu verringern. In dieser Hinsicht haben die Tool-Suites der Anbieter von traditionellen Lösungen bisher jedoch versagt, denn es fallen Jahr für Jahr erhebliche Kosten für Professional Services an, um die einzelnen Teile der Suite zusammen zu halten und diese zu managen. Die APM-Systeme der dritten Generation durchbrechen diese Barriere mit einem von Grund auf neuen Design, das diese Anforderungen vorhersah und erfüllt. Zuerst muss eine Installation laufen und eine entsprechende Wertsteigerung in Produktion, Test oder Entwicklung bewirken. Es muss alle Interessengruppen in der Application Performance Management-Kette unterstützen - Entwickler, Architekten, IT-Manager und Business Manager. Die Komponenten müssen wiederverwendbar sein, konsistent in Herangehensweise und Technik, mit einem integrierten Collaboration Framework zur automatisierten Datenerfassung und Kommunikation. Die erforderliche Datenerfassung - das Aufzeichnen von Ausreißern, Transaktion für Transaktion, mit dem entsprechenden Kontext - sollte nicht übersehen werden. Genaue Aufzeichnungen des Anwendungsverhaltens unter Last sind erforderlich für eine faktenbasierte Kommunikation zwischen den Interessengruppen, besonders wenn sich diese nicht am gleichen Ort befinden oder Angestellte eines anderen Unternehmens sind. Aufgezeichnete Informationen sollten in Echtzeit ohne Verzögerung online verfügbar sein, um eine Analyse von endlos laufenden Transaktionen zu ermöglichen, sowie offline, da es oft keinen Echtzeit- Zugriff für Entwickler gibt. Der Idealzustand wäre erreicht, wenn Fehlkommunikation minimiert und Schuldzuweisungen eliminiert würde, so dass eine sofortige Problemlösung durch das richtige Team und das richtige Teammitglied ermöglicht wird. Zweitens müssen diese APM-Systeme nahtlos in existierende Performance-Umgebungen integrierbar sein und deren Wert steigern. In der Produktion heißt das eine einfache Integration in alle Komponenten beginnend mit der Anwendung selbst, den verwendeten Management-Konsolen und Central DB Business-, Systemarchitekt- und Entwickler-Ansichten auf eine einzelne Datenquelle dynatrace software

17 Alarmierungsprozessen, bis hin zum aufzeichnenden Bug-Trackingsystem. Im Testbereich verlangt dies nach einer einfachen Integration in alle Komponenten beginnend mit der zu testenden Anwendung, dem Lasttest-Tool, den Troubleshooting-Prozessen bis hin zum aufzeichnenden Bug- Trackingsystem. In der Entwicklung bedingt das die flexible Unterstützung der Entwicklungsprozesse (z.b. Agile), Integrationen in Continuous Integration Systeme und Entwicklungsumgebungen. Ein APM-System der dritten Generation wirkt sich schnell wertsteigernd aus, indem es redundante, zeitraubende Aufgaben automatisiert, die sonst von hoch bezahlten Personen übernommen werden müssen. Zudem sollten die Wertsteigerungen eines solchen Systems auch in Zukunft gesteigert werden können, da Anwendungsentwicklungs-Prozesse über Entwicklung, Test und Betrieb hinweg silo-übergreifend optimiert werden können. Für alle, die für die Zukunft planen, werden sich APM-Lösungen, die sich im gesamten Lebenszyklus integrieren lassen, bald als Notwendigkeit erweisen, wenn ihre Anwendungen für virtualisierte Datencenter und Clouds optimiert werden. Anwendungsarchitektur und Produktionsumgebungen sollten nicht länger als zwei voneinander unabhängige Entscheidungen behandelt werden. Wie hoch skalierbare Anwendungen in einer virtualisierten Produktionsumgebung entworfen und realisiert werden, ist eine fundamental wichtige und notwendige, möglichst frühzeitige Überlegung in deren Design. Und die einzige verlässliche und konsistente Art und Weise, mit dieser Wechselbeziehung umzugehen, ist der APM-Ansatz, bei dem Entwicklung, Test und Produktion effizient aneinder ausgerichtet und integriert werden. APM for Development APM for Test APM for Production IDEs: Eclipse Visual Studio CI Build Systems: Ant, NAnt MSBuild Maven Load Testers: HP LoadRunner MicroFocus SilkPerformer Microsoft VSTS IBM Rational Performance Center Radview WebLOAD itko SOA Test Neotys NewLoad Proxysniffer Push2Test JMeter OpenSTA End-User Monitoring: Coradiant TrueSight BMC TM-ART Ops Mgmt: IBM Tivoli HP OpenView BMC PM CA Unicenter MS SCOM Continuous APM erfordert nahtlose Integration während des gesamten Lebenszyklus 3.4 ANFORDERUNG 4: HOCH AUTOMATISIERT Es gibt drei Ausbaustufen bei der Automatisierung im APM Bereich, die bei der Einschätzung eines APM-Systems der dritten Generation zu beurteilen sind. Die erste Stufe der Automatisierung ist die der Anwendungsinstrumentierung selbst, in traditionellen APM-Tools eine fast gänzlich manuelle Aufgabe. Der zweite ist der Grad der Automatisierung zur effizienten Eliminierung redundanter, zeitraubender Aufgaben, die uns Zeit und Geld im Form von verlorenen Ressourcen und verlorene Prozesseffizienz kostet. Die dritte Stufe ist der Automatisierungsgrad, der verfügbar ist, um komplexe, dynamische Anwendungsumgebungen zu verwalten, ein Erfordernis, das zusammen mit der wachsenden Komplexität der Anwendungen immer dringlicher wird. Anwendungsinstrumentierung in traditionellen APM-Systemen ist hochgradig manuell und schwierig. Wenn sie nicht richtig durchgeführt wird, drohen schwere Anwendungsprobleme. Mit dem APM- Systemen der dritten Generation können Sie diese Herausforderung mit Smart Agent-Technologie und Sensor Placement Wizards relativ einfach bewältigen. Das Agent-Management ist am Server dynatrace software

18 zentralisiert. Das Deployment der Agents erfolgt automatisch, die Sensoren werden an den logischen Grenzen der Anwendungskomponenten platziert. Idealerweise sollten die Agents "selbstlernend" und zentral konfigurierbar sein, außerdem sollten sie sich automatisch an Lastbedingungen und/oder neuen Produktionskonfigurationen anpassen. Zusätzlich sollten Ihnen Wizards helfen, die Sensoren so zu platzieren, dass die Visibilität bei geringstmöglichen Overhead maximiert wird und so, dass sich die Agents selbst des Overheads bewusst sind, den sie verursachen, um den Administratoren bei der richtigen Instrumentierung zu helfen. Sicherlich muss ein manuelles Überschreiben für jede Sensorplatzierung im Agentmöglich sein, je automatisierter und intelligenter das Instrumentierungssystem jedoch ist, desto leichter ist das Management und desto weniger Pannen gibt es. Die Automatisierung von redundanten, zeitraubenden Aufgaben stellt einen unmittelbaren, sofortigen Wert dar, wenn man ein APM-System der dritten Generation implementiert. Denken Sie an die viele Zeit, die Entwicklern, Architekten und Testern verloren geht, wenn sie sich durch Lasttestberichte wühlen, Tests mit anderen Parametern wiederholen und tausende Zeilen von Logfiles durchsuchen müssen, um jene Probleme zu isolieren, die vielleicht Performance-Probleme verursachen könnten. Untersuchungen zeigen, dass die Entwicklung allein 10-15% ihrer Zeit dazu verwendet, Performance-Probleme zu reproduzieren, diagnostizieren und zu beheben, die alleine in Tests gefunden Lasttests mit integrierter Data Collection auf Code-Ebene automatisiert die Dokumentation von Performance-Problemen werden. Stellen Sie sich vor, dass für jedes Problem, das in einem Lasttestbericht identifiziert wurde, Details auf Transaktionslevel für Performance-Analyst oder den Review der Entwickler/Architekten vorliegen. Und stellen Sie sich vor, dass ein APM-System die häufigsten Diagnoseschritte automatisch ausführt, um die Eingrenzung eines Problems zu beschleunigen. Keine Testdokumentation, die vervollständigt werden muss, keine Tests, die wiederholt werden müssen, keine Debatte darüber, wer verantwortlich ist und kein Streit darüber, was für Probleme wo auftreten. Entwickler und Architekten können ihre Zeit jetzt darauf verwenden, Bugs zu reparieren und die Anwendungen zu verbessern, anstatt potentielle Probleme zu analysieren, reproduzieren und diagnostizieren. Und denken Sie auch an die Zeit, die für den Betrieb, die Architekten, Tester und Management verloren geht, wenn ein Problem mit der Anwendung erst in der Produktion gefunden wird. Die Dokumentation von Vorfällen ist heute eine manuelle Aufgabe, die laut Forrester durchschnittlich eine Stunde Zeit pro Vorfall kostet. Ein Team wird zusammengestellt, um den Bericht des Monitoring-Tools zu überprüfen, mit seinen Durchschnittswerten und Korrelationen. Sie schätzen grob ein, wo man anfangen muss, lassen Logs auslesen, gehen wieder auseinander, um die Daten sorfältig zu analysieren, führen lange Telefongespräche, versuchen das Problem in Tests oder Staging nachzuvollziehen und so weiter. Forrester schätzt, dass die Entwicklung allein bis zu 25% ihrer Zeit mit der Analyse, Problemreproduktion und Diagnose von Fehlern verbringt, die in der Produktion gefunden wurden, und in 25% der Fälle wird die Problemursache niemals gefunden. Jetzt stellen Sie sich vor, dass jedes Mal, wenn ein Alarm ausgelöst wird, gleichzeitig Details zur Transaktion und dem entsprechenden Anwendungskontext aufgezeichnet werden, der das Problem verursacht hat. Diese detaillierten Aufzeichnungen werden einem Architekten übergeben, der dann das Problem im groben auswertet, entsprechend einschätzt und dem zuständigen Entwicklungsteam übergibt. Dieses Team kann dann die entsprechenden Codezeilen identifizieren und in ihre Entwicklungsumgebung öffnen, um den Fehler zu beseitigen. Keine langen Konferenzgespräche mehr, keine groben Schätzungen, kein verschwendeter Aufwand. Die Entwickler sind viel produktiver, die Kunden glücklicher und das Management kann besser schlafen. Da wir uns auf dynamische Produktionsumgebungen zu bewegen, werden agentenbasierte APM- Ansätze als erstes in Schwierigkeiten geraten, wenn sie sich nicht automatisch deren Dynamik dynatrace software

19 anpassen können. Virtualisierte Produktionsumgebungen und Clouds werden fast nie homogene Hardware-, Betriebssystem- und Anwendungsserver-Konfigurationen besitzen. Daher müssen neue APM-Systeme, um diese hoch entwickelten Produktionsumgebungen zu unterstützen, jede neue Instanz automatisch einbinden und die Datensammlung sofort starten, um sicherzustellen, dass die Integrirät des End-to-End Tracing gewahrt bleibt. APM-Systeme müssen sich daher dynamisch auf die sich ständig ändernde Produktionsumgebung anpassen, um die gesamten Pfade akkurat und im Detail aufzuzeichnen. Da sich die Ausführpfade und das Verhalten von Transkationen in so einer dynamischen Umgebung unter Last mitunter unerwartet ändern, kann nur so die Performance, Skalierbarkeit und Stabilität von Anwendungen in dynamischen Produktionsumgebungen sichergestellt werden. Automatisierung ist eine vielseitige Anforderung an die APM-Systeme der nächsten Generation, und eine Gelegenheit für eine enorme Wertsteigerung für diejenigen, die sie in den Lebenszyklus ihrer Anwendungen integrieren. Mit steigender Komplexität und Produktionsumgebungen, die immer dynamischer und virtualisierter werden, ist Automatisierung mehr als eine Bequemlichkeit. Sie ist eine Notwendigkeit. 3.5 ANFORDERUNG 5: WERTSTEIGERUNG BESTEHENDER INVESTIONEN Wie bereits im vorigen Kapitel "Grenzen" aufgeführt, haben die meisten Unternehmen schon beträchtliche Investitionen in Application Management-Tools und Prozesse getätigt. Jede Interessengruppe und jedes Team im Software-Lebenszyklus hat heutzutage eine eigene Arbeitsweise. Die ist vielleicht nicht optimal, aber vertraut. Jedes neue System, das in ein bestehendes APM-System eingeführt wird, muss daher nahtlos integrierbar sein und den Wert und die Effizienz des früheren Systems bezüglich Tools, Systeme und Prozesse steigern. Die Integration sollte leicht und erweiterbar sein, so dass sich der Einsatz von Professional Services auf ein Minimum beschränken und die Selbstständigkeit des Anwenders maximieren lässt. APM-Systeme der dritten Generation haben den Vorteil, dass sie neu und mit neuen Techniken erstellt worden sind, sodass sie eine leicht verständliche, leicht erweiterbare, offene Umgebung darstellen. Ein Open Source Model (z.b. OSGi) für Monitore, Erweiterungen und Integrationen bedeutet schnelle Amortisierung und maximale Erweiterungsfähigkeit. Der Hersteller des APM- Systems selbst kann sein Angebot mit der Zeit verbessern, indem es seinen Kunden eine wachsende Liste mit Plugins für verschiedene verwandte Funktionalitäten anbietet, wie beispielsweise Systemund Betriebssystem-Monitoring, synthetisches End-User Experience Monitoring und Integrationen mit automatisierten Build-Systemen, Lasttest-Tools, Managementkonsolen und Bug-Trackingsystemen. Kunden können selbst eigene neue Plugins hinzufügen oder existierende modifizieren, ihren eigenen Anforderungen entsprechend. Alle Plugins können, da sie Open Source sind, als Modelle verwendet, leicht modifiziert, validiert und aktiv genutzt werden. Wenn also ein Community Portal verfügbar gemacht wird, können Kunden Plugins gemeinsam nutzen, so dass der Wert der ersten APM- Investition gesteigert wird. dynatrace software

20 Monitors -Synthetic end-user monitoring -URL pinger -System monitoring Extensions -Preconfigured sensor packs -Automatic session analysis -Management actions Integrations -IDEs -CI and load testing -Operations management -Incident management OSGi OSGi OSGi Continuous Application Performance Management Systems Ein offenes Plugin-Modell garantiert leichte Erweiterbarkeit und damit eine Wertsteigerung bestehender Investitionen Ein offenes Datenmodell ist zudem für die Integrationsfähigkeit eines APM Systems der dritten Generation auch sehr wichtig. Traditionelle Systeme erfordern oft eine maßgeschneiderte Integration um die speziellen Anforderungen eines Kunden bezüglich des Reportings zu erfüllen, oder um einen bestimmten Geschäftsprozess entsprechend unterstützen zu können. Die APM-Systeme der dritten Generation sollten einen offenen, Webservice-basierten Zugang zu normal lesbaren Performance- Berichten und zu strukturierten, XML-basierten Performance-Resultaten bieten, damit sich wiederholende Analyseaufgaben (z.b. herausfiltern von Performanceveränderungen zwischen aufeinander folgenden Testläufen, Transaktionen mit mehr als 100 SQLs, etc.) einfach automatisiert werden können. Zusätzlich bedeutet diese Offenheit auch, dass Open Source-Datenbanken wie PostgreSQL zusätzlich zu kommerziellen wie Oracle, DB2 und SQL Server für eine permanente Datenspeicherung zur Verfügung stehen sollen. Zusammengenommen definieren diese Anforderungen die Ansätze für APM-Systeme der dritten Generation, um den Herausforderungen der immer komplexer werdenden Anwendungsentwicklung und der global verteilten, hoch dynamischen Anwendungsumgebungen von morgen zu begegnen. Es ist ein Ansatz, der die Effizienz von Anwendungsentwicklung, Test und Troubleshooting maximiert - so spart man eine Menge Zeit und Ressourcen im gesamten Anwendungs-Lebenszyklus. dynatrace software