Evolution: Von Performance Tests zur produktiven Anwendungsüberwachung

Transkript

1 QualityConf 2011 Evolution: Von Performance Tests zur produktiven Anwendungsüberwachung Manuel Núñez, Stefan Ruppert MyARM GmbH Altkönigstraße Kriftel Deutschland web: info@myarm.com QualityConf 2011, München 30. März 2011

2 Inhalt Annahmen und Motivation Modellbildung Application Response Measurement Standard (ARM) Anwendungsinstrumentierung Testzyklus Integration in produktive Umgebungen Kennzahlen QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 2

3 Annahmen Verteilte Systeme sind gutes Beispiel für relevante Szenarien Nonfunktionale Aspekte zu oft vernachlässigt Messen realer Werte ist unersetzlich Testphase hat bei Messungen herausragende Bedeutung Gemeinsam genutztes Werkzeug notwendig QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 3

4 Motivation (nonfunktional) Nonfunktionale Aspekte sind schwer zu erfassen Hohe Komplexität Verteilter Systeme Fehlende Instrumentierung Fehlende Lasttreiber Infrastruktur anders als Produktionsumgebung Manche Probleme sieht man nur im Betrieb QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 4

5 Motivation (Messungen) Im Ingenieurswesen werden Systeme durch Messungen über die gesamte Lebensspanne qualitätsgesichert Materialien (Dichte, Härte, Leitfähigkeit) Prozesse (Schweißstrom, Pressdruck) Funktionsprüfungen (Airbag) Betriebswerte (Öltemperatur, Füllstände) Fehleranalysen QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 5

6 Modellbildung (Messgrößen) Interessante Kriterien für Softwaresysteme CPU-Zeitverbrauch Netzwerklatenzen, Bandbreiten Speicherverbrauch Fachliche Kennzahlen Alle relevanten Messwerte schlagen sich in der Antwortzeit nieder QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 6

7 Modellbildung (Antwortzeit) In Verteilten Systemen ist Antwortzeit ein sehr gutes Maß für die Qualität des Services (im Betrieb). Sie beinhaltet: Netzlaufzeiten Zeiten in anderen Systemen Technisch bedingte Verzögerungen CPU Netzlast Parallelisierungsgrad QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 7

8 Modellbildung (business tx.) Laufzeitmessungen als Grundlage für Beurteilung eines Systems im Betrieb Änderungshinweise für Architektur Änderungshinweise für Entwicklung Auswahl der relevanten Services, Transaktionen etc. der Anwendung ist die eigentliche Modellierung business transactions QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 8

9 Modellbildung (Erwartung) Architektur und Entwicklung: Erwartungswerte formulieren Toleranzbereiche festlegen Wenn bekannt, ansonsten können Informationen in Testphase abgeschätzt werden QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 9

10 Modellbildung (Entwicklung) Reichert Architektur Performancemodell um technische Messpunkte an (technical transaction) Validiert die Erwartungen Zeigt Engpässe auf QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 10

11 ARM Standard QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 11

12 ARM (Architektur) QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 12

13 ARM Konzepte (Überblick) QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 13

14 ARM Transaktionen Zentraler Begrif der Transaktion Start- und Stoppzeiten Defnition ( was ) Vater-Transaktion Applikation Status (GOOD, FAILED, ABORTED) Weitere Kontextdaten QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 14

15 ARM Selektionskriterien Kriterien, nach denen in Auswertungen selektiert werden kann: Properties Metrics System User Application QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 15

16 ARM Konzepte (Details) QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 16

17 Testzyklus Während Entwicklungsphase messen, verifzieren etc. Test kann inhaltlich prüfen (entsprechen Abläufe fachlichen Vorgaben?) Test prüft auch Erwartungen bzgl. Performance, Fehlerbehandlung Ergebnisse fießen in Architektur, Entwicklung zurück QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 17

18 Anwendungsüberwachung Ermittlung von KPIs möglich Tracing für Fehleranalyse Statistische Aggregation APDEX-Index zur einfachen Ermittlung von tolerierbaren Zeitdauern Ggf. Korrelation mit Log-Einträgen SLAs QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 18

19 Kennzahlen (MyARM) Call-Overhead für Java typisch 2,5-6 µs Call-Overhead für C typisch 1,1-4,8 µs Ca. 100 Byte je Messung serialisiert Inserts je Sekunde in DB Ca Messungen/s in Applikation Implementierung entkoppelt von Applikation, Speicher-Backend Keine Störung der Applikation QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 19

20 Zusammenfassung Instrumentierung für alle beteiligten Parteien nützlich Nonfunktionale Aspekte lassen sich einfach messen, überprüfen Einbautes Konzept der Korrelatoren Verteilte Architektur dabei kein Problem ARM gestattet auch Messung funktionaler Kennzahlen QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 20

21 Ende Danke für Ihre Aufmerksamkeit! QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 21

22 Background QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 22

23 ARM Architektur QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 23

24 ARM (response time) QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 24

25 QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 25

26 ARM Korrelationsbeispiel QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 26

27 ARM APDEX Apdex T = Satisfied count Tolerating count 2 Total count QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 27

28 MyARM Manager Korrelation QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 28

29 MyARM Manager Korrelation QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 29

30 Nonfunktionale Tests Nonfunktionale Tests, wenn vorhanden Oft manuell durchgeführt Ad hoc Zeitintensiv Unscharf formuliert QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 30

31 Motivation (III) Nonfunktionale Regressionstests nur mit hohem Aufwand machbar Wie kommt man zu Aussagen über Skalierbarkeit und Fehlertoleranz? Bei der Erstellung der Architektur Entwicklungsentscheidungen Test Betrieb QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 31

32 Motivation (IV) Informationen bzgl. Performance etc. werden meist aus Log-Dateien extrahiert Unscharf (Granularität der Zeitstempel) Langsam (IO-Systeme etc.) Unfexibel (Skripte) Geringe Aufösung (lediglich Start&Stop) Wie korreliert man Ereignisse in anderen Systemen? QualityConf 2011, München, 30. März 2011, Manuel Núñez Folie 32