Guia de transição de runtime para localizações privadas do Synthetics

A New Relic está fazendo a transição das imagens de runtime do Synthetics do Node.js 16 com Chrome 134 para o Node.js 22 com Chrome 147 ou superior. Esta atualização corrige a CVE-2026-5281 e traz os runtimes para as versões atualmente suportadas. O Chrome 134 está fora dos canais suportados do Google, e o Node.js 16 atingiu o fim da vida útil em setembro de 2023.

As novas imagens de tempo de execução estão disponíveis no Docker Hub:

• newrelic/synthetics-node-api-runtime:rc1.x
• newrelic/synthetics-node-browser-runtime:rc1.x

Diferenças entre localização pública e privada

O caminho de migração depende se seus monitores são executados em locais públicos ou localizações privadas.

Localizações públicas: Altere o dropdown de versão do Browser na página de configuração do monitor de Chrome 134 para Latest. Nenhuma alteração de infraestrutura necessária.

Localizações privadas: você deve implantar novas imagens de tempo de execução na infraestrutura do seu gerenciador de jobs de Sintéticos (SJM).

A página Runtime Upgrades em Synthetics > Runtime Upgrades foi projetada para monitores públicos. Para localizações privadas, não há validação pré-migração automatizada por meio dessa ferramenta. Se você apontar vários gerenciadores de jobs — cada um executando um runtime diferente — para a mesma chave de localização privada, quaisquer resultados exibidos são execuções reais de tarefas, não verificações isoladas de compatibilidade. Use a estratégia de localização privada paralela para comparar o comportamento do monitor entre runtimes antes de confirmar a atualização.

O que está mudando

Use esta tabela para identificar se os resultados do seu monitor vieram de um SJM executando uma imagem rc1.x.

Consultando versões de runtime

Cada tag rc1.x do Docker Hub corresponde a um valor nr.runtimeVersion específico reportado em eventos SyntheticCheck. Você pode consultar o atributo nr.runtimeVersion em NRQL:

SELECT count(*) FROM SyntheticCheck
WHERE locationLabel = 'YOUR_PRIVATE_LOCATION'
FACET type, nr.runtimeVersion SINCE 1 day ago

Principais alterações comportamentais

Essas alterações podem impactar seus monitores existentes:

• O padrão do HTTP keep-alive foi alterado. O Node.js 22 define http.globalAgent como keepAlive: true por padrão (era false no Node.js 16). Scripts que criam agentes HTTP personalizados sem definir explicitamente keepAlive: false podem apresentar tempos de execução mais longos ou timeouts, pois as conexões permanecem abertas e impedem que o processo seja encerrado.

• Maior uso de recursos. O Chrome 147 requer mais CPU e memória do que o Chrome 134 para o mesmo workload. Os contêineres de tempo de execução de Browser normalmente usam 625-980 MiB do seu limite de memória padrão de 3,256 GiB durante a execução, em comparação com o uso menor no Chrome 134.

• Aumento da sobrecarga do contêiner. Monitores de browser com script têm uma sobrecarga média de contêiner de 6–10 segundos. Monitores de API com script têm uma média de 2–4 segundos. Monitores que estavam próximos aos limites de timeout no tempo de execução antigo podem agora excedê-los.

Escolha sua estratégia de migração

Existem duas abordagens para a migração de localização privada. Escolha com base na sua tolerância a riscos e no tamanho da frota de monitores.

Opção A: Atualização in-place

Atualize todos os SJMs para as novas imagens de tempo de execução. Todos os monitores são executados imediatamente nos novos runtimes.

Ideal para: Pequenas frotas de monitores, ambientes não críticos ou quando você pode tolerar algumas falhas de monitor durante a transição.

Passos:

1. Atualize a configuração DESIRED_RUNTIMES em cada SJM para usar as novas tags de imagem.
2. Reinicie ou reimplante o SJM.
3. Resultados do monitor.

Risco: Alguns monitores podem falhar até que seus scripts sejam atualizados para funcionar com o Node.js 22 e o Chrome 147 ou superior.

Opção B: Localização privada paralela (recomendada)

Crie uma segunda localização privada, implante SJMs com as novas imagens de tempo de execução lá e execute monitores em ambas as localizações simultaneamente para comparação A/B.

Ideal para: Ambientes de produção, grandes frotas de monitores ou quando você precisa de zero interrupção no monitoramento existente.

Passos:

1. Crie uma nova localização privada na New Relic. Dê um nome descritivo.

2. Implante um ou mais SJMs apontados para a nova localização privada com as novas imagens de tempo de execução.

3. Configure uma regra de silenciamento para suprimir o ruído de alerta do novo local durante os testes:

   Acesse Alerts > Muting rules e crie uma regra com a condição tags.privateLocation EQUALS <your-new-location-name>.

4. Adicione a nova localização privada aos seus monitores. Cada monitor pode ser atribuído a várias localizações privadas. Os jobs de cada local são executados de forma independente — uma falha no novo local não afeta os resultados do local antigo.

5. Compare os resultados entre os dois locais. Use esta consulta NRQL:

   SELECT count(*), percentage(count(*), WHERE result = 'SUCCESS') AS 'Success %',
          average(executionDuration) AS 'Avg Exec Duration'
   FROM SyntheticCheck
   SINCE 1 day ago
   FACET locationLabel, monitorName

   Copiar

6. Corrija quaisquer monitores com falha no novo local editando manualmente os scripts.

7. Assim que todos os monitores passarem no novo local, remova o local antigo dos seus monitores e desative a infraestrutura antiga do SJM.

Compensação: custo duplo de infraestrutura durante o período de transição. Você precisa de hosts ou recursos de cluster separados para o segundo conjunto de SJMs.

Essa abordagem oferece uma visão completa de como todos os seus monitores são executados nos novos tempos de execução, incluindo diferenças nos resultados e na duração de execução — ambos afetam a carga do gerenciador de tarefas e o planejamento de recursos.

Para testar apenas falhas de script sem a comparação completa da infraestrutura, configure uma segunda localização privada com um pequeno SJM de teste e execute um subconjunto de monitores. Isso mostra como os monitores existentes se comportam nos novos runtimes, mas não como os runtimes se adequam à capacidade da sua infraestrutura existente.

Implantar SJM com novas imagens de runtime

Atualize sua implantação existente do SJM para usar as novas tags de imagem de runtime. O próprio SJM (newrelic/synthetics-job-manager:latest) não muda — apenas as imagens de runtime que ele baixa.

Docker

Atualize a variável de ambiente DESIRED_RUNTIMES para referenciar as novas tags de imagem:

$
docker run \
>
  --name sjm \
>
  --restart unless-stopped \
>
  -e PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY \
>
  -e "DESIRED_RUNTIMES=[newrelic/synthetics-ping-runtime:latest,newrelic/synthetics-node-api-runtime:RC_IMAGE_TAG,newrelic/synthetics-node-browser-runtime:RC_IMAGE_TAG]" \
>
  -v /var/run/docker.sock:/var/run/docker.sock:rw \
>
  newrelic/synthetics-job-manager:latest

Substitua YOUR_PRIVATE_LOCATION_KEY pela sua chave de localização privada e RC_IMAGE_TAG pela tag da imagem do Docker Hub, como rc1.17.

Se você tiver um contêiner SJM existente, pare e remova-o primeiro, depois inicie o novo:

$
docker stop YOUR_CONTAINER_NAME
$
docker rm YOUR_CONTAINER_NAME

Homem-Pod

Certifique-se de ter concluído todas as dependências do Podman incluindo o serviço de API do Podman na porta 8000. Em seguida, atualize o DESIRED_RUNTIMES:

$
podman pod create --network slirp4netns --name sjm-pod \
>
  --add-host=podman.service:YOUR_HOST_IP
$

$
podman run -d \
>
  --name sjm \
>
  --pod sjm-pod \
>
  --restart unless-stopped \
>
  -e PRIVATE_LOCATION_KEY=YOUR_PRIVATE_LOCATION_KEY \
>
  -e "DESIRED_RUNTIMES=[newrelic/synthetics-ping-runtime:latest,newrelic/synthetics-node-api-runtime:RC_IMAGE_TAG,newrelic/synthetics-node-browser-runtime:RC_IMAGE_TAG]" \
>
  -e CONTAINER_ENGINE=PODMAN \
>
  -e PODMAN_API_SERVICE_PORT=8000 \
>
  -e PODMAN_POD_NAME=sjm-pod \
>
  newrelic/synthetics-job-manager:latest

$
podman pull docker.io/newrelic/synthetics-node-browser-runtime:RC_IMAGE_TAG
$
podman pull docker.io/newrelic/synthetics-node-api-runtime:RC_IMAGE_TAG
$
podman pull docker.io/newrelic/synthetics-ping-runtime:latest

Substitua YOUR_PRIVATE_LOCATION_KEY pela sua chave de localização privada e RC_IMAGE_TAG pela tag da imagem do Docker Hub, como rc1.17.

Kubernetes

Atualize os valores do Helm para o chart do gerenciador de tarefas do Synthetics. Se você usar um arquivo values.yaml, atualize as tags de imagem de tempo de execução:

$
helm repo update
$

$
helm upgrade sjm newrelic/synthetics-job-manager \
>
  --namespace YOUR_NAMESPACE \
>
  --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY \
>
  --set-json 'synthetics.desiredRuntimes=[{"image":"newrelic/synthetics-ping-runtime","tag":"latest"},{"image":"newrelic/synthetics-node-api-runtime","tag":"RC_IMAGE_TAG"},{"image":"newrelic/synthetics-node-browser-runtime","tag":"RC_IMAGE_TAG"}]'

Para uma nova instalação:

$
helm install sjm newrelic/synthetics-job-manager \
>
  --namespace synthetics --create-namespace \
>
  --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY \
>
  --set-json 'synthetics.desiredRuntimes=[{"image":"newrelic/synthetics-ping-runtime","tag":"latest"},{"image":"newrelic/synthetics-node-api-runtime","tag":"RC_IMAGE_TAG"},{"image":"newrelic/synthetics-node-browser-runtime","tag":"RC_IMAGE_TAG"}]'

Substitua YOUR_PRIVATE_LOCATION_KEY pela sua chave de localização privada e RC_IMAGE_TAG pela tag da imagem do Docker Hub, como rc1.17.

Consultas NRQL para monitoramento da transição

Se você configurou uma segunda localização privada com os mesmos monitores — onde as verificações são executadas como tarefas reais, não como validações pré-migração — use estas consultas para acompanhar o progresso da sua migração:

Taxa de falhas por monitor no novo tempo de execução:

SELECT percentage(count(*), WHERE result = 'SUCCESS') AS 'Success %',
       count(*) AS 'Total Checks'
FROM SyntheticCheck
WHERE locationLabel = 'YOUR_NEW_LOCATION'
SINCE 1 day ago
FACET monitorName

Comparação da duração da execução entre as localizações antigas e novas:

SELECT average(executionDuration) AS 'Avg Execution Duration (ms)',
       average(duration) AS 'Avg Duration (ms)',
       average(executionDuration - duration) AS 'Avg Overhead (ms)'
FROM SyntheticCheck
SINCE 1 day ago
FACET locationLabel, monitorName

Identificar monitores com tempos de execução aumentados:

SELECT monitorName, average(executionDuration) AS 'Avg ExecDuration'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName, locationLabel
ORDER BY average(executionDuration) DESC

Corrigir monitores com falha

// Option 1: Set keepAlive: false
const agent = new https.Agent({ keepAlive: false });

// Option 2: Destroy the agent after use
const agent = new https.Agent({ keepAlive: true });
// ... make requests ...
agent.destroy();

// Before (may break on Node.js 22)
const url = `http://${ipv6Address}:${port}/path`;

// After
const url = `http://[${ipv6Address}]:${port}/path`;

Resolução de problemas

Problemas comuns

Consultas NRQL úteis

Verificar se há monitores com aumento nas taxas de falha:

SELECT percentage(count(*), WHERE result = 'FAILED') AS 'Failure %'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName
WHERE percentage(count(*), WHERE result = 'FAILED') > 0

Compare a duração de execução antes e depois da migração:

SELECT average(executionDuration) AS 'Avg ExecDuration',
       max(executionDuration) AS 'Max ExecDuration',
       average(executionDuration - duration) AS 'Avg Overhead'
FROM SyntheticCheck
SINCE 1 day ago
FACET monitorName
ORDER BY average(executionDuration) DESC

Encontre monitores com falhas nas abas do Chrome:

SELECT count(*)
FROM SyntheticCheck
WHERE error LIKE '%tab crashed%'
SINCE 1 day ago
FACET monitorName

Recomendações de recursos

Com base em testes com runtimes rc1.15:

HEAVY_WORKER_CPUS define os compartilhamentos de CPU do Docker (um peso relativo), não um limite rígido de núcleos de CPU. Aumentá-lo só faz diferença quando vários contêineres estão competindo por CPU simultaneamente.

Linha do tempo

Documentação relacionada

• Instale o gerenciador de jobs de Sintéticos
• Configuração do gerenciador de trabalhos
• Resolução de problemas de monitor de browser com script
• Boletim de segurança NR26-04