Certains problèmes s’annoncent bruyamment. D’autres se cachent dans l’écart entre « ça marche sur ma machine » et « ça marche pour tout le monde ». Celui-ci vivait fermement dans ce vide.

Le symptôme semblait simple : certains utilisateurs ne pouvaient pas charger nos formulaires alimentés par HubSpot. La cause était suffisamment raisonnable ; Les paramètres de confidentialité du navigateur et les bloqueurs de suivi intervenaient et refusaient de laisser passer quoi que ce soit qui ressemblait à un traceur. Mais dès que nous avons essayé de mesurer le problème, nous avons heurté un mur qui a transformé une solution apparemment rapide en quelque chose de bien plus intéressant.

L’outil que nous utilisions normalement pour détecter ces défaillances, la surveillance réelle des utilisateurs, était bloqué par les mêmes protections qui cassaient les formulaires. Notre New Relic RUM ressemblait à un traceur parce que, eh bien, c’en est un. Nous essayions en fait d’installer un détecteur de fumée dans une pièce où la fumée déclenchait un dispositif qui désactivait les détecteurs.

Cet article explique comment nous avons contourné ce paradoxe : proxyer New Relic via notre propre domaine propriétaire pour qu’il ne ressemble plus à un suivi tiers, gérer les complications liées aux sous-domaines, garder nos données de télémétrie propres, et enfin construire une détection fiable des pannes HubSpot ; même les silencieux où rien ne se charge du tout. En cours de route, nous aborderons le câblage CDN et du répartiteur, les tests dans un environnement de développement rapide, le déploiement via Cloud Manager, ainsi que la période de burn-in qui transforme une solution astucieuse en un indicateur fiable.

Une note importante fournie par New Relic:

Lorsque vous utilisez la méthode proxy, il est important de vous assurer que vous en avez le droit de le faire, en fonction de toute obligation contractuelle, réglementaire ou juridique que vous pourriez avoir envers vos utilisateurs finaux et/ou visiteurs du site.

Faire de la nouvelle relique une première partie

Au lieu de charger New Relic directement depuis ses terminaux standards, la solution a été de tout proxy via notre propre domaine. Cela déplace les requêtes de tiers → de première partie, ce qui évite la plupart des protections de suivi.

Deux points de terminaison ont été introduits :

• /nr/agent/ → dessert l’agent du navigateur New Relic
• /nr/data/ → reçoit des requêtes de balises (télémétrie)

Codage dur des valeurs de proxy

La façon la plus simple de configurer un proxy de première partie dans New Relic est de définir les chemins proxy directement dans NREUM.init comme chaînes statiques. Vous pointez assets vers l’URL qui sert les blocs de script de l’agent New Relic, et beacon vers l’URL qui reçoit les données de télémétrie ; les deux sont acheminés via votre propre domaine plutôt que par le CDN de New Relic.

proxy: {
  assets: 'www.arborydigital.com/nr/agent',
  beacon: 'www.arborydigital.com/nr/data'
}

C’est facile à raisonner. Les chemins sont visibles d’un coup d’œil, ne nécessitent pas de logique d’exécution et sont définis avant l’initialisation de l’agent ; Il n’y a donc aucun souci de timing quant à savoir si la configuration atterrit dans le temps. Tant que votre serveur a ces deux routes configurées et que les transferts correctement vers New Relic, ça fonctionne. Pour les sites situés sur un seul domaine sans trafic de sous-domaine, c’est souvent tout ce dont vous avez besoin.

Proxy entre sous-domaines

Lorsque votre site utilise des sous-domaines, comme blog.arborydigital.com, un seul chemin proxy codé en dur ne suffit pas. Chaque sous-domaine fonctionne à partir de sa propre origine, et les règles de sécurité du navigateur signifient qu’une requête de blog.arborydigital.com vers un chemin proxy hébergé sur www.arborydigital.com est techniquement une requête cross-origin. Bien que cela puisse fonctionner, cela va à l’encontre d’une partie de l’objectif du proxying first-party, qui est d’envoyer la télémétrie par la même origine en laquelle le navigateur a déjà confiance.

Pour résoudre cela, la configuration proxy peut être définie dynamiquement à l’exécution. Plutôt que de pointer vers un domaine fixe, le script vérifie window.location.hostname pour déterminer sur quelle origine la page s’exécute actuellement. Si ce nom d’hôte correspond à votre domaine racine ou à l’un de ses sous-domaines, les points de terminaison proxy sont construits en utilisant window.location.origin — ce qui signifie que blog.arborydigital.com acheminera son trafic New Relic via blog.arborydigital.com/nr-assets/ et blog.arborydigital.com/nr-beacon, tandis que www.arborydigital.com utilise ses propres chemins équivalents.

Cette approche exige que chaque sous-domaine dispose des routes proxy correspondantes configurées au niveau serveur ou CDN. La configuration de l’agent New Relic, y compris les champs beacon et errorBeacon dans NREUM.info, doit également être mise à jour pour refléter le nom d’hôte actuel afin que l’agent sache où rapporter les données.

ajax.deny_list

L’agent navigateur New Relic est configuré pour acheminer toute la télémétrie via un blog.arborydigital.com/nr/data proxy first-party au lieu des serveurs propres de New Relic bam.nr-data.net. Cela évite les bloqueurs qui ciblent les domaines NR connus.

Un effet secondaire de cela : l’agent NR surveille toutes les requêtes XHR/fetch sortantes sur la page pour les capturer comme événements AJAX ; y compris ses propres appels de balises envoyés à blog.arborydigital.com/nr/data. Sans la liste de refus, NR enregistrerait ses propres POSTs de télémétrie comme événements AJAX, qui seraient ensuite envoyés sous forme de télémétrie supplémentaire, polluant les données AJAX avec le trafic NR interne.

Pour corriger cela et éviter que vos débits de données ne paraissent sortis d’Akira, nous pouvons bloquer ces appels balises en utilisant le joker intégré. Cela finirait par ressembler à blog.arborydigital.com/nr/data/* . Lorsque cela est mis en œuvre, New Relic indique à New Relic de ne pas créer une entrée ajax lorsque les données du navigateur sont capturées avec succès. Toutes les informations contenues dans le POST sont conservées et il n’y aura plus d’entrée Ajax redondante.

Utilisation d’un paramètre de requête comme drapeau de caractéristique

Verrouiller le proxy derrière ?proxy=yes vous permet de tester le comportement en production sans affecter d’autres visiteurs. Quiconque n’a pas ce paramètre dans son URL contourne complètement le blocage et, dans ce cas, New Relic ne s’activerait pas. Vous ouvrez un onglet avec le paramètre ajouté, vous confirmez dans DevTools que les requêtes passent par votre propre domaine, et une fois que tout est en ordre, vous supprimez la condition du script. À partir de là, la vérification du nom d’hôte prend le relais et le proxy s’active automatiquement pour tout le trafic.

Mise en œuvre du nouvel agent relique

Vous pouvez trouver l’extrait JavaScript par :

1. Connectez-vous à New Relic One (one.newrelic.com)
2. Naviguer dans le navigateur → ajouter des données → Surveillance du navigateur
3. Sélectionnez l’application (ID d’application) ou créez-en une nouvelle
4. Choisissez la méthode de déploiement Copier/Coller avec le chargeur SPA
5. Copiez l’extrait complet généré <script>

Lorsque vous ajoutez le script RUM à votre dépôt, vous voudrez vous assurer qu’il vit dans son propre fichier newrelic.js afin que nous puissions l’appeler à l’intérieur de head.html

• Une remarque : <script src="/scripts/newrelic.js"></script> doit être le premier script que vous initialisez, immédiatement après toute meta balise.

Une fois cela fait, vous devrez ajouter les paramètres spécifiques du proxy dans cette chaîne. Dans le bloc NREUM.init du extrait généré, ajoutez la configuration proxy :

proxy: {
  assets: 'www.arborydigital.com/nr/agent',
  beacon: 'www.arborydigital.com/nr/data'
}

Câblage du proxy (EDS / couche CDN)

Le proxy lui-même se trouve à la couche CDN. L’objectif est simple : transmettre les requêtes de /nr/* entrantes vers les véritables points de terminaison de New Relic.

Le sélecteur d’origine doit exclure /nr/agent/* et /nr/data/* afin que ces requêtes ne soient pas acheminées vers l’origine des services de livraison Edge. À la place, elles se retrouvent dans l’origine de publication AEM par défaut où s’exécutent les règles Apache ProxyPass. À l’intérieur de votre cdn.yaml cela ressemblerait à ceci :

originSelectors:
  rules:
    - name: arbory-da
      when:
        allOf:
          - reqProperty: path
            like: /*
          # ...existing exclusions...
          - reqProperty: path
            doesNotMatch: /nr/agent/*
          - reqProperty: path
            doesNotMatch: /nr/data/*
      action:
        type: selectOrigin
        originName: arbory-da

Vous devrez également modifier votre fichier VirtualHost (.vhost) :

# New Relic Browser Agent Proxy
SSLProxyEngine on

# Proxy New Relic agent JS chunks (lazy-loaded scripts)
<Location "/nr/agent/">
    ProxyPass "https://js-agent.newrelic.com/"
    ProxyPassReverse "https://js-agent.newrelic.com/"
    RewriteEngine Off
</Location>

# Proxy New Relic beacon/telemetry data
<Location "/nr/data/">
    ProxyPass "https://bam.nr-data.net/"
    ProxyPassReverse "https://bam.nr-data.net/"
    RewriteEngine Off
</Location>

Détails clés :

• SSLProxyEngine on requis car les cibles en amont sont HTTPS
• RewriteEngine Off empêche les règles de réécriture par défaut de l’AEM d’interférer avec les chemins de proxy

Détection des pannes HubSpot (même quand rien ne charge)

Une fois New Relic débloqué, le problème suivant est que les pannes de HubSpot ne génèrent pas toujours des erreurs évidentes ; Surtout quand le script ne se charge jamais.

Pour gérer cela, deux chemins de détection ont été ajoutés :

1. Échec de charge du script

Détectez quand le script HubSpot ne se charge pas complètement :

script.onerror = () => {
  reportError('HubSpot script failed to load');
};

2. Défaillance à l’exécution

Détecter les erreurs après le chargement du script :

window.addEventListener('error', (e) => {
  if (e.filename && e.filename.includes('hsforms')) {
    reportError('HubSpot runtime error');
  }
});

Les deux alimentent la même fonction de rapport :

function reportError(errorMsg) {
  console.error(errorMsg);
  if (window.newrelic) {
    window.newrelic.noticeError(new Error(errorMsg));
  }
}

Vérifier que cela fonctionne réellement

Une fois tout câblé, la validation est assez simple mais reste importante. Les tests devraient se concentrer sur les navigateurs avec une protection/extensions strictes de suivi activées, où vous devriez voir les formulaires HubSpot ne pas se charger, des erreurs apparaître dans la console, et ces mêmes erreurs apparaître dans New Relic. Dans DevTools, confirmez que l’agent se charge depuis /nr/agent/ et que les balises sont envoyées à /nr/data/, sans qu’aucune requête ne soit envoyée vers des domaines tiers comme bam.nr-data.net. Dans New Relic, vérifiez que des erreurs apparaissent dans le tableau de bord, que les événements correspondent aux échecs déclenchés et que les sessions sont enregistrées. Si des sessions manquent toujours, il est probable que le proxy ne soit pas configuré correctement

Tests avec un environnement de développement rapide (RDE)

Si vous êtes l’un de nos lecteurs habituels, vous vous souvenez peut-être d’un article que j’ai écrit sur l’utilisation d’un environnement de développement rapide (RDE) pour tester les modifications de configuration des CDN. Lors de l’essai de ce nouveau rhum, j’ai utilisé exactement ça !

En suivant les meilleures pratiques, le développement aura lieu sur une branche. Pour vous assurer que vos modifications sont faites sur une branche plutôt que sur la principale, vous devrez faire des modifications supplémentaires à cdn.yaml :

    origins:
     # ...existing code...
      - name: arbory-da
        domain: (BRANCH_NAME)--(rest of domain).aem.live
        forwardHost: false

Il y a deux commandes principales dont vous aurez besoin une fois que vous serez prêt à pousser vos modifications :

aio aem:rde:install -t env-config ./config : Cela va mettre en avant le contenu de votre /config et les exclusions que nous avons faites plus tôt.

aio aem:rde:install -t dispatcher-config ./dispatcher/src : cela transmettra le contenu de votre /src— à savoir les changements dans la configuration de votre répartiteur .vhost .

Puisque le RDE fonctionne sur un domaine différent de vos autres environnements, vous devrez spécifier une nouvelle URL à travers laquelle proxyer. Sinon, il sera considéré comme un domaine tiers :

proxy: { 
   assets: 'your-rde-domain.aem.live/nr/agent', 
   beacon: 'your-rde-domain.aem.live/nr/data' 
}

Déploiement du pipeline Cloud Manager (Dev + Prod)

Le déploiement via Adobe Cloud Manager demande un peu plus de coordination qu’un changement de code classique. Le comportement du proxy dépend de plusieurs couches (CDN, dispatcher et navigateur), et toutes doivent être alignées au sein du même déploiement.

Comment fonctionne le déploiement

Une exécution en pipeline va :

• Construisez et validez l’application
• Configuration du répartiteur de déploiement (incluant .vhost, filtres et règles proxy)
• Déploiement de la configuration CDN (cdn.yaml, y compris les sélecteurs d’origine)
• Invalider le cache et promouvoir des changements dans l’environnement

Pour cette implémentation, les changements du répartiteur et du CDN sont étroitement couplés. Le proxy ne fonctionnera pas correctement à moins que les deux ne soient présents et cohérents.

Modifications requises (doivent être déployées ensemble)

Les mises à jour suivantes doivent être incluses dans la même exécution de pipeline :

• CDN (cdn.yaml)

  • Excluez /nr/agent/* et /nr/data/* du routage Edge Delivery

• Répartiteur (.vhost)

  • ProxyPass / ProxyPassReverse règles pour les points de terminaison de New Relic
  • SSLProxyEngine on
  • Désactiver les réécritures pour les chemins de proxy

• Filtres de répartiteur

  • Règle explicite de permettre pour /nr/*

Si l’un de ces éléments manque ou est désynchronisé, les requêtes seront soit mal acheminées, bloquées, soit reviendront vers des points d’accès tiers.

Période de combustion

Maintenant que le proxy a été configuré et déployé, vous devrez avoir une période de burn-in pour vous assurer que tout fonctionne comme prévu. Puisque les pannes dépendent de conditions réelles de l’utilisateur, comme les paramètres de confidentialité, les extensions et le comportement réseau, il faudra un certain temps pour avoir une vision complète.

Une fois que vous avez pris le temps de vérifier que les données sont correctement ingérées, l’étape suivante consiste à examiner ces données ; Valider les taux d’erreur par rapport au trafic attendu, assurer la couverture entre environnements et affiner les éventuels écarts (événements manqués, domaines incohérents ou blocages de cas particuliers). À partir de là, vous pouvez commencer à considérer cela comme un indicateur fiable, une tendance au fil du temps, et l’utiliser pour quantifier un impact réel sur les utilisateurs plutôt que des rapports anecdotiques.

Dernières réflexions

Ce qui avait commencé comme « ajouter un peu de surveillance » s’est transformé en une visite des modèles de confidentialité des navigateurs, du proxy de première partie, du routage CDN, et de l’art subtil de mesurer quelque chose qui, par conception, résiste à être mesuré.

L’essentiel mérite d’être conservé : lorsque ce que vous essayez d’observer et ce que vous observez sont tous deux considérés comme indésirables par le navigateur, vous ne pouvez pas vous en sortir avec des outils standards. Vous devez modifier la façon dont le navigateur perçoit votre télémétrie. Faire passer New Relic par le biais de notre domaine de première partie a fait exactement cela — transférer les requêtes de tiers vers de première partie, contourner les blocages, et nous offrir une véritable fenêtre sur des échecs auparavant invisibles.

Mais le proxy ne représentait que la moitié du combat. La détection des échecs HubSpot, en particulier les cas silencieux où le script ne se charge jamais, nécessitait une gestion délibérée à la fois des erreurs de chargement et d’exécution des erreurs, tous canalisés dans un seul chemin de rapport. Et rien de tout cela ne compte tant que les données ne se prouvent pas lors de la période de burn-in, où les conditions réelles de l’utilisateur remplacent les hypothèses par des preuves.

La récompense est la possibilité d’échanger des anecdotes contre des chiffres. Au lieu de « certains utilisateurs disent que le formulaire ne se chargera pas », nous avons désormais un signal mesurable et tendanceur qui quantifie l’impact réel sur les utilisateurs. Parfois, la solution la plus précieuse n’est pas celle qui résout le problème directement ; C’est celle qui vous permet enfin de le voir clairement. Et à partir de là, vous pouvez réellement commencer à l’améliorer.

Dépannage

À propos de l’auteur

Tu as aimé ce que tu as entendu ? Vous avez des questions sur ce qui vous convient ? Nous serions ravis de discuter ! Contactez-nous

Plus d’articles que vous pourriez aimer