APM in Zeiten von DevOps und Cloud

Software Applications laufen heutzutage in einer Vielzahl von IT-Umgebungen – auf klassischer Hardware oder virtualisiert in Clouds. Gleichzeitig rücken Systemadministration und Software-Entwicklung nach dem DevOps-Prinzip immer weiter zusammen.

Entwicklung, Installation in virtualisierter Umgebung, persistentes Monitoring, zügiges Troubleshooting und letztlich weniger Aufwand im Betrieb der Applikation selbst als auch der IT-Landschaft, in die sie eingebettet ist, ergeben zusammen den natürlichen Lebenszyklus des APM. Endziel ist es, für Anwender und Kunden ein optimiertes Service Level bereitzustellen.

Was ist APM?

Einfach gesprochen verbirgt sich hinter Application Performance Monitoring und Management die Methode, Software als gekapselte Applikation zu besserer Leistungsfähigkeit zu verhelfen und ihre Verfügbarkeit zu optimieren sowie ihre Nutzbarkeit für den letztendlichen User zu verbessern. Das Monitoring der Software liefert Informationen, die wiederum Impulse für die kontinuierliche Verbesserung der Performance und eine gesteigerte Anwenderfreundlichkeit ermöglichen. Vereinfacht wird manchmal bei Application Performance Monitoring und Management etwas einschränkend von Application Performance Measurement gesprochen. Schlussendlich jedoch mündet APM stets darin, Software günstiger und verlässlicher und für den User anwenderfreundlicher zu gestalten – und dabei die Bedürfnisse moderner IT zu berücksichtigen.

Am Anfang aller Software steht das Coden und intensive Testen in den Testumgebungen. Je nach Applikation muss von Beginn an daran gedacht werden, für die Portabilität der Anwendungzu sorgen, um sie auf verschiedenenAnwendersystemen zum Laufen zu bringen und gegebenenfalls zu migrieren. DevOps als Leitgedanke sorgt dafür, dass schon ab der Konzeption von Software Entwickler und Administratoren zusammenarbeiten und es als Ziel ansehen, dass die Anwendung von Beginn an betriebs- und anwenderfreundlich gebaut wird. Ein praktisches Beispiel für DevOps findet sich auf www.devopscentral.com. Ist die Applikation in der Testumgebung umfassend qualitätsgesichert worden, erfolgt das Deployment – und damit die erste richtige Bewährungsprobe für APM: Der Betrieb in Produktivumgebung.

Code Monitoring

Von Beginn an muss der Betrieb nun konstant in Echtzeit überwacht werden. Dies geschieht idealerweise bis hinunter auf die Code-Ebene. Tools wie New Relic, AppDynamics oder Dynatrace profilieren das Ausführen des Codes und protokollieren die anfallenden Transaktionen und Requests. Gleichzeitig arbeitet Software ja heute im Verbund mit anderen Anwendungen oder mit unterschiedlichen Host-Systemen. Somit ist es gleichfalls wichtig, die Code Performance im Netzwerkverbund im Blick zu haben. In der Cloud bei Providern wie AWS, Azure oder ProfitBricks tritt noch ein wichtiger dritter Aspekt hinzu: die Auswirkungen der Software auf die Hardwareressourcen. Software muss ressourcenoptimiert betrieben werden können, um Hardware sparsam einsetzen zu können. In die Überwachung miteinbezogen werden typischerweise Applikationen auf virtuellen Anwendungsservern sowie Web Server und damit verknüpfte Datenbanken. Allen diesen Systemen ist zu eigen, dass ihr Betrieb garantierten Servicelevels unterliegt. Folglich hat die Performance und die Verfügbarkeit der Applikation direkte Auswirkungen auf den Betrieb der darunter befindlichen Serverinstanz.

Das Ziel von APM ist es, Software günstiger, verlässlicher und anwenderfreundlicher zu gestalten.

Virtualisierungs- und Cloud Monitoring

Softwarecode, der kontinuierlich in der Produktionsumgebung überwacht wird, produziert Daten und Metriken, die über einen Zeitverlauf gemessen werden können. So lassen sich Benchmarks festlegen, innerhalb deren Grenzen Software ablaufen darf. Gleichzeitig liefern sie Eckpunkte für Zielvorgaben bei Verbesserungswünschen.Tools wie Retrace von Stackify protokollieren das Softwareverhalten auf mehreren Ebenen und bilden es ab. Selbstredend setzt solches Monitoring optimalerweise schon im Entwicklungsstadium der Software ein und nicht erst im Anwendungsbetrieb nach Roll-out. In der Cloud ist zusätzlich zu beachten, ob und ggf. wie sich die Software Performance in Abhängigkeit von der zur Verfügung stehenden Prozessorkapazität und der Art und Geschwindigkeit des verwendeten Speichers verhält. Werden Cores einer Anwendung bzw. einer virtuellen Instanz dezidiert zugewiesen, gibt es genügend Arbeitsspeicher und steht SSD-Storage zur Verfügung, wenn auf externe Daten zugegriffen werden muss? Oder muss die Anwendung sich die Ressourcen des Hostsystems mit anderen teilen?

Auf den Endnutzer abgestimmtes Monitoring

Jedes Monitoring von Applikationen sollte die gemessenen Werte in übersichtlicher Art und Weise darstellen. Über den Zeitverlauf hinweg muss nachvollziehbar sein, wie:

• die Softwareanwendung generell genutzt wird, um übliche Peaks von unvorhergesehenen Lastspitzen unterscheiden zu können,

• sich Herausforderungen wie SQL Queries und Queues auf die Performance auswirken oder welchen Einfluss Caches haben,

• welche Transaktionen und Requests üblicherweise längere Zeit benötigen

• welche Transaktionen und Requests zeit- und jobabhängig häufig oder weniger häufig ablaufen.

Idealerweise werden die gemessenen Informationen möglichst in Echtzeit aus den Rohdaten aufbereitet und grafisch um insbesondere im Störfall einen schnellen Überblick zu haben oder diesen vor Entstehung abzuwenden, so wie es Tools wie AlertSite oder Retrace tun.

Troubleshooting

Wenn Softwareapplikationen nicht optimal performen, kann das zwei Gründe haben. Zum einen möchte man ihre Leistungsfähigkeit planhaft steigern, um kontinuierliche Verbesserungen zu erzielen. Zum anderen kann es zu Störfällen, sogenannten Incidents, kommen. Bei letzteren gilt es, unverzüglich zu reagieren und schnell auf Performanceeinbußen und Ausfälle zu reagieren. APM wirkt dann besonders effektiv, wenn relevante Erkenntnisse nicht nur zügig bereitstehen, sondern auch noch Gründe liefern, um die spätere Root-Cause-Analyse bzw. Problem-Analyse voranzutreiben.

Eine ganze Reihe von Fragen sind zu beantworten:

• Hat sich die Performance im Vergleich zum erwartenden Niveau bei gleichartiger Tageszeit und Auslastungsart und -last verändert?

• Wie verhielt sich der Code? Welche Key Methods wurden angesprochen? Welche reagierten langsam? Verursachten JIT-Compiler oder Garbage Collection Verzögerungen? Welche spezifischen Abhängigkeiten der Software in Zusammenarbeit mit externen Anwendungen gab es?

• Wie verhielten sich die Software umgebenden Systeme wie Datenbanken, externe Web Services, Serverinstanzen oder Netzwerke? Gab es Noisy Neighbours? Wieviel CPU und Arbeitsspeicher standen zur Verfügung? Wieviel verbrauchte die Anwendung?

• Wie verhielten sich insbesondere externe Web Requests und Transaktionen? Welche Spuren hinterließen diese Vorgänge? URLs, Usertypen und Clients – welche Logging Statements oder Application Errors gab es zu verzeichnen? Welches sind die Key Methods im verwendeten Code?

• Software ist oft Teil eines Frameworks. Neben der Messung softwaretypischer Metriken der in Frage kommenden Applikation wie z. B. Garbage Collection, Queing Requests, Transaktionsvolumina, Page-Load-Dauer sollten Framework Services wie JMX mBeans, Elasticsearch, Redis, SQL und viele andere mit betrachtet werden.

• Wo sind die Log Files der Applikation? Aufbereitete Daten helfen für den schnellen Überblick. Öfter als gewünscht muss jedoch ein Blick in die Log Files her. Hilfreich wäre es, wenn alle am Troubleshooting teilnehmenden DevOps dezentral Zugriff hätten auf diese essenzielle Datenquelle.

• Gibt es neue Typen von Application Errors? Werden diese in Echtzeit angezeigt? Es lohnt sich, neu auftretende Fehlermeldungen oder eine abweichende Zusammensetzung der üblichen Fehlermeldungen genau zu beobachten. Häufig lässt sich ein tiefergehender Systemausfall bereits voraussehen und vorbeugend bekämpfen.

• Last but not least nützt das komplette Monitoring aller serverseitigen Anwendungen nichts, wenn nicht die Client-Seite miteinbezogen wird. Langsam ladendes oder fehlerhaftes Javascript z.B. mag ganz unerwünschte Auswirkungen auf die Performance der zu managenden Applikation aufweisen. Somit ist es unerlässlich, auch die echten Endanwender in die Überwachung und Fehleranalyse mit einzubeziehen.

Hohes Service Level

Cloud Computing erfordert Vertrauen der Kunden und Anwender – insbesondere gilt es Vertrauen zu schaffen, denn Kunden sourcen durch Cloud Computing einen Teil ihrer IT gewissermaßen aus. Selbst wenn der Kunde in einer IaaS Cloud beispielsweise selbst für die Überwachung seiner eigenen Applikationen Sorge trägt, so ist doch auch der Cloud Provider mit in der Pflicht dafür zu sorgen, dass die Anwendungen des Kunden nicht komplett systemschädigend sind bzw. Auswirkungen auf die IT-Workload dritter Kunden haben. In PaaS oder SaaS Clouds sind es dann die Anwendungen generell, die monitort und gemanagt werden müssen. Gerade von der Cloud erwarten Anwender, dass sie stets verfügbar ist und hochgradig gut performt.

An einhundertprozentiger Verfügbarkeit wird hart gearbeitet. Fail-over-Architekturen helfen dabei. Letztlich sticht der Cloud-Dienstleister heraus, dem es gelingt, die höchsten Mehrwert- bzw. Service- Level-Grade für den Kunden zu erzielen. Ein harter Job, der auf APM nicht verzichten kann.

Autor: Uwe Geier, Head of System Operations, ProfitBricks