Algunos problemas se hacen públicos. Otros se esconden en el hueco entre "funciona en mi máquina" y "funciona para todos". Este vivía firmemente en ese hueco.

El síntoma parecía sencillo: algunos usuarios no podían cargar nuestros formularios con HubSpot. La causa era razonable; La configuración de privacidad del navegador y los bloqueadores de seguimiento intervinieron y se negaron a dejar pasar algo que se pareciera a un rastreador. Pero en el momento en que intentamos medir el problema, nos topamos con un muro que convirtió una solución aparentemente rápida en algo mucho más interesante.

La herramienta a la que normalmente recurríamos para detectar estos fallos, la monitorización real del usuario, estaba siendo bloqueada por las mismas protecciones que estaban rompiendo los formularios. Nuestro New Relic RUM parecía un rastreador porque, bueno, lo es . Estábamos intentando instalar un detector de humo en una habitación donde el humo activaba un dispositivo que desactivaba los detectores.

Este artículo explica cómo sorteamos esa paradoja: proxy de New Relic a través de nuestro propio dominio de primera mano para que deje de parecer un seguimiento de terceros, gestionar las complicaciones que conllevan los subdominios, mantener limpios nuestros datos de telemetría y, finalmente, construir una detección fiable para fallos de HubSpot; Incluso los silenciosos, donde no carga nada. A lo largo del camino cubriremos el cableado CDN y del despachador, las pruebas en un entorno de desarrollo rápido, el despliegue a través de Cloud Manager y el periodo de burn-in que convierte una solución ingeniosa en una métrica fiable.

Una nota importante proporcionada por New Relic:

Cuando utilizas el método proxy, es importante asegurarte de que tienes derecho a hacerlo en función de cualquier obligación contractual, regulatoria u otra obligación legal que puedas tener hacia tus usuarios finales y/o visitantes del sitio.

Crear una nueva reliquia por primera parte

En lugar de cargar New Relic directamente desde sus endpoints estándar, la solución fue proxy de todo a través de nuestro propio dominio. Esto desplaza las solicitudes de terceros → primeras partes, lo que evita la mayoría de las protecciones de rastreo.

Se introdujeron dos puntos finales:

• /nr/agent/ → sirve al agente del navegador New Relic
• /nr/data/ → recibe solicitudes de baliza (telemetría)

Codificación fija de los valores proxy

La forma más sencilla de configurar proxy de primera mano en New Relic es establecer las rutas proxy directamente en NREUM.init como cadenas estáticas. Apuntas assets a la URL que sirve a los bloques de script del agente de New Relic y beacon a la URL que recibe los datos de telemetría; ambos se enrutan a través de tu propio dominio en lugar del CDN de New Relic.

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

Esto es fácil de razonar. Los caminos son visibles de un vistazo, no requieren lógica en tiempo de ejecución y se establecen antes de que el agente se inicialice; Así que no hay preocupación temporal sobre si la configuración aterriza a tiempo. Mientras tu servidor tenga esas dos rutas configuradas y reenvíen correctamente a New Relic, funciona. Para sitios que viven en un solo dominio sin tráfico de subdominio, esto suele ser todo lo que necesitas.

Proxy entre subdominios

Cuando tu sitio utiliza subdominios, como blog.arborydigital.com, una sola ruta proxy codificada no es suficiente. Cada subdominio opera desde su propio origen, y las reglas de seguridad del navegador significan que una solicitud de blog.arborydigital.com a una ruta proxy alojada en www.arborydigital.com es técnicamente una solicitud de origen cruzado. Aunque esto pueda funcionar, anula parte del propósito del proxying de primera mano, que es enviar telemetría a través del mismo origen en el que el navegador ya confía.

Para resolver esto, la configuración proxy puede establecerse dinámicamente en tiempo de ejecución. En lugar de apuntar a un dominio fijo, el script comprueba window.location.hostname para determinar en qué origen se está ejecutando la página actualmente. Si ese nombre de host coincide con tu dominio raíz o cualquiera de sus subdominios, los extremos proxy se construyen usando window.location.origin — es decir, blog.arborydigital.com enrutará su tráfico de New Relic a través de blog.arborydigital.com/nr-assets/ y blog.arborydigital.com/nr-beacon, mientras www.arborydigital.com utiliza sus propias rutas equivalentes.

Este enfoque requiere que cada subdominio tenga las rutas proxy correspondientes configuradas a nivel de servidor o CDN. La configuración del agente New Relic, incluyendo los campos beacon y errorBeacon en NREUM.info, también debe actualizarse para reflejar el nombre de host actual y así que el agente sepa dónde reportar los datos.

ajax.deny_list

El agente del navegador New Relic está configurado para enrutar toda la telemetría a través de un proxy blog.arborydigital.com/nr/data de primera mano en lugar de los propios servidores de New Relic bam.nr-data.net. Esto evita bloqueadores que apunten a dominios NR conocidos.

Un efecto secundario de esto: el agente NR monitoriza todas las solicitudes XHR/fetch salientes en la página para capturarlas como eventos AJAX; incluyendo sus propias llamadas de baliza que van a blog.arborydigital.com/nr/data. Sin la lista de denegación, NR registraría sus propios POSTs de telemetría como eventos AJAX, que luego se enviarían como más telemetría, contaminando los datos AJAX con tráfico interno de NR.

Para solucionar esto y evitar que tus tasas de datos parezcan sacadas de Akira, podemos bloquear estas llamadas beacon usando el comodín incorporado. Esto acabaría siendo blog.arborydigital.com/nr/data/* . Cuando esto se implementa, indica a New Relic que no cree una entrada ajax cuando los datos del navegador se capturan correctamente. Toda la información dentro del POST se conserva y ya no habrá una entrada redundante de Ajax.

Uso de un parámetro de consulta como bandera de característica

Bloquear el proxy detrás de ?proxy=yes te permite probar el comportamiento en producción sin afectar a otros visitantes. Cualquiera que no tenga ese parámetro en su URL se saltará el bloqueo por completo y, en este caso, New Relic no se activaría. Abres una pestaña con el parámetro añadido, confirmas en DevTools que las solicitudes están enrutando a través de tu propio dominio, y cuando todo esté correcto, eliminas la condición del script. A partir de ahí, la comprobación del nombre de host toma el control y el proxy se activa automáticamente para todo el tráfico.

Implementación del nuevo agente de reliquias

Puedes encontrar el fragmento de JavaScript dejando:

1. Iniciar sesión en Nueva Reliquia Uno (one.newrelic.com)
2. Navegar al navegador → añadir datos → Monitorización del navegador
3. Selecciona la aplicación (ID de la aplicación) o crea una nueva
4. Elige el método de despliegue Copiar/Pegar con el cargador SPA
5. Copia el fragmento completo de <script> generado

Cuando añades el script RUM a tu repositorio, querrás asegurarte de que vive dentro de su propio archivo newrelic.js para poder llamarlo dentro de head.html

• Una nota: <script src="/scripts/newrelic.js"></script> debe ser el primer script que inicialices, inmediatamente después de cualquier etiqueta de meta .

Una vez hecho esto, tendrás que añadir los ajustes específicos del proxy a esta cadena. En el bloque NREUM.init del fragmento generado, añade la configuración proxy:

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

Cableado del proxy (EDS / Capa CDN)

El proxy en sí reside en la capa CDN. El objetivo es sencillo: reenviar las solicitudes de /nr/* entrantes a los verdaderos endpoints de New Relic.

El selector de origen debe excluir /nr/agent/* y /nr/data/* para que estas solicitudes no se dirijan al origen de Edge Delivery Services. En su lugar, se aplican al origen predeterminado de publicación de AEM, donde se ejecutan las reglas de Apache ProxyPass. Dentro de tu cdn.yaml eso se vería así:

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

También tendrás que editar tu archivo 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>

Detalles clave:

• SSLProxyEngine on requerida porque los objetivos aguas arriba son HTTPS
• RewriteEngine Off impide que las reglas de reescritura por defecto de AEM interfieran con las rutas proxy

Detección de fallos en HubSpot (incluso cuando no carga nada)

Una vez desbloqueado New Relic, el siguiente problema es que los fallos de HubSpot no siempre generan errores evidentes; Especialmente cuando el script nunca carga.

Para gestionar esto, se añadieron dos rutas de detección:

1. Fallo de carga del script

Detectar cuándo el script de HubSpot no se carga por completo:

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

2. Fallo en tiempo de ejecución

Errores de captura después de que carga el script:

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

Ambos alimentan la misma función de informe:

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

Verificarlo realmente funciona

Una vez que todo está conectado, la validación es bastante sencilla pero sigue siendo importante. Las pruebas deberían centrarse en navegadores con protección estricta de seguimiento/extensiones activadas, donde deberías ver que los formularios de HubSpot no cargan, errores aparecen en la consola y esos mismos errores aparecen en New Relic. En DevTools, confirma que el agente se carga desde /nr/agent/ y que las balizas se envían a /nr/data/, sin que ninguna solicitud vaya a dominios de terceros como bam.nr-data.net. En New Relic, verifica que aparecen errores en el panel de control, que los eventos coinciden con los fallos activados y que se están registrando las sesiones. Si las sesiones siguen faltando, probablemente el proxy no esté configurado correctamente

Pruebas con un entorno de desarrollo rápido (RDE)

Si eres uno de nuestros lectores habituales, quizá recuerdes un artículo que escribí sobre el uso de un entorno de desarrollo rápido (RDE) para probar cambios de configuración de CDN. ¡Al probar este nuevo RUM usé exactamente eso!

Siguiendo las mejores prácticas, el desarrollo se realizará en una rama. Para asegurarte de que tus cambios se hacen en una sucursal en lugar de en la principal, tendrás que hacer cambios adicionales en cdn.yaml :

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

Hay dos comandos principales que necesitarás cuando estés listo para hacer tus cambios:

aio aem:rde:install -t env-config ./config : Esto impulsará el contenido de tu /config y las exclusiones que hicimos antes.

aio aem:rde:install -t dispatcher-config ./dispatcher/src : esto enviará el contenido de tu /src—es decir, los cambios en la configuración de tu despachador .vhost .

Como el RDE funciona en un dominio diferente al de tus otros entornos, tendrás que especificar una nueva URL para hacer un proxy. De lo contrario, se considerará un dominio de terceros:

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

Despliegue de la Pipeline de Cloud Manager (Desarrollo + Prod)

Desplegar esto a través de Adobe Cloud Manager requiere un poco más de coordinación que un cambio típico de código. El comportamiento del proxy depende de múltiples capas (CDN, despachador y navegador), y todas deben estar alineadas dentro del mismo despliegue.

Cómo funciona el despliegue

Una ejecución en pipeline será:

• Construye y valida la aplicación
• Despliegue configuración del despachador (incluyendo .vhost, filtros y reglas de proxy)
• Desplegar configuración CDN (cdn.yaml, incluyendo selectores de origen)
• Invalidar la caché y promover cambios en todo el entorno

Para esta implementación, los cambios entre el despachador y la CDN están estrechamente acoplados. El proxy no funcionará correctamente a menos que ambos estén presentes y sean consistentes.

Cambios requeridos (deben desplegarse juntos)

Las siguientes actualizaciones deben incluirse en la misma ejecución de la pipeline:

• CDN (cdn.yaml)

  • Excluye /nr/agent/* y /nr/data/* del enrutamiento de Edge Delivery

• Despachador (.vhost)

  • ProxyPass / ProxyPassReverse reglas para los endpoints de Nueva Reliquia
  • SSLProxyEngine on
  • Desactivar las reescrituras para rutas proxy

• Filtros de despachador

  • Regla explícita de permitir para /nr/*

Si alguna de estas opciones falta o está desincronizada, las peticiones serán mal enrutadas, bloqueadas o recurrirán a endpoints de terceros.

Periodo de combustión

Ahora que el proxy ha sido configurado y desplegado, necesitarás un periodo de incorporación para asegurarte de que todo funciona como se espera. Dado que los fallos dependen de condiciones reales del usuario, como la configuración de privacidad, las extensiones y el comportamiento de la red, llevará tiempo obtener una visión completa.

Una vez que te hayas tomado un tiempo y verificado que los datos se están ingieriendo correctamente, el siguiente paso es revisar esos datos; validar las tasas de error frente al tráfico esperado, asegurar cobertura entre entornos y refinar cualquier laguna (eventos perdidos, dominios inconsistentes o bloqueadores de casos límite). A partir de ahí, puedes empezar a tratar esto como una métrica fiable, una tendencia a lo largo del tiempo y usarla para cuantificar el impacto real en el usuario en lugar de informes anecdóticos.

Reflexiones finales

Lo que empezó como "simplemente añade algo de monitorización" se convirtió en un recorrido por modelos de privacidad de navegadores, proxys de primera mano, enrutamiento de CDN y el sutil arte de medir algo que, por diseño, resiste ser medido.

La idea fundamental merece la pena conservarla: cuando lo que intentas observar y lo que lo observas son tratados como no bienvenidos por el navegador, no puedes monitorizar la salida con herramientas estándar. Tienes que cambiar cómo el navegador percibe tu telemetría. Proxy de New Relic a través de nuestro dominio de primera mano hizo exactamente eso: cambió las solicitudes de terceros a primeras partes, esquivó los bloqueadores y nos dio una ventana genuina a fallos que antes eran invisibles.

Pero el proxy solo era la mitad de la batalla. Detectar fallos en HubSpot, especialmente los silenciosos en los que el script nunca carga, requería un manejo deliberado tanto de los errores de carga como de los errores de ejecución, todos canalizados en una única ruta de informe. Y nada de eso cuenta hasta que los datos se demuestren durante el periodo de burn-in, cuando las condiciones reales del usuario sustituyen las suposiciones por evidencia.

La recompensa es la posibilidad de intercambiar anécdotas por números. En lugar de "algunos usuarios dicen que el formulario no cargará", ahora tenemos una señal medible y tendencial que cuantifica el impacto real en el usuario. A veces, la solución más valiosa no es la que resuelve el problema de forma directa; Es el que finalmente te permite verlo con claridad. Y a partir de ahí, puedes empezar a mejorarla.

Resolución de problemas

Sobre el autor

¿Te ha gustado lo que has oído? ¿Tienes preguntas sobre lo que es lo mejor para ti? ¡Nos encantaría hablar! Contáctanos

Más artículos que quizá te interesen