Von Raphael Pionke, Quality Architekt bei Telekom MMS
Für jedes Unternehmen ist es ein Albtraum, wenn Produktseiten nicht mehr aufrufbar oder Dienste nicht nutzbar sind und der Kunde seinen Kauf nicht tätigen kann. Dies bedeutet oft einen großen Verlust. Aus diesem Grund ist es besonders wichtig, Überlastungsgrenzen, fehlerhafte Anwendungen oder Störursachen schnellstmöglich zu erkennen und diese zu beheben. Daher sollten Unternehmen regelmäßig Lasttests durchführen. Unser Team für Application Performance Management (APM) und Lasttests hilft Kunden eine automatisierte Ursachenerkennung und Ausfallsicherheitsüberprüfung zu ermöglichen.
Um Performance- und Skalierbarkeitsprobleme zu identifizieren nutzen wir KI-basierte Whitebox-Last- und Ausfallsicherheitstests, welche mit JMeter durchgeführt werden in Kombination mit Dynatrace. In diesem Blog-Artikel erfahren Sie mehr über das Thema Application Performance Management mit Open Source Tools & Dynatrace von Raphael Pionke, Quality Architekt bei Telekom MMS.
In den letzten Jahren haben sich die Kundenprojekte in Richtung komplexer Cloud-Architekturen entwickelt, die Dutzende von Micro-Services und unterschiedlichen Technologie-Stacks umfassen, was eine Herausforderung für die Entwicklung, Wartung und Optimierung der Ausfallsicherheit darstellt. Aus diesem Grund haben wir Dynatrace in fast allen wichtigen Anwendungen unserer Kunden implementiert, um Transparenz vom Endbenutzer bis zur Code-Ebene zu erhalten und die Zeit für Problembehebungen und proaktive Skalierbarkeitsoptimierungen mit Hilfe der KI-basierten Ursachenanalyse von Dynatrace zu reduzieren.
Unsere Kunden binden uns normalerweise 2-4 Wochen vor der Produktionsfreigabe ein. Dies scheint zwar sehr spät im Entwicklungszyklus zu sein, aber unser White-Box-Ansatz zur Validierung der Release-Readiness ermöglicht es uns, konkrete Empfehlungen zur Behebung von Skalierbarkeitsengpässen sowie zur Verbesserung der Leistung und Ausfallsicherheit zu geben.
Black-Box-Lasttests ohne Monitoringlösung sind heutzutage unvorstellbar, da sie zu viel Zeit in Anspruch nehmen, aufgrund fehlender Daten nicht automatisiert werden können und daher nicht skalierbar sind. Unsere Lösung ist ein Ansatz, den wir White Box nennen, bei dem wir Open-Source-Lasttest-Tools wie JMeter mit der Beobachtungsfunktion und den Analysefunktionen von Dynatrace kombinieren. Auf diese Weise können wir unseren Kunden Dienstleistungen anbieten, die sich auf die folgenden drei Hauptpfeiler konzentrieren:
- Skalierbarkeit: Unsere Lösung nutzt eine skalierbare Cloud-Infrastruktur
- Automatisierung: Einzelne Lasttestausführungen können wiederholt und nachverfolgt werden. Jeder Schritt ist automatisiert, von der Bereitstellung der Infrastruktur bis zur Problemanalyse.
- Transparenz: Wir verlassen uns auf tiefe Einblicke, die Dynatrace bieten kann, einschließlich verteiltem Tracing einzelner Anfragen.
Nun zu den technischen Details, wie unsere Lösung funktioniert und wie wir JMeter mit Dynatrace verbinden, um eine automatisierte Ursachenerkennung und Ausfallsicherheitsüberprüfung zu ermöglichen:
Schritt 1: Integration von JMeter mit Dynatrace
Die Dynatrace-Dokumentation und die Video-Tutorials geben einen guten Überblick über die Integration jedes HTTP-basierten Testwerkzeugs mit Dynatrace. Hier zeigen wir Ihnen, wie wir diese Praktiken implementiert und erweitert haben!
Testkontext durch Web-Request-Header
Wir fügen den „x-dynatrace-test“-Header zu jeder Anfrage hinzu, der den aktuellen Testschritt und den Namen der Thread-Gruppe/des Anwendungsfalls enthält:
Dieser Header wird von Dynatrace interpretiert und kann während der Analyse verwendet werden, um zwischen Lasttestanfragen und anderen Anfragen (z.B. von anderen Testwerkzeugen oder echten Benutzer*innen) zu unterscheiden.
Nutzung des W3C Trace Context Headers
Während der Kontext des Testschritts, des Anwendungsfalls und des Thread-Gruppennamens hilfreich ist, wollen wir auch die Analyse einzelner fehlgeschlagener Anfragen beschleunigen. Wenn JMeter einen Fehler meldet, sollte es nur ein einziger Klick sein, um den Trace zu analysieren (ein Dynatrace PurePath).
Eine gute Lösung ist der W3C Trace Context Standard, der von Dynatrace, Google, Microsoft und anderen entwickelt wurde. Dieser Request Header besteht aus verschiedenen Komponenten zur eindeutigen Identifizierung jedes einzelnen Abschnitts eines verteilten End-2-End-Trace. In unserem Fall waren die Parent-ID und die Trace-ID die wichtigsten.
Wir generieren eine eindeutige Trace-ID für jede einzelne Anfrage über alle Threads und JMeter-Agenten hinweg. Einerseits fügen wir diesen Wert als zusätzlichen HTTP-Header hinzu, der dann von Dynatrace aufgegriffen wird. Auf der anderen Seite speichern wir diese Trace-ID zusammen mit der fehlgeschlagenen Anfrage und anderen Metainformationen (Screenshot, Zeitstempel usw.) als Teil unserer Testergebnisse:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "TimeStamp": "2021-11-24 14:11:00", "VUID": "VU-4", "Sample": "0010_Startseite_Labelkauf_RT", "ThreadGroup": "Labelkauf - Basic load", "APM-TracingId": "00-19c0383f590caeebffbaa09b819f50bd-1637762145174fff-01", "SamplerClass": "org.apache.jmeter.protocol.java.sampler.JSR223Sampler", "CurrentUrl": "https://mycompany.com/send-parcel/gw/restweb/nepal/portal.html?type=ShipmentEditorProductSelection", "failedOnLabeledWebElement": "Section fuer MyCompany Application", "Screenshot": "Labelkauf/0010_Startseite_Labelkauf_RT-20211124-141101-VU4-10.175.18.82.png", "responseCode": "500", "responseMessage": "javax.script.ScriptException: org.openqa.selenium.TimeoutException: Expected condition failed: waiting for visibility of element located by By.cssSelector: section.mm_section.mm_section-primary.position-relative (tried for 20 second(s) with 500 milliseconds interval)", "responseData": "" } |
Diese Tracing ID kann dann in der Distributed Traces Ansicht in Dynatrace verwendet werden, um den dazugehörigen Dynatrace PurePath für diese W3C Trace Context ID zu finden.
Ein Klick mehr und Dynatrace zeigt uns den vollständigen Trace (=Dynatrace PurePath), der es einfach macht, zu identifizieren, warum eine Anfrage langsam war oder fehlschlug, welche Backend-Services oder Datenbanken beteiligt waren:
Das Fehlerprotokoll des JMeter Lasttests enthält eine Meldung über ein fehlendes Element, das mit Hilfe der W3C Trace Context Id auf eine Exception im Anwendungscode zurückgeführt werden kann.
Dynatrace Backend Listener für JMeter:
Dynatrace Engineering hat einen Backend-Listener für JMeter entwickelt, den sie intern verwenden. Er sendet automatisch JMeter-Metriken an das Dynatrace-Cluster über die Metrics Ingest API. Diese Metriken können verwendet werden, um den Lasttestplan oder die Ziellast zu validieren und um zwischen verschiedenen Anwendungsmetriken Verknüpfungen zu schaffen. Der Screenshot unten zeigt ein Dynatrace-Dashboard, das JMeter-Metriken neben den nativ von Dynatrace erfassten Metriken anzeigt:
Mit einem solchen Dashboard können wir leicht die getaggten Webanfragen für jeden Anwendungsfall mit Antwortzeit und Anzahl auslesen. Im gegebenen Beispiel war das Ziel, die maximale Anzahl der gleichzeitigen Anfragen pro Stunde zu ermitteln und das Antwortzeitverhalten über die Testlaufzeit zu untersuchen. Aus den Graphen lässt sich ablesen, dass die Antwortzeiten am Ende des Tests deutlich angestiegen sind.
Das Dashboard kombiniert die Lasttest-Metriken von JMeter mit CPU/Memory/JVM-Metriken für die JMeter-Infrastruktur (Agenten und Controller) und den Anwendungs- und Infrastruktur-Metriken, die von Dynatrace erfasst werden. Die zu testende Anwendung verwendet ein Azure Application Gateway und einen Load Balancer vor den Worker Nodes, die ebenfalls Teil dieses Dashboards sind, da Dynatrace automatisierte Unterstützung für die Erfassung von Metriken aus Cloud-Diensten wie Azure bietet.
Die Einrichtung des White-Box-Lasttest-Projekts
Nachdem wir erklärt haben, wie wir JMeter in Dynatrace integrieren und was wir mit den Daten machen können, sobald sie in Dynatrace sind, wollen wir nun erklären, wie wir die Ausführung und Analyse von Leistungstests als Teil unserer Lasttestprojekte automatisieren. Die folgende Abbildung gibt einen Überblick über unsere Architektur und unser Setup:
Jedes Lasttestprojekt wird in einem separaten Git-Repository mit allen notwendigen Metainformationen definiert:
- Propertyfiles für Workloads,
- Testdaten
- einen Testplan und
- ein Jenkinsfile.
Unsere Jenkins-Instanz verfügt über einen Seeder-Job, der die Jobs durch automatisches Einlesen aller Git-Repositories erstellt.
Terraform und Ansible zur Bereitstellung der Infrastruktur und Konfiguration von Dynatrace
Die Testinfrastruktur und die Dynatrace-Konfiguration werden über Terraform bereitgestellt. Der Azure Terraform-Provider erledigt alle infrastrukturbezogenen Aufgaben. Der neue Dynatrace Terraform Provider wird verwendet, um alle notwendigen Dynatrace Konfigurationsschritte durchzuführen:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
locals { apps = [ { name : "ABC", zone : "1809_ABC" }, { name : "DEF", zone : "3328_DEF" } ] } resource "dynatrace_calculated_service_metric" "teststep-metric" { count = length(local.apps) name = "Teststep avg. response time (${local.apps[count.index].name})" enabled = true … } resource "dynatrace_calculated_service_metric" "usecase-metric" { count = length(local.apps) name = "UseCase avg. response time (${local.apps[count.index].name})" enabled = true … } resource "dynatrace_request_attribute" "x-dynatrace-test_NA" { name = "x-dynatrace-test NA" enabled = true … } resource "dynatrace_request_attribute" "x-dynatrace-test_PC" { name = "x-dynatrace-test PC" enabled = true … } resource "dynatrace_dashboard" "golden_signals" { dashboard_metadata { name = "${local.apps[count.index].name} – Jmeter loadtest results" owner = "Dynatrace" shared = true filter { timeframe = "-1h to now" management_zone { name = local.apps[count.index].zone } } } } |
Diese Datei zeigt, wie man ein Starterpaket für jedes neue Projekt implementiert. Nach der Erstellung der Testinfrastruktur verwenden wir Ansible als Konfigurationsmanagement-Tool, um Docker zu installieren, die Jenkins-Agenten und den Dynatrace OneAgent vorzubereiten.
Analyse der Testergebnisse
Jeder Testlauf wird in unserem selbstentwickelten Testmanagement-Tool dokumentiert, um Konfigurationsänderungen zwischen verschiedenen Testläufen zu verfolgen:
Das selbst entwickelte Testmanagement-Tool der Telekom MMS ermöglicht den direkten Zugriff auf die Ergebnisse jedes Testlaufs.
Über das von uns entwickelte Testmanagement-Tool können verschiedene Benutzeroberflächen unserer Testautomatisierung aufgerufen werden, z.B. Jenkins, Git, JMeter, das Dynatrace-Dashboard zusammen mit dem Testzeitrahmen und unser selbst entwickelter Report Engine-Testbericht:
Die Ergebnisübersicht zeigt derzeit Daten aus JMeter, die durch Parsen der JLT-Rohdaten nach Anwendungsfällen aufgeteilt wurden.
Nächste Schritte: Zusammenarbeit mit Keptn
Wir streben immer nach mehr und einfacher zu handhabender Automatisierung. Aus diesem Grund werden zukünftige Projekte eine dedizierte Jenkins-Pipeline-Bibliothek verwenden, um den verwaltbaren Code in den Jenkins-Dateien zu reduzieren und schneller wiederzuverwenden.
Einige bereits etablierte und laufende Lasttest-Projekte stellen derzeit auf kontinuierliche Lasttests mit Pipeline-Integration um, anstatt das Lasttest-Team für die manuelle Auslösung von Tests nur bei der Veröffentlichung größerer Releases einzubeziehen.
Unser Team arbeitet auch mit Dynatrace zusammen, um einige dieser Funktionen durch das Open-Source-Projekt Keptn zu standardisieren. Im Kern verwendet Keptn einen SLO (Service Level Objective) Scoring-Ansatz, um die Analyse über mehrere Metriken (SLIs) zu automatisieren. Diese Funktionalität wollen wir besser in Jenkins und unsere Berichtsfunktionen integrieren. Darüber hinaus löst Keptn die Herausforderung der Interoperabilität zwischen verschiedenen Tools wie Konfigurationsmanagement-, Infrastruktur-, Bereitstellungs-, Test- und Beobachtungstools. Da der Wechsel oder die Integration neuer Tools in einen Automatisierungsprozess immer mit viel Arbeit verbunden ist, erwarten wir, dass Keptn uns helfen wird, den Automatisierungsaufwand in unseren aktuellen Jenkins-Pipelines zu verringern.
Intelligente Plattform – Dynatrace Monitoring
Gastautor Raphael Pionke, Quality Architekt bei Telekom MMS
Raphael Pionke ist seit 2013 als DevOps Engineer und IT-Architect im Bereich Application Performance Management tätig. Während dieser Zeit begleitete er zahlreiche Projekte für KMU, Großunternehmen und den öffentlichen Sektor. Seit 2020 beschäftigt er sich als IT-Architekt intensiv mit den Themen Performance, DevOps, IaaC, Cloud und der Implementierung & Anwendung von intelligenten APM-Lösungen.
Co-Autor Andreas Grabner, Dynatrace
Andreas Grabner hat mehr als 20 Jahre Erfahrung als Softwareentwickler, Tester und IT-Architect und ist ein Verfechter von hochperformanten Cloud-Scale-Anwendungen. Er leistet regelmäßig Beiträge für die DevOps-Community, spricht häufig auf Technologiekonferenzen und veröffentlicht regelmäßig Artikel auf blog.dynatrace.com.
Ob Digitalisierungsexpert*in, Werkstudent*in oder Schülerpraktikant*in – Hier berichten unsere Gastautoren aus ihrem Alltag.
