Was ist APM (Application Performance Management)?
Application Performance Management (APM) ist entscheidend für jede IT-Strategie und bietet viele Vorteile über die reine Leistungsüberwachung hinaus.
Zuletzt aktualisiert: 07. September 2026
Wofür steht APM?
Zwei Dinge, weshalb der Begriff so viel Verwirrung stiftet. Management ist die ältere und umfassendere Bedeutung. Monitoring ist das, was die meisten Anbieter verkaufen, also die Bedeutung, die auf Produktseiten und in Suchergebnissen dominiert. Die Managementseite ist eine Rolle, die jemand innehat. Jemand entscheidet, was “schnell genug” für jede Anwendung bedeutet, hält es schriftlich fest und ist verantwortlich, wenn es nicht eingehalten wird. Diese Person entscheidet auch, was ausgegeben wird – für Tools, für Entwicklungszeit, für Infrastruktur – um die Leistung sicherzustellen. In der Praxis umfasst die Management-Disziplin vier Dinge:- Zielsetzungen. Welche Antwortzeit, Fehlerrate und Verfügbarkeit jede Anwendung ihren Nutzern schuldet und welche davon vertraglich sind.
- Verantwortlichkeit. Welches Team für jedes Ziel verantwortlich ist und wer informiert wird, wenn es nicht eingehalten wird.
- Ausgaben. Was die Arbeit an der Leistung und die Leistungswerkzeuge kosten und was das Unternehmen dafür zurückbekommt.
- Belege. Die Berichte, die Kunden, Auditoren und Ihren Führungskräften beweisen, dass die Ziele erreicht wurden.
Application Performance Management vs. Application Performance Monitoring
Monitoring sagt Ihnen, dass die Kaufabwicklung letzten Dienstag beim 95. Perzentil 840 Millisekunden dauerte. Management entscheidet, ob 840 Millisekunden akzeptabel sind, wer verantwortlich ist, sie zu verringern, und ob diese Arbeit gegenüber den drei Funktionen, die darauf warten, Priorität hat. Die eine liefert Daten. Die andere liefert Entscheidungen.Die Frage | Beantwortet von |
|---|---|
Ist der Checkout-Prozess langsamer als im letzten Monat? | Monitoring |
Ist „langsamer als im letzten Monat“ schlimm genug, um zu handeln? | Management |
Welcher Dienst fügt die Latenz hinzu? | Monitoring |
Welches Team ist für die Behebung verantwortlich und bis wann? | Management |
Haben wir die 99,9 % Verfügbarkeitsziel im Q2 verletzt? | Monitoring |
Was schulden wir dem Kunden und verhandeln wir das SLA neu? | Management |
Eine Entscheidung, die Monitoring-Daten nicht treffen können
In den Dotcom-Monitor-Plattformdaten klären sich ungefähr 38 % der erkannten Ausfälle innerhalb von fünf Minuten von selbst. Eine Route schwankt, ein Knoten startet neu, eine Umschaltung wird abgeschlossen. Monitoring meldet jeden dieser Fälle genau.
Was Monitoring nicht sagen kann, ist, was man dagegen tun soll. Es folgen drei Entscheidungen, und alle drei sind Managemententscheidungen:
- Löst ein vierminütiger selbstheilender Ausfall nachts um 3 Uhr einen Techniker aus oder wartet man auf den Morgenbericht?
- Zählt er gegen die Verfügbarkeitszahl im Vertrag? Das hängt davon ab, ob Ihre Vereinbarung eine Mindestdauer für Ausfälle festlegt – viele tun das nicht.
- Ist die Entwicklungsarbeit, um diese Art von Fehler zu beseitigen, mehr wert als das, was als nächstes auf der Roadmap steht?
Wo ein Tool ins Spiel kommt: Dotcom-Monitor kann die erste Entscheidung durchsetzen, sobald sie getroffen wurde. Alarmfilter halten eine Benachrichtigung zurück, bis ein Monitor N-mal hintereinander fehlschlägt oder von M von N Standorten aus fehlschlägt, sodass ein einzelner flappender Prüfort niemanden weckt. Was die Plattform nicht kann, ist die Wahl von N. Setzen Sie sie zu hoch, verpassen Sie echte Ausfälle; ist sie zu niedrig, stoppt die Bereitschaft die Alarmweiterleitung. Diese Schwelle ist eine Managemententscheidung darüber, wie viel Risiko Sie für wie viel Schlaf tauschen möchten.
Die fünf Komponenten einer APM-Strategie
Die Standardunterteilung von APM hat fünf Teile und ist seit über einem Jahrzehnt das Referenzmodell für die Kategorie. Jeder Teil entspricht einer Frage, die Ihr Team mit Ja, Nein oder einem unbehaglichen Zögern beantworten kann – und einer klaren Antwort darauf, ob eine außen-in-Plattform wie unsere sie abdeckt.
1. End-User Experience Monitoring
Was Ihre Kunden tatsächlich bekommen: Seitenladezeiten, abgeschlossene Transaktionen und Fehler, gemessen von dort, wo sie sich befinden, nicht von innerhalb Ihres Netzwerks. Es ist die Komponente, die Ihr CDN, Ihren DNS-Anbieter und das Zahlungsgateway, das Sie nicht kontrollieren, in die Messung einbezieht, nicht ausschließt.
Fragen Sie Ihr Team: Von welchen Benutzerpfaden messen wir außerhalb unserer eigenen Infrastruktur und wie oft? Wenn die Antwort ist „ein Uptime-Check trifft alle fünf Minuten die Startseite“, messen Sie viel weniger, als Sie denken. Echtes Web Application Monitoring folgt dem gesamten Weg – Einloggen, Suche, Warenkorb, Checkout – nicht nur, ob die Haustür aufgeht.
Dotcom-Monitor deckt dies vollständig ab. Die Pfade laufen in echten Browsern von Tier-3-Prüfstellen auf sechs Kontinenten, auf über 40 Desktop- und Mobil-Browser- und Geräte-Kombinationen, mit simulierten 2G- bis 4G-Netzwerkbedingungen, sodass Sie sehen, was ein Kunde mit langsamer Verbindung sieht. Was es nicht kann: sagen, was Ihre echten Nutzer tatsächlich getan haben. Das sind skriptgesteuerte Pfade nach Zeitplan, kein Real User Monitoring (RUM). Zu wissen, welche von sechs Checkout-Varianten Nutzer abbrechen, ist eine RUM-Frage, und das ist eine andere Produktkategorie.
2. Runtime Application Architecture Discovery
Eine genaue, aktuelle Karte dessen, was mit was kommuniziert. Nicht das Diagramm, das jemand beim Systemdesign gezeichnet hat – sondern das, was tatsächlich heute morgen läuft, inklusive des Dienstes, den ein Auftragnehmer im März hinzugefügt hat.
Fragen Sie Ihr Team: Können wir eine aktuelle Abhängigkeitskarte ohne menschliches Zeichnen erstellen? Wenn ein Mensch sie aus dem Gedächtnis neu erstellen muss, beginnt Ihre Incident Response damit, überhaupt zu verstehen, wie das System aussieht.
Dotcom-Monitor macht das nicht, und das ist die größte Lücke im agentenlosen Ansatz. Automatische Erkennung Ihrer internen Service-Grafik benötigt einen Agenten innerhalb der Laufzeitumgebung. Was wir abdecken, ist stattdessen die externe Abhängigkeitsoberfläche: DNS-Auflösung, Zertifikatsablauf, Endpunkte von Drittanbieter-APIs und Traceroute aus mehreren Regionen, um ISP-Level-Routingänderungen zu erkennen. Das ist die Kartenhälfte, die außerhalb Ihres Codes liegt und von agentenbasierten Tools am schlechtesten gesehen wird.
3. Benutzerdefinierte Transaktionsprofilierung
Verfolgung der spezifischen Geschäftstransaktionen, die zählen – Angebot bis Bindung, zum Warenkorb hinzufügen bis Bestellung bestätigt, Einloggen bis Dashboard geladen – statt Durchschnittswerte aller Anfragen zusammen. Durchschnitte verschleiern die eine fehlerhafte Transaktion.
Fragen Sie Ihr Team: Nennen Sie die fünf Transaktionen, die uns Geld kosten, wenn sie fehlschlagen. Sind alle fünf instrumentiert und alarmieren separat? Die meisten Teams können sie schneller benennen, als sie beweisen können, dass alle fünf abgedeckt sind.
Dotcom-Monitor deckt dies vollständig ab. Der EveryStep Recorder erfasst einen Pfad, indem er ihn einmal durchläuft, und spielt ihn dann nach Zeitplan mit Schrittzeiten, Screenshots und HAR-Exporten ab. Skriptgesteuerte Logins laufen End-to-End über Okta, Auth0, Azure AD und Ping, was Fehler abfängt, die nur bei Schritt 4 von 6 beim Ablauf eines Session-Tokens auftreten. Was es nicht kann: den Codepfad innerhalb der Transaktion profilieren. Sie wissen, dass Schritt 4 neun Sekunden dauerte, nicht aber, welche Funktion sie verbraucht hat.
4. Komponenten-Deep-Dive-Monitoring
Details aus der Anwendung – Datenbankaufrufe, Warteschlangen, externe API-Aufrufe – zurückverfolgt zur auslösenden Transaktion. Ohne diese Verbindung erhalten Sie eine Wand von Komponentenmetriken ohne Bezug zur Kundenbeschwerde.
Fragen Sie Ihr Team: Wenn eine Schlüsseltransaktion langsam ist, wie viele Minuten vergehen, bis wir wissen, welche Komponente verantwortlich ist? Das ist meist der längste Abschnitt eines Vorfalls und den lohnt es, durch Investitionen zu verkürzen.
Dotcom-Monitor deckt einen Teil davon ab. Ein Seitenlade-Wasserfall zeigt die Zeiten aller Ressourcen, blockierende Assets und JS-Fehler; API-Monitore verketten Anfragen, übergeben Auth-Token und prüfen Endpunkt für Endpunkt die Antwortdaten; Protokollprüfungen identifizieren ein abgelaufenes Zertifikat oder einen fehlerhaften Downstream-Dienst. Was es nicht kann: die langsame SQL-Abfrage oder die Methode, die das Lock hält, benennen. Das ist wirklich Agenten-Territorium und wird durch außen-in-Messung nicht ersetzt.
5. Anwendungsanalyse
Umwandlung gesammelter Daten in Entscheidungen: Kapazitätsplanung, Trendberichte, SLA-Nachweise und Business Case für die nächste Runde an Leistungserweiterungen.
Fragen Sie Ihr Team: Welche Entscheidung haben wir im letzten Quartal aufgrund von APM-Daten getroffen? Wenn niemand eine nennen kann, bezahlen Sie für Datensammlung, die Sie nicht nutzen – der häufigste Grund, warum ein APM-Budget gekürzt wird.
Dotcom-Monitor deckt die Berichtshälfte ab: SLA-Berichte für Verfügbarkeit, Antwortzeit und Fehlerrate gemäß Ihren eigenen Schwellenwerten, exportierbar nach Zeitplan und im White-Label, wenn Sie ein MSP sind, der Kunden berichtet. Was es nicht kann: als allgemeines Analyse-Repository dienen. Sie können Monitoring-Daten nicht mit Umsatz- oder Funnel-Daten auf der Plattform verknüpfen; das gehört in Ihr Data Warehouse.
Vorteile des Application Performance Management
Die meisten veröffentlichten Listen von APM-Vorteilen könnten geschrieben werden, ohne etwas über Ihr Geschäft zu wissen. Hier sind die, die es wert sind, in Begriffen genannt zu werden, die ein Manager überprüfen kann, mit dem Mechanismus, der jeden einzelnen hervorbringt.
Verbesserte Benutzererfahrung
Leistung gemessen im Rechenzentrum und Leistung gemessen vom Handy eines Kunden mit 4G in São Paulo sind unterschiedliche Werte. Der zweite Wert ist der entscheidende Faktor für Entscheidungen. Hier zeigen sich Drittanbieter-Skripte, DNS-Auflösung und regionales CDN-Verhalten, die in serverseitigen Metriken nicht erscheinen. Der Mechanismus ist Geografie plus Gerät: Führen Sie dieselbe Reise aus den Regionen Ihrer Kunden aus auf den von ihnen genutzten Browsern und Netzgeschwindigkeiten aus, und das regionale Problem erscheint in einem Diagramm statt in einem Support-Ticket zwei Tage später.
Erhöhte operative Effizienz
Der längste Teil der meisten Vorfälle ist nicht die Behebung. Es ist die Zeit zwischen “etwas ist falsch” und “wir wissen, welches Team verantwortlich ist.” Der Mechanismus zur Verkürzung ist Beweiserfassung zum Zeitpunkt des Fehlers statt nachträglicher Rekonstruktion. Ein fehlgeschlagener Dotcom-Monitor-Durchlauf übergibt dem Bereitschaftstechniker den defekten Schritt, einen Screenshot, ein Video der Sitzung, das Konsolenprotokoll und den Wasserfall, bevor jemand etwas reproduzieren muss.
Kosteneinsparung und Optimierung
Das Geld zeigt sich an zwei Stellen. Überdimensionierte Infrastruktur, weil Teams für einen nie gemessenen Peak planen und APM-Daten ihnen sagen, wie der Peak wirklich ist. Und die Toolkosten, die davon abhängen, wie Ihr Anbieter abrechnet. Agentenbasierte Plattformen rechnen meist pro Host oder pro Gigabyte Datenvolumen ab, deshalb steigt die Rechnung, wenn Ihre Flotte oder Ihr Logvolumen wächst. Dotcom-Monitor basiert die Preise auf der Anzahl der Monitore, der Prüffrequenz und der Plattformmischung – keine Kosten pro Host oder Nutzer, keine Zeile für Datenvolumen. Keines der Modelle ist durchgängig günstiger. Die Kosten werden auf eine andere Variable verlagert, und die Frage ist, welche Variable Sie kontrollieren.
Fundierte Entscheidungsfindung
Kapazitätsplanung im Vorfeld eines bekannten Ereignisses – Produkteinführung, Black Friday-Spitze, Abgabetermin – ist nur so gut wie Ihre Basiswerte. Ohne Basis wird die Frage “Können wir das Fünffache an Traffic bewältigen?” von dem beantwortet, der im Meeting am sichersten klingt. Der Mechanismus ist simpel: Führen Sie dieselbe skriptgesteuerte Reise im gleichen Zeitplan lange genug aus, sodass Sie monatelange vergleichbare Zahlen haben, bevor Sie sie brauchen.
Proaktive Fehlererkennung und -behebung
Die messbare Version dieses Vorteils ist eine Zahl: Welchen Anteil Ihrer Vorfälle finden Sie, bevor ein Kunde einen meldet? Teams, die das nicht beantworten können, erkennen meist, dass ihre Erkennung schlechter ist als vermutet. Geplante Prüfungen erhöhen diesen Anteil, weil sie unabhängig von der Nutzung der Anwendung laufen – so finden Sie einen kaputten Checkout um 4 Uhr morgens an einem Sonntag. Die Einschränkung muss erwähnt werden: Sie decken nur die von jemandem skriptierten Pfade ab. Ein ungeskripteter Pfad kann still fehlschlagen.
Verbesserte Anwendungsbereitstellung
Leistungsrückgänge sind am günstigsten vor der Freigabe zu beheben. Ein Team mit Basiswerten kann in der Deployment-Pipeline eine Schwelle setzen: Wenn die Checkout-Transaktion in Staging 20 % langsamer wird, wird der Build gestoppt. Ohne Basiswerte wird die Regression ausgeliefert und erscheint eine Woche später in der Produktion, wenn sich niemand mehr an den Code erinnert. Die praktische Umsetzung ist, dieselbe aufgezeichnete Reise sowohl in Staging als auch in Produktion laufen zu lassen. Wenn Staging hinter einem VPN liegt oder keine öffentliche Adresse hat, sorgt ein Private Agent in Ihrem Netzwerk dafür, dass diese Prüfungen den öffentlichen entsprechen.
Der Markt für Application Performance Management und wie man Anbieter bewertet
Warum veröffentlichte Marktgrößen auseinandergehen
Suchen Sie nach „application performance management market“, erhalten Sie eine Seite voller Analystenfirmen, die Ihnen jeweils eine Zahl verkaufen. Legen Sie deren Zusammenfassungen nebeneinander, stimmen die Schätzungen für dasselbe Jahr nicht überein – nicht durch Rundung, sondern um Milliardenbeträge.
Diese Streuung ist keine Schlamperei, sondern Grenzziehung. Manche Firmen zählen ganze Observability-Plattformen; andere nur das APM-Modul darin; wieder andere schließen Infrastruktur-Monitoring, Log-Management und digitales Experience Monitoring ein oder aus. Und eine niedrig wirkende Zahl ist oft eine ältere Prognose, die noch ohne Bezugsjahr kursiert. Bevor Sie eine Marktzahl in eine Budgetanfrage setzen, prüfen Sie drei Dinge: Welche Firma hat sie veröffentlicht, was wurde gezählt und für welches Jahr gilt sie? Eine Zahl ohne diese Infos ist keine Messung.
Die Hauptkategorien von APM-Tools
Agentenbasierte Full-Stack-Plattformen. Tools wie Datadog, New Relic und Dynatrace installieren einen Agenten neben Ihrer Anwendung und instrumentieren sie von innen. Das bringt Detailinformationen auf Code-Ebene – die langsame SQL-Abfrage, die Methode, die das Lock hält – die sonst niemand liefern kann. Der Nachteil ist der Einführungsaufwand und eine Rechnung, die mit Ihrer Infrastruktur wächst. Die Preise berechnen sich typischerweise pro Host, pro eingelesenen Gigabyte, pro Nutzer oder einer Kombination. Dynatrace veröffentlicht zum Beispiel seinen Full-Stack-Tarif mit 58 USD pro Monat und 8 GiB Host, berechnet mit 0,01 USD pro Memory-GiB-Stunde, Stand August 2026. Schauen Sie auf die Einheit: Die Rechnung orientiert sich am Arbeitsspeicher Ihrer Hosts, nicht am Traffic.
Agentenloses externes Monitoring. Läuft die Anwendung von außen ab, so wie ein Kunde es tut, ohne etwas in Ihrem Code zu installieren. Es sieht, was der Kunde sieht, inklusive der Drittanbieter-SaaS, auf die Sie angewiesen sind, die Sie aber nicht kontrollieren oder instrumentieren können. Die Application Performance Monitoring Software von Dotcom-Monitor fällt in diese Kategorie, indem sie skriptgesteuerte Benutzerwege über echte Browser von externen Standorten abspielt – ein Ansatz, der allgemein als synthetisches Monitoring bezeichnet wird. Weil die Prüfungen außen-in laufen, spielt die daruntergelegene Laufzeitumgebung keine Rolle: Bare Metal, VMs, Kubernetes und Serverless werden gleich geprüft.
Open-Source- und OpenTelemetry-basierte Stacks. Sie bauen Ihre eigene Lösung aus OpenTelemetry-Instrumentierung plus Backend wie Prometheus, Grafana, Tempo oder Jaeger zusammen. Keine Lizenzgebühr und kein Anbieter, der Ihr Datenformat kontrolliert. Die Kosten verlagern sich auf die Entwicklung: Jemand baut’s, jemand betreibt’s, jemand hat Bereitschaft dafür. Gut geeignet für Teams mit eigenen Plattformingenieuren, weniger für Teams, die Entwicklungszeit von Produktentwicklern abzweigen.
SaaS vs. Self-Hosted. Das verläuft quer durch die drei Kategorien oben. Self-Hosting beantwortet Fragen zu Datenresidenz und -aufbewahrung nach Ihren Vorgaben und legt Ihnen die Betriebsverantwortung aufs Auge; SaaS ist das Gegenteil. Regulierte Branchen klären diese Frage meist zuerst.
Was außen-in Monitoring beantwortet und was nicht
Die meisten Organisationen nutzen Werkzeuge aus mehr als einer Kategorie, weil sie unterschiedliche Fragen beantworten. Folgend die Aufteilung für eine agentenlose Plattform wie unsere, klar dargelegt, damit Sie sehen können, welche Hälfte Ihrer Fragen sie offen lässt:
Die Frage | Agentenlos, von außen nach innen | Was Sie stattdessen brauchen |
|---|---|---|
Funktioniert der Checkout gerade für Nutzer in Frankfurt? | Ja – spiele die Reise von einem Frankfurter Checkpoint ab | — |
Hat das letzte Release das Seitenrendering verlangsamt? | Ja – vergleiche Wasserfälle vor und nachher | — |
Welche Drittanbieterabhängigkeit ist ausgefallen? | Ja – DNS-, Zertifikats-, API- und Protokollchecks | — |
Erfüllen wir den von uns unterzeichneten SLA? | Ja – SLA-Berichte gemäß Ihren Schwellenwerten | — |
Welche Datenbankabfrage ist langsam? | Nein | Eine agentenbasierte Plattform |
Welcher Service in unserem Mesh hat die Latenz hinzugefügt? | Nein | Distributed Tracing |
Was haben echte Nutzer gemacht, bevor sie abgebrochen haben? | Nein | Real User Monitoring |
Wie viel Last können wir ertragen, bevor wir versagen? | Nein | Ein Lasttest-Tool |
Was über die Feature-Liste hinaus zu prüfen ist
Feature-Checklisten gleichen sich an. Die meisten seriösen APM-Tools können die meisten Dinge. Die Unterschiede, die ins Gewicht fallen, zeigen sich erst nach der Vertragsunterzeichnung:
- Was die Rechnung antreibt. Hosts, verarbeitete Gigabytes, Nutzerplätze, Monitore oder Prüfintervalle? Wählen Sie das Modell, das zum Wachstum Ihres Systems passt. Preise pro Host bestrafen Teams, die viele kleine Container betreiben. Preise pro Gigabyte bestrafen ausführliche Protokollierung. Preise pro Monitor bestrafen eine breite Abdeckung.
- Standardmäßige Datenaufbewahrung. Fragen Sie, was enthalten ist und was eine Verlängerung kostet. Die Aufbewahrung ist der Punkt, an dem sich der angegebene Preis und die tatsächliche Rechnung unterscheiden.
- Pro-Host versus Pro-Transaktion. Wenn der Traffic stabil ist und Ihre Flotte wächst, ist pro Transaktion günstiger. Wenn es umgekehrt ist, ist pro Host günstiger.
- Zeit bis zum ersten nützlichen Signal. Eine Agenten-Rollout benötigt die Genehmigung des Plattform-Teams, ein Change-Fenster und einen Rückfallplan. Ein externes Monitoring benötigt eine URL oder eine aufgezeichnete Nutzerreise. Fragen Sie jeden Anbieter, wie lange es bis zur ersten echten Benachrichtigung dauert, nicht wie lange bis zum Vertragsbeginn.
- Vertragsgestaltung. Laufzeit, jährliche Mindestabnahmen, Mehrkosten und was passiert, wenn Sie weniger nutzen als vertraglich zugesichert.
- Ausstiegskosten. Wenn Sie kündigen, was nehmen Sie mit? OpenTelemetry-native Instrumentierung ist portabel. Proprietäre Agenten sind es nicht; die erneute Instrumentierung ist ein Projekt, keine Aufgabe.
APM für kleinere Teams
Ein Team ohne dedizierte Observability-Funktion sollte kein heruntergestuftes Enterprise-APM-Programm fahren. Vier Prioritäten decken den größten Teil des Mehrwerts ab.
Starten Sie von außen. Wenn Sie nur eine Sache messen, messen Sie, ob Ihre drei wichtigsten Nutzerreisen erfolgreich abgeschlossen werden, aus den Regionen, in denen Ihre Kunden sind. So erfassen Sie die Fehler, die Umsatz kosten, und agentenloses Application Performance Monitoring Software erledigt das ohne Codeänderungen oder ein Deployment-Projekt. Praktisch heißt das, eine Reise einmal aufzuzeichnen und sie regelmäßig automatisch abspielen zu lassen – Minuten Arbeit statt eines Sprints.
Verteilen Sie verteiltes Tracing erst, wenn Sie verteilt sind. Tracing zahlt sich aus, wenn eine Anfrage viele Dienste durchläuft. Bei einem Monolithen und einer Datenbank sind Aufwand und Komplexität zu hoch für Details, die Ihre Logs bereits enthalten.
Ein Alarmkanal, ein Verantwortlicher. Alerts, die sich auf vier Tools verteilen, werden von niemandem gelesen. Wählen Sie den Kanal, den das Team bereits nutzt – PagerDuty, Slack, Teams, SMS oder einen Webhook für Ihre Tools – und leiten Sie alles dorthin.
Kaufen Sie nur Aufbewahrung, die Sie wirklich abfragen. Dreizehn Monate hochauflösende Daten klingen vernünftig. Wenn niemand Daten öffnet, die älter als zwei Wochen sind, zahlen Sie für Sicherheit, nicht Nutzen.
Der Vorbehalt: Außensicht-Checks sagen Ihnen dass der Checkout gebrochen ist und an welchem Schritt, nicht warum im Code. In dieser Größenordnung ist das meist der richtige Kompromiss, weil das teure Problem ist, überhaupt keine Information zu haben. Der Kompromiss ist nicht mehr richtig, wenn „welcher Dienst?“ eine echte Frage wird.
Aufbau einer APM-Praxis in fünf Stufen
Teams springen selten von nichts direkt zu ausgereift. Sie durchlaufen erkennbare Phasen, und zu wissen, in welcher Sie sind, zeigt Ihnen, was als nächstes zu tun ist.
Stufe 1—Reaktiv
Sie erfahren von Kunden oder einem plötzlich vollen Support-Ticket-System von Problemen. Keine Basiswerte, keine Ziele, kein Verantwortlicher. Sie sind hier, wenn die letzten drei Vorfälle Ihnen gemeldet wurden, statt dass Sie sie selbst entdeckt haben.
Stufe 2—Beobachtet
Verfügbarkeitsprüfungen und Basis-Alerts existieren. Sie wissen, wann etwas ausgefallen ist. Sie wissen nicht warum oder wie langsam es vorher war. Sie sind hier, wenn Sie sagen können „Die Seite war 22 Minuten offline“, aber nicht „Der Checkout war zwei Stunden vorher fehlerhaft.“ Der Übergang zu Stufe 3 besteht darin, URLs nicht mehr zu prüfen, sondern Nutzerreisen zu kontrollieren.
Stufe 3—Gemessen
Wichtige Transaktionen sind separat instrumentiert, Basiswerte existieren und jeder hat einen verantwortlichen Namen. Performance wird mit Zahlen statt Gefühlen diskutiert. Sie sind hier, wenn jemand auf die Frage „Ist der Checkout langsamer als letzten Monat?“ antworten kann, ohne ein Ticket zu öffnen. Der Übergang zu Stufe 4 ist, die Zahlen in ein Ziel-Dokument zu schreiben und jeweils eine verantwortliche Person zu benennen.
Stufe 4—Gesteuert
Ziele sind schriftlich fixiert, auf die unterschriebenen SLAs gemappt, werden regelmäßig überprüft und sind einem Budget zugeordnet. Performance-Aufgaben konkurrieren um Roadmap-Slots auf Basis klarer Kriterien statt wer am lautesten eskaliert. Sie sind hier, wenn ein Performance-Ziel jemals ein Release-Datum verändert hat. Das ist die Stufe, auf der geplante SLA-Berichte kein Nice-to-have mehr sind, weil jetzt jemand außerhalb der Entwicklung sie liest.
Stufe 5—Durchgesetzt
Performance-Budgets laufen in der Deployment-Pipeline. Ein Build, der eine wichtige Transaktion deutlich verlangsamt, wird nicht ausgeliefert. Sie sind hier, wenn im letzten Quartal ein Deployment aufgrund einer Performance-Prüfung blockiert wurde.
Stufe 4 ist, wo der Großteil des Geschäftswerts entsteht, und es ist die Stufe, die keine neuen Tools benötigt – nur eine Vereinbarung, wer was besitzt.
Häufig gestellte Fragen
Wofür steht APM?
APM steht für Application Performance Management, die geschäftliche Disziplin des Festlegens, Besitzens und Bezahlens von Performance-Zielen für Anwendungen. Dieselbe Abkürzung wird auch für Application Performance Monitoring verwendet, die technische Praxis darunter. Außerhalb der Software kann APM auch für Asset Performance Management in der Fertigung und Energieversorgung stehen.
Was ist der Unterschied zwischen Application Performance Management und Application Performance Monitoring?
Management ist die geschäftliche Disziplin: Performance-Ziele festlegen, Verantwortlichkeiten zuweisen, den Wert der Performance bestimmen und Bericht erstatten. Monitoring ist die technische Praxis, Anwendungen zu instrumentieren und Daten zu sammeln. Monitoring sagt Ihnen, dass eine Transaktion 840 Millisekunden dauerte. Management entscheidet, ob das akzeptabel ist und wer es behebt.
Was ist ein APM-Tool?
Software, die Leistungsdaten über Anwendungen sammelt und zur Diagnose und Berichterstellung aufbereitet. APM-Tools fallen in drei Gruppen: agentenbasierte Plattformen, die Code von innen instrumentieren, agentenlose Tools wie Dotcom-Monitor’s Application Performance Monitoring Software, die von außen in der Weise messen, wie ein Nutzer dies tut, und Open-Source-Stacks, die auf OpenTelemetry basieren.
Benötigt APM die Installation von Agenten in Ihrer Anwendung?
Es kommt darauf an, welche Hälfte des Bildes Sie brauchen. Code-Detailebene – langsame Abfragen, Timing auf Methodenebene, verteilte Traces – erfordert einen Agenten oder SDK innerhalb der Laufzeitumgebung. Alles, was von der Nutzerseite gemessen wird, nicht: Dotcom-Monitor läuft komplett außerhalb Ihrer Anwendung, ohne SDK, das gepflegt werden muss, und ohne etwas auf Ihren Servern zu deployen. Für interne Anwendungen ohne öffentliche Adresse läuft ein Private Agent als einzelne Binärdatei in Ihrem Netzwerk, was Infrastrukturinstallation statt Codeinstrumentierung bedeutet.
Wie misst man den Erfolg von APM?
Nicht wie viele Daten Sie sammeln. Nützliche Messgrößen: Anteil der gemeldeten Vorfälle, die Sie erkennen, bevor ein Kunde meldet, Zeit vom Alarm bis zur Fehlerquelle, ob Sie Verfügbarkeits- und Antwortzeitziele aus Ihren Verträgen eingehalten haben, und ob Leistungsdaten im letzten Quartal eine Roadmap- oder Kapazitätsentscheidung beeinflusst haben. Wenn sich daran nichts verändert, funktioniert das Programm unabhängig von der Anzahl der Dashboards nicht.
Welche geschäftlichen Vorteile hat APM?
Kürzere Vorfälle, weil weniger Zeit darauf verwendet wird, zu entscheiden, welches Team das Problem besitzt. Geringere Infrastrukturkosten, da Kapazitätsentscheidungen auf gemessenen Spitzen und nicht Vermutungen basieren. Nachweis für SLA-Berichte. Und weniger Performance-Regressions, die Kunden erreichen, weil Sie diese gegen eine Basislinie vor einem Release abfangen.
Was treibt die Kosten eines APM-Tools?
Die Abrechnungseinheit, mehr als der Anbieter. Agentenbasierte Plattformen berechnen normalerweise pro Host oder verarbeitetem Gigabyte, sodass die Rechnung Größenordnung Ihrer Flotte und Ihres Logvolumens folgt, agentenlose Plattformen berechnen meist nach Monitoranzahl und Prüfintervall, also nach Abdeckung; unser Leitfaden zu APM-Tools vergleicht die Möglichkeiten.
Brauchen kleine Teams APM?
Sie brauchen eher die Management-Komponente, jemanden, der Performance-Ziele besitzt, als eine vollständige Plattform. Beginnen Sie mit der Messung Ihrer wichtigsten Nutzerreisen von außen und benennen Sie jeweils einen Verantwortlichen. Fügen Sie Tiefe hinzu, wenn die Architektur es erfordert.
Testen Sie Dotcom-Monitor 30 Tage kostenlos
Wie auch immer Ihre APM-Strategie auf dem Papier aussieht, sie beruht auf einer Messung: Ob Ihre wichtigen Nutzerreisen gerade funktionieren, von dort, wo Ihre Kunden sind. Dotcom-Monitor spielt diese Reisen durch echte Browser von Tier-3-Checkpunkten auf sechs Kontinenten ab, ohne Agenten und ohne Codeänderungen. Es wird Ihren Code nicht profilieren – dafür sind die agentenbasierten Tools da – aber es sagt Ihnen, was Ihre Kunden erleben, während Sie entscheiden, was zu tun ist.
Keine Kreditkarte erforderlich, alle vier Plattformen inklusive. Oder sehen Sie sich zuerst Pläne und Preise an.
