End-to-End Monitoring und Tracing

Transkript

1 End-to-End Monitoring und Tracing Sven Vetter Trivadis AG Principal Consultant & Partner DOAG Karlsruhe Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart

2 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

3 Überblick Mit Oracle GridControl 10.2 hat Oracle ein neues (lizenzpflichtiges) Pack auf den Markt gebracht: Das "Service Level Management Pack" Ziel (lt. Oracle-Store): Mit dem Service Level Management Pack lässt sich die Verfügbarkeit und Performance von kritischen Anwendungen (Diensten und Internetanwendungen), Standorten und Infrastrukturkomponenten aktiv überwachen. Außerdem können entsprechende Berichte erstellt werden. Zu diesem Zweck werden von externen Standorten (Beacons) aus künstlich Transaktionen ausgeführt. End-to-End Tracing und Monitoring

4 Ziele Performance- und Verfügbarkeitsüberwachung End-to-End-Monitoring Root-Cause Analyse Einfache Übersichtsanzeigen (um First Level Support die Möglichkeit zu geben, Probleme zu finden und zu lösen) End-to-End Tracing und Monitoring

5 Ziele: Dashboard-Funktionalität End-to-End Tracing und Monitoring

6 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

7 Services Überblick Ein Service entspricht einer End-User- bzw. Business- Funktionalität z.b. eine CRM-Applikation, Online Banking, Mail, Damit ein Service als "lauffähig" betrachtet wird, braucht es: Die generelle Verfügbarkeit aller Komponenten Definierte Antwortzeiten Korrekte Daten Folgende Servicearten existieren: Webapplication Generic Service Aggregate Service Identity Management Service Collaboration Suite Service End-to-End Tracing und Monitoring

8 Services Webapplication Überwachung einer Webseite bzw. Webapplikation Über Systeme (siehe nächstes Kapitel) können Beziehungen zu den zugehörigen Komponenten (Datenbank, Listener, Server, Webserver, Netzwerk, ) definiert werden Performance und Verfügbarkeit werden durch Webtransaktionen überwacht (oder durch System-Tests) Transaktionen werden durch "Beacons" durchgeführt, jeder GridControl Agent kann als Beacon fungieren Transaktionen können von mehreren Standorten durchgeführt werden, um die Performance von unterschiedlichen Locations zu überwachen (bedingt einen Beacon pro Standort) End-to-End Tracing und Monitoring

9 Services Webapplication Webtransaktionen können einzelne URL-Zugriffe sein oder aber beliebige viele Schritte einer Webapplikation Diese Schritte können manuell erfasst werden oder durch einen integrierten Macro-Recorder aufgezeichnet werden Dieser Recorder bedingt aber den Microsoft Internet Explorer Wenn IE, wird ein ActiveX-Control installiert, welches es erlaubt, einen normalen Arbeitsablauf aufzuzeichnen Leider nur von Webapplikationen, die kein Java im Client ausführen (als Forms geht z.b. nicht ) End-to-End Tracing und Monitoring

10 Services Webapplication Beim manuellen Erfassen kann pro Step definiert werden: Die Methode des Requests Eventuelle zusätzliche Header-Informationen Die gesendeten Daten, wenn die Methode=POST "Basic Authentication Credentials" können übergeben werden End-to-End Tracing und Monitoring

11 Services Webapplication Über "Advanced Properties" können weitere Tests vorgenommen werden, z.b. ob bestimmte Texte auf der Seite enthalten sind Es kann nicht nur die totale Zeit eines Web-Requests gemessen werden, sondern dieser in seine Bestandteile aufgegliedert werden Dadurch ist zu erkennen, ob z.b. ein DNS-Problem vorliegt End-to-End Tracing und Monitoring

12 Services Webapplication Pro Performance-Messwert können Schwellwerte festgelegt werden: Diese können dann für die Verfügbarkeitsberechnung benutzt werden Innerhalb eines Services können beliebig viele Tests durchgeführt werden Das Test-Intervall kann pro Service definiert werden End-to-End Tracing und Monitoring

13 Services Webapplication Ergebnis Übersichtsseite End-to-End Tracing und Monitoring

14 Services Webapplication Ergebnis viele Details: End-to-End Tracing und Monitoring

15 Services Webapplication Überschreitungen von Schwellwerten werden protokolliert und können Aktionen auslösen ( , PL/SQL, SNMP-Trap) End-to-End Tracing und Monitoring

16 Services Webapplication und HTTPS Sollen SSL Verbindungen überwacht werden, muss das Zertifikat ausgewertet werden können und gültig sein (ansonsten Fehlermeldung "SSL handshake failed ") also muss die "Certificate Authority" bekannt sein Eine Reihe von CA's sind in der Beacon Software integriert Um weitere CA's zuzulassen, müssen diese manuell in "$AGENT_HOME/sysman/config/b64InternetCertificate.txt" erfasst werden Genaue Beschreibung dazu im Kapitel "Enterprise Manager Security" der EM-Dokumentation End-to-End Tracing und Monitoring

17 Generic Services Ausser Webapplikationen können noch diverse andere Applikationsarten getestet werden: Oracle SQL Timing, JDBC SQL Timing DNS FTP Ping, HTTP-Ping, TNS Ping IMAP, POP, SMTP LDAP NNTP (Network News Transfer Protocol) Port Checker (offene und geschlossene Ports, mit/ohne SSL) SOAP Eigene Scripts End-to-End Tracing und Monitoring

18 Generic Services Oracle SQL Timing Mittels "Oracle SQL Timing" können beliebige SQL-Statements gegen beliebige Oracle-Datenbanken ausgeführt werden End-to-End Tracing und Monitoring

19 Generic Services Oracle SQL Timing Es können diverse Metrics überwacht werden, so dass zu einem Performanceproblem schnell die Ursache gefunden werden kann: Zu all diesen Metrics können wiederum Schwellwerte gesetzt werden: End-to-End Tracing und Monitoring

20 Generic Services Custom Script Mit Custom Scripts können beliebige Targets überwacht werden Ein Script kann bis zu 10 Messwerte zurückgeben Diese müssen als numerische Werte in max. 10 Zeilen per Standardoutput ausgegeben werden Dazu können wieder Schwellwerte (und sprechende Namen) definiert werden Zusätzlich wird der Exit-Code (Status) und die Laufzeit ausgewertet End-to-End Tracing und Monitoring

21 Generic Services Custom Script Beispiel Folgendes Testscript #!/bin/sh date "+%M" date "+%H" exit 0 Aufgerufen jede Minute gibt es u.a. folgende schöne Grafiken: End-to-End Tracing und Monitoring

22 Aggregate Services Aggregate Services sind die Kombination von Subservices zu einem übergeordneten Service Z.B.: Alle Applikationen einer Firma ergeben die gesamte IT Die Metriken der Einzelservices können übernommen, die Thresholds noch angepasst werden Bei der Definition der Verfügbarkeit (und damit auch bei der Benachrichtigung) wird entschieden, wann ein Threshold verletzt ist (wenn der Durchschnitt der Services grösser als der Wert ist, wenn Min/Max grösser ist, ) End-to-End Tracing und Monitoring

23 Aggregate Services Beispiel: End-to-End Tracing und Monitoring

24 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

25 Erweiterung durch Systeme Durch Services wurde bis zu diesem Punkt nur die Performance und Verfügbarkeit für die Endanwender überwacht Auf der anderen Seite kann Oracle schon immer durch Metrics die Performance von Hardware und Software überwachen Interessant wäre es jetzt, diese beiden Punkte zu kombinieren, um eine Verbindung von Enduser-Problemen zu deren Ursachen zu erhalten Dies erfolgt durch die Definition von Systemen und deren Zuordnung zu Services End-to-End Tracing und Monitoring

26 Systeme: Überblick Ein System ist ein Set von Infrastruktur (Hardware, Datenbank, Application Server, ) welches benötigt wird, um eine Applikation zu betreiben Alle EM-Targets können in Systemen benutzt werden Systeme können geschachtelt werden Zwischen den einzelnen Targets können Beziehungen definiert werden (z.b. braucht eine bestimmte Datenbank eine ASM- Instanz) End-to-End Tracing und Monitoring

27 Systeme: Topologie Wenn mit Internet Explorer ob Version 5.5 gearbeitet wird (und das SVG-Plugin installiert ist), kann die Topologie (Abhängigkeiten) grafisch erfasst werden: End-to-End Tracing und Monitoring

28 Systeme: Topologie Ohne IE muss dies tabellarisch erfasst werden: Systeme können auch geschachtelt werden, sprich in Subsysteme unterteilt werden Dadurch wird die Übersichtlichkeit und Wiederverwendbarkeit sehr erhöht! End-to-End Tracing und Monitoring

29 Systeme: Charts Welche Charts wie angezeigt werden, kann definiert werden: Leider bleibt der Browser bei der Anzeige dieser Charts oft hängen End-to-End Tracing und Monitoring

30 Systeme: Charts End-to-End Tracing und Monitoring

31 Systeme: Auswertungen Diverse Übersichten: End-to-End Tracing und Monitoring

32 Systeme: Auswertungen Auch hier schon eine Dashboard-Sicht: End-to-End Tracing und Monitoring

33 Services und Systeme Zu einem Service kann ein System zugeordnet werden Dadurch können sowohl die Enduser- Performance-Daten (Performance) als auch die "technischen" Performance- Daten (Usage) in einer Übersicht überwacht werden Und natürlich alle Details End-to-End Tracing und Monitoring

34 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

35 Root Cause Analysis (RCA) Ist ein Service nicht verfügbar (oder die Performance verletzt die Schwellwerte), kann Oracle anhand des Systems die Ursache ermitteln Zwei Arten: Manuell: Wenn ein Problem auftritt, muss manuell die RCA gestartet werden, Ergebnisse davon werden nicht abgespeichert Automatisch (Default): Die RCA wird automatisch immer bei einem Problem durchgeführt, die Ergebnisse werden auf der Service-Homepage angezeigt und für spätere Auswertungen abgespeichert End-to-End Tracing und Monitoring

36 Root Cause Analysis (RCA) Standardmässig werden auf Targetebene definierten Metrics für die Analyse herbeigezogen Innerhalb des Services können aber noch weitere Komponententests hinzugezogen werden Dadurch können Metrics überschrieben werden, wenn sie für diesen Service unwichtig sind oder anders benötigt werden Im Service können "Key Components" definiert werden, nur diese werden für die Tests benutzt (so dass Systeme auch für mehrere, ähnliche Services benutzt werden können) End-to-End Tracing und Monitoring

37 Root Cause Analysis (RCA) Beispiel: Ein für einen Service benötigter OAS und eine DB wurden gestoppt, dadurch war die Webseite nicht mehr verfügbar: End-to-End Tracing und Monitoring

38 Root Cause Analysis (RCA) Dies ist dann natürlich auch in der Topologie-View sichtbar End-to-End Tracing und Monitoring

39 Root Cause Analysis (RCA) Auch auf der Target-Seite selbst (hier bei einem gestoppten Listener) ist der Impact erkennbar End-to-End Tracing und Monitoring

40 Root Cause Analysis (RCA) Bei der automatischen RCA wird die Ursache "aufbewahrt" und kann für spätere Ursachenforschung benutzt werden: Sehr nützlich sind dann eigene Kommentare End-to-End Tracing und Monitoring

41 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

42 Page Performance Anzeige der Performance-Daten aus der Endbenutzer-Sicht Per Default werden die 10 langsamsten Requests angezeigt, es können aber auch eigene "Watch-Lists" erzeugt werden also Seiten, deren Performance immer überwacht wird: End-to-End Tracing und Monitoring

43 Page Performance Übersicht: "Incomplete Page Loads" entstehen, wenn Seiten nicht oder nicht vollständig geladen wurden End-to-End Tracing und Monitoring

44 Page Performance Analyse Die Performance-Daten können dann weiter analysiert werden Folgende Gruppierungen können getroffen werden: Domain (von welcher Domain kommen die Besucher meiner Seite) Region (Regionen können selbst anhand IP-Range oder Domain festgelegt werden) Visitor (gruppiert nach IP-Adressen) Web-Server End-to-End Tracing und Monitoring

45 Page Performance Analyse Von hier ist ein Drill-Down auf den einzelnen Aufruf möglich: End-to-End Tracing und Monitoring

46 Page Performance Installation Bei der Installation ist zu beachten: In der Webapplikation muss ein System mit einem Oracle WebCache oder Apache Webserver enthalten sein Die "Web Server Data Collection" muss im Service eingeschaltet sein End-User-Performance-Monitoring muss im Webserver eingeschaltet sein, Log Format muss WCLR sein End-to-End Tracing und Monitoring

47 Request Performance Im Gegensatz zu 'Page Performance' ist die 'Request Performance' die technische Sicht Es wird nicht überwacht, wie lang ein Benutzer auf eine Seite warten musste, sondern die einzelnen Programmkomponenten auf der Middletier (Java-Klasse, Servlet, JSP, ) selbst In der Übersicht werden die 10 langsamsten Requests gezeigt: End-to-End Tracing und Monitoring

48 Request Performance Durch einen Drilldown in einen Request werden weitere Informationen angezeigt Wichtig dabei immer die Trennung zwischen Middletier und Backend-(Datenbank-) Zeit End-to-End Tracing und Monitoring

49 Request Performance Call Stack Interessant wird die Anzeige des Call Stack Hier wird der Request in seine Bestandteile zerlegt: End-to-End Tracing und Monitoring

50 Request Performance Call Stack Durch Öffnen der Database Connection werden die einzelnen SQL-Statements sichtbar Auch hier wieder als wichtige Information: Wieviel % der Zeit des Gesamt-Requests hat die einzelne Komponente gebraucht End-to-End Tracing und Monitoring

51 Request Performance Noch tiefer: Analyse des Einzelstatements End-to-End Tracing und Monitoring

52 Request Performance Und durch "SQL Statement Analysis" sind wir auf der DB-Ebene: End-to-End Tracing und Monitoring

53 Request Performance - Installation Bei der Installation ist zu beachten: In der Webapplikation muss ein System mit Oracle Application Server enthalten sein Auf Service-Ebene muss die Collection eingeschaltet sein: Oracle empfiehlt als Intervall 60 min., ich konnte mit kleineren Werten (bis zu 5 min.) keine Probleme feststellen Achtung: Wenn hier mehrere Targets vorhanden sind, müssen die Tracing Properties (nächste Seite) für alle Komponenten gesetzt werden, der "Enable Logging"-Link macht dies nur für die erste Zeile! End-to-End Tracing und Monitoring

54 Request Performance - Installation Bei der Installation ist (weiter) zu beachten: Auf Application-Server-Ebene muss Tracing richtig definiert sein: Wichtig: Kein Eintrag bei Trace-Directory das Feld muss leer sein! Auch hier empfiehlt Oracle ein Intervall von 60 min. (3600 sek.) End-to-End Tracing und Monitoring

55 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

56 SLA-Überwachung Definition Nach der Definition eines Services ist automatisch die Verfügbarkeitsüberwachung eingeschaltet Auf der Homepage wird der aktuelle Servicelevel angezeigt Standardmässig wird für die Berechnung nur die reine Verfügbarkeit von Key Komponenten benutzt End-to-End Tracing und Monitoring

57 SLA-Überwachung Definition Sollen noch Performance-Metrics einbezogen werden, muss dies definiert werden (Mein SLA gilt nur als erfüllt, wenn eine bestimmte Antwortzeit nicht überschritten wird): Sobald der kritische Wert einer ausgewählten Metric überschritten wird, zählt dies dann als Verletzung End-to-End Tracing und Monitoring

58 SLA-Überwachung Definition Neben dem erwarteten Servicelevel müssen die Geschäftszeiten definiert werden: Ausserdem ob unbekannte Zustände und Blackouts als Verletzung zählen oder nicht: End-to-End Tracing und Monitoring

59 SLA-Überwachung Auswertungen Eine Übersichtsgrafik wird angezeigt: Ausserdem eine Tabelle aller Verletzungen: End-to-End Tracing und Monitoring

60 SLA-Überwachung Auswertungen Sind mehrere Servicetests definiert, wird für jeden Test die Verfügbarkeit angezeigt: End-to-End Tracing und Monitoring

61 Agenda Überblick, Ziele Definition von Services Systeme und Infrastrukturabhängigkeiten Daten sind immer im Spiel. Die "Root Cause" End-to-End-Performance SLA-Überwachung Dashboards End-to-End Tracing und Monitoring

62 Dashboards Pro Service gibt es einen vordefinierten Dashboard-Report: Angezeigt werden: Aktueller Status des Services Die 3 "kritischsten" Performance- und Usage-Werte Status der System-Komponenten Die Verfügbarkeit der letzten 24 Stunden, 7 Tage und 31 Tage End-to-End Tracing und Monitoring

63 Dashboards Typischerweise sollen aber mehrere Services auf einem Dashboard angezeigt werden Dazu muss der vordefinierte Report kopiert werden und mehrere Service-Targets aufgenommen werden Dabei können auch andere/zusätzliche SLA-Zeitspannen benutzt werden End-to-End Tracing und Monitoring

64 Dashboards Dieser Dashboard-Report kann auch per Scheduler geplant und per verschickt werden Ausserdem kann der Report "public" gesetzt werden, d.h. er kann ohne Anmeldung am Enterprise Manager angezeigt werden: End-to-End Tracing und Monitoring

65 Dashboards Beispiel Und natürlich kann immer ein DrillDown durchgeführt werden Dashboards können auch erweitert werden und andere Informationen enthalten, z.b. Kritische Fehlermeldungen, Status von Systemen, End-to-End Tracing und Monitoring

66 Dashboards Beispiel mit System-Erweiterung End-to-End Tracing und Monitoring

67 Kernaussagen Die Überwachung von Diensten ist gut möglich, unabhängig von Oracle Komponenten Durch die Definition von Systemen und Abhängigkeiten wird die Fehlersuche (Performance und Verfügbarkeit) stark vereinfacht Das End-to-End-Tracing ist hervorragend, leider auf Oracle- Komponenten (+ Apache) begrenzt im Moment... End-to-End Tracing und Monitoring

68 Vielen Dank!? Basel Baden Bern Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart