Tipps für das Application Performance Monitoring


Reibungslos funktionierende Anwendungen und Services sind für Unternehmen heute unerlässlich. Ausfallzeiten - beispielsweise bei einer Website - können immense Umsatzeinbußen zur Folge haben. Daher ist ein wirksames Applications Performance Monitoring unumgänglich – sowohl von internen als auch externen Applikationen.

Erfolgreiche Unternehmen stellen daher den Kunden ins Zentrum und

  • bieten Self-Service-Technologien, damit Anwender auch selbst aktiv werden können und nicht für alle Tätigkeiten auf die Hilfe eines Support-Mitarbeiters angewiesen sind.
  • bieten digitale, kontextbasierte Applikationen, so dass die Anwendungen auf jedem Endgerät in derselben Qualität verfügbar ist.
  • entwickeln diese Applikationen weiter, um einen hohen Qualitätsstandard sicherzustellen.

Was sind die häufigsten Fehler beim Application Performance Monitoring?

Kein ganzheitlicher Ansatz

Viele Bereiche oder Entwickler setzen eigene Monitoring-Tools ein, um die für sie wichtigen Parameter zu überwachen. Das führt zu vielen Einzellösungen und unübersichtlichen, teils doppelt vorhandenen Datensätzen. Doch welche Informationen sind zuverlässig und vergleichbar?

Fehlende Zusammenarbeit

Die in Unternehmen verbreitete Aufteilung in Datenbank-, Netzwerk-, Server- und Desktop-Administratoren führt im Störungsfall häufig zu einem Pingpong-Spiel bei Zuständigkeiten und gar zu Schuldzuweisungen. Die Ursache der Störung lässt sich auf diese Weise jedoch nicht beheben.

Monitoring nur für den Live-Betrieb

Eine Funktionsüberwachung auf den Live-Betrieb zu beschränken, setzt zu spät an: Bei Ausfällen wären die Anwender bereits direkt betroffen. Für ein professionelles Monitoring muss bereits der Entwicklungsbereich einbezogen werden – denn schon in der Designphase lassen sich Log-Punkte einbauen, die es anschließend zu überwachen gilt.

Fokus ausschließlich auf Performance und Verfügbarkeit

Zu wissen, dass die Applikationen technisch gut laufen, sagt nichts über die Customer Experience. Erfüllt die Applikation auch die Anforderungen des Anwenders? Ist sie komfortabel zu bedienen?

Gutes Application Performance Management bezieht daher den Endanwender und alle IT-Bereiche mit ein: Netzwerk, Infrastruktur, Applikationen.

Folgende Schritte und Überlegungen sind für das Application Performance Management empfehlenswert:

  1. Applikationen überwachen
    1. Welche Anwendungen müssen überwacht werden (Web, Mobile, traditionelle Applikationen)?
    2. Applikations-Monitore anlegen
    3. Anwendungen gruppieren
    4. Abhängigkeiten identifizieren
  2. Die Ursache von Performance-Problemen analysieren
    1. Zusammenarbeit ermöglichen
    2. Die richtigen Dashboards erstellen
  3. Aufgaben automatisieren
    1. Alarme generieren und mit dem Ticketsystem verknüpfen
    2. Skripte ausführen, um gegebenenfalls System neu zu starten

Sehen Sie im Folgenden am Beispiel eines CMS-Systems / Webshops, wie eine professionelle Anwendungsüberwachung aussehen könnte:


Schritt 1: Applikationen überwachen

Der Entschluss steht also fest, das CMS-System zu überwachen. Doch welche Schritte sind für die konkrete Durchführung erforderlich? Die anschließende prototypische Vorgehensweise hat dabei durchaus „Rezept-Charakter“.


Schritt 1.1: Welche Anwendungen müssen überwacht werden?

Im Beispiel erfahren Sie, wie Sie die genannten Applikationen überwachen können, um bei Problemen oder Ausfällen Rückschlüsse auf die Ursache zu ziehen:

  • Verfügbarkeit der Webseite mit Antwortzeiten
  • Verfügbarkeit der Webseite aus Kundensicht (EUM)
  • Monitoring des Apache/IIS-Webservers
  • Monitoring der Zertifikate
  • Monitoring des Application Server
  • Monitoring von Tomcat
  • Monitoring der MS-SQL/Oracle/… Datenbank
  • Monitoring APM Insight
  • Monitoring Java Runtime
  • Monitoring Exchange (für Empfang und Weiterleitung von Bestellungen)
  • Monitoring Server mit Netzwerk
  • Monitoring virtuelle Umgebung (optional)
  • Monitoring Cloud (optional)

Schritt 1.2: Applikations-Monitore anlegen

Für alle zu überwachenden Anwendungen müssen Sie zunächst Applikations-Monitore einrichten. Wählen Sie dazu im Applications Manager in der zweiten Menüleiste Add New Monitor aus. Im Beispiel legen Sie den Monitor „Java Runtime“ an und definieren die entsprechenden Parameter. Hilfestellung beim Ausfüllen gibt die rechts eingeblendete Helpcard.


Schritt 1.3: Anwendungen gruppieren

Im nächsten Schritt fassen Sie die Monitore zu einer Gruppe zusammen. In unserem Beispiel legen Sie die Gruppe „Webapplications“ an und assoziieren im Anschluss die Monitore in die Untergruppen.

Sobald Sie in der zweiten Menüleiste auf Add New Monitor Group klicken, schlägt Applications Manager bereits entsprechende Gruppen vor. In unserem Beispiel wählen Sie die Web Application Group. Geben Sie der Gruppe einen Namen sowie eine Beschreibung und bestimmen Sie die für die Betreuung verantwortlichen „Owner“.

Auch an dieser Stelle macht Applications Manager automatisch Vorschläge für Untergruppen, die „Application Components“, und legt sie direkt an.

Klicken Sie anschließend auf Advanced und wählen Sie den Standort aus. Schließen Sie den Vorgang mit Create Group ab.

Assoziieren Sie nun die Monitore mit der Gruppe. Im Beispiel wählen Sie dafür die „Web Server Group“, klicken auf Associate Monitors und setzen das Häkchen beim Monitor „EUM-RBM ME-CMS01“.

Führen Sie diese Aktionen für alle Monitore und Untergruppen aus. Sind alle Untergruppen angelegt, erscheint folgende Übersicht für die CMS-Gruppe:


Schritt 1.4: Abhängigkeiten identifizieren und Schwellwerte setzen

Schwellwerte für Monitoring-Attribute definieren bzw. Templates editieren

Im Beispiel legen Sie für das URL-Monitoring ein neues Schwellwert-Profil an. Klicken Sie dazu oben in der zweiten Menüleiste auf Treshold Profile, wählen New Treshold Profile und definieren die Grenzwerte für die Veränderung der Seitengröße in Prozent. Ist der Wert größer als 50%, handelt es sich um einen kritischen Alarm. Ab 30% soll bereits eine Warnung ausgelöst werden, und bei einem Grenzwert kleiner als 30% wird der Alarm auf „clear“ gesetzt. Ergänzen Sie noch eine Beschreibung, und erstellen Sie über Create Treshold Profile den Schwellwert.

Schwellwerte dem Attribut des Monitors zuweisen (direkt oder in der Vorlage)

Im Beispiel setzen Sie über Configure Alarms in der zweiten Menüleiste die Option „Configure by Monitor / Monitor Groups Monitorgroup“. Wählen Sie hier „Monitor Group“ und anschließend in der zweiten Zeile unter „Monitor Group“ die „Web Server Group“. Bei „Action Type“ klicken Sie in das Feld „Template“ und wählen den Monitor-Typ „HTTP(s) URLs“. Es folgt die Konfiguration des Alarms beim Attribut „PageSize Change(%)“ über einen Klick auf Associate.

In einem neuen Fenster wählen Sie nun unter Associate Threshold das zuvor erstellte Profil aus. Beim Attribut „Page size changed in %“ sollen die bestehenden Schwellwerte in der Gruppe „Web Server Group“ überschrieben werden. Setzen Sie hierzu den Haken in das Feld „Override existing Treshold Configuration for monitors in Web Server Group“.

Abhängigkeiten unter den Monitoren und ggf. auch vom verfügbaren Host bestimmen (direkt oder in der Vorlage)

Im Beispiel gehen Sie in die Monitorgruppe „Web Server Group“. Klicken Sie oben rechts auf den Button Monitor Group Actions und wählen dann im Dropdown-Menü Configure Alarms. Klicken Sie nun auf den unteren Button Configure Availability.

Es öffnet sich ein neues Fenster, dort lässt sich über den Tab „Dependent Device“ das abhängige Gerät verknüpfen, und zwar über Add Dependent Device. Verknüpfen Sie nun die abhängigen Geräte.

Verfahren Sie mit allen anderen Geräten auf die gleiche Weise: Identifizieren Sie weitere Abhängigkeiten und setzen Sie Schwellwerte für alle entsprechenden Monitore.


Schritt 2: Die Ursache von Performance-Problemen analysieren

Im Beispiel befinden sich die Webserver-Gruppe auf „Warning Level“ und die Gruppe „End User Transaction“ auf kritischem Niveau. Ursache des kritischen Zustands ist in diesem Fall der End-User URL-Monitor, da der Schwellwert für Antwortzeiten (>500ms) überschritten wurde.

Für eine detaillierte Analyse eignen sich z. B. „APM Insight“ (Antwortzeiten auf Applikationsebene) sowie die Analyse auf Netzwerkebene.


Schritt 2.1: Zusammenarbeit ermöglichen

Um Silo- bzw. Inseldenken zu vermeiden, können Sie Kollegen Zugriffsrechte auf die für sie relevanten Informationen geben. Gehen Sie dazu über den Admin in der Rubrik „Product Settings“ in das User Management und wählen Sie eine „User Group“ bzw. erstellen Sie eine neue Gruppe. Im Beispiel ist die entsprechende Gruppe „Server Admins“. Wählen Sie im Anschluss diejenigen User aus, die Sie dieser Gruppe zuordnen möchten. In der Ansicht „Select Monitor Group“ erhalten in unserem Beispiel die Mitglieder dieser Gruppe so Zugriff auf die Monitor-Gruppe „Servers Group“.


Schritt 2.2: Die richtigen Dashboards erstellen

Erstellen Sie für die Monitor-Gruppe eine eigene Gruppenansicht. Dazu klicken Sie im Home Screen rechts auf den Button Actions und im Anschluss auf New Dashboard. Geben Sie Ihrem neuen Dashboard einen Namen sowie eine Beschreibung, und wählen Sie aus der Liste die gewünschten Ansichten aus.


Schritt 3: Aufgaben automatisieren

Gehen Sie im Bereich „Admin“ auf Actions und wählen Sie eine Aktion aus. In unserem Beispiel soll ein Script ausgeführt werden, das auf dem Applications Manager Server hinterlegt wurde und einen Neustart durchführen kann.


Schritte 3.1 & 3.2: Alarme generieren, mit dem Ticketsystem verknüpfen und Scripte ausführen

Als weitere Aktion soll Applications Manager bei einem Alarm eine E-Mail versenden und ein Ticket im ServiceDesk Plus eröffnen. Dazu ist es zunächst erforderlich, das Ticketsystem mit dem Applications Manager zu verbinden. Klicken Sie dazu im Bereich Admin auf Product Settings/Add-On Settings.

Danach kann die entsprechende Action definiert werden.

Im nächsten Schritt lassen sich die definierten Aktionen mit den Monitoren, deren Attributen oder mit einer Monitor-Gruppe verknüpfen. Dazu gehen Sie im jeweiligen Fenster (Gruppe bzw. Monitor) auf Configure Alarms aus dem Action Menü und wählen dort entweder Health oder Availability.

Wenn beispielsweise der Tomcat-Monitor nicht verfügbar ist (Availability), soll per Ticket im System eine Benachrichtigung erstellt werden, und erneut, wenn der Monitor wieder verfügbar ist.

Ist das Attribut „Health“ (zu dem alle untergeordneten Attribute gehören bzw. zugefügt werden können) des Apache ME-CMS-Monitors kritisch, soll das System einen Neustart des Servers durchführen und per E-Mail ein Ticket erstellen. Bei Warnungen wird genauso vorgegangen. Sobald der Zustand wieder im normalen Bereich ist, wird das Ticket geschlossen und eine E-Mail an die dazu hinterlegte Adresse verschickt.

Sicht auf das Ticket in ServiceDesk Plus „Achtung Servers Group hat Probleme“


Fazit

Wenige, einmalig auszuführende Schritte genügen also bereits, um die Verfügbarkeit kritischer Systeme langfristig zu sichern – gut investierte Zeit bei einem Blick auf mögliche Umsatzverluste durch Ausfälle. Auch aufwändige und zeitkritische „Reparaturen“ sind somit meist nicht mehr erforderlich, was für alle Beteiligten ebenfalls nur von Vorteil ist.

ManageEngine – Support & Kontakt


MicroNova AG
Unterfeldring 6
85256 Vierkirchen

Vertrieb
   +49 8139 9300-456
   Sales-ManageEngine@micronova.de

Technische Unterstützung
   Support kontaktieren