Website Monitoring-Häufig gestellte Fragen

Was ist der Unterschied zwischen Seitenansichten, Ladevorgängen und Übergängen?

Einseitige und mehrseitige Anwendungen funktionieren aus technischer Sicht anders. Dieser Unterschied ist wesentlich, um die Leistung und damit die Benutzererfahrung zu beurteilen. Diese Begriffe helfen Ihnen, die Verwendung einer Website zu kommunizieren. Kommunizieren, wie eine Website verwendet wird.

• Laden der Seite: Der Abruf des ursprünglichen HTML-Dokuments und aller nachfolgenden Aktionen bis zur nächsten Navigation im Browser. Zum Beispiel eine Navigation, die den Aufbau eines neues HTML-Dokument erfordert. In der Regel wird der Inhalt der Website als HTML auf dem Server wiedergegeben und anschließend an den Benutzer bereitgestellt. Eine mehrseitige Anwendung hat nur Seitenladevorgänge. Ein Beispiel für eine mehrseitige Anwendungswebsite ist Wikipedia.

• Seitenübergänge: Websites können den Inhalt ändern, den die Benutzer mit JavaScriptbetrachten. Im Gegensatz zum Laden von Seiten verwenden Seitenübergänge keine klassische Browsernavigation. Normalerweise wird neuer Websiteinhalt mit JavaScript geladen und dann in HTML umgewandelt. Diese HTML wird dann in das Dokument eingefügt, um das vorhandene Dokument aufzubereiten oder zu ersetzen. Einzelseitenanwendungen verwenden dieses Verfahren. Bei Einzelseitenanwendungen ist die Anzahl der Seitenübergänge größer als beim Laden von Seiten. Ein Beispiel für eine Website, die diese Architektur implementiert, ist Instana.

  Ein Seitenübergang wird ausgelöst, sobald der Seitenname mithilfe der APIgeändert wird.

• Seitenaufruf: Der Begriff "Seitenaufruf" wird eingeführt, um die allgemeine Aktivität auf einer Website unabhängig von der implementierten Architektur zu beurteilen. Seitenaufrufe sind die Summe der Seitenaufbau- und Seitenwechselvorgänge.

Was ist ein Beacon?

Der JavaScript -Agent überträgt kleine Überwachungsnutzdaten an die Instana-Server, die bestimmte Ereignisse modellieren, die innerhalb des Lebenszyklus einer Seitenansicht einer Website auftreten (z. B. Seitenladen, Ressourcenabruf und HTTP -Anforderungen). Der Begriff Beacon stammt aus der W3C Beacon-Spezifikation.

Was ist ein Ursprung?

Ursprünge sind ein zentraler Bestandteil der Websicherheitsmechanismen. Weitere Informationen zu Ursprüngen finden Sie unter Cross-Origin Resource Sharing (CORS). Die Kombination aus Schema (auch als 'Protokoll' bezeichnet), Hostnamen und Port bildet einen Ursprung. Sehen Sie sich das folgende Beispiel für eine URLan:

https://shop.example.com/articles/hoverboard/ratings

Die vorhergehende URL hat den Ursprung https://shop.example.com.

- Scheme: `https`
- Hostname: `shop.example.com`
- Port: 443 (based on the default for the HTTPS protocol)

Zwei Ursprünge sind identisch, wenn alle drei Teile (Schema, Hostname und Port) gleich sind. Die folgenden Beispiele sind alle ungleich zueinander:

• https://shop.example.com
• http://shop.example.com
• https://example.com
• http://example.com

Same-Origin-und Cross-Origin-Aufrufe oder gemeinsame Ressourcennutzung ist eine Terminologie, die häufig verwendet wird, wenn Sie Ursprünge erwähnen. Der Websicherheitsmechanismus same-origin policy und der Mechanismus cross-origin resource sharing sind allgemein bekannt. Wenn der Quellenursprung (der Ursprung des HTML-Dokuments) und der Zielursprung (der Ursprung eines API-Servers) unterschiedlich sind, wird ein Aufruf als Cross-Origin und nicht als derselbe Ursprung betrachtet.

Das Konzept der Ursprünge darf nicht mit dem ähnlichen verwechselt werden, aber besonders unterschiedlich in der Implementierung und Absicht Konzept der Sites.

Was bedeuten die Websitemetriken?

Die meisten der Website-Messdaten werden von den verschiedenen W3C-Spezifikationen empfangen. Insbesondere

• Ressourcentimings,
• Navigationsablaufsteuerung,
• Paint Timing und
• Netzinformationen-API

Instana verwendet allgemeine Webterminologie aus dem Web-Vitals-Projekt.

• Größte inhaltsvolle Farbe (LCP)
• Erste Eingabeverzögerung (FID)
• Kumulative Layoutverschiebung (CLS)
• Zeit bis zum ersten Byte (TTFB)

Instana hält diese Terminologie so weit wie möglich ein. Instana verwendet die folgenden Metriken:

• onLoad -Zeit: Diese Ablaufsteuerung gilt für jedes Laden von Seiten und modelliert die Zeit bis zum Abschluss einer Navigation (d. h., das Ladedrehfeld wird gestoppt). Sie ist als loadEventEnd - fetchStart definiert (siehe Navigationsablaufsteuerung). In der Benutzerschnittstelle werden onLoad -Zeit und onLoad -Ereigniszeit hinsichtlich der Unterschiede in der Terminologie zwischen der Instana-Benutzerschnittstelle und der Spezifikation des Navigationszeitpunkts unterschieden.
• DOM: Eine Variation des Timings, das im Navigationstiming definiert ist. Diese Metrik ist als domContentLoadedEventStart - domLoading definiert (siehe Navigationsablaufsteuerung). Sie wird als nützlichere Timing-Aufgliederung betrachtet als die Verarbeitungszeit des Navigationszeitpunkts. Sehen Sie sich das folgende Diagramm an, um die DOM-Zeit zu verstehen.
• Kinder: Eine Variation des Zeitpunkts, der im Navigationszeitpunkt definiert ist. Diese Metrik ist als loadEventEnd - domContentLoadedEventStart definiert (siehe Navigationsablaufsteuerung). Es wird als eine hilfreichere Timing-Aufgliederung betrachtet als die onLoad -Zeiten des Navigationszeitpunkts. Sehen Sie sich das folgende Diagramm an, um die Zeit für untergeordnete Elemente zu verstehen.

Für Benutzer der Instana-Web-REST-API wird ein API-Endpunkt mit Informationen zu den IDs der technischen Metriken (metricId) angezeigt. Die Metrik-IDs, auf die in der Antwort dieses Endpunkts verwiesen wird, können verwendet werden, um Metriken mit verschiedenen REST-APIs für die Websiteüberwachungvon Instana abzufragen.

Warum sind manche Websitemetriken nicht immer verfügbar oder weisen seltsame Werte auf?

Die wichtigsten Faktoren sind Benutzerinteraktion und Web-Browser-Unterstützung.

Für einige Metriken innerhalb des Zeitrahmens, in dem die Metriken erfasst werden, ist eine Benutzerinteraktion erforderlich, z. B. 'Verzögerung bei der ersten Eingabe'. Ohne Benutzerinteraktion ist kein Messwert verfügbar.

Der zweite wichtige Faktor ist die Web-Browser-Unterstützung. Einige Metriken erfordern Web-Browser-Funktionen, die noch nicht allgemein unterstützt werden, z. B. die modernen Web-Vitals. Ein nicht unterstütztes Web-Browser-Feature bedeutet, dass einige Websites als Ganzes, einige Seiten oder das Laden einer einzelnen Seite möglicherweise keine Informationen zu einer Metrik enthalten (z. B. zum kumulativen Layout-Shift). Unterschiede in der Web-Browser-Unterstützung können auch zu verwirrenden Situationen führen. Beispiel: FCP (First-Contentful Paint) wird weiter unterstützt als LCP (Largest-Contentful Paint). Daher führen statistische Aggregationen über eine Gruppe von Beobachtungen hinweg zu einem kleineren LCP als FCP-Werte. Obwohl die Überwachung für das Laden einer einzelnen Seite schwierig ist, können statistische Aggregationen für eine Gruppe von Seitenladevorgängen auftreten, wenn die Web-Browser-Unterstützung unterschiedlich ist, wie in den folgenden Beispielen gezeigt.

• Beobachtete Werte für 'First-Contentful Paint': 1000 ms, 1400 ms, 1600 ms Mittelwert: 1333ms.
• Beobachtete Größte-Contentful Paint-Werte: 1000 ms, UNSUPPORTED METRIC, 1600 ms. Mittelwert: 1300ms.

Warum sind die aufgezeichneten Timings für einige meiner HTTP -Aufrufe ungewöhnlich groß?

Die Überwachung der Instana-Website erfasst die Zeit zwischen Beginn der Anforderung (XMLHttpRequest#send) und dem Erfolgsereignis (XMLHttpRequest#onreadystatechange) mit readyState === 4. Die folgenden Faktoren wirken sich auf die Zeit zwischen den beiden vorhergehenden Ereignissen aus:

• HTTP-Umleitungen
• DNS-Suchzeit
• Zeit zum Herstellen von TCP-oder TLS-Verbindungen
• Serverantwortzeiten
• Anforderungswarteschlangenzeiten
• Latenz und Durchsatz
• Anforderungs- und Antwortgrößen
• Seitendrosselungen

Bei der Seitenregulierung entscheiden Browser möglicherweise, die Verarbeitung für nicht sichtbare Webseiten zu drosseln oder gar zu stoppen. Die Seitendrosselung ist wahrscheinlich der Grund für hohe Timing-Werte. Weitere Informationen finden Sie im Blogbeitrag vonGooglezu diesem Thema oder auf der entsprechenden Seite der Mozilla Developer Network Page Visibility API.

Warum fehlen die geografischen Informationen?

Die Überwachung der Website von Instana erfasst die geografischen Informationen basierend auf IP-Adresse/ oder Geo-Location-Mapping. Die IP-Adressinformationen werden über den Reverse-Proxy-Server erfasst. Wenn die geografischen Informationen in der Benutzerschnittstelle für die Websiteüberwachung fehlen, können Sie überprüfen, ob die URL für die Berichterstellung des JavaScript -Agenten so konfiguriert ist, dass der Reverse-Proxy-Server umgangen und Daten direkt an den internen Überwachungsendpunkt (normalerweise 2999) gesendet werden.

Der Reverse-Proxy-Server wird automatisch als Teil der selbst gehosteten Instana-Konfiguration (lokal) installiert. Weitere Informationen finden Sie unter Überwachungsendpunkt für Endbenutzer zugänglich machen.

Wie erfassen Sie diese Informationen?

Die Überwachung der Website von Instana basiert auf einer Open-Source-Bibliothek namens weasel. Weasel stellt die Informationen aus der Browser Navigation Timing API zusammen und überträgt sie in effizienter Form. Weitere Informationen zu Weasel finden Sie im Quellcode unter GitHub.

Welche Browser werden unterstützt?

Der JavaScript-Agent unterstützt alle gängigen Browser. Einige APIs und JavaScript-Sprachfunktionen werden in älteren Browsern jedoch nicht unterstützt. In diesen Fällen kann der JavaScript -Agent möglicherweise nicht alle gewünschten Datenpunkte wie Navigations-, Ressourcen-und Farbablaufsteuerungsinformationen erfassen.

In alten Browsern (alle Browser vor Internet Explorer 6) kann das Laden des JavaScript -Agenten fehlschlagen. Daher werden keine Daten erfasst.

Wie gehen Sie mit Browsern um, die die Navigations-Timing-API nicht unterstützen?

Für Browser, die die Navigations-Timing-API nicht unterstützen, stellt Instana ungefähre Zeitangaben bereit. Diese Timings sind nicht zuverlässig und verlassen sich daher nicht zu sehr auf sie für diese Spuren. Wenn Instana auf Näherungswerte für Seitenladezeiten zurückgreifen muss, werden die Werte aus der Statistik ausgeschlossen, d. h., Näherungswerte sind nicht Teil aggregierter Seitenladezeiten wie Mittelwert, Minimum und Maximum.

Welche Art von ineum -Aufrufen kann ich durchführen?

Weitere Informationen zur globalen ineum -Funktion finden Sie unter API-Dokumentation zur Websiteüberwachung.

Warum werde ich von AdBlock oder ähnlichen Browsererweiterungen blockiert?

Während die meisten der Ad-Blocking-Erweiterungen erstellt werden, um keine Werbung anzuzeigen, die meisten von ihnen entwickeln sich zu Erweiterungen, die Website-Besitzer daran hindern, ihre Benutzer zu verfolgen. Das Instana-Überwachungsscript endet in vielen der Ad-blocking-Erweiterungen. Wenn Sie Kontrolle über Ihre Benutzer haben, können Sie sie bitten, das EUM-Script in ihrer Ad-Blocking-Erweiterung zuzulassen.

Wie funktioniert die Back-End-Korrelation mit Ajax-Aufrufen?

Weitere Informationen zu Back-End-Korrelationsmechanismen finden Sie unter Back-End-Korrelation.

Welche Fehler können bei einer HTTP auftreten?

Der JavaScript -Agent wird in dem Web-Browser ausgeführt, der HTTP -Anforderungen ausgibt. Der JavaScript -Agent erfasst die allgemeinen HTTP , einschließlich -Clientfehler mit HTTP -Antwortcode 4XX und -Serverfehler mit HTTP -Antwortcode 5XX, die mit dem HTTP -Antwortcode angegeben werden. Der Agent kann auch die folgenden Fehler erkennen, wenn der Web-Browser die unvollständigen HTTP -Anforderungen verarbeitet:

• Timeout
• Anforderung abgebrochen
• Fehler beim Öffnen des XHR-Objekts
• Nicht-HTTP -Fehler

Welche HTTP -Header werden verwendet?

Der JavaScript-Agent verwendet die folgenden HTTP-Header, um eine Back-End-Korrelation zu erreichen.

• Anforderungsheader (an das Back-End):
  • X-INSTANA-T
  • X-INSTANA-S
  • X-INSTANA-L
• Antwortheader (zum Front-End):
  • Server-Timing

Warum gibt es keine Daten für GoogleBot und andere?

Aufgrund von Bots, die JavaScript -APIs bearbeiten, um vorhersehbare oder reproduzierbare Ergebnisse zurückzugeben, identifizieren und blockieren Instana JavaScript Agent und Server die Datenerfassung für verschiedene Bots. Das Blockieren der Datenerfassung wirkt sich positiv auf das Scraping des Web aus, führt aber leider zu Problemen, wenn die Benutzererfahrung überwacht werden soll. Beispiel: Die JavaScript -API von GoogleBot:

• Date.now() gibt nicht die aktuelle Uhrzeit in Millisekunden zurück, sondern einige scheinbar festgelegte Zeitmarken. Daher kann die Dauer, die durch die Streunung von zwei Zeitmarken aufgezeichnet wird, die von Date.now() angefordert werden, nicht anerkannt werden.
• Math.random() und crypto.getRandomValues() geben Werte aus einem Pool vordefinierter Werte zurück. Dies führt zu Problemen mit clientseitig generierten IDs, z. B. zu falschen Back-End-Korrelationsreferenzen.

An welche HTTP -Endpunkte rufen Benutzer an (für SaaS)?

Sie müssen nichts für die korrekte Datenübertragung zur SaaS -Plattform von Instana konfigurieren. Die Instana-Benutzerschnittstelle stellt immer das korrekte Tracking-Snippet dar, das die erforderlichen URLs enthält. Weitere Informationen zu Endpunkten finden Sie unter Website-Überwachungsendpunkte.

Ist es möglich, die HTTP -Endpunkte (für SaaS) weiterzuleiten?

Versuchen Sie nicht, die HTTP -Endpunkte als Proxy zu verwenden. Instana bietet keine Unterstützung für Proxy-Konfigurationen oder Probleme, die aufgrund der Verwendung eines Proxys auftreten können. Wenn Sie weiterhin Proxy einrichten möchten (oder haben), finden Sie möglicherweise die folgenden Tipps hilfreich:

• Legen Sie die richtigen HTTP-Header für Host fest.
• Beachten Sie den Unterschied zwischen den eum.instana.io -und eum-{region}.instana.io -Servern.
• Stellen Sie sicher, dass Instanzia-Server die Benutzer-IPs kennen. Senden Sie einen X-FORWARDED-FOR -Header an Instana-Server mit der IP-Adresse des Benutzers. Senden Sie alternativ einen X-REALER-IP HTTP (nicht X-REAL-IP) an die Instana-Server, die die IP-Adresse des Benutzers enthalten.
• Geben Sie alle HTTP-Header durch, die die Instana-Server in den Antwortteil aufnehmen.
• Führen Sie kein Caching im Proxy durch.

Erfassen Sie Daten aus WebSockets?

Der JavaScript-Agent von Instana erfasst keine Informationen über WebSockets. WebSockets verfügen über kein Semantikmodell, das Instana effektiv überwachen kann, abgesehen von Nachrichten, die zwischen Client und Server fließen. Da WebSocket -Nachrichten beliebige Formate (nur Zeichenfolgen oder Bytes) haben, kann Instana keinen Typ von Anforderung, Antwort, Erfolg oder Fehlerstatus ableiten.

Obwohl Sie theoretisch jede Nachricht, die mit WebSockets übertragen oder empfangen wird, an die Server von Instana übertragen können, hat diese Übertragung mehrere Probleme:

• Hohe Wahrscheinlichkeit der Erfassung sensibler Daten, die niemals in einem Überwachungssystem landen dürfen.
• Große Datenmengen werden von jedem Benutzer erfasst, was zu einem Systemaufwand für Benutzer führt.
• Typischerweise ein geringes Signal-Rausch-Verhältnis in den erfassten Daten.
• Das Fehlen eines standardisierten Semantikmodells in den Daten bedeutet, dass Instana den Zugriff auf die Daten für Sie nicht optimieren kann.

Aus diesen Gründen erfasst Instana nicht automatisch Daten zu WebSockets. Einige Kunden implementieren jedoch Anforderungs-oder Antwort-und Subskriptionsmechanismen in WebSockets. Weitere Informationen finden Sie unter API für angepasste Ereignisse. Mit der API für angepasste Ereignissekönnen Sie eine Back-End-Korrelation für WebSocket-basierte Anforderungs-oder Antwortsysteme realisieren.

Warum ist eum.js der Initiator aller Aufrufe von XMLHttpRequest und Fetch?

Instana JavaScript Agent instrumentiert die XMLHttpRequest -und fetch -APIs der Web-Browser, um sich über Aufrufe von Websites zu informieren. Diese Instrumentierung bewirkt, dass der JavaScript -Agent (eum.js) als Initiator in den Entwicklertools des Web-Browsers angezeigt wird, wie im folgenden Screenshot dargestellt. Der Instana JavaScript -Agent scheint diese Aufrufe auszuführen. Diese Aufrufe werden jedoch von der Website ausgeführt, die Instana überwacht.

Der JavaScript -Agent von Instana kommuniziert direkt nur mit Servern, die im JavaScript -Snippet definiert sind und von der Instana-Benutzerschnittstelle angezeigt werden oder für lokale Implementierungen angepasst wurden.

Was geschieht für Benutzer mit schlechten Internet-oder Netzverbindungen?

Zwei Fälle sind möglich:

1. Die Website-Besucher sind möglicherweise nicht in der Lage, unseren JavaScript-Agenten herunterzuladen. In diesen Fällen können keine Daten erfasst werden.
2. Datenübertragungsanforderungen von Ihren Websitebesuchern an unsere Server funktionieren möglicherweise nicht. Instana versucht in diesen Fällen weder die Zustellung erneut, noch speichert Instana die Daten für eine spätere Zustellung.

Warum enthält Ihr Script-Tag das Attribut defer ?

Fragen zum JavaScript -Snippet, seiner Struktur und dem von Instana ausgewählten Ansatz werden häufig gestellt. Das Snippet ist sorgfältig entworfen, um die Bedürfnisse der Kunden auszugleichen. Der folgende Abschnitt enthält einige Einblicke in diese Fragen.

Debugprotokollierung für den JavaScript -Agenten aktivieren

Das JavaScript von Instana unterstützt die Debugprotokollierung, die Sie verwenden können, um zusätzliche Einblicke in fehlerhafte Konfiguration, Datenübertragung, Grenzwerte usw. zu erhalten. Um die Debugprotokollierung für den JavaScript -Agenten zu aktivieren, ändern Sie die URL in den JavaScript -Agenten im Überwachungssnippet.

Bearbeiten Sie das Überwachungssnippet und ersetzen Sie die Dateireferenzen von eum.min.js auf eum.debug.js, wie im folgenden Snippet gezeigt.

<!-- before -->
<script defer crossorigin="anonymous" src="https://{{hostname}}/eum.min.js"></script>

<!-- after -->
<script defer crossorigin="anonymous" src="https://{{hostname}}/eum.debug.js"></script>

Gibt es Begrenzungen für das erfasste Datenvolumen?

Der JavaScript -Agent verfügt über ein Datenerfassungslimit pro Browserregisterkarte, um Instana-Systeme und Benutzer vor einer fehlerhaften Konfiguration und kreisförmigen Überwachungsmustern zu schützen. Es gibt folgende Grenzwerte:

• Jeder übertragene Beacon (außer für Seitenressourcen, hier gelten zusätzlich zu den später erwähnten spezifischeren Regeln weitere Regeln)
  • max. pro 10 s: 128
  • max. pro 10 min: 4096
  • max. pro Seitenladevorgang: 8096
• Seitenwechsel
  • max. pro 10 s: 32
  • Max. pro 10 Min.: 128
• Angepasste Ereignisse
  • max. pro 10 s: 32
  • Max. pro 10 Min.: 128
• HTTP -Aufrufbeacons, die mithilfe von window.fetch eingeleitet werden
  • max. pro 10 s: 32
  • Max. pro 10 Min.: 256
• HTTP -Aufrufbeacons, die mithilfe von window.XMLHttpRequest eingeleitet werden
  • max. pro 10 s: 32
  • Max. pro 10 Min.: 256

Erfassen Sie Daten, die Benutzer eindeutig identifizieren können?

Standardmäßig enthält der Instana JavaScript -Agent keine Daten, die Benutzer eindeutig identifizieren können. Außerdem wendet der Instana JavaScript -Agent keine Verfahren wie den Fingerabdruck von Geräten oder Browsern an.

Benutzerspezifische Daten können Instana über die Benutzer-APIzur Verfügung gestellt werden.

Was tun Sie mit den Benutzerdaten, die an Instana übertragen werden?

Die Benutzer-API kann von Kunden so konfiguriert werden, dass sie identifizierende Benutzerinformationen an Instana übertragen. Diese Informationen werden nur verwendet, um die im Produkt sichtbaren Funktionen bereitzustellen. Instana interpretiert diese Daten nicht auf andere Weise und korreliert auch nicht über mehrere Kunden hinweg.

Ist es möglich, Benutzerdaten nach der Übertragung an Instana zu löschen?

Instana unterstützt gelegentliche Löschanforderungen, z. B. zur Einhaltung der DSGVO. Wenn Sie häufige oder regelmäßige Löschanforderungen erwarten, übertragen Sie stattdessen anonymisierte Daten an Instana (z. B. hashverschlüsselte Benutzer-IDs).

Werden IPs anonymisiert?

IP-Adressen werden anonymisiert. Standardmäßig werden das letzte Oktett von IPv4 -Adressen und die letzten 80 Bit von IPv6 -Adressen auf Nullen gesetzt. Strengere Anonymisierungsregeln können über die Registerkarte 'Konfiguration' im Dashboard einer Website in der Instana-Benutzerschnittstelle konfiguriert werden.

Wie erhalten Sie Zugriff auf Benutzer-IPs?

Der JavaScript -Agent hat keinen Zugriff auf IP-Adressen. Auf Benutzer-IP-Adressen wird über die Netzverbindungen zugegriffen, die sie zu den Servern herstellen. Die von den JavaScript -Agenten empfangenen Daten werden von den Servern mit anonymisierten IP-Adressenaufbereitet.

Verwendet Instana Cookies?

Die Website-Überwachung selbst verwendet keine Cookies. Das Content-Delivery Network (Cloudflare) von Instana setzt jedoch aus Sicherheitsgründen ein Cookie mit dem Namen __cfduid . Weitere Informationen zum Cookie __cfduid finden Sie im Artikel zu häufig gestellten Fragen zu Cloudflare.

Verwendet Instana localStorage oder sessionStorage?

Standardmäßig verwendet Instana JavaScript Agent die Technologien localStorage und sessionStorage nicht. localStorage wird jedoch verwendet, wenn Sie die Sitzungsüberwachungaktivieren. Standardmäßig ist die Sitzungsüberwachungsfunktion im Instana JavaScript -Agenten nicht verfügbar.

Wo speichert Instana Websiteüberwachungsdaten?

Wo die Website-Überwachungsdaten gespeichert werden, hängt von der jeweiligen Instana-Installation ab. Im Allgemeinen werden die Daten entweder in der Amazon-oder Google -Cloud innerhalb ihrer europäischen oder US-Region gespeichert. Sie können anhand der reportingUrl im Instanzerfassungssnippet und der Liste der Berichtsendpunkte für JavaScript -Agentenermitteln, wo Ihre Daten gespeichert werden.

speichert CDN (Cloudflare) Benutzerdaten?

Benutzer laden den JavaScript -Agenten mithilfe des von Cloudflare bereitgestellten Content-Delivery Network (CDN) herunter. Cloudflare speichert Benutzerdaten (einschließlich IP-Adressen) für einen kleinen Zeitraum in Protokollen. Weitere Informationen finden Sie unter Cloudflare FAQ.

Ich habe eine Content-Security-Policy eingerichtet. Gibt es etwas, das ich tun muss?

Der Instana JS-Agent wird asynchron aus eum.instana.io geladen und kann mit HTTP(S) geladen werden. Überprüfen Sie, ob das Laden von Scripts aus dieser Domäne möglich ist.

Daten werden mit Bildladevorgängen, HTTP GET-und POST-Anforderungen (mit XMLHttpRequest) an Instana übertragen. Die Ursprünge, die für die Datenübertragung verwendet werden, werden im Tracking-Snippet angezeigt.

Die folgende Definition einer Content-Security-Policy zeigt, was für das SaaS-Produkt von Instana erforderlich ist:

script-src *.instana.io;
img-src *.instana.io;
connect-src *.instana.io;

Welche Auswirkungen hat die Same-Origin-Policy auf die Websiteüberwachung?

Die Same-Origin-Policy ist eines der wichtigsten Sicherheitskonzepte für Websites. Jede Website unterliegt der Richtlinie, da alle Web-Browser sie durchsetzen. Als Provider zur Überwachung von Websites kann Instana die Sicherheit Ihrer Website oder Ihres Browsers nicht kontrollieren. Instana kann nur innerhalb der auferlegten Sicherheitsvorgaben funktionieren. Leider werden dadurch die Instana-Überwachungsfunktionen eingeschränkt.

• Browser beschränken den Zugriff auf Fehlermeldungen und Stack-Traces auf Scripte mit gleichem Ursprung.
• Browser schränken die zulässigen HTTP-Header für Cross-Origin-Anforderungen ein. Daher ist eine Back-End-Korrelation nicht immer möglich.

Um diese Funktionen zu entsperren, wenn mehrere Ursprünge beteiligt sind, können Sie Cross-Origin Resource Sharing (CORS)verwenden. CORS ist ein Mechanismus, mit dem kleine kontrollierte Löcher innerhalb des Sicherheitsmechanismus der Same-Origin-Policy geöffnet werden. In der folgenden Abbildung wird detailliert beschrieben, was getan werden muss, um die von der Same-Origin-Policy auferlegten Einschränkungen anzugehen.

Weitere Informationen zu Instana-Back-End-Korrelationsmechanismen und wie sich die Websicherheit auf diese Korrelationsmechanismen auswirkt, finden Sie unter Back-End-Korrelation.

Warum sind detaillierte Aufgliederungen zum Abrufen von Ressourcen nicht immer verfügbar?

Die Verfügbarkeit von Einblicken in Netzzeiten, Cachingstatistiken und Assetgrößen hängt von Funktionen für das Ressourcentimingab. Diese Funktionen sind in den meisten modernen Web-Browsern verfügbar, wenn sie von derselben Ursprungsrichtlinie zugelassen werden.

Um Einblicke in Ressourcen von Cross-Origin-Ressourcen zu ermöglichen (z. B. Ursprung https://cdn.example.com:443 für ein HTML-Dokument, das aus https://example.com:443geladen wird) können Sie den Header Timing-Allow-Origin HTTP verwenden. Die folgende Abbildung zeigt, wie der Header festgelegt wird. Weitere Informationen finden Sie auch in der Spezifikation des Ressourcentimings.

Wie kann ich Einblicke in Scriptfehler gewinnen?

Bei Websites, auf denen viele Scripts von Drittanbietern eingebettet sind, treten in der Regel immer mehr Scriptfehler auf. Script Error gibt JavaScript -Fehler in Scripts anderer Anbieter an. Aus Sicherheitsgründen schränken Web-Browser den Zugriff auf JavaScript -Fehler von Scripts anderer Anbieter ein, indem sie die tatsächliche Fehlernachricht durch Script Error ersetzen und den Stack-Trace löschen.

Im Web können Sie mithilfe der folgenden Methoden Einblicke in Script Errorgewinnen:

• Sie können Webbrowser anweisen, Fehlermeldungen und Stack-Traces offenzulegen, indem Sie angeben, dass das Script des Drittanbieters keine vertraulichen Daten enthält.
• Sie können Schlupflöcher im Websicherheitsmodell verwenden (nicht empfohlen und funktioniert nicht garantiert).

Es wird empfohlen, die erste Option zu verwenden, da dies die designierte und richtige Methode ist, um Script Error Insights zu erhalten. Gehen Sie wie folgt vor, um die erste Option zu implementieren:

• Fügen Sie ein Attribut crossorigin="anonymous" zu Script-Tags hinzu.
• Stellen Sie sicher, dass die HTTP-Antwort mit der Quelle des Scripts einen Access-Control-Allow-Origin-Antwort-Header sendet.

Warum werden Cookie-Warnungen für dieselbe Site angezeigt, wenn ich den JavaScript -Agenten verwende?

Wenn Sie Warnungen zu Cookies derselben Site analysieren, müssen Sie zwischen den folgenden beiden Fällen unterscheiden:

• Benutzer, die am Produkt von Instana angemeldet sind (entweder SAAS oder selbst gehostet), haben Cookies gesetzt, die sich auf ihre Anmeldung und Instana-Produktnutzung beziehen.
• Ihre Website-Besucher, die keine Beziehung zu Instana haben und in der Regel nicht über Instana informiert sind.

Für die frühere Gruppe (d. h. Instana-Benutzer) setzen Instana und ihre Partner Cookies. Web-Browser übertragen diese Cookies auf Instana-Server als Teil der Website-Überwachung. Instana Server erwarten nie, dass diese Cookies für die Website-Überwachung existieren. Daher ist die Blockierung von Cookies durch Web-Browser kein Problem. Das einzige Cookie, das für die Websiteüberwachung verwendet wird, ist das von Cloudflare.

Für die letztere Gruppe (d. h. die Besucher Ihrer Website) hat das Cookie SameSite keine bekannten Probleme. Der CDN-Provider von Instana legt ein Cookie mit einer gültigen SameSite=Lax -Cookiekonfiguration fest.

Suchen Sie mithilfe eines Inkognito-oder privaten Browserfensters nach potenziellen SameSite -Cookieproblemen. Mit diesem Inkognito-oder InPrivate -Browserfenster können Sie Ihre Website wie einen Besucher erleben.

Was ist JavaScript -Stack-Trace-Umsetzung?

Die JavaScript-Stack-Trace-Übersetzung stellt innerhalb von Instana klare und besser verwertbare Stack-Traces bereit.

Before:
at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559

After:
at ProductDetails.js 26:11

Das Problem mit nicht übersetzten Stack-Trace-Zeilen ist, dass die Fehler nicht verwertbar sind. Entwickler arbeiten mit vielen (typischerweise kleinen) Dateien. Aus Leistungsaspekten werden diese Dateien in einem gebündelten und verkleinerten Format an Benutzerbrowser ausgeliefert, die zu Dateinamen, Zeilen und Spaltennummern in Stack-Traces führen, die nicht lesbar oder umsetzbar sind.

Bei einem übersetzten Stack-Trace ist klar, dass der Fehler, der in …/main.b1510333.chunk.js:1:1559 auftritt, tatsächlich at ProductDetails.js 26:11ist.

Wie funktioniert die Umsetzung von JavaScript -Stack-Traces?

Die Übersetzung funktioniert mithilfe von Quellenmaps. Quellenmaps ermöglichen es uns, nicht umsetzbare Stack-Traces in umsetzbare Stack-Traces zu übersetzen. Genauer gesagt, ermöglichen sie die Übersetzung von Verweisen auf Dateien, Namen, Zeilen und Spalten in die tatsächlichen Quelltext-Pendants.

Dazu führt Instana die folgenden Schritte aus:

1. Der JavaScript-Agent meldet JavaScript-Fehler an Instana-Server. Angenommen, der Stack-Trace enthält die Zeile at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559.
2. Die Server von Instana versuchen, die JavaScript -Datei herunterzuladen, um die Quellenmap zu identifizieren, die für diese Datei verantwortlich ist.
3. Die HTTP -Antwort wird geparst und Instana sucht nach Referenzen auf Quellenmaps.
4. Wenn eine Quellenmapdatei referenziert wird, lädt Instana die Quellenmapdatei mithilfe einer HTTP -GET-Anforderung herunter oder sucht in den hochgeladenen Quellenmapdateien nach dem Benutzer.
5. Wenn der Download oder die Suche erfolgreich ist, wird die Quellenmapdatei verwendet, um die Datei, den Namen, die Zeile und die Spalte zu übersetzen.

Sehen Sie sich die folgenden Schritte für die Stack-Trace-Zeile at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559an.

1. Den Instana-Servern wird ein Fehler gemeldet.
2. Die Instana-Server geben eine HTTP-GET-Anforderung an http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js aus.
3. Die Quellenzuordnungsreferenz //# sourceMappingURL=main.b1510333.chunk.js.map befindet sich in der JavaScript -Datei.
4. Die Quellenmapdatei http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.map wird mithilfe einer HTTP -GET-Anforderung heruntergeladen oder in den hochgeladenen Quellenmapdateien gefunden.
5. Die Quellenzuordnung wird syntaktisch analysiert und der Stack-Trace lesbar gemacht.

Wie genau ruft Instana Dateien von unseren Servern ab?

Wenn Instana von dem Stack-Trace erfährt, gibt es automatisch HTTP -Anforderungen aus, um die JavaScript -und Quellenmapdateien abzurufen. Der folgende Aufruf zeigt die nächste Darstellung der durchgeführten Aufrufe:

curl -H 'Accept: */*' \
  # Use a fake user-agent to bypass simple bot blockers
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36' \
  {{url of JavaScript or source map files}}

Mit dem vorherigen Befehl können Sie ermitteln, welche Art von Konfiguration Instana benötigt, um die JavaScript -und Quellenmapdateien von Ihren Servern herunterzuladen. Die HTTP -Anforderungen werden von Servern ausgegeben, die in AWS (Amazon Web Services) oder Google Cloudausgeführt werden. Erweiterte Bot-Erkennungsmechanismen können Anforderungen blockieren, die von AWS oder Google Cloudstammen. Ziehen Sie daher in Betracht, zusätzliche Header zu konfigurieren, die Instana an Ihre Server senden muss, um Mechanismen zur Bot-Erkennung zu umgehen.

Wie kann ich sicherstellen, dass die Instanziserver eine TCP-oder TLS-Verbindung herstellen können?

Die Instana-Server geben Anforderungen von AWS -oder Google Cloud -Servern aus. Daher ist der Zugriff auf die JavaScript -und Quellenmapdateien über das Internet möglich. Außerdem müssen Sie sicherstellen, dass Ihr Server über eine funktionierende TLS-Konfiguration mit einer vollständigen Zertifikatskette verfügt. Sie können mithilfe des kostenlosen SSL-Tests von SSL Labs/Qualys oder durch Ausführen der folgenden Befehle nach TLS-Problemen suchen:

openssl s_client -showcerts -connect {{YOUR_DOMAIN_HERE}}:443

Wie kann ich Quellenmapdateien in Instana hochladen?

Informationen zum Hochladen von Quellenmapdateien in Instana finden Sie unter Quellenmapdateien in Instana hochladen.