Alcuni problemi si fanno notare rumorosamente. Altri si nascondono nel vuoto tra "funziona sulla mia macchina" e "funziona per tutti." Questa viveva saldamente in quel vuoto.

Il sintomo sembrava semplice: alcuni utenti non riuscivano a caricare i nostri moduli alimentati da HubSpot. La causa era abbastanza ragionevole; Le impostazioni di privacy del browser e i blocchi di tracciamento intervenivano rifiutando di far passare qualsiasi cosa che assomigliasse a un tracker. Ma nel momento in cui abbiamo provato a misurare il problema, abbiamo incontrato un muro che ha trasformato una soluzione apparentemente rapida in qualcosa di molto più interessante.

Lo strumento che normalmente avremmo usato per rilevare questi fallimenti, il vero monitoraggio dell'utente, veniva bloccato dalle stesse esatte protezioni che rompevano i moduli. Il nostro New Relic RUM sembrava un localizzatore perché, beh, lo è . Stavamo praticamente cercando di installare un rilevatore di fumo in una stanza dove il fumo attivava un dispositivo che disattivava i rilevatori.

Questo articolo spiega come abbiamo superato questo paradosso: proxy di New Relic tramite il nostro dominio first-party così che smetta di sembrare un tracciamento di terze parti, gestire le complicazioni derivanti dai sottodomini, mantenere puliti i dati di telemetria e infine costruire un rilevamento affidabile per i guasti di HubSpot; Anche quelli silenziosi dove non si carica affatto. Nel frattempo affronteremo il cablaggio CDN e dispatcher, i test in un ambiente di sviluppo rapido, il deployment tramite Cloud Manager e il periodo di burn-in che trasforma una soluzione intelligente in una metrica affidabile.

Una nota importante fornita da New Relic:

Quando si utilizza il metodo proxy, è importante assicurarsi di avere il diritto di farlo in base a eventuali obblighi contrattuali, normativi o legali che si possano avere verso gli utenti finali e/o i visitatori del sito.

Creare una nuova reliquia di prima parte

Invece di caricare New Relic direttamente dai suoi endpoint standard, la soluzione è stata proxy di tutto tramite il nostro dominio. Questo sposta le richieste da terze parti → prime parti, evitando così la maggior parte delle protezioni di tracciamento.

Furono introdotti due endpoint:

• /nr/agent/ → serve l'agente del browser New Relic
• /nr/data/ → riceve richieste di beacon (telemetria)

Codifica fissa dei valori proxy

Il modo più semplice per configurare il proxy di prima parte in New Relic è impostare i percorsi proxy direttamente in NREUM.init come stringhe statiche. Punti assets all'URL che serve i blocchi dello script dell'agente New Relic e beacon all'URL che riceve i dati di telemetria; entrambi instradati attraverso il tuo dominio invece che tramite la CDN di New Relic.

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

È facile ragionare su questo. I percorsi sono visibili a colpo d'occhio, non richiedono logica a runtime e vengono impostati prima che l'agente iniziali; Quindi non c'è alcun problema di tempistica sul fatto che la configurazione arrivi in tempo. Finché il tuo server ha configurato queste due rotte e inoltra correttamente a New Relic, funziona. Per i siti che vivono su un solo dominio senza traffico in sottodominio, spesso questo è tutto ciò di cui hai bisogno.

Proxy tra sottodomini

Quando il tuo sito utilizza sottodomini, come blog.arborydigital.com, un singolo percorso proxy hardcoded non è sufficiente. Ogni sottodominio opera dalla propria origine, e le regole di sicurezza del browser significano che una richiesta da blog.arborydigital.com a un percorso proxy ospitato su www.arborydigital.com è tecnicamente una richiesta cross-origin. Anche se questo può funzionare, vanifica parte dello scopo del proxy first-party, ovvero inviare telemetria attraverso la stessa origine di cui il browser già si fida.

Per risolvere questo problema, la configurazione proxy può essere impostata dinamicamente a runtime. Invece di puntare a un dominio fisso, lo script controlla window.location.hostname per determinare su quale origine la pagina sia attualmente in esecuzione. Se quel nome host corrisponde al tuo dominio root o a uno dei suoi sottodomini, gli endpoint proxy sono costruiti usando window.location.origin — il che significa blog.arborydigital.com che instradarà il traffico New Relic attraverso blog.arborydigital.com/nr-assets/ e blog.arborydigital.com/nr-beacon, mentre www.arborydigital.com utilizza i propri percorsi equivalenti.

Questo approccio richiede che ogni sottodominio abbia le corrispondenti rotte proxy configurate a livello di server o CDN. La configurazione dell'agente New Relic, inclusi i campi beacon e errorBeacon in NREUM.info, deve essere aggiornata per riflettere il nome host attuale, così che l'agente sappia dove riportare i dati.

ajax.deny_list

L'agente del browser di New Relic è configurato per instradare tutta la telemetria tramite un proxy blog.arborydigital.com/nr/data di prima parte invece che tramite i server di New Relic bam.nr-data.net. Questo evita blocchi che prendono di mira domini NR noti.

Un effetto collaterale di ciò: l'agente NR monitora tutte le richieste XHR/fetch in uscita sulla pagina per catturarle come eventi AJAX; inclusi i propri beacon call che arrivano a blog.arborydigital.com/nr/data. Senza la lista di rifiuti, NR registrerebbe i propri POST di telemetria come eventi AJAX, che poi verrebbero inviati come altra telemetria, inquinando i dati AJAX con traffico NR interno.

Per risolvere questo problema ed evitare che i tuoi tassi dati sembrino usciti da Akira, possiamo bloccare queste chiamate beacon usando il jolly integrato. Questo finirebbe per sembrare blog.arborydigital.com/nr/data/* . Quando questo viene implementato, viene detto a New Relic di non creare una voce ajax quando i dati del browser vengono catturati con successo. Tutte le informazioni all'interno della POST vengono conservate e non ci sarà più una voce ajax ridondante.

Utilizzo di un parametro di query come flag di caratteristica

Bloccare il proxy dietro ?proxy=yes ti permette di testare il comportamento in produzione senza influenzare altri visitatori. Chiunque non abbia quel parametro nel proprio URL bypassa completamente il blocco e, in questo caso, New Relic non sparerebbe. Apri una scheda con il parametro aggiunto, confermi in DevTools che le richieste instradano attraverso il tuo dominio e, una volta che tutto è in regola, rimuovi la condizione dallo script. Da lì, il controllo del nome host prende il controllo e il proxy si attiva automaticamente per tutto il traffico.

Implementazione del Nuovo Agente Reliquia

Puoi trovare l'estratto JavaScript da:

1. Accedi a New Relic One (one.newrelic.com)
2. Naviga al browser → aggiungi dati → Monitoraggio del browser
3. Seleziona l'applicazione (ID app) o creane una nuova
4. Scegli il metodo di distribuzione Copia/Incolla con il caricatore SPA
5. Copia il frammento completo generato <script>

Quando aggiungi lo script RUM al tuo repository, vorrai assicurarti che risieda all'interno del suo file newrelic.js così possiamo chiamarlo all'interno di head.html

• Una nota: <script src="/scripts/newrelic.js"></script> deve essere il primo script che iniziali, subito dopo qualsiasi meta tag.

Una volta fatto questo, dovrai aggiungere le specifiche impostazioni del proxy a questa stringa. Nel blocco NREUM.init dello snippet generato, aggiungi la configurazione proxy:

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

Cablaggio del proxy (EDS / Layer CDN)

Il proxy stesso vive al livello CDN. L'obiettivo è semplice: inoltrare le richieste di /nr/* in arrivo ai veri endpoint di New Relic.

Il selettore di origine deve escludere /nr/agent/* e /nr/data/* affinché queste richieste non vengano instradate all'origine di Edge Delivery Services. Invece, si ritrovano nell'origine predefinita di pubblicazione di AEM dove vengono eseguite le regole Apache ProxyPass. All'interno della tua cdn.yaml sarebbe così:

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

Dovrai anche modificare il file 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>

Dettagli chiave:

• SSLProxyEngine on necessaria perché i target a monte sono HTTPS
• RewriteEngine Off impedisce alle regole di riscrittura predefinite di AEM di interferire con i percorsi proxy

Rilevamento dei guasti di HubSpot (anche quando nulla si carica)

Una volta sbloccato New Relic, il problema successivo è che i guasti di HubSpot non sempre generano errori evidenti; Soprattutto quando lo script non si carica mai.

Per gestire questo problema, sono stati aggiunti due percorsi di rilevamento:

1. Fallimento del caricamento dello script

Rileva quando lo script HubSpot non si carica completamente:

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

2. Guasto in tempo reale

Errori di cattura dopo il caricamento dello script:

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

Entrambi alimentano la stessa funzione di reportistica:

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

Verificare che funzioni davvero

Una volta tutto collegato, la validazione è abbastanza semplice ma comunque importante. I test dovrebbero concentrarsi su browser con protezione/estensioni di tracciamento rigorose attivate, dove dovresti vedere i moduli HubSpot non caricarsi, errori nella console e quegli stessi errori compaiono in New Relic. In DevTools, conferma che l'agente si carica da /nr/agent/ e che i beacon vengano inviati a /nr/data/, senza che le richieste vengano inviate a domini di terze parti come bam.nr-data.net. In New Relic, verifica che compaiano errori nella dashboard, che gli eventi corrispondano ai fallimenti scatenati e che le sessioni vengano registrate. Se le sessioni mancano ancora, probabilmente il proxy non è configurato correttamente

Test con un ambiente di sviluppo rapido (RDE)

Se sei uno dei nostri lettori abituali potresti ricordare un articolo che ho scritto sull'uso di un ambiente di sviluppo rapido (RDE) per testare le modifiche di configurazione delle CDN. Quando ho provato questo nuovo RUM ho usato proprio quello!

Seguendo le migliori pratiche, lo sviluppo avverrà su un ramo. Per assicurarti che le tue modifiche vengano apportate a un ramo invece che al principale dovrai apportare ulteriori modifiche a cdn.yaml :

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

Ci sono due comandi principali di cui avrai bisogno quando sarai pronto a spingere le modifiche:

aio aem:rde:install -t env-config ./config : Questo sposterà il contenuto del tuo /config e le esclusioni che abbiamo fatto prima.

aio aem:rde:install -t dispatcher-config ./dispatcher/src : questo spingerà il contenuto del tuo /src— ovvero i cambiamenti nella configurazione del tuo dispatcher .vhost .

Dato che il RDE funziona su un dominio diverso rispetto agli altri ambienti, dovrai specificare un nuovo URL attraverso cui fare un proxy. Altrimenti sarà considerato un dominio di terze parti:

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

Distribuzione della pipeline Cloud Manager (Dev + Prod)

Distribuire questo tramite Adobe Cloud Manager richiede un po' più di coordinamento rispetto a una normale modifica di codice. Il comportamento del proxy dipende da più livelli (CDN, dispatcher e browser), e tutti devono essere allineati all'interno della stessa distribuzione.

Come funziona il dispiegamento

Un'esecuzione di pipeline sarà:

• Compila e convalida l'applicazione
• Configurazione del dispatcher di distribuzione (inclusi .vhost, filtri e regole proxy)
• Deploy CDN configuration (cdn.yaml, inclusi i selettori di origine)
• Invalidare la cache e promuovere cambiamenti nell'ambiente

Per questa implementazione, le modifiche tra dispatcher e CDN sono strettamente accoppiate. Il proxy non funzionerà correttamente a meno che entrambi non siano presenti e coerenti.

Modifiche Richieste (Devono essere implementate insieme)

I seguenti aggiornamenti devono essere inclusi nella stessa esecuzione della pipeline:

• CDN (cdn.yaml)

  • Escludere /nr/agent/* e /nr/data/* dal routing di consegna Edge

• Centralina (.vhost)

  • ProxyPass / ProxyPassReverse regole per gli endpoint di New Relic
  • SSLProxyEngine on
  • Disabilita le riscritture per i percorsi proxy

• Filtri del dispatcher

  • Regola esplicita di permesso per /nr/*

Se uno di questi è mancante o fuori sincrono, le richieste verranno instradate errotate, bloccate o torneranno a endpoint di terze parti.

Periodo di Burn In

Ora che il proxy è stato configurato e distribuito, avrai bisogno di un periodo di burn-in per assicurarti che tutto funzioni come previsto. Poiché i guasti dipendono da condizioni reali dell'utente, come impostazioni di privacy, estensioni e comportamento di rete, ci vorrà un po' di tempo per avere un quadro completo.

Dopo aver preso del tempo e verificato che i dati vengono correttamente assimilati, il passo successivo è esaminare quei dati; Validare i tassi di errore rispetto al traffico atteso, garantire la copertura tra gli ambienti e perfezionare eventuali lacune (eventi mancanti, domini incoerenti o blocchi di casi limite). Da lì, puoi iniziare a trattare questo come una metrica affidabile, una tendenza nel tempo e usata per quantificare l'impatto reale sull'utente piuttosto che come rapporti aneddotici.

Considerazioni finali

Quello che era iniziato come "basta aggiungere un po' di monitoraggio" si è trasformato in un tour attraverso modelli di privacy nei browser, proxy first-party, routing CDN e la sottile arte di misurare qualcosa che, per design, resiste a essere misurato.

L'intuizione fondamentale vale la pena di essere conservata: quando ciò che stai cercando di osservare e ciò con cui lo osservi sono entrambi trattati come indesiderati dal browser, non puoi monitorare la tua via d'uscita con strumenti già disponibili. Devi cambiare come il browser percepisce la tua telemetria. Proxy di New Relic attraverso il nostro dominio di primo possesso ha fatto proprio questo: spostando le richieste da terze parti a prime parti, aggirare i blocchi e dandoci una vera finestra su fallimenti prima invisibili.

Ma il proxy era solo metà della battaglia. Rilevare i fallimenti di HubSpot, specialmente quelli silenziosi in cui lo script non si carica mai, richiedeva una gestione deliberata sia degli errori di caricamento che di quelli di runtime, tutti convogliati in un unico percorso di report. E nulla di tutto ciò conta finché i dati non si dimostrano validi durante il periodo di burn-in, quando le reali condizioni dell'utente sostituiscono le assunzioni con le prove.

Il vantaggio è la possibilità di scambiare aneddoti con numeri. Invece di "alcuni utenti dicono che il modulo non si carica", ora abbiamo un segnale misurabile e tendente che quantifica l'impatto reale sugli utenti. A volte la soluzione più preziosa non è quella che risolve il problema del tutto; È quello che finalmente ti permette di vederlo chiaramente. E da lì, puoi davvero iniziare a migliorarla.

Risoluzione dei problemi

Informazioni sull'autore

Ti è piaciuto quello che hai sentito? Hai domande su cosa sia giusto per te? Ci piacerebbe parlare! Contattaci

Altri articoli che potrebbero piacerti