Manche Probleme kündigen sich laut an. Andere verstecken sich in der Lücke zwischen "es funktioniert auf meinem Rechner" und "es funktioniert für alle." Dieser lebte fest in dieser Lücke.

Das Symptom schien einfach: Einige Nutzer konnten unsere HubSpot-gesteuerten Formulare nicht laden. Die Ursache war durchaus vernünftig; Browser-Datenschutzeinstellungen und Tracking-Blocker griffen ein und weigerten sich, irgendetwas, das einem Tracker ähnelte, durchzulassen. Doch in dem Moment, als wir versuchten, das Problem zu messen , stießen wir auf eine Wand, die aus einer scheinbar schnellen Lösung etwas viel Interessanteres machte.

Das Werkzeug, zu dem wir normalerweise greifen würden, um diese Fehler zu erkennen, die echte Benutzerüberwachung, wurde von genau denselben Schutzmaßnahmen blockiert, die die Formulare gebrochen haben. Unser New Relic RUM sah aus wie ein Tracker, weil es eben einer ist . Wir versuchten im Grunde, einen Rauchmelder in einem Raum zu installieren, in dem Rauch ein Gerät auslöste, das Rauchmelder deaktivierte.

Dieser Artikel erklärt, wie wir dieses Paradoxon umgangen sind: indem wir New Relic über unsere eigene First-Party-Domain proxyen, damit es nicht mehr wie Drittanbieter-Tracking aussieht, die Komplikationen mit Subdomains bewältigen, unsere Telemetriedaten sauber halten und schließlich eine zuverlässige Erkennung von HubSpot-Ausfällen aufbauen; Sogar die stillen Läden, in denen überhaupt nichts geladen wird. Dabei behandeln wir die Verkabelung von CDN und Dispatcher, Tests in einer schnellen Entwicklungsumgebung, die Bereitstellung über Cloud Manager und die Burn-in-Phase, die eine clevere Workaround in eine vertrauenswürdige Kennzahl verwandelt.

Ein wichtiger Hinweis von New Relic:

Wenn Sie die Proxy-Methode verwenden, ist es wichtig sicherzustellen, dass Sie das Recht dazu haben, basierend auf vertraglichen, regulatorischen oder anderen rechtlichen Verpflichtungen gegenüber Ihren Endnutzern und/oder Websitebesuchern.

Neue Relikt als Erstpartei erschaffen

Anstatt New Relic direkt von seinen Standard-Endpunkten zu laden, bestand die Lösung darin, alles über unsere eigene Domain zu proxyen. Dadurch werden die Anfragen von Drittanbietern → Erstanbieter verlagert, was die meisten Tracking-Schutzmaßnahmen umgeht.

Zwei Endpunkte wurden eingeführt:

• /nr/agent/ → bedient den New Relic Browseragenten
• /nr/data/ → erhält Beacon-(Telemetrie-)Anfragen

Festkodierung von Proxy-Werten

Die einfachste Möglichkeit, First-Party-Proxying in New Relic zu konfigurieren, besteht darin, die Proxy-Pfade direkt in NREUM.init als statische Strings einzustellen. Man zeigt assets auf die URL, die die New Relic Agent-Skript-Chunks bereitstellt, und beacon auf die URL, die Telemetriedaten empfängt; beide wurden über deine eigene Domain geleitet und nicht über das CDN von New Relic.

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

Das ist leicht zu überlegen. Die Pfade sind auf einen Blick sichtbar, benötigen keine Laufzeit-Logik und werden vor der Initialisierung des Agenten gesetzt; Es gibt also keine zeitliche Bedenken, ob die Konfiguration rechtzeitig landet. Solange dein Server diese beiden Routen konfiguriert und korrekt an New Relic weiterleitet, funktioniert es. Für Seiten, die auf einer einzigen Domain ohne Subdomain-Verkehr leben, ist das oft alles, was man braucht.

Proxying über Unterdomänen hinweg

Wenn Ihre Seite Subdomains wie blog.arborydigital.comverwendet, reicht ein einzelner fest codierter Proxy-Pfad nicht aus. Jede Subdomain arbeitet von ihrem eigenen Ursprung aus, und Browser-Sicherheitsregeln bedeuten, dass eine Anfrage von blog.arborydigital.com an einen auf www.arborydigital.com gehosteten Proxy-Pfad technisch gesehen eine Cross-Origin-Anfrage ist. Auch wenn das funktionieren mag, widerspricht es einem Teil des Zwecks von First-Party-Proxying, nämlich Telemetrie über denselben Ursprung zu senden, dem der Browser bereits vertraut.

Um dies zu lösen, kann die Proxy-Konfiguration zur Laufzeit dynamisch eingestellt werden. Anstatt auf eine feste Domäne zu verweisen, prüft das Skript window.location.hostname , um zu bestimmen, auf welchem Ursprung die Seite aktuell läuft. Wenn dieser Hostname mit Ihrer Root-Domain oder einer ihrer Unterdomänen übereinstimmt, werden die Proxy-Endpunkte mit window.location.origin konstruiert – das heißt, blog.arborydigital.com seinen New-Relic-Verkehr über blog.arborydigital.com/nr-assets/ und blog.arborydigital.com/nr-beaconleitet, während www.arborydigital.com eigene äquivalente Pfade verwendet.

Dieser Ansatz erfordert, dass jede Unterdomäne die entsprechenden Proxy-Routen auf Server- oder CDN-Ebene konfiguriert hat. Die New-Relic-Agentenkonfiguration, einschließlich der Felder beacon und errorBeacon in NREUM.info, muss ebenfalls aktualisiert werden, um den aktuellen Hostnamen widerzuspiegeln, damit der Agent weiß, wo er Daten melden muss.

ajax.deny_list

Der New Relic-Browseragent ist so konfiguriert, dass er alle Telemetrien über einen First-Party-Proxy- blog.arborydigital.com/nr/data anstatt über die eigenen Server von New Relic bam.nr-data.netzu leiten. Dies vermeidet Blocker, die bekannte NR-Domänen anvisieren.

Ein Nebeneffekt davon: Der NR-Agent überwacht alle ausgehenden XHR/Fetch-Anfragen auf der Seite, um sie als AJAX-Ereignisse zu erfassen; einschließlich eigener Beacon-Rufe, die nach blog.arborydigital.com/nr/datagehen. Ohne die Ablehnungsliste würde NR seine eigenen Telemetrie-POSTs als AJAX-Ereignisse aufzeichnen, die dann als weitere Telemetrie gesendet würden, wodurch AJAX-Daten mit internem NR-Verkehr verschmutzt würden.

Um das zu beheben und zu verhindern, dass Ihre Datenraten wie etwas aus Akira aussehen, können wir diese Beacon-Calls mit der eingebauten Wildcard blockieren. Das würde am Ende nach blog.arborydigital.com/nr/data/* aussehen. Wenn dies implementiert ist, fordert es New Relic mit, keinen ajax -Eintrag zu erstellen, wenn Browserdaten erfolgreich erfasst wurden. Alle Informationen im POST werden erhalten und es gibt keinen redundanten Ajax-Eintrag mehr.

Verwendung eines Abfrageparameters als Feature-Flag

Das Gat des Proxys hinter ?proxy=yes erlaubt es dir, das Verhalten in der Produktion zu testen, ohne andere Besucher zu beeinflussen. Jeder, der diesen Parameter nicht in seiner URL hat, umgeht den Block komplett, und in diesem Fall würde New Relic nicht ausgelöst werden. Man öffnet einen Tab mit dem angehängten Parameter, bestätigt in DevTools, dass Anfragen über die eigene Domain laufen, und sobald alles in Ordnung ist, entfernt man die Bedingung aus dem Skript. Danach übernimmt die Hostname-Prüfung und der Proxy aktiviert sich automatisch für den gesamten Datenverkehr.

Implementierung des neuen Reliktagenten

Den JavaScript-Ausschnitt finden Sie unter:

1. Melden Sie sich bei New Relic One an (one.newrelic.com)
2. Navigieren Sie zum Browser → Daten hinzufügen → Browserüberwachung
3. Wählen Sie die Anwendung (App-ID) oder erstellen Sie eine neue
4. Wählen Sie die Copy/Paste-Bereitstellungsmethode mit dem SPA-Loader
5. Kopiere den vollständigen generierten <script> Ausschnitt

Wenn du das RUM-Skript zu deinem Repository hinzufügst, solltest du sicherstellen, dass es in einer eigenen newrelic.js -Datei liegt, damit wir es in der head.html

• Ein Hinweis: <script src="/scripts/newrelic.js"></script> muss das erste Skript sein, das du direkt nach meta Tags initialisierst.

Sobald das erledigt ist, musst du die spezifischen Proxy-Einstellungen in diesen String einfügen. Im NREUM.init Block des generierten Snippets fügen Sie die Proxy-Konfiguration hinzu:

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

Verdrahtung des Proxys (EDS / CDN-Schicht)

Der Proxy selbst befindet sich auf der CDN-Ebene. Das Ziel ist einfach: Eingehende /nr/* Anfragen an die echten New Relic-Endpunkte weiterleiten.

Der Ursprungsselektor muss /nr/agent/* und /nr/data/* ausschließen, damit diese Anfragen nicht an den Edge Delivery Services-Ursprung weitergeleitet werden. Stattdessen fallen sie auf den Standard-AEM-Veröffentlichungs-Ursprung zurück, wo die Apache ProxyPass-Regeln ausgeführt werden. In deinem cdn.yaml sieht das so aus:

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

Sie müssen außerdem Ihre VirtualHost-Datei (.vhostbearbeiten:

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

Wichtige Details:

• SSLProxyEngine on erforderlich, da die Upstream-Ziele HTTPS sind
• RewriteEngine Off verhindert, dass AEMs Standard-Umschreibregeln die Proxypfade stören

Erkennung von HubSpot-Ausfällen (auch wenn nichts geladen wird)

Sobald New Relic entblockt ist, besteht das nächste Problem darin, dass die Ausfälle von HubSpot nicht immer offensichtliche Fehler verursachen; Vor allem, wenn das Skript nie lädt.

Um dies zu bewältigen, wurden zwei Erkennungspfade hinzugefügt:

1. Skriptlastfehler

Erkennen, wenn das HubSpot-Skript komplett nicht geladen wird:

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

2. Laufzeitfehler

Fehler erkennen, nachdem das Skript geladen ist:

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

Beide fließen in dieselbe Berichtsfunktion ein:

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

Überprüfen, ob es tatsächlich funktioniert

Sobald alles verdrahtet ist, ist die Bestätigung ziemlich unkompliziert, aber trotzdem wichtig. Das Testen sollte sich auf Browser konzentrieren, die strengen Tracking-Schutz/Erweiterungen aktiviert haben, wo man sieht, dass HubSpot-Formulare nicht geladen werden, Fehler in der Konsole erscheinen und dieselben Fehler in New Relic angezeigt werden. Bestätigen Sie in DevTools, dass der Agent von /nr/agent/ lädt und dass Beacons an /nr/data/gesendet werden, ohne dass Anfragen an Drittanbieter-Domains wie bam.nr-data.netgesendet werden. Überprüfen Sie in New Relic, dass Fehler im Dashboard erscheinen, Ereignisse mit den ausgelösten Ausfällen übereinstimmen und Sitzungen aufgezeichnet werden. Wenn Sitzungen noch fehlen, ist der Proxy wahrscheinlich nicht korrekt konfiguriert

Testen mit einer Schnellentwicklungsumgebung (RDE)

Wenn Sie einer unserer regelmäßigen Leser sind, erinnern Sie sich vielleicht an einen Artikel, den ich über die Nutzung einer Rapid Development Environment (RDE) zum Testen von CDN-Konfigurationsänderungen geschrieben habe. Beim Testen dieses neuen RUM habe ich genau das verwendet!

Wenn Best Practices befolgt werden, erfolgt die Entwicklung auf einem Zweig. Um sicherzustellen, dass deine Änderungen an einem Branch statt an Main vorgenommen werden, musst du zusätzliche Änderungen an cdn.yaml vornehmen:

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

Es gibt zwei Hauptbefehle, die du brauchst, sobald du bereit bist, deine Änderungen voranzutreiben:

aio aem:rde:install -t env-config ./config : Das wird den Inhalt Ihrer /config und die zuvor vorgenommenen Ausschlüsse vorantreiben.

aio aem:rde:install -t dispatcher-config ./dispatcher/src : Dies wird den Inhalt Ihrer /src– nämlich der Änderungen an der Konfiguration Ihres Disponenten .vhost .

Da die RDE auf einer anderen Domain als deine anderen Umgebungen funktioniert, musst du eine neue URL angeben, durch die du proxyen kannst. Andernfalls wird es als Drittanbieter-Domain betrachtet:

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

Cloud Manager Pipeline-Bereitstellung (Entwicklung + Produktion)

Die Bereitstellung über Adobe Cloud Manager erfordert etwas mehr Koordination als eine typische Codeänderung. Das Proxy-Verhalten hängt von mehreren Schichten ab (CDN, Dispatcher und Browser), und alle müssen innerhalb derselben Bereitstellung ausgerichtet sein.

Wie der Einsatz funktioniert

Eine Pipeline-Ausführung wird:

• Bauen und validieren Sie die Anwendung
• Dispatcher-Konfiguration bereitstellen (einschließlich .vhost, Filter und Proxy-Regeln)
• CDN-Konfiguration bereitstellen (cdn.yaml, einschließlich Ursprungsselektoren )
• Cache ungültig machen und Änderungen in der Umgebung fördern

Für diese Implementierung sind die Änderungen zwischen Dispatcher und CDN eng miteinander verknüpft. Der Proxy funktioniert nicht korrekt, es sei denn, beide sind vorhanden und konsistent.

Erforderliche Änderungen (müssen gemeinsam bereitgestellt werden)

Die folgenden Updates müssen im selben Pipeline-Run enthalten sein:

• CDN (cdn.yaml)

  • /nr/agent/* und /nr/data/* vom Edge-Delivery-Routing ausschließen

• Disponent (.vhost)

  • ProxyPass / ProxyPassReverse Regeln für New Relic Endpunkte
  • SSLProxyEngine on
  • Deaktivieren Sie Neuschreibungen für Proxy-Pfade

• Disponent-Filter

  • Explizite Erlaubnisregel für /nr/*

Wenn eines davon fehlt oder nicht synchronisiert ist, werden Anfragen entweder falsch weitergeleitet, blockiert oder fallen auf Drittanbieter-Endpunkte zurück.

Burn-In-Periode

Jetzt, da der Proxy konfiguriert und bereitgestellt wurde, brauchst du eine Burn-in-Phase, um sicherzustellen, dass alles wie erwartet funktioniert. Da Fehler von den tatsächlichen Benutzerbedingungen wie Datenschutzeinstellungen, Erweiterungen und Netzwerkverhalten abhängen, dauert es eine Weile, bis man ein vollständiges Bild bekommt.

Sobald Sie sich Zeit genommen und überprüft haben, dass die Daten ordnungsgemäß eingelesen werden, besteht der nächste Schritt darin, diese Daten zu überprüfen; Fehlerraten gegenüber erwartetem Datenverkehr zu validieren, Abdeckung über Umgebungen hinweg sicherzustellen und eventuelle Lücken (verpasste Ereignisse, inkonsistente Domänen oder Randfallblocker) zu optimieren. Von dort aus können Sie dies als verlässliche Kennzahl behandeln, einen Trend über die Zeit nutzen und den tatsächlichen Nutzereinfluss quantifizieren, anstatt nur anekdotische Berichte.

Abschließende Gedanken

Was als "einfach etwas Überwachung hinzufügen" begann, entwickelte sich zu einer Führung durch Browser-Datenschutzmodelle, First-Party-Proxying, CDN-Routing und die subtile Kunst, etwas zu messen, das sich von Natur aus nicht messen lässt.

Die Kernerkenntnis ist es wert, festgehalten zu werden: Wenn sowohl das, was du beobachten willst, als auch das, womit du es beobachtest, vom Browser als unerwünscht behandelt werden, kannst du dich mit handelsüblichen Tools nicht mehr herausfinden. Du musst ändern, wie der Browser deine Telemetrie wahrnimmt. Das Proxyen von New Relic über unsere First-Party-Domain hat genau das bewirkt – es hat Anfragen von Drittanbieter auf First-Party verschoben, die Blocker umgangen und uns einen echten Einblick in zuvor unsichtbare Fehler gegeben.

Aber der Stellvertreter war nur die halbe Miete. Die Erkennung von HubSpot-Ausfällen, insbesondere der stillen, bei denen das Skript nie geladen wird, erforderte eine gezielte Behandlung sowohl von Ladefehlern als auch von Laufzeitfehlern, die alle in einem einzigen Berichtspfad zusammengeführt wurden. Und nichts davon zählt, bis die Daten sich während der Einbrennphase beweisen, in der echte Nutzerbedingungen Annahmen durch Belege ersetzen.

Der Vorteil ist die Möglichkeit, Anekdoten gegen Zahlen zu tauschen. Anstelle von "Einige Nutzer sagen, das Formular lädt nicht", haben wir jetzt ein messbares, trendiges Signal, das den tatsächlichen Nutzereinfluss quantifiziert. Manchmal ist die wertvollste Lösung nicht die, die das Problem vollständig löst; Es ist der, der es dir endlich klar sehen lässt. Und von dort aus kannst du tatsächlich anfangen, es zu verbessern.

Fehlerbehebung

Über den Autor

Gefällt dir, was du gehört hast? Haben Sie Fragen dazu, was für Sie am besten ist? Wir würden uns sehr freuen, zu reden! Kontaktieren Sie uns

Mehr Artikel, die Ihnen gefallen könnten