Application-Performance-Management
Sammeln und bewerten
Die IT befindet sich in einem konstanten Umbruch. In der Vergangenheit sind Anwendungen von einem Werkzeug zur Erleichterung der Arbeit zu einem unverzichtbaren Bestandteil, sogar zum Rückgrat eines Unternehmens geworden. Mittlerweile gibt es Unternehmen, die sich über eine einzige Applikation definieren. Ebenso hat sich das Deployment dem Business angepasst. Es ist nicht mehr allgemein hybrid, sondern Multi-Cloud-hybrid und basiert auf Containern und Micro-Services.
Nicht weniger komplex ist die digitale Transformation in traditionellen Unternehmen oder gar dem öffentlichen Sektor, wo die scheinbar moderne Bedienung über eine App auf dem Smartphone oft lediglich eine Isolierungsschicht ist, die als Proxy den Zugriff auf eine veraltete Infrastruktur und verteilte Datenquellen ermöglicht.
Unabhängig von Deployment oder dem tatsächlichen Umfang ist es für jedes Unternehmen wichtig, die genutzten Anwendungen auch im Griff zu behalten. Dazu dienen verschiedene Techniken, die sich unter dem Begriff Application-Performance-Management (APM) zusammenfassen lassen.
Zunächst gilt: Konstrukte jeglicher Komplexität lassen sich überwachen. Der kleinste gemeinsame Nenner in Sachen Überwachung sind die Logs, die sowohl die Cloud-Anbieter als auch die Anwendungen selbst generieren. Der Umgang mit diesen ist relativ simpel. Grundsätzlich stellen sich nur zwei Fragen: Wie kann man Logs sammeln? Und: Wo werden sie abgelegt?
Der Zugriff wiederum variiert. Sind es einfache Syslogs, wird der Quelle eine IP-Adresse als Ziel vorgegeben. Manche Systeme nutzen lokale Speicherorte für Logdateien, auf die man per FTP oder SMB zugreifen kann. Andere legen Logs direkt in einer Datenbank an. Die meisten modernen Systeme verfügen jedoch über eine API. Gesammelte Logs sollte man jedoch zentral ablegen. Dazu gibt es sowohl On-Premises- als auch SaaS-Lösungen, die Vor- und Nachteile haben können. Was der IT-Profi häufig übersieht: Im Gegensatz zu Metriken einer Anwendung können Logs sensible Daten enthalten. Beim Umgang gilt es folglich möglicherweise, auch gesetzliche Anforderungen zu beachten.
Zusammenfassend gewähren Logs einen Einblick in die „Gesundheit“ der Bereitstellung einer Anwendung. Ein Problem auf der zugrunde liegenden Plattform kann schnell zu einem Problem mit der Anwendung an sich führen.
Der Gedanke dahinter ist simpel: Bevor man Leistung und Verhalten betrachtet, muss die Verfügbarkeit gesichert sein. Daher dienen die Logs im Bedarfsfall auch direkt dem Troubleshooting.
Die Sicht des Anwenders
Eine weitere Option ist das „Überwachen“ der Anwender. Dabei unterscheidet man grundsätzlich zwischen echten und synthetischen Benutzern. Bei echten Benutzern wird ein Code in den Browser eingesetzt, zum Beispiel durch Cookies. Oder aber JavaScripts, die bei Mausklick auf einen Button auf der Website in der Session des Benutzers ablaufen. Dies ist klassisches „Real User Monitoring“ (RUM). Eine Kontrollanwendung „weiß“, wo der Code eingesetzt ist und auch, wann eine Antwort an anderer Stelle zu erwarten ist. Ist der Vorgang langsamer als üblich oder erfolgt er gar nicht, deutet dies auf eine Anomalie hin.
Leider ist ein echter Benutzer nur bedingt berechenbar, weshalb RUM eine größere Datenmenge benötigt, um verwertbare Informationen zu bekommen. Sobald jedoch die so gesammelten Informationen zur Verfügung stehen, sind diese auch anderweitig nutzbar, zum Beispiel im Marketing, wenn man feststellt, dass man Besucher an einer bestimmten Stelle auf der Website verliert.
Im Gegensatz dazu steht der „künstliche Benutzer“: ein automatisiertes Skript, das typische Schritte eines Nutzers immer wieder von verschiedenen Standorten aus ausführt. Dies stellt eine kontrollierte Umgebung dar, einen Sandkasten. Selbst die geringste Abweichung kann in diesem Fall eine tatsächliche Indikation liefern.
Beide Varianten liefern Informationen zu zwei Metriken von höchster Bedeutung: der tatsächlichen Antwortzeit der Anwendung sowie dem Durchsatz von Transaktionen, wie etwa bei einem Bestellvorgang. Was passiert jedoch im Hintergrund? Wenn noch genauere Informationen nötig sind, müssen die einzelnen Schritte einer Anwendung in Teilen unter die Lupe. Dazu setzt man üblicherweise einen Agenten auf dem Betriebssystem beziehungsweise der Plattform ein, der nicht nur Informationen von genutzten und verfügbaren Ressourcen sammelt und mit dem Web-Server kommuniziert, sondern auch direkt mit einem Framework wie .NET, Java oder Ruby.
Als Beispiel kann .NET dienen: Dort schleust man meist ein ASP.NET-NuGet-Paket ein, das mit sowohl dem IIS (Internet Information Server) als auch mit der WCF (Windows Communication Foundation) kommuniziert. Die Kommunikation mit der Anwendung findet dann idealerweise direkt über das .NET Core SDK statt. So lassen sich alle individuellen Aufrufe einer Anwendung abfangen und mitschneiden.
Dies ist umso sinnvoller, wenn der Kontext durch die darunterliegende Plattform ergänzt wird. Dabei ist es nun unerheblich, ob es sich um Windows, Linux, um einen Container, AWS CloudWatch oder Azure Monitor über die PowerShell handelt. Durch die Verbindung und visuelle Anzeige von Abhängigkeiten und Auslastungen lässt sich die Geschwindigkeit einzelner Schritte auswerten, bis hin zum Troubleshooting. Dies kann sogar nahezu in Echtzeit erfolgen.
In der Vergangenheit haben Techniker diesen Ansatz oft nur während der Entwicklung einer Anwendung verfolgt. Die notwendigen Werkzeuge waren sehr speziell, nicht gerade günstig zu beschaffen und die Bedienung ließ zu wünschen übrig. Durch den Fortschritt, den Bedarf am Markt und DevOps-Initiativen bei einigen Unternehmen hat sich dies jedoch verändert.
Leider sehen sich viele Technikexperten bei APM mit verschiedenen Herausforderungen konfrontiert. Dabei zeigt eine von Solarwinds in Auftrag gegebene Studie [1] den Mangel an Training als größte Hürde auf. Für Nicht-Entwickler ist das Thema APM noch relativ neu. Der „durchschnittliche“ Technikexperte weiß nicht, welche Metriken tatsächlich wichtig sind oder wie man an diese überhaupt gelangen kann. Anschließend folgt die Frage, was auf dem Markt verfügbar ist und welche Lösung den aktuellen Bedarf am besten abdeckt.
Nachdem eine Lösung angeschafft ist, verfallen IT-Profis oft in das Schema, sie nur zum Troubleshooting zu nutzen, wie man es von anderen Silos – beispielsweise der Netzwerküberwachung – gewohnt ist. Jedoch bietet gerade APM dem Business einen Mehrwert, nämlich durch ein Potenzial zu permanenter Optimierung. Diesen Mehrwert sollte das IT-Führungspersonal in der Planungsphase immer in Betracht ziehen.
- Sammeln und bewerten
- Eine Strategie kann helfen
Lesen Sie mehr zum Thema
