Ein Proof-of-Concept mit den drei d.velop platform Bausteinen ShellApp, AppRouter und BusinessObjects zeigt, wie Produkt-Teams von diesen Daten profitieren k\u00f6nnen. Gleichzeitig belegt das Konzept, wie einfach und zentral sich Telemetrie in eine bestehende Software-Landschaft integrieren l\u00e4sst. Damit das volle Potenzial dieser Ans\u00e4tze ausgesch\u00f6pft wird, sollten alle relevanten Bausteine einer solchen Software-Landschaft den W3C Trace Context und Tracing implementieren.<\/p>\n\n\n\n
Grundlagen auf dem Weg zur datengetriebenen Produktentwicklung<\/h3>\n\n\n\n
Auf dem Weg zur datengetriebenen Produktentwicklung sind jedoch einige grundlegende Aspekte zu ber\u00fccksichtigen. Datenschutz- und Sicherheitsfragen m\u00fcssen sorgf\u00e4ltig gepr\u00fcft, Datenmengen und Performance-Auswirkungen abgesch\u00e4tzt werden. Ebenso ist eine klare Abw\u00e4gung notwendig, welche Daten aus kontrollierten Laborumgebungen und welche aus realen Nutzungsszenarien analysiert werden sollen.<\/p>\n\n\n\n
<\/span>Motivation: Ein „Telemetrie-Buffet“ f\u00fcr umfassende Analysen<\/span><\/h2>\n\n\n\n\u201eWarum nur einen Datentopf anr\u00fchren, wenn man gleich ein ganzes Telemetrie-Buffet servieren kann?\u201c \u2013 Genau das dachten wir uns, als wir uns im Rahmen eines teaminternen Hackathons mit dem Thema Nutzungsdatenerfassung auf Frontend- und Backend-Kommunikations-Ebene besch\u00e4ftigt haben. Unser Ziel war es, ein besseres Verst\u00e4ndnis f\u00fcr die M\u00f6glichkeiten der Telemetrie-Datenerfassung zu gewinnen und die Daten f\u00fcr umfassendere Analysen verf\u00fcgbar zu machen. Hierzu wollten wir mit Hilfe von OpenTelemetry (OTel) und Grafana Faro Telemetrie-Daten aus unterschiedlichen Komponenten nach Grafana Cloud \u00fcbertragen, um die einzelnen Telemetrie-Datent\u00f6pfe dort zusammenzuf\u00fchren und zu verkn\u00fcpfen. Welche spannenden Erkenntnisse wir dabei gewonnen haben, erfahrt ihr im Folgenden.<\/p>\n\n\n\n
<\/span>\u00dcbersicht: Architektur, Tracing und Real User Monitoring<\/span><\/h2>\n\n\n\nF\u00fcr unsere prototypische Umsetzung haben wir die Instrumentierung in die ShellApp, den AppRouter und die BusinessObjects integriert.<\/p>\n\n\n\n
\n- Die ShellApp<\/a> bildet die grundlegende H\u00fclle f\u00fcr alle Apps. Sie stellt den Rahmen f\u00fcr die \u00fcbergreifende Anzeige, Navigation und Interaktion bereit, in den sich s\u00e4mtliche Frontend-Apps nahtlos integrieren lassen.<\/li>\n\n\n\n
- Der AppRouter<\/a> fungiert als Reverse Proxy f\u00fcr alle Apps. Er dient als zentraler Einstiegspunkt der d.velop platform und leitet Anfragen basierend auf Routing-Informationen (z. B. URL-Struktur oder Tenant-Informationen) an die zust\u00e4ndigen Apps weiter.<\/li>\n\n\n\n
- Die App BusinessObjects<\/a> stellt zentrale Gesch\u00e4ftsobjekte, wie z. B. Stammdaten, anderen Apps zur Verf\u00fcgung und erleichtert so die Wiederverwendung und Konsistenz von Daten innerhalb der Plattform.<\/li>\n<\/ul>\n\n\n\n
Diese drei Komponenten senden ihre Telemetrie-Daten (Logs, Metrics, Traces) an eine Grafana Agent genannte Komponente, die sie wiederum an spezialisierte Observability-Backends weiterleitet, namentlich Grafana Loki f\u00fcr Logs, Grafana Mimir f\u00fcr Metriken und Grafana Tempo f\u00fcr Traces. Der Grafana Agent \u00fcbernimmt dabei die Rolle eines Telemetrie-Kollektors, der f\u00fcr eine effiziente und flexible Datensammlung und -weiterleitung sorgt. Mit Grafana selbst k\u00f6nnen die Daten dann abgefragt, visualisiert oder z.B. f\u00fcr Alerting-Zwecke genutzt werden. Das Zusammenspiel ist in der folgenden Abbildung skizziert.<\/p>\n\n\n\n![\"Overview](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/overview-prototype-telemetry-d-velop.png\")
<\/a><\/figure>\n\n\n\n<\/span>Was ist genau ein Trace?<\/span><\/h2>\n\n\n\nTraces helfen dabei, ganz allgemein gesprochen, verteilte Systeme zu \u00fcberwachen und zu analysieren und damit Einblicke in deren Leistung und Verhalten zu gewinnen. Sie erm\u00f6glichen es, die Ausf\u00fchrung von Apps \u00fcber verschiedene Komponenten und Services hinweg zu verfolgen. Dies ist besonders in modernen Software-Systemen wichtig, die aus vielen Apps und Microservices bestehen, die miteinander kommunizieren \u2013 also ganz wie auf der d.velop platform.<\/p>\n\n\n\n
Aufbau eines Trace: Spans und ihre Bedeutung<\/h3>\n\n\n\n
Ein Trace (Spur) ist eine Abfolge von Ereignissen, die den Pfad eines Aufrufs (z.B. App-Request) durch verschiedene Services und Komponenten zeigt. Er stellt einen einzelnen Vorgang oder eine Transaktion in einem verteilten System dar, z. B. eine Benutzeranfrage, die mehrere Services durchl\u00e4uft und gibt einen \u00dcberblick \u00fcber den gesamten Lebenszyklus dieser Anfrage. Oder anders gesagt: Ein Trace zeigt, wie sich eine Anfrage von einem Service zum n\u00e4chsten in einem verteilten System ausbreitet.<\/p>\n\n\n\n
Die grundlegenden Bausteine eines Trace sind seine Spans. Ein Span repr\u00e4sentiert eine einzelne Arbeitseinheit oder eine bestimmte Operation, die als Teil der Anforderung ausgef\u00fchrt wird. Jeder Span hat einen Start- und einen Endzeitpunkt und kann weitere Informationen wie Events, Fehler oder Tags enthalten. Ein Span repr\u00e4sentiert insbesondere die Zeit, die eine Operation in einem Dienst (oft einem Microservice) verbracht hat.<\/p>\n\n\n\n
Der W3C Trace Context: Standardisierte Trace-Informationen<\/h3>\n\n\n\n
In unserem Beispiel schicken ShellApp, AppRouter und Backend\/BusinessObjects ihre Spans an das Observability-Backend. Aber wie werden die Spans zu einem Trace zusammengef\u00fcgt? Hier kommt der W3C Trace Context ins Spiel. Kurz gefasst bietet der W3C Trace Context einen standardisierten Weg f\u00fcr das \u00dcbermitteln von Trace-Informationen \u00fcber Service-Grenzen hinweg.<\/p>\n\n\n\n
Die etwas l\u00e4ngere Fassung: (im Wesentlichen) definiert der W3C Trace Context ein einheitliches Format f\u00fcr Trace-Header, die in HTTP-Anfragen eingef\u00fcgt werden. Wichtig ist hier vor allem der Header traceparent, der die essenziellen Informationen enth\u00e4lt, die ben\u00f6tigt werden, um Spans \u00fcber verschiedene Systeme und Technologien hinweg miteinander zu verkn\u00fcpfen: die traceId, die eindeutige Identifikation des gesamten Traces, und die spanId, die Identifikation des aktuellen Span. Dieser Zusammenhang (Datenfluss) der Spans bzw. Traces ist in der nachfolgenden Abbildung herausgestellt.<\/p>\n\n\n\n![\"Diagramm](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/trace-context-d-velop.png\")
<\/a><\/figure>\n\n\n\nNeben den dargestellten Apps bzw. Services k\u00f6nnen sich auch andere Infrastruktur-Services in die Trace-Kette \u201eeinklinken\u201c und so k\u00f6nnen z.B. auch Datenbank-Aufrufe in einem Trace als Span dargestellt werden (wie wir weiter unten sowohl theoretisch als auch praktisch sehen werden).<\/p>\n\n\n\n
<\/span>Und wie sieht ein Trace dann schlussendlich aus?<\/span><\/h2>\n\n\n\nDie Visualisierung von Traces erfolgt typischerweise in Form eines Gantt-Diagramms<\/a>, das eine zeitliche Abfolge der Spans zeigt. Dies erm\u00f6glicht es, die Performance einzelner Operationen und die Beziehungen zwischen ihnen auf einen Blick zu verstehen. Die Spans werden entlang einer Zeitachse dargestellt, wobei die L\u00e4nge jedes Spans seiner Dauer entspricht. Dies zeigt auf einen Blick, welche Teile der Anfrage wie viel Zeit in Anspruch genommen haben. Spans, die aus anderen Spans resultieren (z.B. ein Datenbankaufruf, der von einem Service-Request ausgel\u00f6st wird), werden hierarchisch unter ihrem \u00fcbergeordneten Span angezeigt. Dies hilft, die Struktur der Anfrage und die Abh\u00e4ngigkeiten zwischen verschiedenen Operationen zu verstehen. Oft werden Spans zudem unterschiedlich farbig markiert, um beispielsweise ihren Typ (z.B. Datenbankabfrage, externer Service-Aufruf) zu kennzeichnen. Dies erleichtert die schnelle Identifizierung von gleichgearteten und unterschiedlichen Spans.<\/p>\n\n\n\nBeispiel: Trace einer Anforderung<\/h3>\n\n\n\n
Das nachstehende Diagramm veranschaulicht einen Trace einer Anforderung, die mit einer Benutzerinteraktion innerhalb der ShellApp beginnt und bis zu einem resultierenden Aufruf in der Datenbank nachvollziehbar gemacht wird.<\/p>\n\n\n\n![\"Diagramm](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/traces-d-velop-1090x393.png\")
<\/a><\/figure>\n\n\n\nDer Anschaulichkeit halber ist das Beispiel auf eine einfache, sequentielle Eltern-Kind-Beziehung von Spans beschr\u00e4nkt. In der Praxis sind deutlich komplexere, teilweise parallele Beziehungen \u00fcblich. Neben den dargestellten Basis-Informationen k\u00f6nnen nahezu beliebig strukturierte Meta-Informationen an die Spans geh\u00e4ngt werden, z.B. eine vorliegende Tenant-Id. OTel selbst bietet mit den Trace Semantic Conventions eine standardisierte Menge von Regeln und Best Practices f\u00fcr das Tagging und Strukturieren von Traces. Diese Konventionen decken typische Anwendungsbereiche ab, wie etwa Tracing im Bereich HTTP- oder Datenbank-Abfragen.<\/p>\n\n\n\n
<\/span>Real User Monitoring mit Faro: Einblicke in die Benutzererfahrung<\/span><\/h2>\n\n\n\nWir sind zun\u00e4chst mit dem Ziel gestartet, Traces und sogenannte Custom-Events aus einer Browser-App erfassen zu k\u00f6nnen. Faro bietet jedoch weit mehr, da es sich auf Real-User-Monitoring (RUM) spezialisiert. RUM erm\u00f6glicht es, Leistung und Verhalten von Apps und Websites aus der Perspektive der tats\u00e4chlichen Benutzer zu \u00fcberwachen und zu analysieren \u2013 daher der Name. Dabei werden Daten in Echtzeit gesammelt, die Einblicke in die Benutzererfahrung geben. Dazu geh\u00f6ren unter anderem Ladezeiten von Apps, Klick-Verhalten, Fehlermeldungen und weitere Interaktionen, die die reale Nutzung und das Verhalten der Endbenutzer widerspiegeln.<\/p>\n\n\n\n
Dadurch, dass RUM Daten von tats\u00e4chlichen Benutzern sammelt, sind die erfassten Informationen repr\u00e4sentativ f\u00fcr die Benutzerbasis. Hier liegt der wesentliche Unterschied zu synthetischen Tests. Diese gehen von vordefinierten, k\u00fcnstlich erdachten Szenarien aus, welche in kontrollierten Umgebungen durchgef\u00fchrt werden. Sie k\u00f6nnen daher nur eine begrenzte Anzahl von Szenarien abdecken, w\u00e4hrend die durch RUM gesammelten Daten das Verhalten und die Erfahrungen einer diversen und dynamischen Benutzerbasis unter realen Bedingungen reflektieren. RUM kann daher auch bei der Identifizierung und Behebung von Problemen auf der letzten Meile sehr hilfreich sein.<\/p>\n\n\n\n
Auch wenn von tats\u00e4chlichen Benutzern die Rede ist, werden die eigentliche Identit\u00e4t oder die pers\u00f6nlichen Daten eines Benutzers f\u00fcr das Real-User-Monitoring nicht ben\u00f6tigt. Die erfassten Daten beziehen sich (im Standard) auf eine generisch gew\u00fcrfelte Sitzung, die auch nichts mit anderen Sitzungen (z.B. Login-Sitzung) zu tun hat. Die Privatsph\u00e4re der Nutzer bleibt bzw. kann vollst\u00e4ndig gewahrt bleiben.<\/p>\n\n\n\n
Es gibt aber sehr wohl Zusammenh\u00e4nge zur Produkt-Analyse und zu Business KPIs: so kann RUM beispielsweise dazu beitragen, die Auswirkungen von Leistungsproblemen auf gesch\u00e4ftliche KPIs wie Konversionsraten, Umsatz und Kundenzufriedenheit besser zu verstehen. Auch k\u00f6nnen RUM-Daten dazu beitragen, den Erfolg von Marketingkampagnen zu messen, indem sie Einblicke in das Engagement der Nutzer und z.B. die Effektivit\u00e4t von Landing Pages bieten.<\/p>\n\n\n\n
<\/span>Rubber on the road<\/span><\/h2>\n\n\n\nAber genug der grauen Theorie, bringen wir etwas Gummi auf die Stra\u00dfe und schauen uns an, welchen Nutzen wir \u00fcberhaupt daraus ziehen k\u00f6nnen. Den Anfang macht hier Faro. Faro st\u00fctzt sich intensiv auf die OpenTelemetry-JS-Bibliotheken, um mehrere spezialisierte Instrumentierungen anzubieten, die f\u00fcr das Sammeln und Messen von Daten \u00fcber die Leistung und das Verhalten von Apps unerl\u00e4sslich sind:<\/p>\n\n\n\n
\n- Console: <\/strong>Klinkt sich in die Browser-Konsole ein, um Log-Events zu sammeln<\/li>\n\n\n\n
- Errors: <\/strong>Erfasst im Browser auftretende (unbehandelte) Fehler<\/li>\n\n\n\n
- Tracing: <\/strong>Erfasst detailliert, was passiert, wenn ein Benutzer mit der Browser-App interagiert (insbesondere Kontrollfluss und Datenverlauf)<\/li>\n\n\n\n
- Session (Tracking):<\/strong> Erfasst Daten zum Lebenszyklus von Nutzersitzungen (insbesondere deren Start, Fortsetzung, Verl\u00e4ngerung)<\/li>\n\n\n\n
- View (Tracking):<\/strong> Erm\u00f6glicht das Tracking des Wechsels von Views<\/li>\n\n\n\n
- WebVitals:<\/strong> Misst die tats\u00e4chliche Leistung in Bezug auf das Nutzungserlebnis<\/li>\n<\/ul>\n\n\n\n
Jede dieser Instrumentierungen sammelt spezifische Daten, die dann einheitlich an den Kollektor, d.h. den Grafana Agent (siehe oben), weitergeleitet werden. Mit Ausnahme der Tracing-Instrumentierung, die bereits in der Grundkonfiguration eine betr\u00e4chtliche Menge an Daten produziert, sind alle Instrumentierungen standardm\u00e4\u00dfig aktiviert, sobald Faro im Code (JavaScript oder TypeScript) initialisiert wurde (ein einfacher Funktionsaufruf mit einer Handvoll Parametern). Sie k\u00f6nnen aber auch jeweils einzeln aktiviert und konfiguriert werden.<\/p>\n\n\n\n
Wir haben uns alle genannten Instrumentierungen einmal angeschaut und die Namen bzw. Kurzbeschreibungen sollten einen ersten kurzen Einblick geben k\u00f6nnen, was sich hinter der jeweiligen Instrumentierung verbirgt. Gleichzeitig erkl\u00e4rungsbed\u00fcrftig und (aus unserer Sicht) mit unmittelbarem Nutzen verbunden ist aber vor allem die Web Vitals<\/a> Instrumentierung, die wir nachfolgend etwas detaillierter betrachten.<\/p>\n\n\n\n<\/span>Web Vitals \u2013 Wie nutzerfreundlich sind unsere UIs mit Blick auf Ladezeiten, Interaktivit\u00e4t und visuelle Stabilit\u00e4t?<\/span><\/h2>\n\n\n\nBei den Web Vitals handelt es sich um eine Reihe von Metriken, die von Google entwickelt wurden, um Entwicklern zu helfen, die Qualit\u00e4t ihrer Web-Seiten und Web-Apps zu messen und zu verbessern. Sie fokussieren drei Hauptaspekte der User-Experience: Ladezeit, Interaktivit\u00e4t und visuelle Stabilit\u00e4t.<\/p>\n\n\n\n
Mit Faro k\u00f6nnen verschiedene Web Vitals Out-of-the-box gemessen und zentral zur Analyse bereitgestellt werden. Einerseits die Core Web Vitals, die laut Google universelle Aussagekraft f\u00fcr eine gute Web-Experience haben:<\/p>\n\n\n\n
\n- Largest contentful paint (LCP<\/a>): <\/strong>Misst die Ladeleistung \u2013 Zeit, bis der Hauptinhalt der Seite angezeigt wird<\/li>\n\n\n\n
- Cumulative layout shift (CLS<\/a>)<\/strong>: Misst die visuelle Stabilit\u00e4t \u2013 Quantifiziert, wie oft Nutzer unerwartete Layout-Verschiebungen erleben<\/li>\n\n\n\n
- First input delay (FID<\/a>): <\/strong>Misst die Interaktivit\u00e4t \u2013 Zeit zwischen der ersten Interaktion eines Nutzers mit einer Seite und dem Zeitpunkt, zu dem der Browser mit der Verarbeitung von Event-Handlern beginnt<\/li>\n\n\n\n
- Interaction to next paint (INP<\/a>):<\/strong> Beobachtet die Latenz aller Interaktionen durch den Nutzer (Anmerkung: ersetzt zuk\u00fcnftig die FID-Metrik in den Core Web Vitals)<\/li>\n<\/ul>\n\n\n\n
Und anderseits weitere Leistungsmetriken, die eine technischere Leistungsmessung abdecken und spezifischere Fragen beantworten k\u00f6nnen:<\/p>\n\n\n\n
\n- Time to first byte (TTFB<\/a>):<\/strong> Die Zeit zwischen dem erstmaligen Abfragen einer Ressource und dem Erhalten des ersten Bytes der Antwort<\/li>\n\n\n\n
- First contentful paint (FCP<\/a>):<\/strong> Zeit, bis der Nutzer erstmalig etwas auf der Seite sehen kann<\/li>\n<\/ul>\n\n\n\n
Hinter den Links sind empfohlene Wertebereiche f\u00fcr die verschiedenen Metriken angegeben. Beispielsweise sollte f\u00fcr eine optimale Web-Experience die ‚Interaction to Next Paint‘ (INP) Zeit 200 Millisekunden oder weniger betragen (im 75%-Perzentil).<\/p>\n\n\n\n
<\/span>Implementierung<\/span><\/h2>\n\n\n\nBei der Umsetzung standen wir vor der Frage, wie wir Telemetrie-Daten, einschlie\u00dflich der hier diskutierten Web Vital Metriken, erfassen k\u00f6nnen, ohne den einzelnen Entwicklungsteams zus\u00e4tzlichen Aufwand aufzuerlegen. Wir haben daher Faro in unsere Rahmenanwendung (ShellApp) integriert, so dass die Erfassung automatisch f\u00fcr alle Apps funktioniert, welche die ShellApp nutzen.<\/p>\n\n\n\n
Die ShellApp iteriert dazu \u00fcber alle von ihr verwalteten IFrames und initialisiert dort jeweils Faro. Zudem generiert sie eine Session-Id, die im Session-Storage abgelegt wird und damit implizit einer Browser-Session entspricht. Diese Session-Id wird gemeinsam von den unterschiedlichen IFrames verwendet und stellt damit sicher, dass die Web Vital Metriken (aber auch weitere Telemetrie-Daten) aus den einzelnen IFrames logisch in einer zusammengeh\u00f6rigen Session geklammert werden. Ohne diesen Kniff w\u00fcrde jede Faro-Initialisierung eines jeden IFrames eine eigene Sitzung generieren.<\/p>\n\n\n\n
Dar\u00fcber hinaus extrahiert die ShellApp den Namen der aktiven App aus der aktuellen URL und verwendet diesen als Name sowie den URL-Pfad als Environment<\/code> f\u00fcr die App-Metadaten, mit der s\u00e4mtliche Telemetrie-Daten versorgt werden und die z.B. bei analytischen Abfragen in Grafana als Dimension genutzt werden k\u00f6nnen.<\/p>\n\n\n\nDie nachfolgende Abbildung zeigt einen Screenshot unseres Grafana-Dashboards, das wir im Rahmen unserer Versuchsanordnung mit relevanten Daten bef\u00fcllt haben. Es veranschaulicht die wesentlichen Web Vital Metriken.<\/p>\n\n\n\n![\"Grafana](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/grafana-dashboard-web-vital-metriken-d-velop-1090x473.png\")
<\/a><\/figure>\n\n\n\nWie oben erw\u00e4hnt, werden die Web Vital Metriken mit dem jeweiligen Namen der in der Shell eingebetteten App versorgt. Damit besteht neben der bereits eingebauten M\u00f6glichkeit, nach Browser zu filtern, ebenfalls die M\u00f6glichkeit, nach Apps zu filtern. Die folgende Abbildung zeigt etwa die Web Vitals f\u00fcr die Dashboard-App im Chrome Browser:<\/p>\n\n\n\n![\"Web](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/web-vitals-dashboard-app-chrome-browser-1090x542.png\")
<\/a><\/figure>\n\n\n\n<\/span>Request Duration \u2013 Wo verlieren wir Zeit?<\/span><\/h2>\n\n\n\nWie weiter oben bereits angedeutet, sind \u00fcbergreifende Traces in einer verteilten Architektur nicht nur \u00e4u\u00dferst hilfreich, sondern mit zunehmender Komplexit\u00e4t und Anzahl von Apps bzw. Services sogar unerl\u00e4sslich, um kritische Bereiche effektiv zu identifizieren. In diesem Kontext bietet sich der AppRouter, \u00fcber den s\u00e4mtliche App-Anfragen innerhalb der Plattform geroutet werden, als idealer Kandidat f\u00fcr die Implementierung von Tracing-F\u00e4higkeiten an. Er verf\u00fcgt bereits \u00fcber Zugriff auf eine Vielzahl relevanter Meta-Informationen, wie Tenant-ID, App-Name und HTTP-Attribute, was ihn zu einem idealen Punkt f\u00fcr die Gewinnung wertvoller Tracing-Daten macht.<\/p>\n\n\n\n
Beispiel: Tracing-Instrumentierung im AppRouter<\/h3>\n\n\n\n
Wir haben dazu Tracing mittels OpenTelemetry in den AppRouter integriert. Im Gegensatz zur Auto-Instrumentierung in der ShellApp mit Faro und in BusinessObjects mit OpenTelemetry mussten wir im AppRouter die Spans selbst erzeugen, einen ggf. vorhanden W3C Trace Context von Hand \u00fcbernehmen\/propagieren und letztlich auch die HTTP Basis Attribute selbst am Span setzen.<\/p>\n\n\n\n
F\u00fcr unsere prototypische Umsetzung haben wir die Instrumentierung in die ShellApp, den AppRouter und die BusinessObjects integriert.<\/p>\n\n\n\n
- \n
- Die ShellApp<\/a> bildet die grundlegende H\u00fclle f\u00fcr alle Apps. Sie stellt den Rahmen f\u00fcr die \u00fcbergreifende Anzeige, Navigation und Interaktion bereit, in den sich s\u00e4mtliche Frontend-Apps nahtlos integrieren lassen.<\/li>\n\n\n\n
- Der AppRouter<\/a> fungiert als Reverse Proxy f\u00fcr alle Apps. Er dient als zentraler Einstiegspunkt der d.velop platform und leitet Anfragen basierend auf Routing-Informationen (z. B. URL-Struktur oder Tenant-Informationen) an die zust\u00e4ndigen Apps weiter.<\/li>\n\n\n\n
- Die App BusinessObjects<\/a> stellt zentrale Gesch\u00e4ftsobjekte, wie z. B. Stammdaten, anderen Apps zur Verf\u00fcgung und erleichtert so die Wiederverwendung und Konsistenz von Daten innerhalb der Plattform.<\/li>\n<\/ul>\n\n\n\n
Diese drei Komponenten senden ihre Telemetrie-Daten (Logs, Metrics, Traces) an eine Grafana Agent genannte Komponente, die sie wiederum an spezialisierte Observability-Backends weiterleitet, namentlich Grafana Loki f\u00fcr Logs, Grafana Mimir f\u00fcr Metriken und Grafana Tempo f\u00fcr Traces. Der Grafana Agent \u00fcbernimmt dabei die Rolle eines Telemetrie-Kollektors, der f\u00fcr eine effiziente und flexible Datensammlung und -weiterleitung sorgt. Mit Grafana selbst k\u00f6nnen die Daten dann abgefragt, visualisiert oder z.B. f\u00fcr Alerting-Zwecke genutzt werden. Das Zusammenspiel ist in der folgenden Abbildung skizziert.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\n<\/span>Was ist genau ein Trace?<\/span><\/h2>\n\n\n\n
Traces helfen dabei, ganz allgemein gesprochen, verteilte Systeme zu \u00fcberwachen und zu analysieren und damit Einblicke in deren Leistung und Verhalten zu gewinnen. Sie erm\u00f6glichen es, die Ausf\u00fchrung von Apps \u00fcber verschiedene Komponenten und Services hinweg zu verfolgen. Dies ist besonders in modernen Software-Systemen wichtig, die aus vielen Apps und Microservices bestehen, die miteinander kommunizieren \u2013 also ganz wie auf der d.velop platform.<\/p>\n\n\n\n
Aufbau eines Trace: Spans und ihre Bedeutung<\/h3>\n\n\n\n
Ein Trace (Spur) ist eine Abfolge von Ereignissen, die den Pfad eines Aufrufs (z.B. App-Request) durch verschiedene Services und Komponenten zeigt. Er stellt einen einzelnen Vorgang oder eine Transaktion in einem verteilten System dar, z. B. eine Benutzeranfrage, die mehrere Services durchl\u00e4uft und gibt einen \u00dcberblick \u00fcber den gesamten Lebenszyklus dieser Anfrage. Oder anders gesagt: Ein Trace zeigt, wie sich eine Anfrage von einem Service zum n\u00e4chsten in einem verteilten System ausbreitet.<\/p>\n\n\n\n
Die grundlegenden Bausteine eines Trace sind seine Spans. Ein Span repr\u00e4sentiert eine einzelne Arbeitseinheit oder eine bestimmte Operation, die als Teil der Anforderung ausgef\u00fchrt wird. Jeder Span hat einen Start- und einen Endzeitpunkt und kann weitere Informationen wie Events, Fehler oder Tags enthalten. Ein Span repr\u00e4sentiert insbesondere die Zeit, die eine Operation in einem Dienst (oft einem Microservice) verbracht hat.<\/p>\n\n\n\n
Der W3C Trace Context: Standardisierte Trace-Informationen<\/h3>\n\n\n\n
In unserem Beispiel schicken ShellApp, AppRouter und Backend\/BusinessObjects ihre Spans an das Observability-Backend. Aber wie werden die Spans zu einem Trace zusammengef\u00fcgt? Hier kommt der W3C Trace Context ins Spiel. Kurz gefasst bietet der W3C Trace Context einen standardisierten Weg f\u00fcr das \u00dcbermitteln von Trace-Informationen \u00fcber Service-Grenzen hinweg.<\/p>\n\n\n\n
Die etwas l\u00e4ngere Fassung: (im Wesentlichen) definiert der W3C Trace Context ein einheitliches Format f\u00fcr Trace-Header, die in HTTP-Anfragen eingef\u00fcgt werden. Wichtig ist hier vor allem der Header traceparent, der die essenziellen Informationen enth\u00e4lt, die ben\u00f6tigt werden, um Spans \u00fcber verschiedene Systeme und Technologien hinweg miteinander zu verkn\u00fcpfen: die traceId, die eindeutige Identifikation des gesamten Traces, und die spanId, die Identifikation des aktuellen Span. Dieser Zusammenhang (Datenfluss) der Spans bzw. Traces ist in der nachfolgenden Abbildung herausgestellt.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nNeben den dargestellten Apps bzw. Services k\u00f6nnen sich auch andere Infrastruktur-Services in die Trace-Kette \u201eeinklinken\u201c und so k\u00f6nnen z.B. auch Datenbank-Aufrufe in einem Trace als Span dargestellt werden (wie wir weiter unten sowohl theoretisch als auch praktisch sehen werden).<\/p>\n\n\n\n
<\/span>Und wie sieht ein Trace dann schlussendlich aus?<\/span><\/h2>\n\n\n\n
Die Visualisierung von Traces erfolgt typischerweise in Form eines Gantt-Diagramms<\/a>, das eine zeitliche Abfolge der Spans zeigt. Dies erm\u00f6glicht es, die Performance einzelner Operationen und die Beziehungen zwischen ihnen auf einen Blick zu verstehen. Die Spans werden entlang einer Zeitachse dargestellt, wobei die L\u00e4nge jedes Spans seiner Dauer entspricht. Dies zeigt auf einen Blick, welche Teile der Anfrage wie viel Zeit in Anspruch genommen haben. Spans, die aus anderen Spans resultieren (z.B. ein Datenbankaufruf, der von einem Service-Request ausgel\u00f6st wird), werden hierarchisch unter ihrem \u00fcbergeordneten Span angezeigt. Dies hilft, die Struktur der Anfrage und die Abh\u00e4ngigkeiten zwischen verschiedenen Operationen zu verstehen. Oft werden Spans zudem unterschiedlich farbig markiert, um beispielsweise ihren Typ (z.B. Datenbankabfrage, externer Service-Aufruf) zu kennzeichnen. Dies erleichtert die schnelle Identifizierung von gleichgearteten und unterschiedlichen Spans.<\/p>\n\n\n\n
Beispiel: Trace einer Anforderung<\/h3>\n\n\n\n
Das nachstehende Diagramm veranschaulicht einen Trace einer Anforderung, die mit einer Benutzerinteraktion innerhalb der ShellApp beginnt und bis zu einem resultierenden Aufruf in der Datenbank nachvollziehbar gemacht wird.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nDer Anschaulichkeit halber ist das Beispiel auf eine einfache, sequentielle Eltern-Kind-Beziehung von Spans beschr\u00e4nkt. In der Praxis sind deutlich komplexere, teilweise parallele Beziehungen \u00fcblich. Neben den dargestellten Basis-Informationen k\u00f6nnen nahezu beliebig strukturierte Meta-Informationen an die Spans geh\u00e4ngt werden, z.B. eine vorliegende Tenant-Id. OTel selbst bietet mit den Trace Semantic Conventions eine standardisierte Menge von Regeln und Best Practices f\u00fcr das Tagging und Strukturieren von Traces. Diese Konventionen decken typische Anwendungsbereiche ab, wie etwa Tracing im Bereich HTTP- oder Datenbank-Abfragen.<\/p>\n\n\n\n
<\/span>Real User Monitoring mit Faro: Einblicke in die Benutzererfahrung<\/span><\/h2>\n\n\n\n
Wir sind zun\u00e4chst mit dem Ziel gestartet, Traces und sogenannte Custom-Events aus einer Browser-App erfassen zu k\u00f6nnen. Faro bietet jedoch weit mehr, da es sich auf Real-User-Monitoring (RUM) spezialisiert. RUM erm\u00f6glicht es, Leistung und Verhalten von Apps und Websites aus der Perspektive der tats\u00e4chlichen Benutzer zu \u00fcberwachen und zu analysieren \u2013 daher der Name. Dabei werden Daten in Echtzeit gesammelt, die Einblicke in die Benutzererfahrung geben. Dazu geh\u00f6ren unter anderem Ladezeiten von Apps, Klick-Verhalten, Fehlermeldungen und weitere Interaktionen, die die reale Nutzung und das Verhalten der Endbenutzer widerspiegeln.<\/p>\n\n\n\n
Dadurch, dass RUM Daten von tats\u00e4chlichen Benutzern sammelt, sind die erfassten Informationen repr\u00e4sentativ f\u00fcr die Benutzerbasis. Hier liegt der wesentliche Unterschied zu synthetischen Tests. Diese gehen von vordefinierten, k\u00fcnstlich erdachten Szenarien aus, welche in kontrollierten Umgebungen durchgef\u00fchrt werden. Sie k\u00f6nnen daher nur eine begrenzte Anzahl von Szenarien abdecken, w\u00e4hrend die durch RUM gesammelten Daten das Verhalten und die Erfahrungen einer diversen und dynamischen Benutzerbasis unter realen Bedingungen reflektieren. RUM kann daher auch bei der Identifizierung und Behebung von Problemen auf der letzten Meile sehr hilfreich sein.<\/p>\n\n\n\n
Auch wenn von tats\u00e4chlichen Benutzern die Rede ist, werden die eigentliche Identit\u00e4t oder die pers\u00f6nlichen Daten eines Benutzers f\u00fcr das Real-User-Monitoring nicht ben\u00f6tigt. Die erfassten Daten beziehen sich (im Standard) auf eine generisch gew\u00fcrfelte Sitzung, die auch nichts mit anderen Sitzungen (z.B. Login-Sitzung) zu tun hat. Die Privatsph\u00e4re der Nutzer bleibt bzw. kann vollst\u00e4ndig gewahrt bleiben.<\/p>\n\n\n\n
Es gibt aber sehr wohl Zusammenh\u00e4nge zur Produkt-Analyse und zu Business KPIs: so kann RUM beispielsweise dazu beitragen, die Auswirkungen von Leistungsproblemen auf gesch\u00e4ftliche KPIs wie Konversionsraten, Umsatz und Kundenzufriedenheit besser zu verstehen. Auch k\u00f6nnen RUM-Daten dazu beitragen, den Erfolg von Marketingkampagnen zu messen, indem sie Einblicke in das Engagement der Nutzer und z.B. die Effektivit\u00e4t von Landing Pages bieten.<\/p>\n\n\n\n
<\/span>Rubber on the road<\/span><\/h2>\n\n\n\n
Aber genug der grauen Theorie, bringen wir etwas Gummi auf die Stra\u00dfe und schauen uns an, welchen Nutzen wir \u00fcberhaupt daraus ziehen k\u00f6nnen. Den Anfang macht hier Faro. Faro st\u00fctzt sich intensiv auf die OpenTelemetry-JS-Bibliotheken, um mehrere spezialisierte Instrumentierungen anzubieten, die f\u00fcr das Sammeln und Messen von Daten \u00fcber die Leistung und das Verhalten von Apps unerl\u00e4sslich sind:<\/p>\n\n\n\n
- \n
- Console: <\/strong>Klinkt sich in die Browser-Konsole ein, um Log-Events zu sammeln<\/li>\n\n\n\n
- Errors: <\/strong>Erfasst im Browser auftretende (unbehandelte) Fehler<\/li>\n\n\n\n
- Tracing: <\/strong>Erfasst detailliert, was passiert, wenn ein Benutzer mit der Browser-App interagiert (insbesondere Kontrollfluss und Datenverlauf)<\/li>\n\n\n\n
- Session (Tracking):<\/strong> Erfasst Daten zum Lebenszyklus von Nutzersitzungen (insbesondere deren Start, Fortsetzung, Verl\u00e4ngerung)<\/li>\n\n\n\n
- View (Tracking):<\/strong> Erm\u00f6glicht das Tracking des Wechsels von Views<\/li>\n\n\n\n
- WebVitals:<\/strong> Misst die tats\u00e4chliche Leistung in Bezug auf das Nutzungserlebnis<\/li>\n<\/ul>\n\n\n\n
Jede dieser Instrumentierungen sammelt spezifische Daten, die dann einheitlich an den Kollektor, d.h. den Grafana Agent (siehe oben), weitergeleitet werden. Mit Ausnahme der Tracing-Instrumentierung, die bereits in der Grundkonfiguration eine betr\u00e4chtliche Menge an Daten produziert, sind alle Instrumentierungen standardm\u00e4\u00dfig aktiviert, sobald Faro im Code (JavaScript oder TypeScript) initialisiert wurde (ein einfacher Funktionsaufruf mit einer Handvoll Parametern). Sie k\u00f6nnen aber auch jeweils einzeln aktiviert und konfiguriert werden.<\/p>\n\n\n\n
Wir haben uns alle genannten Instrumentierungen einmal angeschaut und die Namen bzw. Kurzbeschreibungen sollten einen ersten kurzen Einblick geben k\u00f6nnen, was sich hinter der jeweiligen Instrumentierung verbirgt. Gleichzeitig erkl\u00e4rungsbed\u00fcrftig und (aus unserer Sicht) mit unmittelbarem Nutzen verbunden ist aber vor allem die Web Vitals<\/a> Instrumentierung, die wir nachfolgend etwas detaillierter betrachten.<\/p>\n\n\n\n
<\/span>Web Vitals \u2013 Wie nutzerfreundlich sind unsere UIs mit Blick auf Ladezeiten, Interaktivit\u00e4t und visuelle Stabilit\u00e4t?<\/span><\/h2>\n\n\n\n
Bei den Web Vitals handelt es sich um eine Reihe von Metriken, die von Google entwickelt wurden, um Entwicklern zu helfen, die Qualit\u00e4t ihrer Web-Seiten und Web-Apps zu messen und zu verbessern. Sie fokussieren drei Hauptaspekte der User-Experience: Ladezeit, Interaktivit\u00e4t und visuelle Stabilit\u00e4t.<\/p>\n\n\n\n
Mit Faro k\u00f6nnen verschiedene Web Vitals Out-of-the-box gemessen und zentral zur Analyse bereitgestellt werden. Einerseits die Core Web Vitals, die laut Google universelle Aussagekraft f\u00fcr eine gute Web-Experience haben:<\/p>\n\n\n\n
- \n
- Largest contentful paint (LCP<\/a>): <\/strong>Misst die Ladeleistung \u2013 Zeit, bis der Hauptinhalt der Seite angezeigt wird<\/li>\n\n\n\n
- Cumulative layout shift (CLS<\/a>)<\/strong>: Misst die visuelle Stabilit\u00e4t \u2013 Quantifiziert, wie oft Nutzer unerwartete Layout-Verschiebungen erleben<\/li>\n\n\n\n
- First input delay (FID<\/a>): <\/strong>Misst die Interaktivit\u00e4t \u2013 Zeit zwischen der ersten Interaktion eines Nutzers mit einer Seite und dem Zeitpunkt, zu dem der Browser mit der Verarbeitung von Event-Handlern beginnt<\/li>\n\n\n\n
- Interaction to next paint (INP<\/a>):<\/strong> Beobachtet die Latenz aller Interaktionen durch den Nutzer (Anmerkung: ersetzt zuk\u00fcnftig die FID-Metrik in den Core Web Vitals)<\/li>\n<\/ul>\n\n\n\n
Und anderseits weitere Leistungsmetriken, die eine technischere Leistungsmessung abdecken und spezifischere Fragen beantworten k\u00f6nnen:<\/p>\n\n\n\n
- \n
- Time to first byte (TTFB<\/a>):<\/strong> Die Zeit zwischen dem erstmaligen Abfragen einer Ressource und dem Erhalten des ersten Bytes der Antwort<\/li>\n\n\n\n
- First contentful paint (FCP<\/a>):<\/strong> Zeit, bis der Nutzer erstmalig etwas auf der Seite sehen kann<\/li>\n<\/ul>\n\n\n\n
Hinter den Links sind empfohlene Wertebereiche f\u00fcr die verschiedenen Metriken angegeben. Beispielsweise sollte f\u00fcr eine optimale Web-Experience die ‚Interaction to Next Paint‘ (INP) Zeit 200 Millisekunden oder weniger betragen (im 75%-Perzentil).<\/p>\n\n\n\n
<\/span>Implementierung<\/span><\/h2>\n\n\n\n
Bei der Umsetzung standen wir vor der Frage, wie wir Telemetrie-Daten, einschlie\u00dflich der hier diskutierten Web Vital Metriken, erfassen k\u00f6nnen, ohne den einzelnen Entwicklungsteams zus\u00e4tzlichen Aufwand aufzuerlegen. Wir haben daher Faro in unsere Rahmenanwendung (ShellApp) integriert, so dass die Erfassung automatisch f\u00fcr alle Apps funktioniert, welche die ShellApp nutzen.<\/p>\n\n\n\n
Die ShellApp iteriert dazu \u00fcber alle von ihr verwalteten IFrames und initialisiert dort jeweils Faro. Zudem generiert sie eine Session-Id, die im Session-Storage abgelegt wird und damit implizit einer Browser-Session entspricht. Diese Session-Id wird gemeinsam von den unterschiedlichen IFrames verwendet und stellt damit sicher, dass die Web Vital Metriken (aber auch weitere Telemetrie-Daten) aus den einzelnen IFrames logisch in einer zusammengeh\u00f6rigen Session geklammert werden. Ohne diesen Kniff w\u00fcrde jede Faro-Initialisierung eines jeden IFrames eine eigene Sitzung generieren.<\/p>\n\n\n\n
Dar\u00fcber hinaus extrahiert die ShellApp den Namen der aktiven App aus der aktuellen URL und verwendet diesen als Name sowie den URL-Pfad als
Environment<\/code> f\u00fcr die App-Metadaten, mit der s\u00e4mtliche Telemetrie-Daten versorgt werden und die z.B. bei analytischen Abfragen in Grafana als Dimension genutzt werden k\u00f6nnen.<\/p>\n\n\n\nDie nachfolgende Abbildung zeigt einen Screenshot unseres Grafana-Dashboards, das wir im Rahmen unserer Versuchsanordnung mit relevanten Daten bef\u00fcllt haben. Es veranschaulicht die wesentlichen Web Vital Metriken.<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nWie oben erw\u00e4hnt, werden die Web Vital Metriken mit dem jeweiligen Namen der in der Shell eingebetteten App versorgt. Damit besteht neben der bereits eingebauten M\u00f6glichkeit, nach Browser zu filtern, ebenfalls die M\u00f6glichkeit, nach Apps zu filtern. Die folgende Abbildung zeigt etwa die Web Vitals f\u00fcr die Dashboard-App im Chrome Browser:<\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\n<\/span>Request Duration \u2013 Wo verlieren wir Zeit?<\/span><\/h2>\n\n\n\n
Wie weiter oben bereits angedeutet, sind \u00fcbergreifende Traces in einer verteilten Architektur nicht nur \u00e4u\u00dferst hilfreich, sondern mit zunehmender Komplexit\u00e4t und Anzahl von Apps bzw. Services sogar unerl\u00e4sslich, um kritische Bereiche effektiv zu identifizieren. In diesem Kontext bietet sich der AppRouter, \u00fcber den s\u00e4mtliche App-Anfragen innerhalb der Plattform geroutet werden, als idealer Kandidat f\u00fcr die Implementierung von Tracing-F\u00e4higkeiten an. Er verf\u00fcgt bereits \u00fcber Zugriff auf eine Vielzahl relevanter Meta-Informationen, wie Tenant-ID, App-Name und HTTP-Attribute, was ihn zu einem idealen Punkt f\u00fcr die Gewinnung wertvoller Tracing-Daten macht.<\/p>\n\n\n\n
Beispiel: Tracing-Instrumentierung im AppRouter<\/h3>\n\n\n\n
Wir haben dazu Tracing mittels OpenTelemetry in den AppRouter integriert. Im Gegensatz zur Auto-Instrumentierung in der ShellApp mit Faro und in BusinessObjects mit OpenTelemetry mussten wir im AppRouter die Spans selbst erzeugen, einen ggf. vorhanden W3C Trace Context von Hand \u00fcbernehmen\/propagieren und letztlich auch die HTTP Basis Attribute selbst am Span setzen.<\/p>\n\n\n\n
- First contentful paint (FCP<\/a>):<\/strong> Zeit, bis der Nutzer erstmalig etwas auf der Seite sehen kann<\/li>\n<\/ul>\n\n\n\n
- Cumulative layout shift (CLS<\/a>)<\/strong>: Misst die visuelle Stabilit\u00e4t \u2013 Quantifiziert, wie oft Nutzer unerwartete Layout-Verschiebungen erleben<\/li>\n\n\n\n
- Errors: <\/strong>Erfasst im Browser auftretende (unbehandelte) Fehler<\/li>\n\n\n\n
- Der AppRouter<\/a> fungiert als Reverse Proxy f\u00fcr alle Apps. Er dient als zentraler Einstiegspunkt der d.velop platform und leitet Anfragen basierend auf Routing-Informationen (z. B. URL-Struktur oder Tenant-Informationen) an die zust\u00e4ndigen Apps weiter.<\/li>\n\n\n\n
![\"Dashboard](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/tracing-instrumentierung-approuter-1090x285.png\")
<\/a><\/figure>\n\n\n\n![\"Dashboard](\"https:\/\/www.d-velop.de\/blog\/wp-content\/uploads\/2025\/02\/tracing-businessobjects-d-velop-1090x339.png\")
<\/figure>\n\n\n\n