Foire aux questions relatives à la surveillance de site Web

Dans une application monopage, le contenu affiché dans le navigateur est modifié presque exclusivement à l'aide d' JavaScript, qui permet de modifier un seul document HTML. Le navigateur charge une seule page et, en général, ne quitte pas cette page. Souvent, une application monopage est développée à l'aide d'un framework de type « JavaScript », tel que Angular et React. Un exemple de site web qui utilise cette architecture est Instana.

Dans une application multipages, chaque section de l'application constitue une page distincte que le navigateur doit charger individuellement. Les pages peuvent contenir des éléments d' JavaScript dynamique, mais elles ne sont pas chargées de gérer les transitions entre les différentes parties de l'application. Un exemple de site Web d'application de plusieurs pages est Wikipedia.

Le type d'application dont vous disposez influe sur la manière dont Instana surveille cette application.

Les applications à une page et les applications à plusieurs pages fonctionnent différemment d'un point de vue technique. Cette différence est essentielle pour juger des performances et par conséquent, de l'acquis utilisateur. Ces termes aident à communiquer comment un site Web est utilisé.

• Chargement de page: récupération du document HTML initial et de toutes les actions suivantes jusqu'à la prochaine navigation dans le navigateur. Par exemple, une navigation qui requiert le chargement d'un nouveau document HTML. En général, le contenu du site web est généré au format HTML sur le serveur, puis transmis à l'utilisateur. Une application multipages ne comporte que des chargements de pages.

• Transitions de page: les sites Web peuvent modifier le contenu que les utilisateurs consultent avec JavaScript. Contrairement aux chargements de page, les transitions de page n'utilisent pas la navigation classique dans le navigateur. En général, le nouveau contenu d'un site web est chargé au format JavaScript, puis converti en HTML. Ce code HTML est ensuite placé dans le document pour enrichir ou remplacer le document existant. Les applications à page unique utilisent cette technique. Pour les applications à page unique, le nombre de transitions de page est supérieur au nombre de chargements de page.

  Une transition de page est déclenchée lorsque le nom de la page est modifié à l'aide de la balise ` API `.

• Vue de page: le terme vue de page est introduit pour juger de l'activité générale sur un site Web, quelle que soit l'architecture implémentée. Les vues de page correspondent à la somme des chargements de page et des transitions de page.

L'agent « JavaScript » transmet aux serveurs « Instana » des données de surveillance légères qui modélisent les événements spécifiques survenant au cours du cycle de vie d'une consultation de page sur un site web (par exemple, le chargement de la page, la récupération des ressources et les requêtes HTTP ). Le terme « beacon » provient de la spécification Beacon de l' W3C.

Les origines sont un élément central des mécanismes de sécurité Web. Pour plus d'informations sur les origines, consultez la section « Partage de ressources entre origines » ( CORS ). La combinaison du schéma (également appelé protocole), du nom d'hôte et du port constitue une origine. Consultez l'exemple suivant : URL :

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

L' URL e précédente a pour point de départ https://shop.example.com.

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

Deux origines sont identiques lorsque les trois parties (schéma, nom d'hôte et port) sont identiques. Les exemples suivants sont tous inégaux les uns par rapport aux autres:

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

Les appels de même origine et d'origine croisée ou le partage de ressources sont une terminologie fréquemment utilisée lorsque vous mentionnez des origines. Le mécanisme de sécurité Web connu sous le nom de « politique de même origine » et les mécanismes de partage de ressources entre origines différentes sont bien connus. Lorsque l'origine source (l'origine du document HTML) et l'origine cible (l'origine d'un serveur d'API) sont différentes, un appel est considéré comme inter-origines et non comme de même origine.

Il ne faut pas confondre la notion d’origines avec celle, similaire mais sensiblement différente tant dans sa mise en œuvre que dans son intention, de sites.

La plupart des métriques de site Web proviennent des diverses spécifications W3C, notamment les API :

• Délai de ressource
• Délai de navigation
• Délai d'affichage du premier élément par le navigateur
• Informations sur le réseau API

Instana utilise la terminologie Web courante issue du projet Web Vitals.

• Plus grande peinture de contenu (LCP)
• Délai de première entrée (FID)
• décalage de présentation cumulée (CLS)
• Temps jusqu'au premier octet (TTFB)

Instana s'efforce de respecter cette terminologie autant que possible. Instana utilise les indicateurs suivants :

• onLoad : ce délai existe pour chaque chargement de page et modélise le temps jusqu'à ce qu'une navigation soit terminée (c'est-à-dire que le spinner de chargement s'arrête). Elle est définie en tant que loadEventEnd - fetchStart (voir la spécification Navigation Timing). Dans l'interface utilisateur, on distingue le « onLoad Time » (temps de requête) et le « onLoad Event Time » (temps d'événement de navigation) afin de clarifier les différences terminologiques entre l'interface utilisateur Instana et la spécification relative au timing de navigation.
• DOM: variation du temps défini dans le temps de navigation. Cet indicateur est défini en tant que domContentLoadedEventStart - domLoading (voir temps de navigation). Il est considéré comme une répartition temporelle plus utile que le temps de traitement du temps de navigation. Consultez le diagramme suivant pour comprendre le temps DOM.
• Enfants: variation du temps défini dans le temps de navigation. Cet indicateur est défini en tant que loadEventEnd - domContentLoadedEventStart (voir temps de navigation). Elle est considérée comme une répartition temporelle plus utile que les temps onLoad de la navigation. Consultez le diagramme suivant pour comprendre le temps des enfants.

Pour les utilisateurs de l' REST API Web Instana, un point de terminaison API est affiché pour en savoir plus sur les identifiants des métriques techniques (metricId Les identifiants de métriques référencés dans la réponse de ce point de terminaison peuvent être utilisés pour interroger les métriques avec diverses API REST Web de surveillance de sites Web Instana.

Les facteurs les plus importants sont l'interaction avec l'utilisateur et la prise en charge du navigateur Web.

L'interaction de l'utilisateur est requise pour certains indicateurs dans la période au cours de laquelle les indicateurs sont collectés, par exemple, le délai de première entrée. Sans interaction utilisateur, aucune valeur de métrique n'est disponible.

Le deuxième facteur important est la prise en charge des navigateurs Web. Certaines métriques nécessitent des fonctions de navigateur Web qui ne sont pas encore largement prises en charge, par exemple, les vitals Webmodernes. Une fonction de navigateur Web non prise en charge signifie que certains sites Web dans leur ensemble, certaines pages ou des chargements de page unique peuvent ne pas contenir d'informations sur un indicateur (par exemple, sur la période de présentation cumulée). Les diverses prises en charge des navigateurs Web peuvent également entraîner des confusions. Par exemple, First-Contentful Paint (FCP) est plus largement pris en charge que Largest-Contentful Paint (LCP). Par conséquent, les agrégations statistiques portant sur un ensemble d'observations donnent lieu à des valeurs LCP inférieures aux valeurs FCP. Bien que l'observation d'un chargement de page unique soit difficile, des agrégations statistiques peuvent se produire pour un ensemble de chargements de page compte tenu d'une différence dans la prise en charge du navigateur Web, comme le montrent les exemples suivants.

• Valeurs First-Contentful Paint observées: 1000 ms, 1400 ms, 1600 ms. Moyenne: 1333ms.
• Valeurs de plus grande peinture de contenu observées: 1000 ms, UNSUPPORTED METRIC, 1600 ms. Moyenne: 1300ms.

Instana La surveillance du site web enregistre le délai entre le début de la requête (XMLHttpRequest#send) et l'événement de réussite (XMLHttpRequest#onreadystatechange) à l'aide de readyState === 4. Les facteurs suivants ont une incidence sur le temps écoulé entre les deux événements précédents:

• Les redirections HTTP
• Le temps de recherche DNS
• Il est temps d'établir des connexions via TCP ou TLS
• Les temps de réponse du serveur
• Temps de mise en file d'attente des demandes
• Le temps d'attente et le débit
• La taille des demandes et des réponses
• La régulation des pages

Pour la régulation de page, les navigateurs peuvent décider de réguler ou même d'arrêter le traitement des pages Web qui ne sont pas visibles. La limitation de la mise en mémoire tampon des pages est très probablement à l'origine de ces temps d'attente élevés. Pour plus d'informations, consultez l'article de blog deGoogle sur ce sujet ou la page correspondante du Mozilla Developer Network intitulée « Visibility API ».

Le service de surveillance de sites web de Instana recueille des informations géographiques à partir des adresses IP ou de la géolocalisation. Les informations d'adresse IP sont collectées à l'aide du serveur proxy inverse. Si les informations géographiques ne s'affichent pas dans l'interface utilisateur de surveillance du site web, vous pouvez vérifier si l' URL de rapport de l'agent JavaScript est configurée pour contourner le serveur proxy inverse et envoyer les données directement au point de terminaison de surveillance interne (généralement 2999).

Le serveur proxy inverse est installé automatiquement dans le cadre de l'installation en mode auto-hébergé (sur site) d' Instana. Pour plus d'informations, consultez la section « Mise à disposition du point de terminaison de surveillance pour les utilisateurs finaux ».

Le service de surveillance de sites web de Instana s'appuie sur une bibliothèque open source appelée weasel. Weasel recueille les informations issues de l' API « Browser Navigation Timing » et les transmet sous une forme optimisée. Pour plus d'informations sur Weasel, consultez son code source sur GitHub.

L'agent JavaScript prend en charge tous les navigateurs couramment utilisés. Toutefois, certaines API et certaines fonctions du langage JavaScript ne sont pas prises en charge dans les navigateurs plus anciens. Dans ces cas, l'agent JavaScript peut ne pas être en mesure de collecter tous les points de données souhaités, tels que les informations de navigation, de ressource et de temps de peinture.

Dans les anciens navigateurs (tous les navigateurs antérieurs à Internet Explorer 6), le chargement de l'agent JavaScript peut échouer. Par conséquent, aucune donnée n'est collectée.

Pour les navigateurs qui ne prennent pas en charge l' API « navigation timing », Instana fournit des durées approximatives. Ces délais ne sont pas fiables, et ne vous fiez donc pas trop à eux pour ces traces. Lorsque Instana doit recourir à des estimations pour les temps de chargement des pages, ces valeurs sont exclues des statistiques; en d'autres termes, les estimations ne sont pas prises en compte dans les temps de chargement agrégés, tels que la moyenne, le minimum et le maximum.

Pour plus d'informations sur la fonction ineum globale, consultez la documentation relative à la surveillance de sites Web sur API.

Alors que la plupart des extensions de blocage de publicité sont créées pour ne pas afficher de publicités, la plupart d'entre elles évoluent en extensions qui empêchent les propriétaires de sites Web de suivre leurs utilisateurs. Le script de suivi Instana se retrouve dans de nombreuses extensions de blocage de publicités. Si vous avez le contrôle de vos utilisateurs, vous pouvez leur demander d'autoriser le script EUM dans leur extension de blocage de publicité.

Pour plus d'informations sur les mécanismes de corrélation backend, consultez la section « Corrélation backend ».

L'agent « JavaScript » s'exécute dans le navigateur Web qui envoie des requêtes de type « HTTP ». L'agent « JavaScript » recense les erreurs courantes d' HTTP, notamment l'erreur client avec le code de réponse HTTP ( 4XX ) et l'erreur serveur avec le code de réponse HTTP ( 5XX ), qui sont identifiées par le code de réponse HTTP. L'agent peut également détecter les erreurs suivantes lorsque le navigateur Web traite des requêtes HTTP incomplètes :

• Timeout
• Demande abandonnée
• Erreur d'ouverture d'objet XHR
• Erreur de non- HTTP

L'agent « JavaScript » utilise les en-têtes HTTP suivants pour assurer la corrélation avec le backend.

• En-têtes de demande (back end) :
  • X-INSTANA-T
  • X-INSTANA-S
  • X-INSTANA-L
• En-têtes de réponse (à l'avant-plan):
  • Server-Timing

En raison de l'existence de robots qui manipulent les API d' JavaScript s afin d'obtenir des résultats prévisibles ou reproductibles, l'agent et les serveurs Instana JavaScript identifient et bloquent la collecte de données par divers robots. Le blocage de la collecte de données a un impact positif lors de la récupération du web, mais provoque malheureusement des problèmes lors de la surveillance des expériences utilisateur. Par exemple, l' GoogleBot's, JavaScript, API :

• Date.now() ne renvoie pas l'heure actuelle en millisecondes, mais plutôt des horodatages apparemment fixes. Par conséquent, les durées enregistrées par la diffusion de deux horodatages acquis par Date.now() ne peuvent pas être considérées comme fiables.
• Math.random() et crypto.getRandomValues() renvoient des valeurs à partir d'un pool de valeurs prédéfinies. Cela provoque des problèmes avec les ID générés côté client, par exemple en provoquant des références de corrélation d'arrière-plan incorrectes.

Vous n'avez rien à configurer pour assurer une transmission correcte des données vers la plateforme SaaS d' Instana. L'interface utilisateur d'Instana présente toujours le fragment de suivi correct, qui inclut les URL nécessaires. Pour plus d'informations sur les points de terminaison, consultez la section consacrée aux points de terminaison de surveillance de sites Web.

N'essayez pas d'utiliser un proxy pour les points de terminaison de l' HTTP. Instana ne prend en charge aucune configuration de proxy ni aucun problème pouvant survenir suite à l'utilisation d'un proxy. Si vous souhaitez tout de même (ou devez) configurer un proxy, les conseils suivants pourraient vous être utiles :

• Définissez des en-têtes HTTP Host appropriés.
• Respectez la différence entre les serveurs eum.instana.io et eum-{region}.instana.io.
• Assurez-vous que les serveurs Instana connaissent les adresses IP des utilisateurs. Envoyer un X-FORWARDED-FOR en-tête aux serveurs de Instana, en indiquant l'adresse IP de l'utilisateur. Vous pouvez également envoyer un en-tête X-REALER-IP « HTTP » (et non X-REAL-IP« ```) » aux serveurs Instana, en y indiquant l'adresse IP de l'utilisateur.
• Transmettez tous les en-têtes HTTP que les serveurs d'Instana incluent dans le corps de réponse.
• Ne procédez à aucune mise en cache dans le proxy.

L'agent JavaScript d'Instana ne collecte pas d'informations sur les WebSockets. WebSockets ne disposent d'aucun modèle sémantique permettant à Instana d'effectuer une surveillance efficace, hormis les messages échangés entre le client et le serveur. Étant donné que les messages de l' WebSocket ont des formats arbitraires (simples séquences de caractères ou d'octets), Instana ne peut déduire aucun type de requête, de réponse, ni d'état de réussite ou d'échec.

Bien qu'il soit théoriquement possible de transmettre tous les messages envoyés ou reçus via WebSockets aux serveurs de Instana, une telle transmission pose plusieurs problèmes :

• Probabilité élevée de recueillir des données sensibles qui ne doivent jamais se trouver dans un système de surveillance.
• Des quantités considérables de données sont collectées auprès de chaque utilisateur, ce qui entraîne une charge supplémentaire pour ces derniers.
• Typiquement, un faible rapport signal à bruit dans les données collectées.
• L'absence de modèle sémantique normalisé dans les données empêche Instana d'optimiser l'accès à ces données pour vous.

Pour ces raisons, le site Instana ne recueille automatiquement aucune donnée concernant WebSockets. Toutefois, certains clients implémentent des mécanismes de demande ou de réponse et d'abonnement sur WebSockets. Pour plus d'informations, consultez la documentation sur les événements personnalisés API. Grâce à l'événement personnalisé « API », vous pouvez mettre en place une corrélation côté serveur pour les systèmes de requêtes ou de réponses de type « WebSocket-based ».

Instana JavaScript L'agent exploite les XMLHttpRequestfetch API des navigateurs Web pour identifier les requêtes effectuées par les sites Web. Cette configuration fait apparaître l'agent JavaScript ( eum.js ) comme initiateur dans les outils de développement du navigateur Web, comme le montre la capture d'écran suivante. L'agent Instana JavaScript semble être à l'origine de ces appels. Cependant, ces appels sont effectués par le site web surveillé par Instana.

L'agent JavaScript de Instana communique directement uniquement avec les serveurs définis dans l'extrait de code JavaScript, tels qu'ils apparaissent dans l'interface utilisateur Instana ou tels qu'ils ont été adaptés pour les déploiements sur site.

Deux possibilités :

1. Les visiteurs ne peuvent pas télécharger notre agent JavaScript. Dans ce cas, aucune donnée ne peut être collectée.
2. Les demandes de transmission de données envoyées par les visiteurs de votre site Web à nos serveurs ne peuvent pas être effectuées. Instana Dans ces cas-là, le système ne tente pas de renvoyer le message, et Instana ne conserve pas non plus les données en vue d'une livraison ultérieure.

On pose souvent des questions sur l'extrait « JavaScript », sa structure et l'approche choisie par l' Instana. Le fragment est soigneusement conçu pour équilibrer les besoins des clients. Les sections suivantes apportent quelques éclaircissements sur ces questions.

La fonctionnalité « JavaScript » de Instana prend en charge la journalisation de débogage, que vous pouvez utiliser pour obtenir des informations supplémentaires sur les erreurs de configuration, la transmission des données, les limites et bien plus encore. Pour activer la journalisation de débogage pour l'agent JavaScript, remplacez l' URL par l'agent JavaScript dans l'extrait de code de surveillance.

Modifiez le fragment de surveillance et remplacez les références de fichier eum.min.js par eum.debug.js, comme indiqué dans le fragment suivant.

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

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

L'agent d' JavaScript s impose une limite de collecte de données par onglet de navigateur afin de protéger les systèmes d' Instana s et les utilisateurs contre les erreurs de configuration et les boucles de surveillance. Les limites sont les suivantes :

• Toute balise transmise (sauf pour les ressources de page, les règles s'appliquent en plus des règles plus spécifiques mentionnées plus loin)
  • max par 10 s : 128
  • max par 10 min: 4096
  • Nombre maximal de chargements par page : 8096
• Modifications de page
  • max par 10 s : 32
  • Max par 10 min: 128
• Événements personnalisés
  • max par 10 s : 32
  • Max par 10 min: 128
• HTTP les balises d'appel déclenchées à l'aide de window.fetch
  • max par 10 s : 32
  • max par 10 min: 256
• HTTP les balises d'appel déclenchées à l'aide de window.XMLHttpRequest
  • max par 10 s : 32
  • max par 10 min: 256

Par défaut, l'agent Instana JavaScript n'inclut pas de données permettant d'identifier de manière unique les utilisateurs. De plus, l'agent Instana JavaScript n'utilise pas non plus de techniques telles que l'empreinte numérique des appareils ou des navigateurs.

Les données spécifiques à l'utilisateur peuvent être mises à la disposition d' Instana s en utilisant l' API utilisateur.

Les clients peuvent configurer l ' API -utilisateur afin qu'elle transmette des informations d'identification de l'utilisateur à Instana. Ces informations sont utilisées uniquement pour fournir les fonctions visibles dans le produit. Instana n'interprète pas ces données, de quelque façon que ce soit, et ne les met pas non plus en corrélation entre plusieurs clients.

Instana prend en charge les demandes de suppression occasionnelles, par exemple pour se conformer au RGPD. Si vous prévoyez de recevoir des demandes de suppression fréquentes ou périodiques, transmettez plutôt des données anonymisées à Instana (par exemple, des identifiants d'utilisateur hachés).

Les IP sont anonymisées. Par défaut, le dernier octet des adresses IPv4 et les 80 derniers bits des adresses IPv6 sont définis sur zéro. Il est possible de configurer des règles d'anonymisation plus strictes via l'onglet « Configuration » du tableau de bord d'un site web, dans l'interface utilisateur d' Instana.

L'agent JavaScript n'a pas accès aux adresses IP. Les adresses IP utilisateur sont accessibles via les connexions réseau qu'elles établissent aux serveurs. Les données reçues des agents JavaScript sont enrichies par les serveurs avec des adresses IP anonymisées.

Le suivi du site lui-même n'utilise pas directement les cookies.

Par défaut, l'agent Instana JavaScript n'utilise pas les technologies localStorage sessionStorage et. Toutefois, localStorage est utilisé lorsque vous activez le suivi de session. Par défaut, la fonctionnalité de suivi des sessions n'est pas disponible dans l'agent Instana JavaScript.

L'emplacement de stockage des données de surveillance de site Web dépend de l'installation spécifique d'Instana. En règle générale, les données sont stockées dans le cloud d'Amazon ou d' Google, soit dans leur zone européenne, soit dans leur zone américaine. Vous pouvez déterminer où vos données sont stockées en vous basant sur l' reportingUrl s indiquées dans l'extrait de code de suivi Instana et sur la liste des points de terminaison de rapport pour les agents JavaScript.

Les utilisateurs téléchargent l'agent JavaScript en utilisant le réseau de diffusion de contenu (CDN) fourni par Akamai. Akamai recueille et stocke les données personnelles relatives aux opérations de service. Pour plus d'informations, consultez la FAQ d'Akamai.

L'agent JS d' Instana est chargé de manière asynchrone à partir de eum.instana.io et peut être chargé à l'aide de la balise HTTP. Vérifiez que le chargement de scripts à partir de ce domaine est possible.

Les données sont transmises à Instana lors du chargement d'images, des requêtes GET vers HTTP et des requêtes vers POST (avec XMLHttpRequest). Les origines utilisées pour la transmission des données sont affichées dans le fragment de suivi.

La définition de stratégie de sécurité de contenu (Content-Security-Policy) suivante indique les éléments requis pour le produit SaaS d'Instana :

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

Pour la version auto-hébergée, l'agent JS d' Instana est chargé à partir du backend auto-hébergé plutôt que depuis eum.instana.io le domaine. Pour charger le script de l'agent, les valeurs de Content-Security-Policy définition précédentes telles que *.instana.io doivent être remplacées par le domaine réseau spécifique utilisé par le backend auto-hébergé.

La politique du même domaine est l'un des principes fondamentaux de la sécurité des sites web. Chaque site Web est soumis à la politique car tous les navigateurs Web l'appliquent. En tant que fournisseur de services de surveillance de sites web, Instana ne peut pas contrôler la sécurité de votre site web ou de votre navigateur. Instana ne peut fonctionner que dans le cadre des contraintes de sécurité imposées. Malheureusement, cela limite les capacités de surveillance d' Instana.

• Les navigateurs limitent l'accès aux messages d'erreur et aux traces de pile aux scripts de même origine.
• Les navigateurs limitent les en-têtes HTTP autorisés pour les demandes d'origine croisée. Par conséquent, la corrélation dorsale n'est pas toujours possible.

Pour activer ces fonctionnalités lorsque plusieurs origines sont impliquées, vous pouvez utiliser le partage de ressources entre origines ( CORS ). CORS est un mécanisme qui définit des exceptions contrôlées au mécanisme de sécurité de la politique de même origine. L'image suivante décrit en détail ce qui doit être fait pour répondre aux restrictions imposées par la règle de la même origine.

Pour plus d'informations sur les mécanismes de corrélation en arrière-plan d' Instana, ainsi que sur l'impact de la sécurité Web sur ces mécanismes, consultez la section « Corrélation en arrière-plan ».

La disponibilité des informations sur les temps réseau, les statistiques de mise en cache et les tailles d'actifs repose sur des capacités de temporisation des ressources. Ces fonctions sont disponibles dans les navigateurs Web les plus modernes lorsqu'elles sont autorisées par la règle de même origine.

Pour obtenir des informations sur l'origine des ressources inter-origines (par exemple, l'origine https://cdn.example.com:443 d'un document HTML chargé depuis https://example.com:443), vous pouvez utiliser l'en-tête Timing-Allow-OriginHTTP. L'image suivante montre comment définir l'en-tête. En outre, pour plus d'informations, voir la spécification de temporisation des ressources.

Les sites Web qui incorporent de nombreux scripts tiers rencontrent généralement un nombre constant d'erreurs de script. Script Error indique une erreur JavaScript dans les scripts tiers. Pour des raisons de sécurité, les navigateurs Web limitent l'accès aux erreurs JavaScript des scripts tiers en remplaçant le message d'erreur réel par Script Error et en effaçant la trace de pile.

Sur le Web, vous pouvez utiliser les méthodes suivantes pour obtenir des informations sur Script Error:

• Vous pouvez demander aux navigateurs Web d'exposer les messages d'erreur et les traces de pile en indiquant que le script tiers ne contient pas de données sensibles.
• Vous pouvez utiliser des échappatoires dans le modèle de sécurité Web (déconseillé et non garanti).

Il est recommandé d'utiliser la première option car il s'agit de la méthode conçue et appropriée pour obtenir des informations Script Error . Pour implémenter la première option, procédez comme suit:

• Ajoutez un attribut crossorigin="anonymous" aux balises de script.
• Assurez-vous que la réponse HTTP contenant la source du script envoie un en-tête de réponse Access-Control-Allow-Origin.

Lorsque vous analysez les avertissements de cookie de même site, vous devez différencier les deux cas suivants:

• Les utilisateurs connectés au produit d' Instana (qu'il s'agisse d'une version SaaS ou auto-hébergée) pour lesquels des cookies ont été enregistrés en rapport avec leur connexion et leur utilisation du produit d' Instana.
• Les visiteurs de votre site Web qui n'ont pas de lien avec Instana et qui généralement n'ont pas connaissance d'Instana.

Pour le premier groupe (c'est-à-dire les utilisateurs d' Instana ), Instana et ses partenaires installent des cookies. Les navigateurs Web transmettent ces cookies aux serveurs d'Instana dans le cadre de la surveillance de site Web. Instana Les serveurs ne s'attendent jamais à ce que ces cookies existent à des fins de surveillance du site web. Par conséquent, le blocage des cookies par les navigateurs Web n'est pas un problème.

Pour ce dernier groupe (c'est-à-dire les visiteurs de votre site web), le cookie « SameSite » ne présente aucun problème connu. Instana's

Le fournisseur de CDN installe un cookie avec une configuration de cookie SameSite=Lax valide.

Recherchez les éventuels problèmes de cookie SameSite à l'aide d'une fenêtre de navigateur privée ou incognito. Grâce à cette fenêtre de navigateur incognito ou InPrivate , vous pouvez découvrir votre site Web comme un visiteur.

La traduction de trace de pile JavaScript fournit des traces de pile claires et plus exploitables dans Instana.

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

After:
at ProductDetails.js 26:11
 

Les lignes de trace de pile non traduites présentent l'inconvénient suivant : les erreurs ne sont pas exploitables. Les développeurs travaillent avec de nombreux fichiers (généralement de petite taille). Pour des raisons de performances, ces fichiers sont transmis aux navigateurs des utilisateurs sous une forme regroupée et optimisée, ce qui rend les noms de fichiers, les numéros de ligne et de colonne dans les traces de pile illisibles pour l'utilisateur et inutilisables.

Avec une trace de pile traduite, il est clair que l'erreur qui se produit dans …/main.b1510333.chunk.js:1:1559 est en fait at ProductDetails.js 26:11.

La traduction s'effectue à l'aide de cartes de source. Les mappes source nous permettent de convertir les traces de pile non exploitables en traces de pile exploitables. Plus précisément, elles nous permettent de traduire des références à des fichiers, des noms, des lignes et des colonnes dans leurs équivalents réels de code source.

Pour ce faire, « Instana » exécute les étapes suivantes :

1. L'agent JavaScript signale les erreurs JavaScript aux serveurs d'Instana. Par exemple, supposons que la trace de pile contienne la ligne at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559.
2. Les serveurs de Instana tentent de télécharger le fichier JavaScript afin d'identifier la carte source associée à ce fichier.
3. La réponse de l' HTTP ur est analysée, et Instana recherche les références aux cartes de source.
4. Lorsqu'un fichier de carte source est référencé, Instana télécharge ce fichier à l'aide d'une requête GET HTTP ou effectue une recherche parmi les fichiers de carte source téléchargés par l'utilisateur.
5. Lorsque le téléchargement ou la recherche aboutit, le fichier de mappe source est utilisé pour traduire les références de fichier, de nom, de ligne et de colonne.

Voir les étapes suivantes pour la ligne de trace de pile at http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js:1:1559.

1. Une erreur est signalée aux serveurs d'Instana.
2. Les serveurs d'Instana envoient une demande HTTP GET à http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.
3. La référence de mappe de source //# sourceMappingURL=main.b1510333.chunk.js.map se trouve dans le fichier JavaScript.
4. Le fichier de carte de http://shop-demo-app.instana.io/static/js/main.b1510333.chunk.js.map sources est téléchargé à l'aide d'une requête GET HTTP ou se trouve dans les fichiers de cartes de sources téléchargés.
5. La mappe de source est analysée syntaxiquement et la trace de pile devient lisible.

Lorsque Instana détecte une trace de pile, il envoie automatiquement des requêtes HTTP pour récupérer les fichiers JavaScript et les fichiers de carte de source. L'appel suivant montre la représentation la plus proche des appels effectués:

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}}
 

Vous pouvez utiliser la commande précédente pour déterminer la configuration dont Instana a besoin pour télécharger les fichiers JavaScript et les fichiers de carte source depuis vos serveurs. Les requêtes « HTTP » sont émises depuis des serveurs hébergés sur AWS ( Amazon Web Services ) ou Google Cloud. Les mécanismes avancés de détection des bots pourraient bloquer les requêtes provenant de AWS ou Google Cloud. En conséquence, pensez à configurer les en-têtes supplémentaires qu' Instana doit envoyer à vos serveurs afin de contourner les mécanismes de détection des bots.

Les serveurs Instana envoient des requêtes à partir des serveurs AWS ou Google Cloud. Par conséquent, les fichiers « JavaScript » et «source map» sont accessibles sur Internet. Vous devez également vous assurer que votre serveur dispose d'une configuration TLS opérationnelle avec une chaîne de certificats complète. Vous pouvez vérifier s'il existe des problèmes liés à l' TLS en utilisant le test gratuit « SSL » proposé par SSL Labs/Qualys ou en exécutant les commandes suivantes :

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

Pour plus d'informations sur le téléchargement de fichiers de carte source vers Instana, consultez la page « Téléchargement de fichiers de carte source vers Instana ».

Vous pouvez choisir l'une des deux options suivantes pour vous assurer que votre site web charge toujours la dernière version du script EUM d' Instana :

• Hébergez le script sur votre propre CDN ou serveur

  Vous pouvez télécharger la dernière version du script EUM d' Instana, puis l'héberger sur votre propre CDN ou serveur afin de garder un contrôle total sur les mises à jour sans avoir à modifier le code de votre site web.

1. Téléchargez la dernière version du script sur Instana.
2. Téléchargez le script sur votre propre domaine ou sur un CDN (par exemple, https://yourdomain.com/js/eum.min.js).
3. Intégrez le script dans votre code HTML.

   <script defer src="https://yourdomain.com/js/eum.min.js"></script>

• Utilisez l'adresse Instana URL sans indiquer de version
  Vous pouvez accéder au script EUM d' Instana directement depuis le site officiel InstanaURL sans préciser de version :

  <script defer src="https://eum.instana.io/eum.min.js"></script>

  Si vous accédez au script EUM d' Instana directement depuis le site officiel InstanaURL sans préciser de version, le navigateur charge automatiquement la dernière version.

  Avec cette méthode, vous ne pouvez pas utiliser l' SRI e pour vérifier l'intégrité du script.