EKON 18: Metriken und Anwendungsanalyse

EKON 18: Metriken und Anwendungsanalyse

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

Ebeb5d8fd081058ba8df73d378bf83d7?s=128

Sebastian P.R. Gingter

November 04, 2014
Tweet

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/