Als PDF, PPTX herunterladen
Apm best practices
- 1. APM - BestPractices Rainer Schuppe - codecentric AG 1 Freitag, 11. November 2011
- 2. 2 ©CrunchCrea - sxc.hu Freitag, 11. November 2011
- 3. 3 ©ross666 - sxc.hu Freitag, 11. November 2011
- 4. 4 ©NLTeddy - sxc.hu Freitag, 11. November 2011
- 5. 5 ©PetStarr - sxc.hu Freitag, 11. November 2011
- 6.
- 7. Agenda APM - Worüber reden wir überhaupt? Performance im Application Lifecycle Prioritäten bei der Auswahl 6 Hauptkriterien für die Auswahl Vergleich der Technologien und Architekturen Fazit 7 Freitag, 11. November 2011
- 8. Worüber reden wir? APM = Application Performance Management / Monitoring Monitoring = 24 x 7 Überwachung = Produktion / Datenerfassung / Protokollierung Management = Service Level / Kapazität / Alarm / Historisch / Berichte Application = Services die zusammen eine Business Funktion bilden Performance = Durchsatz und Geschwindigkeit 8 Freitag, 11. November 2011
- 9. PRODUCTION OPERATIONS DEVELOPMENT & QA Developers can focus 24/7 visibility to proactively on innovation determine root cause Freitag, 11. November 2011
- 10. Development Unhappy doing Monitoring Customers Long MTTR Can’t recreate the problem Endless war- room calls Forced No Re-starts Innovation Business Pressures DEVELOPMENT & QA PRODUCTION OPERATIONS Freitag, 11. November 2011
- 11. 150+ 11 © SupaJem - sxc.hu Freitag, 11. November 2011
- 12. Performance im Lifecycle- Entwicklung • Awareness - Ist Performance in der Entwicklung ein Thema? • Intern, extern oder Mischung? • Agil oder Wasserfall? • Non Functional Requirements? • Einzelfall Analyse Lokal beim Entwickler • CI Unterstützung? © drouu - sxc.hu 12 Freitag, 11. November 2011
- 13. Performance im Lifecycle- Test • Fachtest oder Lasttest? • Komplexität • Expertise? • Non Functional Requirements? • Testdaten = Produktionsdaten? • Problem Reproduktion (c) Buzznet Media 13 Freitag, 11. November 2011
- 14. Performance im Lifecycle- Produktion Hier wird Performance ein Business Thema • Service Level Agreements • Umsatzrelevant • Expertise in Operations • Wieviele Applikationen? • Verteilung (selbes Gebäude, Stadt, Land, Kontinent) • DevOps? • Landschaft hetero- oder homogen? © gabriel77 - sxc.hu 14 Freitag, 11. November 2011
- 15. Prioritäten bei derAuswahl 1. Fit für die Produktion? 2. Fit für moderne Architekturen? 3. Wie einfach einzusetzen? 4. Skalierbarkeit 5. Innovation 6. Gesamtkosten 15 Freitag, 11. November 2011
- 16. Produktionsgeeignet Moderne Architekturen Ease of Use Skalierbarkeit Innovation Kosten 16 Freitag, 11. November 2011
- 17. Fit für ProduktionsUmgebungen - Anforderungen • Hohe Last (Anzahl Transaktionen) • Anzahl der Applikationen • Expertise der Operator • Wartungsfenster • Vielfalt der Technologien • Problemszenarien nicht wiederholbar 17 Freitag, 11. November 2011
- 18. Produktions- geeignet Kein Einfluss auf die Applikation (Overhead) Triage und Troubleshooting (Visibilität) Konfigurationsaufwand Automatisches Applikations-Mapping Automatisches Baselining 18 Freitag, 11. November 2011
- 19. Produktions- geeignet Kein Einfluss auf die Applikation (Overhead) • CPU Verbrauch • Antwortzeit-Verlängerung • Server / 2. Overhead • Verdichten der Daten auf dem Server zu Informationen 19 Freitag, 11. November 2011
- 20. Sichtbarkeit 20 Freitag, 11. November 2011
- 21. Sichtbarkeit 21 Freitag, 11. November 2011
- 22. unterstützte Architekturen Monolithische 3-Tier Applikation auch bei agilen Releases Verteilte SOA Applikationen Applikationen in der Cloud Application Code & Frameworks (custom und Standard) Big Data 22 Freitag, 11. November 2011
- 23. unterstützte Architekturen • Cloud • Virtualization Amazon EC2 Public Cloud • SOA • Open-source Tomcat JBoss MQ VMware Spring Private Cloud Weblogic 23 Freitag, 11. November 2011
- 24. Ease of Use Wie schnell einsatzfähig (time to value)? APM Solution – Wartungs- und Betreuungsaufwand Wird eine SaaS Option angeboten? Wie intuitiv ist die Lösung? Wiederholbarkeit von Problemen? Welches Knowhow braucht der User? 24 Freitag, 11. November 2011
- 25. Ease of Use Wie schnell einsatzfähig (time to value)? Braucht man bei der Installation Unterstützung des Herstellers? Welche Expertise ist nötig, um die Lösung wirklich einsetzen zu können? SaaS Angebot? © lusi sxc.hu 25 Freitag, 11. November 2011
- 26. Ease of Use APM Solution – Wartungs- und Betreuungsaufwand Tägliche Wartung / Betreuung nötig? Versionsabhängigkeiten der Komponenten? SaaS Angebot? (c) sanja gjenero 26 Freitag, 11. November 2011
- 27. Skalierbarkeit Wieviele Agenten pro Management Server? Hardwareanforderungen? Speicherplatz für 1 Jahr? Wie kann skaliert werden? Hardware? Benötigte Netzwerkbandbreite? Lastverhalten: Peak oder gleichmässig? 27 Freitag, 11. November 2011
- 28. Skalierbarkeit Wieviele Agenten pro Management Server? • Welche Daten schicken die Agenten? • Wie oft? • Benötigte Netzwerkbandbreite • LAN / WAN / DSL geeignet? • Direkte Kommunikation oder gestaffelt? • Collector Architektur? 28 Freitag, 11. November 2011
- 29. Innovation Hersteller fokussiert auf APM? Anzahl Releases pro Jahr? Unterstützung für Ihre aktuelle Platform? Ist der Hersteller als erster mit neuen Features auf dem Markt? 29 Freitag, 11. November 2011
- 30. Innovation Hersteller fokussiert auf APM? • Ist die Lösung „integriert“ aus Zukäufen? • Wie alt ist die Architektur? • Was deckt die Lösung noch ab? • Wie gross ist der APM Anteil? • Baukästen und Frameworks funktionieren nur mit viel Arbeit 30 Freitag, 11. November 2011
- 31. Kosten Lizenzen Support & Wartung Hardware Implementierung Dienstleistung / Professional Services Ausbildung & Training Administration für Ausbau und Wartung 31 Freitag, 11. November 2011
- 32. Kosten Ausbildung & Training Implementierung Dienstleitung / Professional Services • Wieviele PT nötig für die Inbetriebnahme? • Wieviel Training und wie oft ist es nötig? • Neues Training bei neuen Releases notwendig? 32 Freitag, 11. November 2011
- 33. Kosten Innovation Skalierbarkeit Ease of Use Architekturen Prod Geeignet 150,0 112,5 75,0 37,5 0 Lösung 3 Lösung 2 Lösung 1 Freitag, 11. November 2011
- 34. Vergleich der Technologienund Architekturen • Technologien zur Datenermittlung • Methodologien • Komponenten-Monitoring • Transaktions-Monitoring • Architektur • Agenten • Server • Datenhaltung • Integration • User Interface Freitag, 11. November 2011
- 35. Technologien zur Datenermittlung Bytecode Instrumentierung • Hat Zugriff auf die Ausführungsanzahl • Genaue tatsächliche/max/min/durchschnittliche Ausführungszeit • Genaue Ausführungsreihenfolge • Benötigt Konfiguration der zu messenden Codestellen • Konfiguration muss ausbalanciert sein • Massenhaft aufgerufene Methoden sind auszuschließen • Genauso Methoden mit Ausführungszeit kürzer als die Messcode-Zeit • Produziert große Datenmengen Freitag, 11. November 2011
- 36. Technologien zur Datenermittlung Sampling • Stabiler Overhead, der hauptsächlich durch das Samplingintervall, nicht durch den gemessenen Code, bestimmt wird • Ausführungshotspots werden anstelle einer feingranularen Codereihenfolge gemessen • Kann unbekannten Code aufspüren • Läuft effizient auf Mehrkernsystemen http://blog.codecentric.de/?p=9528 Freitag, 11. November 2011
- 37. Technologien zur Datenermittlung • JMX / PMI • Geeignet zur Begleitung • ARM • Logging • Network Sniffing / SPAN-Port Freitag, 11. November 2011
- 38. Identity ERP Manager CRM Order Load Network Firewall Balancer Portal Mainframe Router Database Switch Web Applications End User Servers Web Services Databases 3rd Party Applications 38 Freitag, 11. November 2011
- 39. Methodologie Komponenten Monitoring Alt - nicht mehr für moderne Architekturen geeignet • JVM Check (CPU, Heap, Health Check) • Servlets, EJB, SpringBeans, etc. • Evtl. mit Bezug zwischen 2 Ebenen (Servlet - EJB) • JMX • Meist in Frameworks zu finden • Ergänzung der System Monitoring Tools • Kein Kontext -> Expertenwissen benötigt 39 Freitag, 11. November 2011
- 40. © marcphelan -sxc.hu 40 Freitag, 11. November 2011
- 41. Methodologie Transaktions-Monitoring • Einstieg über definierte Fachlichkeiten (Business Transaktionen) • Verfolgung über JVM Grenzen hinweg • Identifizierung der beteiligten Komponten / Architektur • End User Experience Integration 41 Freitag, 11. November 2011
- 42. Architektur - Agenten • Aktiv / passiv • Java / nativ • Einer für alles • Gruppe von Agenten für verschiedene Perspektiven? • Autarker Agent • Gar kein Agent? • Transaktionskontext? 42 Freitag, 11. November 2011
- 43. Architektur - Server • Einzelner zentraler Server • Cluster mit Management Server © Linuxgeek - sxc.hu • Staffelung und Arbeitsverteilung mit Management Server • SaaS geeignet oder nur lokale Installation? • Sichere Anbindung der Agenten (Verschlüsselung)? • HA / Failover? 43 Freitag, 11. November 2011
- 44. Agent Agent GUI Agent GUI Management Agent Server GUI GUI Agent Database Agent 44 Freitag, 11. November 2011
- 45. Agent Collector Aux. GUI Server Agent Server GUI Agent Collector Server Management Agent Server GUI Agent Collector GUI Server Database Agent 45 Freitag, 11. November 2011
- 46. Architektur - Datenhaltung • Database • Filesystem • Kombination aus beidem • Wie viel Platz wird über 1 Jahr gebraucht? © runrunrun - sxc.hu 46 Freitag, 11. November 2011
- 47. Architektur - Integration • APIs für Input und Output für Daten? • Java APIs? • Script basiert? • Einfachheit • Service Provider / REST? © gozdeo - sxc.hu 47 Freitag, 11. November 2011
- 48. User Interface • Fat client oder Web-GUI? • Dashboards © vgarcias - sxc.hu • Customizable - Mustomizable? • Für Operator OOTB verwendbar? • Mandantenfähig? 48 Freitag, 11. November 2011
- 49. Fazit Es gibt viele Werkzeuge, aber nur wenige brauchbare Lösungen für den Produktionseinsatz Jede Organisation muss die Kriterien selbst gewichten Automatisierung und Ease of Use sind die Schlüssel für schnelles, effektives Arbeiten 49 Freitag, 11. November 2011