Was ist Application Performance Monitoring (APM)?

Was ist Application Performance Monitoring (APM)?

Application Performance Monitoring (APM) beobachtet eine laufende Anwendung von innen. Ein kleiner Agent in deinem Code zeichnet auf, wie lange jede Anfrage dauert, welche Datenbankabfrage oder welcher externe Aufruf sie gebremst hat und welche Codezeile einen Fehler ausgelöst hat. Du erhältst Antwortzeiten, Fehlerraten, Durchsatz und Request-Traces für echten Produktions-Traffic, gruppiert nach Endpunkt, Service und Host.

So funktioniert APM

Ein APM-Agent läuft im Prozess deiner Anwendung (JVM, Node.js, .NET, Python, Ruby) und klinkt sich in Web-Frameworks, Datenbank-Clients, HTTP-Clients, Queue-Consumer und Caches ein. Jeder instrumentierte Aufruf erzeugt einen Span mit Start- und Endzeit, Elternteil und Tags. Zusammengesetzte Spans bilden einen Trace: den vollständigen Weg einer Anfrage vom Einstiegspunkt bis zur Datenbank und zurück. Aggregiert ergeben Traces die Dashboards, die Teams bei einem Vorfall öffnen.

Beispiel: Der Checkout fühlt sich langsam an. Der Trace einer langsamen Anfrage zeigt 80 ms in deinem Code und 1,9 s Wartezeit auf einen Zahlungsanbieter. Ohne Trace würdest du zwischen Anwendung, Datenbank und Netzwerk raten.

APM vs. Synthetic Monitoring vs. RUM

• APM sitzt in deinem Code und meldet echte Produktionsanfragen mit Detail pro Anfrage. Ideal, um den langsamen Endpunkt oder die langsame Abfrage zu finden.
• Synthetic Monitoring führt skriptgesteuerte Prüfungen von außen aus, in festem Intervall und von festem Standort. Ideal für Verfügbarkeit und für Probleme, wenn kein echter Nutzer online ist.
• Real User Monitoring (RUM) läuft im Browser und meldet, was echte Besucher erlebt haben, inklusive Gerät und Netzwerk. Ideal für die Sicht des Nutzers.

Sie beantworten unterschiedliche Fragen. APM kann zeigen, dass der Server in 80 ms geantwortet hat, während RUM zeigt, dass ein Besucher im langsamen Mobilfunknetz vier Sekunden wartete. APM ist außerdem ein Baustein von Observability, neben Logs und Metriken.

Was APM erfasst

• Rate, Fehler und Dauer pro Endpunkt (die RED-Methode).
• Latenz-Perzentile wie p50, p95 und p99. Warum Durchschnitte täuschen, steht unter Latenz.
• Verteilte Traces über Services hinweg, jeder Hop mit Zeit.
• Datenbank-Performance: langsame Abfragen, wiederholte Abfragen in einer Schleife (N+1) und Wartezeiten auf den Connection-Pool.
• Externe Aufrufe an Drittanbieter-APIs und Zahlungsdienste, oft der langsamste und am schwersten zu behebende Teil.
• Laufzeit-Gesundheit: Speichernutzung, Garbage-Collection-Pausen, Event-Loop-Verzögerung.
• Exceptions mit Stack-Traces, nach Ursache gruppiert und gezählt.

Worauf du alarmieren solltest

1. p95-Latenz deutlich über der üblichen Basislinie eines Endpunkts.
2. Fehlerrate über deinem Ziel. Erfasse 5xx und 4xx getrennt, da 4xx oft Fehlbedienung durch den Client ist.
3. Durchsatz-Einbruch unter das übliche Niveau, oft das erste Zeichen, dass ein Load Balancer ein Ziel verloren hat.
4. Steigende Latenz externer Aufrufe, die dein Service als eigene Verzögerung erbt.

Wähle Schwellenwerte aus deiner eigenen Basislinie und deinen SLOs, nicht aus einer allgemeinen Zahl.

Häufige Fehler

• Alarme auf Durchschnitte, die den langsamen Rand verbergen.
• Nur HTTP-Routen tracen und nie Geschäftsschritte wie Checkout oder einen Batch-Job. Ergänze eigene Spans dafür.
• So stark samplen, dass seltene langsame Anfragen nie auftauchen.
• APM im Staging auslassen, sodass Lasttests nicht zeigen, wo die Zeit bleibt.

APM einführen

Wähle ein kommerzielles APM-Produkt oder einen Open-Source-Stack (Traces und Metriken mit offenen Standards), installiere den Sprach-Agent, vergib einen Service-Namen und prüfe, dass Traces innerhalb weniger Minuten ankommen. Ergänze dann eigene Spans um die Abläufe, die für dein Geschäft zählen. Einen Produktvergleich findest du im Blog-Leitfaden zu APM-Tools.

APM und Load Testing

APM zeigt, was in der Produktion passiert. Load Testing zeigt, was bei mehr Traffic passieren wird. Fahre einen Lasttest gegen Staging mit aktivem APM, und du siehst, welcher Endpunkt zuerst an seine Grenze stößt und warum. Ein längerer Soak-Test mit laufendem APM zeigt außerdem Speicherwachstum über die Zeit. LoadFocus Load Testing erzeugt den Traffic aus 25 Cloud-Regionen und liefert pro Lauf ein Bestanden/Nicht-bestanden-Urteil zu Schwellenwerten für Antwortzeit und Fehlerrate.

LoadFocus ist kein APM und instrumentiert deinen Code nicht. API-Monitoring ist das Gegenstück von außen: Es prüft deine Endpunkte nach Zeitplan (im Free-Plan alle 5 Minuten) und teilt jede Antwortzeit in DNS, TCP-Verbindung, erstes Byte und Download auf, sodass du ein Problem auch bemerkst, wenn kein echter Nutzer es auslöst.

Häufige Fragen

Wofür steht APM?

Für Application Performance Monitoring. Manche Anbieter nutzen es auch für Application Performance Management, das zusätzlich Optimierung und Fehlerbehebung umfasst.

Was ist der Unterschied zwischen APM und Logging?

Logs erfassen einzelne Ereignisse, die du selbst schreibst. APM erfasst automatisch Zeiten und Kontext jeder instrumentierten Anfrage, sodass du siehst, wo die Zeit blieb, nicht nur was passiert ist.

Ist APM dasselbe wie Observability?

Nein. APM ist eine Praxis innerhalb von Observability. Observability umfasst auch Logs, Infrastruktur-Metriken und die Möglichkeit, neue Fragen an die Telemetrie zu stellen.

Brauche ich Synthetic Monitoring, wenn ich APM habe?

Ja. APM sieht nur Traffic, der deinen Code erreicht. Eine synthetische Prüfung von außen bemerkt einen Ausfall, einen fehlerhaften DNS-Eintrag oder ein abgelaufenes Zertifikat auch dann, wenn keine Anfrage ankommt.

Bremst APM meine Anwendung aus?

Ein Agent verursacht etwas Overhead. Die meisten Produkte lassen ihn über Sampling steuern. Miss ihn, indem du denselben Lasttest mit und ohne Agent fährst.