EKON 18: Metriken und Anwendungsanalyse

My slides for the EKON 18 (2014) talk about metrics and application analyses.

Transcript

1. EY, WAS GEHT AB? Metriken und Anwendungsanalyse EKON 18, November 2014 Sebastian P.R. Gingter, Smarthouse Media GmbH 0
2. Vorab: Slides auf Speakerdeck: https://speakerdeck.com/PhoenixHawk Sourcen auf Github: https://github.com/gingters Twitter: @PhoenixHawk E-Mail: sebastian@gingter.org Delphi-PRAXiS: Phoenix
3. “Wissen ist Macht.” - Francois Bacon
4. Wir kümmern uns tagtäglich um die Daten unserer Kunden. Damit sie ihre Arbeit besser machen können. Wer kümmert sich um unsere Daten, damit wir unsere Arbeit besser machen können?
5. “Klug fragen können ist die halbe Weisheit.” - Francois Bacon
6. Welche Informationen - die wir schon haben – helfen uns, effizienter zu arbeiten? Welche Informationen - die wir noch nicht haben - würden uns am ehesten helfen, effizienter zu arbeiten?
7. Fragestellungen: Wo liegen aktuell unsere Probleme? Wo können akute Probleme auftreten, und wo würden uns diese am ehesten weh tun? Welche Informationen brauchen wir, um das zu verifizieren? Welche Informationen brauchen wir, um das zu beheben? Wo können wir mit geringem Aufwand viel für unsere Kunden bewirken?
8. Beispiele: Performanceentwicklung mit steigendem Datenbestand langfristige Entwicklung Nutzerverhalten Feature-Nutzung
9. Nutzen, was wir haben Oder schnell bekommen können
10. Logfiles
11. Anforderungen Zugriff auf Logdateien oder einen Rückkanal für Logdateien
12. Logfiles Eigene Anwendungslogs? Am besten mit Timestamp? Logs anderer Anwendungen: Webserver-Logs: Apache, IIS etc. Datenbanken: MySQL, Firebird etc. etc. pp. Auswertung: Freie Tools: Supercool: Erlaubt SQL gegen Logfiles LogParser von Microsoft Lizard Log Parser GUI Artikel Charting mit Logparser
13. Beispiel: l o g p a r s e r " s e l e c t q u a n t i z e ( t i m e , 6 0 ) a s T i m e G e n e r a t e d , c o u n t ( * ) a s H i t s i n t o q n t . g i f f r o m * . l o g w h e r e t o _ l o w e r c a s e ( e x t r a c t _ e x t e n s i o n ( c s - u r i - s t e m ) ) = ' a s p x ' g r o u p b y T i m e G e n e r a t e d " - i : i i s w 3 c - o : c h a r t - c h a r t T y p e : L i n e
14. Beispiel: l o g p a r s e r " s e l e c t e x t r a c t _ e x t e n s i o n ( c s - u r i - s t e m ) a s R e s o u r c e , m u l ( p r o p c o u n t ( * ) , 1 0 0 . 0 ) a s R e s o u r c e H i n t o p e r c e n t a g e . j p g f r o m * . l o g g r o u p b y R e s o u r c e o r d e r b y R e s o u r c e H i t s d e s c " - c h a r t T y p e : P i e E x p l o d e d 3 D - c h a r t T i t l e : " P e r c e n t a g e s p e r d a t a t y p e " - c a t e g o r i e s : o f f - o : c h a r
15. Wozu? Wir bekommen Aussagen über Nutzung / Lastverhalten (z.B. DB/Sessions über Zeit)? Performance-Informationen (Zeit pro Aktion) Fehlerverhalten (Fehler/Zeit)
16. Datenbank & Datenbestand Statistische Daten
17. Anforderungen Zugriff auf Datenbank(en) oder einen Rückkanal für statistische Daten
18. Erste Statistiken Datensätze pro Tabelle Entwicklung der Anzahl über Zeit Regelmäßig S E L E C T C O U N T ( * ) F R O M t b l X Y Z Datensätze Datensätze über Zeit tblStammdaten tblNutzdaten Jan Feb Mär Apr Mai Jun 0 500 1000 1500 2000
19. Noch besser: Created Timestamp? Daten sofort historisch verfügbar! Modified Timestamp? Durchschnittliches Alter eines Datensatzes Verhältnis Neuanlage / Änderung über Zeit Beides normalerweise über Trigger realisierbar Nicht zwangsläufig Code-Anpassungen notwendig
20. Wozu? Welche Tabellen werden oft bearbeitet? Welche Masken sind hierfür notwendig? Hier mit Optimierungen beginnen Mehr neu als Ändern? ↣ Wizard? Mehr Ändern als Neuanlage? Auf Usability für Änderungen optimieren z.B. Welche Felder werden meist geändert? ↣ Nach vorne.
21. Nutzen, was wir noch nicht haben
22. Metriken Einfache Messungen (Zeiten, Werte)
23. Einfache Metrics-API p u b l i c i n t e r f a c e I M e t r i c s C o l l e c t o r { v o i d I n c r e m e n t ( s t r i n g k e y , s t r i n g d e s c r i p t i o n = n u l l ) ; v o i d D e c r e m e n t ( s t r i n g k e y , s t r i n g d e s c r i p t i o n = n u l l ) ; v o i d M a r k ( s t r i n g k e y , s t r i n g d e s c r i p t i o n ) ; v o i d G a u g e ( s t r i n g k e y , i n t v a l u e , s t r i n g d e s c r i p t i o n = n u l l ) ; I T i m e r C o n t e x t T i m e ( s t r i n g k e y , s t r i n g d e s c r i p t i o n = n u l l ) ; } p u b l i c i n t e r f a c e I T i m e r C o n t e x t : I D i s p o s a b l e { v o i d A b o r t ( ) ; v o i d F i n i s h ( ) ; }
24. Einfache Metrics-API Implementation sended Aufrufe an Metrik-Logger (z.B. Graphite, bzw. dessen StatsD Prozess). Beispiel Graphite: Graphite: Web-Frontend um Metriken graphisch darzustellen Carbon: Cache für Metriken und Storage-Backend für Graphite Whisper: fixed-size Datenbank, erlaubt variable Zeiträume und Auflösungen StatsD: Einfacher Daemon um Statistiken für Carbon vorzuaggregieren
25. Einfache Metrics-API Whisper Beispiel für Resolution:Retention: Sekundengenau für 4 Stunden, 1s:4h 10-Sekundengenau für 1 Tag, 10s:1d Minutengenau für 3 Tage, 1m:3d Viertelstundengenau für 1 Woche, 15m:7d Stundengenau für 1 Monat, 1h:31d Tagesgenau für 1 Jahr, 1d:1y
26. Einfache Metrics-API Whisper Charme: Platzverbrauch exakt berechenbar. Wie eben: 1s:4h, 10s:1d, 1m:3d, 15m:7d, 1h:31d, 1d:1y 60 * 60 * 4 + (60 / 10) * 60 * 24 + 60 * 24 * 3 + (1 / 4) * 24 * 7 + 24 * 31 + 365 = 28511 Einzelwerte 28511 * 12 Bytes pro Einzelwert + Metadaten (28 bytes) = 342160 Bytes = 342 KB.
27. Einfache Metrics-API StatsD Zeiten sind komplexer und haben mehrere Metriken Lower Bound (kürzeste Messung) Upper Bound (längste Messung) Mean (durchschnittlicher Wert) Count (Anzahl der Messungen in der Periode / resolution) 90th percentile (90% der Werte sind unter X und 10% drüber) Auflösung via StatsD meist pro Minute voraggregiert
28. Wozu? „Grenzraumüberwachung“ (alle Schnittstellen messen, Timings) Ermittlung von Featurenutzung (Counter / Inc) Ablage von statistischen Daten (von vorher) Datenvolumen (Gauge) Deployments (Marks)
29. Beispiele:
30. Basic performance data ms Frontend Backend‑Service Database 00:00 04:00 08:00 12:00 16:00 20:00 24:00 0 200 400 600 800
31. Ausblick & Möglichkeiten Aus Logs Statistiken ermitteln und in Graphite werfen Log-Einträge 1:1 in ElasticSearch werfen in Echtzeit mit Kibana auswerten Aus Kibana Statistiken ermitteln (z.B. Anzahl Fehler/Zeit) Aus Statistiken Prognosen ermitteln und diese Monitoren Beispiel: Performance-Schwelle wird in X Tagen erreicht (Frühwarnsystem)
32. Ressourcen LogParser (Microsoft) Lizard LogParser GUI Graphite StatsD Elasticsearch / Logstash / Kibana (ELK) Practical Guide to Graphite Monitoring
33. Vielen Dank! Quellen / Tools dieser Präsentation: Reveal.js: Highlight.js: Highcharts: jQuery: http://lab.hakim.se/reveal-js https://highlightjs.org/ http://www.highcharts.com/ http://jquery.com/