APM Projektbeschreibung Anforderung an Application Performance Management

Transkript

1 APM Projektbeschreibung Anforderung an Application Performance Management

2 1 Inhalt APM Projektbeschreibung Inhalt Beschreibung Ziel Ressource Bewertung End User Access auf Ressourcen/Server Begründung Ziel Notwendige Information Notwendige Datenerfassung/Metriken Granularität der Daten Kapazitäts- Planungsunterstützung Application Performance Performance Metriken User Response Time Netzwerk Server Server- Server Performance Begründung Ziel Notwendige Datenerfassung/Metriken Darstellung SLA Überwachung Anforderungen SLA KPIs Prämissen Application Delivery Service Netzwerk Service System Service Auswahl und Definition kritischer Unternehmensanwendungen Auswahl kritischer Business Ressourcen Auswahl business- relevanter SLA Metriken Auswahl globaler SLA Metriken Generierung von SLA- Ampel Dashboards Alarmierung Troubleshooting Anforderungen Schnittstellen Data Import/Export Schnittstellen Management Schnittstellen System Netzwerk...15

3 2 Beschreibung Unternehmen XXXX plant den Einsatz eines Probe- basierten Application Management Systems, welches das Unternehmen in der Verbesserung der IT- Service Qualität unterstützen soll. Zu den erwarteten Verbesserungen gehört u.a. schnelle Erkennung von Fehlerzuständen präzise und zeitsparende Reaktion auf Fehlerzustände Unterstützung bei der Planung teurer IT- Ressourcen wie Bandbreiten für WAN Standorte 2.1 Ziel Als Zielfunktionen wird entsprechendes erwartet: Globale Ressource Bewertung (Netzwerk, Server) o Historie o Ist- Zustand o Trending kontinuierliche Darstellung des Application- Delivery Success o Availability o Performance Root Cause Analyse o Beschleunigung von Troubleshooting Prozessen o Verweis auf bad performing objects Planungssimulation für Ressourcenbedarf Im Folgenden werden die Anforderungen weitestgehend beschrieben.

4 3 Ressource Bewertung Die Ressource- Bewertung vermittelt Informationen über die Nutzung der Ressourcen in qualitativer (Beschreibung des WAS und WARUM ) und quantitativer Hinsicht (Beschreibung des WIEVIEL ). Sie erlaubt es, volumenabhängige Engpässe zu erkennen und durch die qualitative Analyse korrekt zu reagieren. So können entsprechende Reaktionen am Beispiel mangelnder Bandbreite sein: Erhöhung der Bandbreite Verringerung von Volumen durch Traffic Filter (z.b. nicht erlaubte oder non- konforme Anwendungen) Verringerung von Traffic durch Applikations- Anpassung (Volumenreduktion) Einsatz von Remote Desktop Systemen Einsatz von WAN- Beschleunigern (Caching, Compression, Spoofing) Die Ressourcen müssen für die Bereiche erfasst werden, bei denen eine Ressource performance- oder finanz- relevant ist. Dazu zählen die: End- User Anbindungen (va. Für WAN Standorte) Server- Server- Anbindungen 3.1 End User Access auf Ressourcen/Server Begründung Mangelnde Ressourcen gelten weiterhin als die Hauptursache für Performance Problemen bei End- Kunden Als Ressource gelten sowohl die Netzwerk Ressource Bandbreite - als auch die Server bedingten Ressourcen (CPU, Memory, Throughput) Ziel Feststellung des Ressourcebedarfs je IT- Objekt Feststellung von Ressource Engpässen Verwendung der Kennzahlen für Planung Feststellung ob Ressourcebedarf erwartungskonform ist Notwendige Information Access- Metriken - > welche User/zu welcher Zeit/mit welchen Anwendungen/auf welche Ressourcen Aggregierung der Informationen für Standorte bzw. frei wählbare Gruppierungen Notwendige Datenerfassung/Metriken Application Recognition (port based/content based) o wenn möglich auf Transaktionsebene

5 Frei wählbare Gruppenkriterien Client- Last Metriken o Bytes/Packets o Connections o Application messages o Anz. Messages/Jobs pro Anwendung Erfassung von unternehmenskonformen/nicht konformen Anwendungen und Datenbeziehungen Erfassung von non- konformen Aktionen wie DoS- Attacks/PortScans Darstellung der zeitabhängigen Belastungskurve der IT- Infrastruktur Darstellung von Zusammenhängen zwischen Belastungskurve und Anwendungs- Performance Erfassung von Non- Availability- Zuständen aus Sicht der User a. Da die Verfügbarkeit passiv gemessen werden sollte, müssen sich verbindungs- und applikationsabhängige Metriken definieren lassen, die die Verfügbarkeit darstellen. b. Aktive Testmessungen können die passiven Messungen unterstützen Granularität der Daten Hohe Granualarität wird einer Geringeren gegenüber präferiert, da eine geringe Granularität zu erheblichen Ungenauigkeiten führt, bei der kurzzeitige Negativ- Zustände nivelliert werden können. 3.2 Kapazitäts-Planungsunterstützung Die Daten von der Appliance versetzen die Anwender in die Lage, das reale Lastverhalten im Netzwerk festzustellen, Trends zu erkennen und kapazitätsrelevant im notwendigen Umfang zu reagieren. Da die Planung von Ressourcen und IT- Architektur- Designprozessen jedoch nicht linear verläuft (100 User verbrauchen NICHT 100 mal mehr Bandbreite als ein User), müssen Funktionen verwendet werden, die die Vohersage des Ressource- Verbrauchs bzw. die Application- Performance unter gegebenen, bzw. angenommenen Kapazitäts- Bedingungen, ermittelt. Um diesen Planungsaspekt zu bedienen, muss eine Lösung die folgenden Funktionen bereitstellen: Vorhersage des Bandbreitenbedarfs für eine gegebene Anwendung in gegebenen Infrastrukturszenarien (wie viel Bandbreite benötigen 100 User in einem Remote Standort bei 50 ms Latenzzeit für die Anwendung XYZ) Vohersage der Antwortzeit für eine gegebene Antworzeit in gegebenen Infrastrukturszenarien (welche Antwortzeit erleben die Anwender in einem Remote Standort bei 50 ms Latenzzeit und einer gegebenen Bandbreite von 2 Mbps) Unterstürzung bei der Eumulation von Kapazitätsmassnahmen, wie 1. Veränderung des Applicatin Volumens

6 2. Abhänihigkeit des Bedarfs von gegebenen Parametern wie Latenzzeit 3. Bei Bedarf Emulation von WAN Accelleratoren

7 4 Application Performance Die Sektion Application Performance beschreibt die notwendigen Informationen zur Darstellung von Application Performance aus Sicht der jeweiligen Phasen (Client- Server/Server- Server). Als Application Performance wird der finale Abschluss eines Application- Task bezeichnet und beinhaltet die Phasen: Verbindungsaufbau Client Server Client Request Server Processing Server to Server Transfers Data Delivery Client Data Bestätigung. Die Informationen über Application Perfromance sind die zentralen Success- Kriterien und spielen im Informationsgerüst einer APM Lösung die zentrale Rolle. Ausgehend von der Application Performance werden die folgenden Prozesse initiiert: Service Level Überwachung o Bedarf einer Baseline- Analyse zur Feststellung von Normalwerten Performance Symptom Presentation Alerting Primäre kausale Zuordnung (Netzwerk, Server, Application) Als primäre Success- Metrik gilt die beim Benutzer erlebte Antwortzeit, oder User response time, da sie die Performance einer Anwendung in ihrem finalen Resultat abbildet. In diesem Wert widerspiegeln sich die anderen, für den Erfolg notwendigen Metriken, wie z.b. Netzlaufzeit, Paketverlust, Server- Antwortzeit, Application Design etc.. Werden hier Abweichungen von einer determinierten Erwartung festgestellt, wird ein Fehlersuch- und Eskalationsprozess gestartet. Andere Metriken, die die Application Performance final determinieren, können separat erfasst werden.

8 4.1 Performance Metriken User Response Time Antwortzeit per Application Transaction Verfügbarkeit aus User Sicht Netzwerk Throughput Laufzeit Packet Loss Delay Server Server Response Zeit Per Message Server Server Daten (siehe unten) Server Ressource Bewertung (CPU,Memory) 4.2 Server-Server Performance Begründung In modernen Multi/Tier- Architekturen kann eine finale Performance Analyse nur sinnvoll erbracht werden, wenn Backend- Prozesse berücksichtigt und dargestellt werden, da letztlich die schwächste Stelle in der Tierkette für die beim Benutzer erlebte Performance ursächlich ist Ziel Erfassung der performancerelevanten Kennzahlen im Server- Server- Verkehr Notwendige Datenerfassung/Metriken Infrastruktur Erfassung der Daten zwischen physikalisch getrennten und virtuellen Servern Metriken Server- Server- Responsezeiten Erkennung von Middle- Tier- Systemen Server- Server- Load Server- Server- Transaktions- Analyse Darstellung Applikationszugehörige Server (z.b. Application- Server A, Database Server D) müssen sich gemeinsam und isoliert vom Rest der IT Welt darstellen und auswerten lassen Dashboards müssen die Tier- Verbindungen grafisch darstellen 5 SLA Überwachung SLA Management verfolgt das Ziel, die kritischen Performance- KPIs zu erfassen und sichtbar zu machen, um:

9 schnell Performance- degradierende Zustände bzw. Zustände, die u. U. zu Peformance- Degradierung führen können, frühstmöglich zu erfassen präzise symptom- relevant zu reagieren Zusammenhänge zwischen Performance und performance- degradierenden Faktoren sichtbar zu machen Kundenrelevante Beschwerden abbilden zu können führt wegen Früh- Erkennung zu erheblicher Reduzierung von Fehlersuch- Aktivitäten Service Management geht von der Prämisse aus, dass Servicemetriken aus Kundensicht immer in Zeiteinheiten pro Transaktion (z.b. Login = 3 Sekunden), und nicht in technischen Parametern kommuniziert werden. Demnach muss dieser zeitabhängige Wert pro User dargestellt werden. Allerdings können auch andere service- provisionsabhängige Metriken relevant sein, für die Überwachung des Netzwerk- Service wird ein paket- verlustfreier Transfer, eine maximale Laufzeit oder ein minimaler und maximale Durchsatz vereinbart. Ziel ist die Erfassung und Darstellung der folgenden Informationen: Etablierung von SLA- relevanten Metriken wie Antwortzeit Erfassung der Abhängigkeit der relevanten Metriken (z.b. Server- Antwortzeit von Server- Last) Etablierung von SLA relevanten Schwellwerten und deren Überwachung Darstellung von SLA Überschreitungen und Weiterleitung von APM relevanten Informationen in zentrale Event- Management- Systeme Darstellung der Performance in zentralen Dashboards Generierung von GUI basierten Workflows, die den Weg vom Erkennen der SLA Ueberschreitung hin zur finalen Root- Cause- Analyse darlegen Anforderungen SLA Definition Beschreibung von SLA Metriken (KPIs) Auswahl kritischer Unternehmensanwendungen Auswahl von kritischen Business Ressourcen Auswahl business relevanter SLA Metriken Auswahl globaler SLA Metriken Generierung von SLA - Ampel Dashboards Erzeugung von SLA Reports 5.2 SLA KPIs

10 5.2.1 Prämissen SLAs beziehen sich auf einen abgeschlossenen Zustand eines IT- Service - und nicht auf die Zustände, die diesen Service determinieren Service- Metriken sind Erfolgs- und Leistungsmetriken und variieren abhängig vom Service- Angebot, dass unterschieden wird in: Application Delivery Service Netzwerk Service System Service Application Delivery Service Application Delivery Service beschreibt die Überbringung des Service vom Serviceprovider zum Endkunden in Endkunden- spezifischen Parametern wie z. B. der Erfolg einer Transaktion und deren Antwortzeit Definition von Application Services Application Services müssen sich möglichst dynamisch definieren lassen, und TCP- Ports, IP- Adressen, ephemeral Port Applications (wie MS Exchange) oder Web Urls als Definitionskriterium zulassen Antwortzeit beschreibt die beim Endbenutzer erlebte Antwortzeit beginnend vom Start einer Transaktion und endend beim Erhalt der Information vom Server. Eine Transaktion wird im einfachsten Sinn als vollständiger generischer Application Message Transfer beschrieben im erweiterten Sinn als kontext- abhängige User- wiedererkennbare Klartext- Transaktion Service Verfügbarkeit beschreibt die Möglichkeit mit einem Application- Service zu kommunizieren, und muss demnach das intakte Austauschen von Application Messages pro Anwendung auf einem Server darstellen können Abwesenheiten von Service-Fehlern berücksichtigt den Fakt, dass rein technisch ein Service verfügbar sein kann, dieser aber auf interne Verarbeitungs- Fehler stößt Netzwerk Service Netzwerkverfügbarkeit (End to End) Netz- Throughput Die Abwesenheit Netzwerk- Service degradierender Parameter (Packet Loss, Latenz- Varianz (Jitter) Laufzeit RTT

11 5.2.4 System Service Server Verfügbarkeit Server Responsezeit die Zeit, die der Server benötigt, ein Anwendungsanfrage zu beantworten (dabei kann die Antwort von dahinter liegenden Backend- Tiersystemen abhängen; dieser Umstand sollte darstellbar sein) 5.3 Auswahl und Definition kritischer Unternehmensanwendungen Für das SLA Management müssen sich unternehmenskritische Anwendungen vom Rest der IT- Landschaft isolieren und gruppieren lassen. Die Gruppierungsnotwendigkeit berücksichtigt den Umstand, dass Anwendungen wie z.b. SAP etc. heute völlig unterschiedliche Dienste wie Web Service, Database- Service, Java- Anwendungen etc. beinhalten können, und ein Umbrella über diese Anwendungen gelegt werden muss, um ein sinnvolles Reporting aufzubauen. 5.4 Auswahl kritischer Business Ressourcen Werden bestimmte Ressourcen vom IT- Management als unternehmenskritisch eingestuft (wie z.b. Last auf bestimmten Verbindungen, Servern etc.) müssen diese in das SLA Management mit integriert werden können. 5.5 Auswahl business-relevanter SLA Metriken Als SLA Metriken müssen demnach alle kritischen Metriken verwendet werden können, die das IT- Management vorschreibt. Ist ein direktes Erfassen einer Variable mit einem passivem Management System nicht möglich (z.b. Verfübarkeit eines Service), muss diese Variable aus anderen Metriken abgeleitet werden. So kann die Nicht- Verfügbarkeit eines Service zum Bsp. aus dem Umstand abgeleitet werden: Connection failed > 0 Number of active connections = 0 Number of Applicatino Turns = 0 Diese Ableitung berücksichtigt, dass ein Server physikalisch und OS- seitig noch intakt ist und Pakete empfängt und versendet, die Anwendung jedoch nicht mehr reagiert. 5.6 Auswahl globaler SLA Metriken Globale Metriken beziehen sich auf Variablen, die unter keinen Umständen einen bestimmten Schwellwert überschreiten sollten (z.b. Paketverlust). Demnach müssen alle Metriken, die vom Unternehmen als business- kritisch eingestuft werden, sich im SLA System abbilden lassen. 5.7 Generierung von SLA-Ampel Dashboards Die SLA Kriterien müssen in Dashboards verankert, und diese den entsprechenden technischen Abteilungen bereit gestellt werden.

12 So benötigt das Netzwerk- Team evtl. weniger Informationen über die Server- Responsezeiten, aber einen fokussierten Blick auf die Round- Trip- Time für Ihre Remote- Lokationen. SLA Übertretungen müssen leicht erkennbar, und drill downs in weitere Details zur Analyse möglich sein. 5.8 Alarmierung Die Feststellung von Service Level Überschreitung, als auch die Information über kritische Zustände sollten sowohl in den lösungsinternen Dashboards dargestellt, als auch an zentrale Event- Konsolen weitergeleitet werden. Dazu müssen, wie im SLA Bereich beschrieben, sämtliche kritischen Zustände als Alarm- Zustände definiert werden können. Alarme müssen mit den üblichen Severities (minor, major, critical) definiert werden. Um False- Positive- Alerts zu vermeiden (Paketverlust von 50% für Transfers von wenigen Paketen z.b. Keep- Alives), müssen sich Alarm- Konditionen kombinieren lassen (Paket Verlust von X % AND Traffic von > 50 Paketen/Sec.)

13 6 Troubleshooting Die APM Lösung dient sowohl zur Erkennung von Performance- Degradierungen als auch zur erweiterten Fehlersuche. Die Lösung muss das Informations- Set beinhalten, um Schwachstellen im Detail zu analysieren. Dazu werden klassische Fehlersuch- Workflows erwartet: 1) Erkennung eines Problems durch das Real- Time- Monitoring 2) Darstellung des Fehler- Bereiches ( wer ist seit wann wovon betroffen ) 3) Erst- Analyse durch die Monitoring- Lösung 4) Detail- Analyse durch Forensik/Paketanalyse 5) Verifizierung der Fehlerquelle/Lösungsvorschlag durch Emulation/Simulation Die Detail- Analyse ermöglicht die Analyse im tiefst- möglichen Grad, in der Paket- Analyse, da hiermit die Berechnung der Appliance über Negativ- Zustände verifiziert werden, und exakt überprüft werden kann. In der Detail- Analyse sollte sich die Fehlerquelle darstellen lassen. Durch Behebung der Fehlerquelle sollte damit der Service korrigiert werden können. Diese Funktion, dass angenommene Beheben eines angenommenen Fehlers, und eine damit verbundene Korrektur des Service, sollte sich software- unterstützt virtuell emulieren lassen. Wird z. B. festgestellt, dass eine Anwendung auf Grund mangelnder Bandbreite unperformant agiert, sollte sich aufzeigen lassen, dass durch Behebung des Bandbreitenmangels und der Errechnung des optimalen Bandbreitenbedarfs die Applikation zufriedenstellend performt. 6.1 Anforderungen Erfassen von RAW- Data- Packets in der APM Appliance Erfassung von Paket Daten, unternehmensweit an allen zu berücksichtigenden PORs (POR - points of relevance), unterstützt werden müssen Software- Agenten als auch bereits vorhandene Capture- enabled- Systems, die über einen nativen Capture- Mechanismus verfügen (wie WAN Acellerator, UNIX- Systems, Load Balancer etc.). Kontext basierter Export in Trace- Analyse- Tools Application basierte Trace Analyse auf Bit/Byte- Level o Transaktionserkennung o Transaktions- Performance- Bewertung Verification/Simulation Funktion zur Überprüfung des Erfolgs einer angenommen Lösung 7 Schnittstellen

14 7.1 Data Import/Export Schnittstellen Informationen müssen aus dem System in unter- bzw. übergeordnete Fremdsysteme exportiert werden können. Dazu gehören: Packet Traces (Wirehark Format) Alerts o SNMP o Syslog o Statistiken (CSV) Konfigurationen (Standorte, User, Alerts, Applikationsdefinitionen) 7.2 Management Schnittstellen Jeder einseitige APM Management Ansatz bedingt eine systemische technische Limitierung. So kann ein Paket- Analyse- System nicht erkennen, welche Prozesse auf den Servern laufen und damit den Grund für seine schlechte Antwortzeit angeben, bzw. nur Paketverlust konstatieren ohne den Grund bzw. den kritischen Punkt im Netz dafür anzugeben. Aus diesem Grund werden derartige Probe- basierte Ansätze oft mit Systemen gekoppelt bzw. integriert, die weitere Analysen auf System- Ebene ermöglichen, bzw. bereits vorhandene Management- Agenten wie SNMP etc. verwenden. Dabei muss erklärtes Ziel sein, nicht nur in andere Tools zu verzweigen sondern tool- übergreifende Informationen zu integrieren, und damit Workflows zu ermöglichen, die ein echtes End to End- Application Performance Management bezeichnen: Erkennung von Negativ- Zuständen Darstellung der Auswirkung für den End- Benutzer Data Mining für historische Vergleichs- Analysen Integration von System-, Netzwerk und Applikations- Informationen Hierbei ist die maximale Informationstiefe ausschlaggebendes Kriterium für die Auswahl von Management- Systemen, die es erlauben, aus einem Guss Analyse- Workflows durchzuführen. Kriterien sind demnach: System Ressourcebewertung auf lokalen Server Task- und Job Ressource Bewertung Baselining Application Code Erkennung und Bewertung

15 7.2.2 Netzwerk Hop- Bewertung der Netzwerk Systeme Möglichst automatische Erkennung von Fehlerzuständen auf einem Application- Path von Client zu Server.