Proxy de primeira parte no AEM usando o New Relic RUM

style

border-bottom-glow

Alguns problemas se anunciam em alto e bom som. Outros se escondem na lacuna entre "funciona na minha máquina" e "funciona para todos". Este aqui vivia firmemente nessa lacuna.

O sintoma parecia simples: alguns usuários não conseguiam carregar nossos formulários baseados no HubSpot. A causa era bastante razoável: as configurações de privacidade do navegador e os bloqueadores de rastreamento estavam intervindo e impedindo a passagem de qualquer coisa que se assemelhasse a um rastreador. Mas, no momento em que tentamos mensurar o problema, nos deparamos com um obstáculo que transformou uma solução aparentemente rápida em algo muito mais interessante.

A ferramenta que normalmente usaríamos para detectar essas falhas, o monitoramento de usuários reais, estava sendo bloqueada exatamente pelas mesmas proteções que estavam causando problemas nos formulários. Nosso New Relic RUM parecia um rastreador porque, bem, ele é um. Estávamos tentando instalar um detector de fumaça em uma sala onde a fumaça estava acionando um dispositivo que desativava os detectores de fumaça.

Este artigo descreve como contornamos esse paradoxo: encaminhando o New Relic por meio do nosso próprio domínio para que não pareça um rastreamento de terceiros, lidando com as complicações que surgem com subdomínios, mantendo nossos dados de telemetria limpos e, finalmente, criando uma detecção confiável para falhas do HubSpot; até mesmo as silenciosas, em que nada carrega. Ao longo do caminho, abordaremos a configuração da CDN e do dispatcher, os testes em um ambiente de desenvolvimento rápido, a implantação por meio do Cloud Manager e o período de burn-in que transforma uma solução alternativa inteligente em uma métrica confiável.

Uma observação importante fornecida pela New Relic:

Ao utilizar o método de proxy, é importante garantir que você tenha o direito de fazê-lo com base em quaisquer obrigações contratuais, regulamentares ou outras obrigações legais que você possa ter para com seus usuários finais e/ou visitantes do site.

Tornando New Relic um produto oficial da Nintendo

Em vez de carregar o New Relic diretamente de seus endpoints padrão, a solução foi encaminhar tudo por meio de nosso próprio domínio. Isso transfere as solicitações de terceiros para a própria entidade, o que evita a maioria das proteções contra rastreamento.

Foram introduzidos dois pontos finais:

/nr/agent/ → serve o agente do navegador New Relic
/nr/data/ → recebe solicitações de beacon (telemetria)

Valores de proxy fixos

A maneira mais simples de configurar o proxy de primeira parte no New Relic é definir os caminhos do proxy diretamente em NREUM.init como strings estáticas. Você aponta assets para o URL que fornece os blocos de script do agente New Relic e beacon para o URL que recebe os dados de telemetria; ambos roteados através do seu próprio domínio em vez do CDN do New Relic.

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

É fácil chegar a essa conclusão. Os caminhos são visíveis à primeira vista, não exigem lógica de tempo de execução e são definidos antes da inicialização do agente; portanto, não há preocupação com o tempo de espera para a configuração. Desde que seu servidor tenha essas duas rotas configuradas e encaminhando corretamente para o New Relic, funciona. Para sites que residem em um único domínio sem tráfego de subdomínios, isso geralmente é tudo o que você precisa.

Proxy entre subdomínios

Quando seu site usa subdomínios, como blog.arborydigital.com, um único caminho de proxy codificado não é suficiente. Cada subdomínio opera a partir de sua própria origem e as regras de segurança do navegador significam que uma solicitação de blog.arborydigital.com para um caminho de proxy hospedado em www.arborydigital.com é tecnicamente uma solicitação de origem cruzada. Embora isso possa funcionar, anula parte da finalidade do proxy de primeira parte, que é enviar telemetria pela mesma origem em que o navegador já confia.

Para resolver isso, a configuração do proxy pode ser definida dinamicamente em tempo de execução. Em vez de apontar para um domínio fixo, o script verifica window.location.hostname para determinar em qual origem a página está sendo executada atualmente. Se esse nome de host corresponder ao seu domínio raiz ou a qualquer um de seus subdomínios, os endpoints do proxy serão construídos usando window.location.origin — o que significa que blog.arborydigital.com roteará seu tráfego New Relic por meio de blog.arborydigital.com/nr-assets/ e blog.arborydigital.com/nr-beacon, enquanto www.arborydigital.com usa seus próprios caminhos equivalentes.

Essa abordagem exige que cada subdomínio tenha as rotas de proxy correspondentes configuradas no nível do servidor ou da CDN. A configuração do agente New Relic, incluindo os campos beacon e errorBeacon em NREUM.info, também precisa ser atualizada para refletir o nome do host atual para que o agente saiba onde reportar os dados.

lista_negar_ajax

O agente do navegador New Relic está configurado para rotear toda a telemetria através de um proxy de primeira parte blog.arborydigital.com/nr/data em vez dos próprios servidores da New Relic bam.nr-data.net. Isso evita bloqueadores que têm como alvo domínios NR conhecidos.

Um efeito colateral disso: o agente NR monitora todas as solicitações XHR/fetch de saída na página para capturá-las como eventos AJAX; incluindo suas próprias chamadas beacon indo para blog.arborydigital.com/nr/data. Sem a lista de bloqueio, o NR registraria suas próprias solicitações POST de telemetria como eventos AJAX, que seriam então enviadas como mais telemetria, poluindo os dados AJAX com tráfego interno do NR.

Para corrigir isso e evitar que suas taxas de dados pareçam saídas de um filme de Akira, podemos bloquear essas chamadas de beacon usando o caractere curinga integrado. Isso acabaria ficando parecido com blog.arborydigital.com/nr/data/* . Quando implementado, isso instrui o New Relic a não criar uma entrada ajax quando os dados do navegador forem capturados com sucesso. Todas as informações dentro do POST são preservadas e não haverá mais uma entrada ajax redundante.

Utilizando um parâmetro de consulta como um indicador de recurso.

Ao bloquear o proxy atrás de ?proxy=yes você pode testar o comportamento em produção sem afetar outros visitantes. Qualquer pessoa que não inclua esse parâmetro em sua URL ignora completamente o bloqueio e, nesse caso, o New Relic não seria acionado. Você abre uma aba com o parâmetro adicionado, confirma nas Ferramentas de Desenvolvedor que as solicitações estão sendo roteadas pelo seu próprio domínio e, assim que tudo estiver correto, remove a condição do script. A partir daí, a verificação do nome do host entra em ação e o proxy é ativado automaticamente para todo o tráfego.

Implementando o Agente New Relic

Você pode encontrar o trecho de JavaScript por meio de:

Faça login no New Relic One (one.newrelic.com)
Acesse Navegador → Adicionar dados → Monitoramento do navegador
Selecione o aplicativo (ID do aplicativo) ou crie um novo.
Escolha o método de implantação Copiar/Colar com o carregador SPA.
Copie o trecho <script> completo gerado.

Ao adicionar o script RUM ao seu repositório, certifique-se de que ele esteja dentro de um arquivo newrelic.js próprio para que possamos chamá-lo internamente. head.html

Uma observação: <script src="/scripts/newrelic.js"></script> precisa ser o primeiro script que você inicializa, imediatamente após quaisquer tags meta .

Feito isso, você precisará adicionar as configurações específicas de proxy a essa string. No bloco NREUM.init do trecho de código gerado, adicione a configuração do proxy:

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

Configurando o Proxy (Camada EDS/CDN)

O próprio proxy reside na camada CDN. O objetivo é simples: encaminhar as solicitações /nr/* recebidas para os endpoints reais do New Relic.

O seletor de origem deve excluir /nr/agent/* e /nr/data/* para que essas solicitações não sejam roteadas para a origem do Edge Delivery Services. Em vez disso, elas são encaminhadas para a origem de publicação padrão do AEM, onde as regras do Apache ProxyPass são executadas. Dentro do seu cdn.yaml ficaria assim:

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

Você também precisará editar seu arquivo 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>

Detalhes importantes:

SSLProxyEngine on necessário porque os destinos upstream são HTTPS.
RewriteEngine Off Impede que as regras de reescrita padrão do AEM interfiram nos caminhos do proxy.

Detectando falhas no HubSpot (mesmo quando nada carrega)

Uma vez que o New Relic é desbloqueado, o próximo problema é que as falhas do HubSpot nem sempre geram erros óbvios, especialmente quando o script nunca carrega.

Para lidar com isso, foram adicionados dois caminhos de detecção:

1. Falha ao carregar o script

Detectar quando o script do HubSpot não carrega completamente:

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

2. Falha em tempo de execução

Capturar erros após o carregamento do script:

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

Ambas contribuem para a mesma função de geração de relatórios:

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

Verificando se realmente funciona

Depois de tudo estar conectado, a validação é bastante simples, mas ainda assim importante. Os testes devem se concentrar em navegadores com proteção/extensões de rastreamento rigorosas ativadas, onde você deverá ver os formulários do HubSpot falharem ao carregar, erros aparecerem no console e esses mesmos erros surgirem no New Relic. Nas DevTools, confirme se o agente carrega de /nr/agent/ e se os beacons são enviados para /nr/data/, sem que as solicitações sejam enviadas para domínios de terceiros como bam.nr-data.net. No New Relic, verifique se os erros estão aparecendo no painel, se os eventos correspondem às falhas acionadas e se as sessões estão sendo registradas. Se as sessões ainda estiverem faltando, é provável que o proxy não esteja configurado corretamente.

Testando com um ambiente de desenvolvimento rápido (RDE)

Se você é um de nossos leitores habituais, talvez se lembre de um artigo que escrevi sobre como usar um ambiente de desenvolvimento rápido (RDE) para testar alterações na configuração da CDN. Ao testar este novo rum, usei exatamente isso!

Seguindo as melhores práticas, o desenvolvimento ocorrerá em uma ramificação. Para garantir que suas alterações sejam feitas em uma ramificação em vez da ramificação principal, você precisará fazer alterações adicionais em cdn.yaml :

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

Existem dois comandos principais que você precisará usar quando estiver pronto para enviar suas alterações:

aio aem:rde:install -t env-config ./config : isso irá enviar o conteúdo do seu /config e as exclusões que fizemos anteriormente.

aio aem:rde:install -t dispatcher-config ./dispatcher/src : isto enviará o conteúdo do seu /srcou seja, as alterações na sua configuração do dispatcher .vhost .

Como o RDE funciona em um domínio diferente dos seus outros ambientes, você precisará especificar uma nova URL para o proxy. Caso contrário, será considerado um domínio de terceiros:

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

Implantação do pipeline do Cloud Manager (Desenvolvimento + Produção)

Implementar isso por meio do Adobe Cloud Manager requer um pouco mais de coordenação do que uma alteração de código típica. O comportamento do proxy depende de múltiplas camadas (CDN, dispatcher e navegador), e todas elas precisam estar alinhadas na mesma implementação.

Como funciona a implantação

A execução de um pipeline irá:

Construir e validar a aplicação
Implantar a configuração do dispatcher (incluindo .vhost, filtros e regras de proxy)
Implantar configuração de CDN (cdn.yaml, incluindo seletores de origem)
Invalidar o cache e promover as alterações em todo o ambiente.

Nessa implementação, as alterações no dispatcher e na CDN estão fortemente acopladas. O proxy não funcionará corretamente a menos que ambos estejam presentes e consistentes.

Alterações necessárias (devem ser implementadas em conjunto)

As seguintes atualizações precisam ser incluídas na mesma execução do pipeline:

CDN (cdn.yaml)
- Excluir /nr/agent/* e /nr/data/* do roteamento de Entrega de Borda
Despachante (.vhost)
- ProxyPass / ProxyPassReverse regras para endpoints do New Relic
- SSLProxyEngine on
- Desativar reescritas para caminhos de proxy
Filtros do despachante
- Regra de permissão explícita para /nr/*

Caso algum desses elementos esteja ausente ou dessincronizado, as solicitações serão encaminhadas incorretamente, bloqueadas ou recorrerão a endpoints de terceiros.

Período de amaciamento

Agora que o proxy foi configurado e implantado, você precisará de um período de testes para garantir que tudo esteja funcionando conforme o esperado. Como as falhas dependem das condições reais do usuário, como configurações de privacidade, extensões e comportamento da rede, levará algum tempo para se obter um panorama completo.

Após dedicar algum tempo para verificar se os dados estão sendo ingeridos corretamente, o próximo passo é revisar esses dados: validar as taxas de erro em relação ao tráfego esperado, garantir a cobertura em todos os ambientes e corrigir quaisquer lacunas (eventos perdidos, domínios inconsistentes ou bloqueadores em casos extremos). A partir daí, você pode começar a tratar isso como uma métrica confiável, acompanhar a tendência ao longo do tempo e usá-la para quantificar o impacto real do usuário, em vez de relatos anedóticos.

Considerações finais

O que começou como "basta adicionar algum monitoramento" transformou-se em uma exploração dos modelos de privacidade do navegador, proxy de primeira parte, roteamento de CDN e a sutil arte de medir algo que, por definição, resiste a ser medido.

A principal conclusão é que vale a pena guardar: quando tanto o que você está tentando observar quanto o instrumento que você usa para observá- lo são tratados como indesejáveis pelo navegador, você não consegue contornar o problema usando ferramentas prontas para uso. Você precisa alterar a forma como o navegador interpreta seus dados de telemetria. O encaminhamento do New Relic por meio do nosso domínio próprio fez exatamente isso: redirecionou as solicitações de terceiros para o domínio próprio, contornou os bloqueadores e nos deu uma visão real das falhas que antes eram invisíveis.

Mas a ação por procuração era apenas metade da batalha. A detecção de falhas no HubSpot, especialmente as silenciosas, em que o script nunca carrega, exigiu o tratamento deliberado tanto de erros de carregamento quanto de erros de tempo de execução, todos canalizados para um único fluxo de relatórios. E nada disso importa até que os dados se provem durante o período de teste, onde as condições reais de uso substituem as suposições por evidências.

A vantagem é a possibilidade de trocar anedotas por números. Em vez de "alguns usuários dizem que o formulário não carrega", agora temos um sinal mensurável e passível de análise de tendências que quantifica o impacto real no usuário. Às vezes, a solução mais valiosa não é aquela que resolve o problema de imediato, mas sim aquela que finalmente permite enxergá -lo com clareza. E a partir daí, você pode realmente começar a melhorá-lo.

Solução de problemas

Emitir

Causa

Consertar

Erro CORS com duplicado <https://https//...>

<https://> incluídos nos valores proxy

Use apenas o nome do host sem formatação: arborydigital.com/nr/agent

Não há dados no New Relic.

O script não está carregando ou o proxy está mal configurado.

Verifique a aba Rede das Ferramentas de Desenvolvedor do navegador em busca de solicitações NR; verifique as regras reversas do proxy.

A gravação da sessão não está sendo feita.

A taxa de amostragem é de 10%.

Aumente sampling_rate em NREUM.init.session_replay ou teste com erro para acionar a captura de 100%.

newrelic objeto indefinido

Ordem de carregamento do script incorreta

Garanta que newrelic.js seja o primeiro <script> em head.html

Sobre o autor

Noah Mattison

Gerente de Entrega Técnica na Arbory Digital

Noah é formado em Ciência da Computação pela UNC Wilmington e possui duas certificações como Desenvolvedor AEM. Originalmente com formação em medicina e uma paixão por detecção de câncer e inteligência artificial, ele traz uma mentalidade voltada para a resolução de problemas para seu trabalho na Arbory. Ele auxilia no planejamento da execução de projetos, delega tarefas entre as equipes, mantém uma comunicação eficaz e apoia as operações internas. Ele acredita na comunidade e na visão da Arbory e, fora do trabalho, tem foco em questões ambientais e gosta de se manter ativo ao ar livre, praticando atividades como acampamento, surfe e escalada.

Entre em contato com Noah no LinkedIn.

Gostou do que ouviu? Tem dúvidas sobre o que é certo para você? Adoraríamos conversar! Entre em contato conosco.