{"id":12692,"date":"2020-06-18T02:34:51","date_gmt":"2020-06-18T02:34:51","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2020\/06\/18\/stack-trace-monitoring-gaps-in-measuring-the-user-experience\/"},"modified":"2026-08-22T14:44:26","modified_gmt":"2026-08-22T14:44:26","slug":"stack-trace-monitoring-gaps-in-measuring-the-user-experience","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/stack-trace-monitoring-gaps-in-measuring-the-user-experience\/","title":{"rendered":"Stack-Trace-\u00dcberwachung: L\u00fccken in der Benutzererfahrung"},"content":{"rendered":"<figure id=\"attachment_34459\" aria-describedby=\"caption-attachment-34459\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34459\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps.webp\" alt=\"Entwickler sieht ein gr\u00fcnes APM-Dashboard, w\u00e4hrend ein frustrierter Benutzer denselben Webanwendung einen Lade-Spinner anschaut\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/hero-stack-trace-monitoring-gaps-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34459\" class=\"wp-caption-text\">Ein gr\u00fcnes APM-Dashboard und eine schlechte Benutzererfahrung k\u00f6nnen gleichzeitig wahr sein.<\/figcaption><\/figure>\n<p>Ein K\u00e4ufer in Frankfurt klickt auf Bezahlen und sieht zehn Sekunden lang einen Spinner, bevor er aufgibt. Ihr APM-Dashboard bleibt die ganze Zeit gr\u00fcn. Keine Ausnahme wurde ausgel\u00f6st, kein Stack-Trace erfasst, da in Ihrem Code nichts fehlgeschlagen ist. Das Skript des Zahlungsanbieters hing, die Seite wurde nie vollst\u00e4ndig gerendert und die Bestellung ging verloren. Ihr Backend sah die endg\u00fcltige Checkout-Anfrage nie, daher gibt es keine fehlgeschlagene Transaktion zu untersuchen: Aus Sicht der Anwendung ist nichts passiert. Aus Sicht des Benutzers ist der einzige wichtige Schritt fehlgeschlagen.<\/p>\n<p>Das ist der blinde Fleck, um den es in diesem Artikel geht. Stack-Trace-Monitoring ist wirklich gut darin, was es tut: Wenn Ihr Code eine Ausnahme wirft, liefert es Entwicklern die Datei, die Zeile und die Aufrufkette, die dorthin gef\u00fchrt hat. Das Problem ist, was es strukturell nicht sehen kann. Eine ganze Klasse von benutzerseitigen Fehlern passiert, bevor eine Anfrage Ihren Code erreicht, nachdem Ihre Antwort ihn verlassen hat oder ohne dass eine Fehlermeldung ausgel\u00f6st wird.<\/p>\n<p>Hier ist, was das Stack-Trace-Monitoring gut erfasst, die f\u00fcnf L\u00fccken, die es bei der Messung der Benutzererfahrung l\u00e4sst, und wie synthetisches Real-Browser-Monitoring das abdeckt, was es nicht erfassen kann.<\/p>\n<h2 id='was-ist-stack-trace-monitoring'  id=\"boomdevs_1\" id=\"what-is-stack-trace-monitoring\">Was ist Stack-Trace-Monitoring?<\/h2>\n<p>Ein Stack-Trace ist eine Momentaufnahme des Aufrufstapels zum Zeitpunkt eines Fehlers: welche Funktionen ausgef\u00fchrt wurden, in welchen Dateien, an welchen Zeilennummern und in welcher Reihenfolge sie aufgerufen wurden. Wenn Sie schon einmal einen Konsolenfehler gesehen haben, der eine Kaskade von Methoden und Dateipfaden auflistet, haben Sie einen Stack-Trace gelesen.<\/p>\n<p>Stack-Trace-Monitoring, wie es von <a href=\"https:\/\/www.dotcom-monitor.com\/de\/lernen-mit-dotcom-monitor\/was-ist-apm-application-performance-management\/\">APM-Tools (Application Performance Monitoring)<\/a> praktiziert wird, erfasst diese Traces automatisch, gruppiert sie und verfolgt, wie oft jede Ausnahme auftritt. Wenn in Ihrem Checkout-Service eine NullPointerException auftritt, sagt Ihnen die APM-Plattform genau, wo Sie nachsehen m\u00fcssen und wie verbreitet das Problem ist. Ausnahmen, die sonst in einer Logdatei verschwinden w\u00fcrden, werden eingestuft, getrackt und als zu bearbeitende Aufgaben zugewiesen.<\/p>\n<p>Beachten Sie die Ausl\u00f6sebedingung, denn alles andere in diesem Artikel folgt daraus: Ein Stack-Trace existiert nur, wenn Code ausgef\u00fchrt und ein Fehler geworfen wird. Beide H\u00e4lften dieser Bedingung sind wichtig. Wenn Ihr Code nie ausgef\u00fchrt wird oder ohne Fehler ausgef\u00fchrt wird, gibt es keinen Trace, egal was der Benutzer gerade erlebt hat.<\/p>\n<p>Eine praktische Merkhilfe: Code wurde ausgef\u00fchrt und hat eine Ausnahme geworfen, Sie erhalten einen Trace. Code wurde langsam ausgef\u00fchrt, ohne eine Ausnahme zu werfen, kein Trace. Der Browser ist fehlgeschlagen, bevor er Ihren Code erreicht hat, kein Trace. Etwas au\u00dferhalb Ihres Codes blockierte den Weg, nachdem Ihre Antwort verlassen wurde, kein Trace. Nur ein Zustand von vier liefert Beweise, und Benutzer erleben alle vier.<\/p>\n<h2 id='was-stack-trace-monitoring-gut-erfasst'  id=\"boomdevs_2\" id=\"what-stack-trace-monitoring-catches-well\">Was Stack-Trace-Monitoring gut erfasst<\/h2>\n<p>Nichts von dem Folgenden ist ein Argument gegen APM. Bei Fehlern, die aus Ihrem Code stammen, sind Stack-Traces der schnellste Weg vom Symptom zur L\u00f6sung:<\/p>\n<ul>\n<li><strong>Schnelle Ursachenbestimmung.<\/strong> Ein Trace zeigt auf die fehlerhafte Zeile und den Aufrufpfad, der sie erreichte, und eliminiert den Gro\u00dfteil der Vermutungen, die manuelles Debugging erfordert.<\/li>\n<li><strong>Tiefer Fehlerkontext.<\/strong> Gute Traces \u00fcbertragen Methodenargumente, Variablenzust\u00e4nde und Request-Metadaten, sodass Entwickler nicht nur sehen, wo der Code brach, sondern auch unter welchen Bedingungen.<\/li>\n<li><strong>Eine gemeinsame Sprache f\u00fcr Entwicklerteams.<\/strong> Ein Trace ist pr\u00e4zise und reproduzierbar. Das Einf\u00fcgen eines solchen in ein Ticket kommuniziert mehr als lange Beschreibungen.<\/li>\n<li><strong>Trends zur Codequalit\u00e4t.<\/strong> Das Verfolgen wiederkehrender Ausnahmen und deren Ort weist auf fragile Module und schlechte Muster hin, die man vor einem Ausfall refaktorieren sollte.<\/li>\n<\/ul>\n<p>Behalten Sie Ihr APM-Tool bei. Die Frage ist nicht, ob Stack-Traces n\u00fctzlich sind. Sie ist, ob sie beschreiben, was Ihre Nutzer erleben. Das tun sie nicht, und die L\u00fccken fallen in f\u00fcnf verschiedene Kategorien.<\/p>\n<h2 id='die-l\u00fccken-was-stack-traces-\u00fcber-die-nutzererfahrung-nicht-erfassen'  id=\"boomdevs_3\" id=\"the-gaps-what-stack-traces-miss-about-the-user-experience\">Die L\u00fccken: Was Stack-Traces \u00fcber die Nutzererfahrung nicht erfassen<\/h2>\n<p>Diese f\u00fcnf L\u00fccken sind keine zuf\u00e4lligen blinden Flecken. Es sind Grenzprobleme: ausgeliehener Code, Infrastruktur vor der Anwendung, Browser-Ausf\u00fchrung, Geografie und Zeit. Stack-Traces sind innerhalb der Anwendungsgrenze stark und schwach \u00fcberall dort, wo die Nutzerreise diese Grenze \u00fcberschreitet.<\/p>\n<figure id=\"attachment_34466\" aria-describedby=\"caption-attachment-34466\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34466\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap.webp\" alt=\"Diagramm zeigt die Sichtbarkeitsl\u00fccke zwischen dem, was Stack-Trace-APM im Anwendungscode sieht und was Nutzer im Browser erleben, mit Drittanbieter-Skripten, CDN- und DNS-Ausf\u00e4llen, Rendering-Problemen und regionalen Ausf\u00e4llen dazwischen\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2020\/05\/apm-visibility-gap-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34466\" class=\"wp-caption-text\">Stack-Trace-APM instrumentiert Ihren Code. Nutzer erleben alles zwischen ihrem Browser und diesem Code.<\/figcaption><\/figure>\n<h3 id='drittanbieter-skripte-und-externe-apis'  id=\"boomdevs_4\">Drittanbieter-Skripte und externe APIs<\/h3>\n<p>Eine typische Seite zieht heute Zahlungs-Widgets, Tag-Manager, Chat, Analytics und Werbeskripte von Servern anderer Firmen. Wenn eine dieser Abh\u00e4ngigkeiten h\u00e4ngt oder sich verlangsamt, stockt die Seite f\u00fcr den Nutzer, aber der fehlerhafte Code ist nicht Ihrer, daher l\u00f6st Ihre Instrumentierung nichts aus. Oft gibt es keine explizite Ausnahme: Der Drittanbieter-Endpunkt antwortet, nur langsam genug, um das Rendering zu blockieren. <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/ueberwachung-von-drittanbieterinhalten\/\">Drittanbieter-Inhalte<\/a> sind der klassische Fall, bei dem Nutzer leiden, w\u00e4hrend jedes interne Dashboard gr\u00fcn bleibt.<\/p>\n<h3 id='dns-tls-und-cdn-ausf\u00e4lle'  id=\"boomdevs_5\">DNS-, TLS- und CDN-Ausf\u00e4lle<\/h3>\n<p>Bevor eine Anfrage Ihre Anwendung erreicht, muss Ihre Domain aufgel\u00f6st, ein TLS-Handshake abgeschlossen und oft ein CDN-Edge passiert werden. Ein falsch konfigurierter DNS-Eintrag, ein abgelaufenes Zertifikat oder ein ausfallender Edge-Knoten stoppt Nutzer an der Haust\u00fcr. Ihr Code wird f\u00fcr diese Besucher nie ausgef\u00fchrt, was bedeutet, dass der Fehler definitionsgem\u00e4\u00df keinen Stack-Trace erzeugen kann. Innerhalb Ihrer Infrastruktur ist das sichtbarste Symptom Stille: Der Traffic sinkt, und nichts erkl\u00e4rt es. Die <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/website-monitoring-errors-dns-tcp-tls-http\/\">DNS-, TCP-, TLS- und HTTP-Schichten<\/a> fallen jeweils auf eine Weise aus, die nur eine au\u00dfen-in Pr\u00fcfung beobachten kann.<\/p>\n<h3 id='frontend-rendering-und-ui-fehler'  id=\"boomdevs_6\">Frontend-Rendering- und UI-Fehler<\/h3>\n<p>Serverseitiges APM best\u00e4tigt, dass Ihr Backend eine g\u00fcltige Antwort rechtzeitig zur\u00fcckgegeben hat. Es sagt nichts dar\u00fcber, was der Browser damit gemacht hat. Ein JavaScript-B\u00fcndel, das in einer Browser-Version abst\u00fcrzt, ein Layout, das auf Mobilger\u00e4ten kollabiert, ein Button, dessen Klick-Handler nie gebunden wird: all das l\u00e4sst Nutzer eine kaputte Seite sehen, w\u00e4hrend der Server sauber 200 protokolliert. Clientseitige Ausnahmen k\u00f6nnen separat gesammelt werden, aber langsames Rendering, Layoutverschiebungen und nicht reagierende Steuerelemente werfen meist keine Fehler. Sie verlieren Benutzer einfach still. Ein Hydrationsfehler in einer Next.js-App ist der moderne Klassiker: Der Server sendet ein perfektes 200 mit vollst\u00e4ndig formatiertem HTML, das clientseitige JavaScript schl\u00e4gt fehl, und Nutzer erhalten eine Seite, die richtig aussieht, aber nichts tut. Das zu \u00fcberwachende Ereignis ist nicht, ob JavaScript eine Exception geworfen hat, sondern ob der Meilenstein erreicht wurde: Button klickbar, Formular abgeschickt, Best\u00e4tigung angezeigt. Stack-Traces erfassen Ausnahmen; Nutzer erleben fehlende Meilensteine.<\/p>\n<h3 id='regionale-ausf\u00e4lle'  id=\"boomdevs_7\">Regionale Ausf\u00e4lle<\/h3>\n<p>Ihre Instrumentierung befindet sich innerhalb Ihrer Infrastruktur und berichtet aggregiert. Wenn eine Carrier-Route zwischen einer Region und Ihren Servern abnimmt oder ein CDN-Knotenpunkt in einer Region ausf\u00e4llt, erleben Nutzer dort Timeouts, w\u00e4hrend Ihre Durchschnittswerte kaum schwanken. Ein Stack-Trace kennt keinen Konzept von Nutzerstandort; er wei\u00df nur, welcher Code gerade ausgef\u00fchrt wurde. Regionale Ausf\u00e4lle sind per Definition f\u00fcr eine codezentrierte Sicht unsichtbar.<\/p>\n<h3 id='langsam-ist-keine-ausnahme'  id=\"boomdevs_8\">Langsam ist keine Ausnahme<\/h3>\n<p>Die subtilste L\u00fccke: Performance-Verschlechterungen werfen nie eine Ausnahme. Eine Seite, die von zwei auf acht Sekunden langsamer wird, erzeugt keine Fehler, treibt aber stetig Nutzer weg. Meist bemerkt es zuerst das Marketing in sinkenden Funnel-Metriken, lange bevor ein Entwickler Pager warnt, weil aus Sicht des Codes nichts defekt ist. Stack-Trace-Monitoring ist auch per Design reaktiv, da es erst nach einem Fehler meldet, und seine Ausgabe ist nur f\u00fcr Leute lesbar, die den Code kennen. Ein Stack-Trace erfasst keine Antwortzeiten, keine Ladegeschwindigkeiten, keine nutzerrelevanten Performancekennzahlen. Eine Anwendung kann so langsam sein, dass sie unbenutzbar ist, und aus Stack-Trace-Sicht vollkommen gesund.<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Fehler<\/th>\n<th>Was der Nutzer erlebt<\/th>\n<th>Was Stack-Trace-APM zeigt<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Drittanbieter-Skript h\u00e4ngt<\/td>\n<td>Seite stockt beim Laden, Checkout blockiert<\/td>\n<td>Gr\u00fcn \u2014 keine Ausnahme im eigenen Code<\/td>\n<\/tr>\n<tr>\n<td>A\/B-Test-Skript feuert fehl<\/td>\n<td>Die H\u00e4lfte der Nutzer erh\u00e4lt eine kaputte Variantenseite<\/td>\n<td>Gr\u00fcn \u2014 das Experiment ist nicht Ihr Code<\/td>\n<\/tr>\n<tr>\n<td>DNS-Eintrag falsch konfiguriert<\/td>\n<td>Seite unerreichbar<\/td>\n<td>Gr\u00fcn \u2014 Anfragen kommen nie an<\/td>\n<\/tr>\n<tr>\n<td>TLS-Zertifikat abgelaufen<\/td>\n<td>Sicherheitswarnung im Browser, Nutzer geht<\/td>\n<td>Gr\u00fcn \u2014 Handshake schl\u00e4gt fehl, bevor Code l\u00e4uft<\/td>\n<\/tr>\n<tr>\n<td>JS-B\u00fcndel bricht in einem Browser<\/td>\n<td>Totale Buttons, kaputtes Layout<\/td>\n<td>Saubere 200er Antwort vom Server<\/td>\n<\/tr>\n<tr>\n<td>CDN-Edge verschlechtert sich in einer Region<\/td>\n<td>Zehn-Sekunden-Ladezeiten in dieser Region<\/td>\n<td>Normale aggregierte Antwortzeiten<\/td>\n<\/tr>\n<tr>\n<td>Allm\u00e4hlicher Performanceverfall<\/td>\n<td>Langsamere Seiten, steigendes Abbruchverhalten<\/td>\n<td>Keine Fehler, nichts zu melden<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h2 id='wie-synthetisches-monitoring-die-l\u00fccken-schlie\u00dft'  id=\"boomdevs_9\" id=\"how-synthetic-monitoring-fills-the-gaps\">Wie synthetisches Monitoring die L\u00fccken schlie\u00dft<\/h2>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/what-is-synthetic-monitoring\/\">Synthetisches Monitoring<\/a> n\u00e4hert sich dem Problem von der entgegengesetzten Seite. Statt Ihren Code zu instrumentieren und zu warten, bis dieser eine Ausnahme wirft, f\u00fchrt es geplante, skriptgesteuerte Pr\u00fcfungen Ihrer Anwendung von echten Browsern aus Weltstandorten aus durch und misst genau das, was ein Nutzer an diesem Ort und zu diesem Zeitpunkt erh\u00e4lt. Diese Umkehrung deckt jede L\u00fccke direkt ab:<\/p>\n<ul>\n<li><strong>Es l\u00e4dt die gesamte Seite, nicht nur Ihren Code.<\/strong> Eine Real-Browser-Pr\u00fcfung f\u00fchrt jedes Drittanbieter-Skript aus, das die Seite enth\u00e4lt. H\u00e4ngt der Tag-Manager oder verlangsamt ein Zahlungs-Widget das Laden, erkennt die Pr\u00fcfung es, und ein Wasserfalldiagramm zeigt <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/optimieren-web-performance-understanding-waterfall-charts\/\">welche Ressource wie lange blockierte<\/a>.<\/li>\n<li><strong>Sie beginnt dort, wo der Nutzer beginnt.<\/strong> Jede Pr\u00fcfung l\u00f6st DNS auf, verhandelt TLS und durchl\u00e4uft das CDN von au\u00dferhalb Ihres Netzwerks. Ein abgelaufenes Zertifikat oder ein ausgefallener Edge-Knoten schl\u00e4gt die Pr\u00fcfung innerhalb eines Monitoring-Zyklus fehl, statt in einer unerkl\u00e4rlichen Traffic-Delle Stunden sp\u00e4ter aufzutauchen.<\/li>\n<li><strong>Sie rendert in einem echten Browser.<\/strong> Da die Pr\u00fcfung eine echte Browser-Engine steuert, zeigen sich kaputte Skripte, nicht reagierende Elemente und Rendering-Fehler als fehlgeschlagene Schritte, nicht als unsichtbare clientseitige Probleme.<\/li>\n<li><strong>Sie l\u00e4uft aus vielen Regionen.<\/strong> Pr\u00fcfungen aus einem <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/synthetische-ueberwachungsfrequenz\/\">globalen Standortnetzwerk<\/a> isolieren regionalspezifische Fehler: Wenn Frankfurt ausf\u00e4llt, Dallas aber durchkommt, kennen Sie das Ausma\u00df des Problems, bevor Nutzer dar\u00fcber twittern.<\/li>\n<li><strong>Sie misst die Geschwindigkeit bei jedem Lauf, Fehler oder nicht.<\/strong> Jede Pr\u00fcfung zeichnet Lade- und Timing-Daten zu jedem Schritt auf, sodass eine achtsek\u00fcndige Seite eine Warnung bei einem von Ihnen gesetzten Schwellenwert ausl\u00f6st, lange bevor irgendetwas technisch kaputtgeht.<\/li>\n<\/ul>\n<p>Die daraus abzuleitende Priorisierungsregel lautet: Eine Pr\u00fcfung, die vor dem ersten Byte fehlschl\u00e4gt, weist auf DNS-, TLS- oder CDN-Verantwortung hin. Ein Wasserfall, der bei einer Drittanbieter-Domain stockt, l\u00f6st den ersten Anruf beim Anbieter aus, nicht beim Anwendungsteam. Ein skriptgesteuerter Schritt, der Ihr Backend erreicht, w\u00e4hrend APM eine Ausnahme zeigt, geht mit angeh\u00e4ngtem Trace an die Entwickler.<\/p>\n<p>Mehrstufige Abl\u00e4ufe erhalten dieselbe Behandlung. Mit <a href=\"https:\/\/www.dotcom-monitor.com\/de\/funktionen\/everystep\/\">EveryStep Scripting<\/a> kann eine Pr\u00fcfung sich einloggen, suchen, in den Warenkorb legen und bezahlen \u2013 nach Zeitplan rund um die Uhr \u2013 sodass die Einnahmepfade kontinuierlich verifiziert werden, anstatt als gesund angenommen zu werden.<\/p>\n<p>Um klarzustellen, was synthetisches Monitoring nicht ist: Es sieht nicht in Ihren Code hinein. Wenn eine Pr\u00fcfung fehlschl\u00e4gt, weil Ihr Backend eine Ausnahme geworfen hat, sagt der Stack-Trace, nicht der Browser, dem Entwickler, welche Zeile zu fixieren ist. Genau deshalb geh\u00f6ren die beiden zusammen.<\/p>\n<h2 id='apm-und-synthetisches-monitoring-besser-zusammen'  id=\"boomdevs_10\" id=\"apm-and-synthetic-monitoring-better-together\">APM und synthetisches Monitoring: Besser zusammen<\/h2>\n<p>Dies ist keine entweder\/oder Entscheidung, und wenn man sie so behandelt, werden Teams \u00fcberrascht. APM mit Stack-Traces \u00fcberwacht von innen nach au\u00dfen und beantwortet <em>Warum ist der Code fehlgeschlagen?<\/em> Synthetisches Monitoring beobachtet von au\u00dfen nach innen und beantwortet <em>K\u00f6nnen Nutzer wirklich die wichtigen Dinge jetzt von dort aus tun, wo sie sind?<\/em> Jeder spiegelt die blinden Flecken des anderen wider.<\/p>\n<blockquote><p>Die gef\u00e4hrlichen Fehler sind die, die jedes Tool allein \u00fcbersehen w\u00fcrde: bei APM ein durch ein Drittanbieter-Skript blockierter Checkout; bei synthetischen Pr\u00fcfungen eine Ausnahme, die nur unter seltenen Eingaben auftritt. Beide zusammen eingesetzt, verschwinden keine Fehlerklasse.<\/p><\/blockquote>\n<p>In der Praxis bilden die beiden eine Pipeline. Eine synthetische Pr\u00fcfung schl\u00e4gt bei einem Checkout in Frankfurt fehl. Der Wasserfall isoliert die betroffene Schicht: DNS, CDN, einen Drittanbieter-Aufruf oder das eigene Backend. Wenn die Spur in Ihrer Anwendung endet, \u00fcbernimmt der Stack-Trace in Ihrem APM-Tool und benennt die Funktion, die die Ausnahme geworfen hat. Erkennung von au\u00dfen, Diagnose von innen, und keine L\u00fccke zwischen dem, was Ihre Dashboards sagen, und dem, was Ihre Nutzer sehen. Es beendet auch das bekannte Patt, bei dem ein Team auf gr\u00fcnes APM besteht, w\u00e4hrend das andere Team von Nutzerbeschwerden berichtet: Nur mit APM zu arbeiten ist wie \u00dcberwachungskameras im Tresor ohne Kameras an der T\u00fcr \u2013 eine perfekte Aufzeichnung des Diebstahls entdeckt erst, wenn der Tresor leer ist.<\/p>\n<p>Dotcom-Monitor sitzt auf der synthetischen Seite dieser Kombination. Es ist keine APM-Plattform und ersetzt Tools wie New Relic oder Datadog nicht; es erg\u00e4nzt sie mit <a href=\"https:\/\/www.dotcom-monitor.com\/de\/loesungen\/synthetic-monitoring\/\">Real-Browser-Synthetik-Monitoring<\/a> aus einem globalen Standortnetzwerk, mit Timing pro Schritt, Wasserfalldetails und Alarmierung, wenn ein Ablauf sich verlangsamt oder fehlschl\u00e4gt.<\/p>\n<h2 id='das-fazit'  id=\"boomdevs_11\" id=\"the-bottom-line\">Das Fazit<\/h2>\n<p>Stack-Trace-Monitoring hat seinen Platz verdient: Wenn Ihr Code eine Ausnahme wirft, kommt kein Entwickler schneller zur fehlerhaften Zeile. Aber seine Ausl\u00f6sebedingung, Code, der ausgef\u00fchrt wird und Fehler verursacht, definiert genau, was es niemals zeigen kann. Drittanbieter-Skripte, DNS- und CDN-Ausf\u00e4lle, Frontend-Rendering-Probleme, regionale Ausf\u00e4lle und langsamer, aber fehlerfreier Abbau treffen Nutzer, ohne einen Trace zu hinterlassen, im w\u00f6rtlichen Sinne.<\/p>\n<p>Synthetisches Real-Browser-Monitoring schlie\u00dft diese L\u00fccken, indem es den gesamten Weg der Nutzer \u00fcberpr\u00fcft, aus jeder f\u00fcr Sie wichtigen Region, nach Zeitplan, der Probleme erkennt, bevor Support-Tickets es tun. Behalten Sie die Stack-Traces zur Diagnose. Erg\u00e4nzen Sie diese durch au\u00dfen-in Pr\u00fcfungen zur Entdeckung. Ihre Nutzer erleben den ganzen Weg, also sollte Ihr Monitoring den ganzen Weg abdecken.<\/p>\n<section class=\"final-cta\">\n<h2 id='sehen-sie-was-ihr-apm-nicht-kann'  id=\"boomdevs_12\">Sehen Sie, was Ihr APM nicht kann<\/h2>\n<p>F\u00fchren Sie Real-Browser-<a href=\"https:\/\/www.dotcom-monitor.com\/de\/loesungen\/synthetic-monitoring\/\">synthetisches Monitoring<\/a> f\u00fcr Ihre kritischen Nutzerfl\u00fcsse mit einem globalen Netzwerk durch und erkennen Sie Fehler, die nie eine Ausnahme ausl\u00f6sen. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Starten Sie eine kostenlose Testversion<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Stack-Traces zeigen, wo der Code unterbrochen wurde, nicht was Benutzer erlebt haben. Sehen Sie die L\u00fccken im Stack-Trace-APM und wie synthetisches Monitoring diese f\u00fcllt.<\/p>\n","protected":false},"author":21,"featured_media":34462,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-12692","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12692","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=12692"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/12692\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/34462"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=12692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=12692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=12692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}