Guía de transición del runtime de ubicaciones privadas de Sintéticos

New Relic está migrando las imágenes de tiempo de ejecución sintético de Node.js 16 con Chrome 134 a Node.js 22 con Chrome 147 o superior. Esta actualización soluciona el CVE-2026-5281 y actualiza los runtimes a las versiones compatibles actualmente. Chrome 134 está fuera de los canales con soporte de Google, y Node.js 16 llegó al fin de su vida útil en septiembre de 2023.

Las nuevas imágenes en tiempo de ejecución están disponibles en Docker Hub:

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

Diferencias entre ubicaciones públicas y privadas

La ruta de migración depende de si sus monitores se ejecutan en ubicaciones públicas o privadas.

Ubicaciones públicas: Cambie el menú desplegable de versión de Browser en la página de configuración del monitor de Chrome 134 a Latest. No se necesitan cambios de infraestructura.

Ubicaciones privadas: debe desplegar nuevas imágenes de tiempo de ejecución en su infraestructura de gestores de trabajos de Sintéticos (SJM).

La página Runtime Upgrades en Synthetics > Runtime Upgrades está diseñada para monitores públicos. Para las ubicaciones privadas, no hay validación automatizada previa a la migración mediante esa herramienta. Si apunta múltiples gestores de trabajos —cada uno ejecutando un runtime diferente— a la misma clave de ubicación privada, los resultados mostrados son ejecuciones de trabajos reales, no comprobaciones de compatibilidad aisladas. Use la estrategia de ubicación privada paralela para comparar el comportamiento del monitor entre tiempos de ejecución antes de confirmar la actualización.

Qué cambia

Utilice esta tabla para identificar si los resultados de su monitor provienen de un SJM que ejecuta una imagen rc1.x.

Consultar versiones de tiempo de ejecución

Cada etiqueta rc1.x de Docker Hub corresponde a un valor nr.runtimeVersion específico reportado en eventos SyntheticCheck. Puede consultar el atributo nr.runtimeVersion en NRQL:

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

Cambios clave de comportamiento

Estos cambios pueden afectar sus monitores existentes:

• Cambió el valor predeterminado de HTTP keep-alive. Node.js 22 establece http.globalAgent en keepAlive: true de forma predeterminada (era false en Node.js 16). Los scripts que crean agentes HTTP personalizados sin establecer explícitamente keepAlive: false pueden experimentar tiempos de ejecución más largos o tiempos de espera agotados, ya que las conexiones permanecen abiertas e impiden que el proceso finalice.

• Mayor uso de recursos. Chrome 147 requiere más CPU y memoria que Chrome 134 para la misma workload. Los contenedores de entorno de ejecución de Browser normalmente utilizan 625-980 MiB de su límite de memoria predeterminado de 3.256 GiB durante la ejecución, en comparación con un uso menor en Chrome 134.

• Mayor sobrecarga del contenedor. Los monitores de browser con script tienen una sobrecarga promedio del contenedor de 6-10 segundos. Los monitores de API con scripts promedian 2-4 segundos. Los monitores que estaban cerca de los umbrales de tiempo de espera en el tiempo de ejecución anterior ahora pueden superarlos.

Elige tu estrategia de migración

Existen dos enfoques para la migración de ubicaciones privadas. Elija según su tolerancia al riesgo y el tamaño de la flota de monitores.

Opción A: actualización in situ

Actualice todos los SJM a las nuevas imágenes de tiempo de ejecución. Todos los monitores se ejecutan inmediatamente en los nuevos tiempos de ejecución.

Ideal para: flotas de monitores pequeñas, entornos no críticos o cuando puedes tolerar algunas fallas de monitor durante la transición.

Pasos:

1. Actualice la configuración de DESIRED_RUNTIMES en cada SJM para usar las nuevas etiquetas de imagen.
2. Reiniciar o redesplegar el SJM.
3. Resultados del monitor.

Riesgo: algunos monitores pueden fallar hasta que sus scripts se actualicen para funcionar con Node.js 22 y Chrome 147 o superior.

Opción B: ubicación privada paralela (recomendada)

Cree una segunda ubicación privada, despliegue SJM con las nuevas imágenes de tiempo de ejecución allí y ejecute monitores en ambas ubicaciones simultáneamente para una comparación A/B.

Ideal para: entornos de producción, grandes flotas de monitores o cuando necesita cero interrupciones en el monitoreo existente.

Pasos:

1. Crea una nueva ubicación privada en New Relic. Asigne un nombre descriptivo.

2. Despliegue uno o más SJM que apunten a la nueva ubicación privada con las nuevas imágenes de ejecución.

3. Configure una regla de silenciamiento para suprimir el ruido de alerta de la nueva ubicación durante las pruebas:

   Vaya a Alerts > Muting rules y cree una regla con la condición tags.privateLocation EQUALS <your-new-location-name>.

4. Agregue la nueva ubicación privada a sus monitores. Cada monitor se puede asignar a múltiples ubicaciones privadas. Los trabajos de cada ubicación se ejecutan de forma independiente — una falla en la nueva ubicación no afecta los resultados de la ubicación antigua.

5. Compare los resultados entre las dos ubicaciones. Utilice 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

   Copia

6. Corrige cualquier monitor que falle en la nueva ubicación editando manualmente los scripts.

7. Una vez que todos los monitores pasen en la nueva ubicación, elimine la ubicación antigua de sus monitores y retire la antigua infraestructura de SJM.

Desventaja: doble costo de infraestructura durante el período de transición. Necesita hosts o recursos del clúster independientes para el segundo conjunto de SJM.

Este enfoque le brinda un panorama completo de cómo se ejecutan todos sus monitores en los nuevos entornos de ejecución, incluidas las diferencias en los resultados y la duración de ejecución, los cuales afectan la carga del administrador de trabajos y la planificación de recursos.

Para probar solo las fallas de script sin la comparación completa de la infraestructura, configure una segunda ubicación privada con un pequeño SJM de prueba y ejecute un subconjunto de monitores. Esto muestra cómo se comportan los monitores existentes en los nuevos tiempos de ejecución, pero no cómo los tiempos de ejecución se adaptan a la capacidad de su infraestructura existente.

Desplegar SJM con nuevas imágenes de tiempo de ejecución

Actualice su despliegue de SJM existente para usar las nuevas etiquetas de imagen de tiempo de ejecución. El SJM en sí (newrelic/synthetics-job-manager:latest) no cambia — solo las imágenes de tiempo de ejecución que extrae.

Docker

Actualice la variable de entorno DESIRED_RUNTIMES para hacer referencia a las nuevas etiquetas de imagen:

$
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

Reemplace YOUR_PRIVATE_LOCATION_KEY con su clave de ubicación privada y RC_IMAGE_TAG con la etiqueta de la imagen de Docker Hub, como rc1.17.

Si tiene un contenedor SJM existente, deténgalo y elimínelo primero, luego inicie el nuevo:

$
docker stop YOUR_CONTAINER_NAME
$
docker rm YOUR_CONTAINER_NAME

Podman

Asegúrese de haber completado todas las dependencias de Podman, incluido el servicio de la API de Podman en el puerto 8000. Luego, actualice el 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

Reemplace YOUR_PRIVATE_LOCATION_KEY con su clave de ubicación privada y RC_IMAGE_TAG con la etiqueta de la imagen de Docker Hub, como rc1.17.

Kubernetes

Actualice los valores de Helm para el chart del gestor de trabajos de sintéticos. Si usas un archivo values.yaml, actualiza las etiquetas de imagen en tiempo de ejecución:

$
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 una nueva instalación:

$
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"}]'

Reemplace YOUR_PRIVATE_LOCATION_KEY con su clave de ubicación privada y RC_IMAGE_TAG con la etiqueta de la imagen de Docker Hub, como rc1.17.

Consultas NRQL para el monitoreo de la transición

Si ha configurado una segunda ubicación privada con los mismos monitores —donde las comprobaciones se ejecutan como trabajos reales, no como validaciones previas a la migración— utilice estas consultas para hacer un seguimiento del progreso de su migración:

Tasa de fallas por monitor en el nuevo tiempo de ejecución:

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

Comparación de la duración de ejecución entre las ubicaciones anteriores y las nuevas:

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 con tiempos de ejecución aumentados:

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

Corregir monitores fallidos

// 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`;

Resolución de problemas

Problemas comunes

Consultas NRQL útiles

Verifica si hay monitores con mayores tasas de fallas:

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

Compare la duración de la ejecución antes y después de la migración:

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

Buscar monitores con fallos en las pestañas de Chrome:

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

Recomendaciones de recursos

Basado en pruebas con runtimes rc1.15:

HEAVY_WORKER_CPUS establece las cuotas de CPU de Docker (un peso relativo), no un límite estricto de núcleos de CPU. Aumentarlo solo marca la diferencia cuando varios contenedores compiten por la CPU simultáneamente.

Línea de tiempo

Documentación relacionada

• Instalar el administrador de trabajos de sintéticos
• Configuración del administrador de trabajos
• Resolución de problemas de monitores de browser con script
• Boletín de seguridad NR26-04