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?
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?
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?
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
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
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
Wozu? Wir bekommen Aussagen über Nutzung / Lastverhalten (z.B. DB/Sessions über Zeit)? Performance-Informationen (Zeit pro Aktion) Fehlerverhalten (Fehler/Zeit)
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
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
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.
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 ( ) ; }
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
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
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
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)