Überwachung von Browseranwendungen mit OpenTelemetry

Viele Entwicklungsteams nutzen OpenTelemetry (OTeL) auf der Serverseite, um Signale wie Protokolle, Traces und Metriken aus ihren Anwendungen zu sammeln. Was jedoch oft übersehen wird, ist die Leistungsfähigkeit der Browser-Instrumentierung von OTeL. Diese clientseitigen Observability-Daten können aussagekräftige Erkenntnisse liefern und einen umfassenden Überblick über die Leistung einer Anwendung schaffen, indem sie Traces zwischen Client und Server verbinden.

Was ist OpenTelemetry?

OpenTelemetry ist eine Sammlung von Tools, APIs und SDKs, die zum Instrumentieren, Generieren, Sammeln und Exportieren von Telemetriedaten (Metriken, Protokolle und Traces) zur Analyse verwendet werden, um die Leistung und das Verhalten Ihrer Software zu verstehen.

Wenn Sie an einem tieferen Einblick in OTeL interessiert sind, lesen Sie unseren aktuellen Artikel: Was ist OpenTelemetry und warum sollte es mich interessieren?.

OpenTelemetry in Browseranwendungen

Wenn es um Browser-Apps geht, kann OpenTelemetry wertvolle Einblicke in Folgendes liefern:

1. Dokumentladeleistung
2. Benutzerinteraktionen
3. Netzwerkanfragen (XMLHttpRequest und Fetch)

Diese Erkenntnisse ermöglichen es Entwicklern, Engpässe zu identifizieren, Benutzerinteraktionen zu verfolgen und Netzwerkanforderungen ohne manuelle Instrumentierung zu überwachen. Bei den oben erwähnten Daten handelt es sich um Daten, die Sie relativ einfach erhalten, indem Sie die automatische Instrumentierung von OTeL nutzen. Sie können aber auch manuelle Instrumentierung hinzufügen, um Spuren für jeden anderen Code in Ihren clientseitigen Apps zu sammeln.

Highlight und OpenTelemetry

Das JavaScript SDK von Highlight bietet integrierte Unterstützung für die Erfassung von OpenTelemetry-Daten aus clientseitigen Anwendungen. Durch diese Integration können Sie OpenTelemetry-Tracing nahtlos in Ihre Webanwendungen integrieren.

Aktivieren von OpenTelemetry mit Highlight

Die OTeL-Datenerfassung befindet sich noch in der Betaphase, daher müssen Sie sie explizit aktivieren, indem Sie bei der Initialisierung des SDK die Konfigurationsoption „enableOtelTracing“ festlegen:

H.init({
  // ...
  enableOtelTracing: true
})

Mit dieser einfachen Konfiguration sammelt Highlight automatisch die meisten OpenTelemetry-Daten, die Sie benötigen, indem es die automatischen Instrumentierungen nutzt und einige zusätzliche Verarbeitungen durchführt, um die Daten in Highlight nützlicher zu machen.

Verbinden von Client- und Server-Traces

Eine der leistungsstärksten Funktionen von OpenTelemetry ist die Möglichkeit, Traces über verschiedene Dienste und Umgebungen hinweg zu verbinden. Die SDKs von Highlight erleichtern dies durch Kontextweitergabe und ermöglichen Ihnen die Erstellung von End-to-End-Traces, die von Benutzerinteraktionen im Browser bis hin zu Ihren Backend-Diensten reichen.

So funktioniert es:

1. Trace-Initiierung: Wenn eine Benutzerinteraktion oder eine Netzwerkanforderung im Browser initiiert wird, erstellt das SDK einen neuen Span oder setzt einen vorhandenen Trace fort.
2. Header-Injection: Bei ausgehenden HTTP-Anfragen (sowohl XHR als auch Fetch) fügt das SDK automatisch Trace-Kontext-Header in die Anfrage ein. Zu diesen Headern gehören typischerweise:
   • Traceparent: Enthält die Trace-ID, die übergeordnete Span-ID und Trace-Flags.
   • Tracestate: Enthält herstellerspezifische Trace-Informationen.
3. Serverseitiger Empfang: Die serverseitigen Highlight-SDKs extrahieren diese Header und setzen den Trace fort, indem sie die serverseitigen Spans mit dem clientseitigen Trace verknüpfen.
4. Trace-Abschluss: Wenn die Anfrage abgeschlossen ist und an den Client zurückkehrt, kann der vollständige Trace, einschließlich der Client- und Serverspannen, in der Benutzeroberfläche von Highlight visualisiert werden.

Diese Verbindung zwischen Client- und Server-Traces sorgt für eine durchgängige Sichtbarkeit und ist die erforderliche Verbindung für Einblicke in die Seitengeschwindigkeit und Client-/Server-Fehlerkorrelation.

Für serverseitiges Rendering, bei dem Code auf dem Server ausgeführt wird, bevor HTML an den Browser gesendet wird, wird der Trace-Kontext über ein weitergegeben. Tag, der dem HTML hinzugefügt wird.

Beispiel eines Client-Server-Trace-Lebenszyklus

Hier ist ein vereinfachtes Beispiel, wie das in der Praxis funktioniert:

1. Ein Benutzer klickt auf eine Schaltfläche in Ihrer Webanwendung.
2. Das Highlight SDK erstellt eine Spanne für diese Benutzerinteraktion.
3. Diese Interaktion löst einen API-Aufruf an Ihr Backend aus.
4. Das SDK fügt automatisch Trace-Header in diesen API-Aufruf ein.
5. Ihr Backend empfängt die Anfrage, extrahiert den Trace-Kontext und setzt den Trace fort.
6. Das Backend verarbeitet die Anfrage und sendet eine Antwort.
7. Der Kunde erhält die Antwort und vervollständigt den Bereich.

Das Ergebnis ist eine einzelne Ablaufverfolgung, die den gesamten Verlauf der Anfrage zeigt, von der ersten Benutzerinteraktion im Browser über Ihre Backend-Dienste bis zurück zum Client.

Vorteile

Diese Verbindung zwischen Client- und Server-Traces bietet mehrere Vorteile:

• End-to-End Visibility: You can trace a user's action all the way through your system, making it easier to diagnose issues and understand performance bottlenecks.
• Performance Optimization: By seeing the complete picture, you can identify whether performance issues are occurring on the client-side, server-side, or in the network communication between them.
• Error Correlation: If an error occurs, you can see the full context of what led to that error, including any relevant client-side actions or server-side processing.

By leveraging Highlight's OpenTelemetry integration, you can gain these insights with minimal configuration, allowing you to focus on improving your application's performance and user experience.

Handling Server-Initiated Traces

When a request for a page is made by fetching a new URL in the browser we don't have the JS SDK initialized in the browser until the server returns the HTML and renders the page, then fetches all the JS assets to render the app. In this case you pass the trace ID from the server to the client in a tag to handoff the trace initiated on the server to the client.

Here is an example of what the meta tag looks like in the browser:

<meta
  name="traceparent"
  content="00-ab42124a3c573678d4d8b21ba52df3bf-d21f7bc17caa5aba-01"
>

Note that the Highlight server SDKs often have helpers to create this tag. Here's an example using the Highlight Ruby SDK

<%= highlight_traceparent_meta %>

The browser OTeL instrumentation gathers timing information from window.performance.timing and creates spans for all the different timing events in the browser. This instrumentation parses the tag and associates all the spans it creates with trace data from the tag. This is illustrated in the screenshot of the flame graph below.

Here's how to parse what's going on in this flame graph:

1. The documentLoad span shows the full timing from submitting the URL in the browser to be loaded to having all the assets loaded and the page being fully interactive. The timing data for this span is gathered from window.performance.timing since we can't actually initiate a span before the JS loads.
2. The PagesController#home is the first span created on the server. You can trace the server code execution required to render the HTML that will be returned to the browser. When the HTML is returned to the browser the documentFetch span finishes.
3. After the HTML is loaded int he browser you can see the requests for the page's resources (all the JS and CSS files), these are the resourceFetch spans.

These resource timings provide a full picture of your app's load time, making it clear where the opportunities are to improve performance and provide a better UX.

Leveraging OpenTelemetry Data in Highlight

Collecting OpenTelemetry data is one thing, but gleaning actionable insights is another. You need some way of visualizing the data (like the flame graph shown above) in order to get actionable insights. Highlight exposes this data a few ways.

Viewing Traces in Highlight

When you open Highlight's UI, you'll find a dedicated section for traces. Here, you can see a list of all the traces collected from your application, including those that span from the browser to your backend services.

1. Trace List: This view provides an overview of all traces, typically sorted by timestamp. You can filter and search for specific traces based on various criteria such as duration, error status, or custom attributes.

2. Trace Detail View: Clicking on a specific trace opens a detailed view, showing the full journey of a request or user interaction. This view includes:

   • A flame graph visualization of the trace, showing the hierarchy and timing of spans.
   • Detailed information about each span, including start time, duration, and any custom attributes or events.
   • For spans representing network requests, you can see details like HTTP method, status code, and headers.

3. Cross-Service Tracing: For traces that span from the browser to your backend services, you'll see a seamless view of the entire request lifecycle. This makes it easy to identify whether performance issues are occurring on the client-side, server-side, or in the network communication between them.

Analyzing Resource Timings and Web Vitals

Highlight's metrics product provides powerful tools for analyzing resource timings and Web Vitals, which are crucial for understanding and optimizing your application's performance.

1. Ressourcen-Timing-Dashboard: Dieses Dashboard bietet einen Überblick darüber, wie lange es dauert, verschiedene Ressourcen auf Ihren Webseiten zu laden. Sie können sehen:

   • Ladezeiten für verschiedene Arten von Ressourcen (JS, CSS, Bilder usw.)
   • Zeitaufwand für DNS-Suche, TCP-Verbindung, TLS-Aushandlung und mehr für jede Ressource
   • Visualisierungen, die dabei helfen, langsam ladende Ressourcen oder Engpässe im Ladevorgang zu erkennen

2. Web Vitals-Metriken: Markieren Sie wichtige Web Vitals-Metriken und zeigen Sie sie an, darunter:

   • Größter Contentful Paint (LCP): Misst die Ladeleistung
   • First Input Delay (FID): Misst die Interaktivität
   • Cumulative Layout Shift (CLS): Misst die visuelle Stabilität
   • First Contentful Paint (FCP): Misst die Zeit von der Navigation bis zum Rendern des ersten Inhalts durch den Browser

3. Leistungstrends: Mit Highlight können Sie diese Kennzahlen im Zeitverlauf verfolgen und so Folgendes identifizieren:

   • Die Auswirkungen von Codeänderungen oder Bereitstellungen auf die Leistung
   • Allmähliche Verschlechterungen, die sonst möglicherweise unbemerkt bleiben würden
   • Verbesserungen durch Optimierungsbemühungen

4. Segmentierung und Filterung: Sie können diese Metriken basierend auf verschiedenen Faktoren segmentieren und filtern, wie zum Beispiel:

   • Gerätetyp (Mobilgerät, Desktop, Tablet)
   • Browser
   • Geografischer Standort
   • Benutzerdefinierte Attribute, die Sie definiert haben

Durch die Kombination der detaillierten Trace-Daten mit diesen allgemeinen Leistungsmetriken erhalten Sie einen umfassenden Überblick über die Leistung Ihrer Anwendung. Dadurch können Sie Probleme schnell identifizieren, ihre Grundursachen verstehen und die Auswirkungen Ihrer Optimierungsbemühungen messen.

Abschluss

OpenTelemetry bietet leistungsstarke Tools zur Überwachung und Optimierung von Browseranwendungen. Durch die Nutzung der OpenTelemetry-Integration von Highlight können Entwickler mit minimaler Konfiguration umsetzbare Erkenntnisse gewinnen.

Ganz gleich, ob Sie mit clientseitigen Leistungsproblemen, serverseitigen Engpässen oder komplexen Benutzerreisen über mehrere Dienste zu kämpfen haben, OpenTelemetry und Highlight bieten die Transparenz, die Sie für die Bereitstellung außergewöhnlicher Webanwendungen benötigen.

Das obige ist der detaillierte Inhalt vonÜberwachung von Browseranwendungen mit OpenTelemetry. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!