Guide de transition du runtime des sites privés Synthetics

New Relic effectue la transition des images de runtime synthétique de Node.js 16 avec Chrome 134 vers Node.js 22 avec Chrome 147 ou supérieur. Cette mise à jour corrige la CVE-2026-5281 et met à jour les runtimes vers les versions actuellement prises en charge. Chrome 134 est en dehors des canaux pris en charge par Google, et Node.js 16 a atteint la fin de vie en septembre 2023.

Les nouvelles images d'exécution sont disponibles sur Docker Hub :

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

Différences entre emplacement public et site privé

Le chemin de migration dépend du fait que vos monitors s'exécutent sur des emplacements publics ou des sites privés.

Emplacements publics : modifiez la liste déroulante de la version de Browser dans la page de configuration du moniteur pour passer de Chrome 134 à Latest. Aucun changement d'infrastructure nécessaire.

Sites privés : vous devez déployer de nouvelles images d'exécution sur votre infrastructure de gestionnaire de tâches Synthetics (SJM).

La page Runtime Upgrades dans Synthetics > Runtime Upgrades est conçue pour les monitorer publics. Pour les sites privés, il n’y a pas de validation de pré-migration automatisée via cet outil. Si vous pointez plusieurs gestionnaires de tâches — exécutant chacun un environnement d'exécution différent — vers la même clé de site privé, tous les résultats affichés sont de véritables exécutions de tâches, et non des vérifications de compatibilité isolées. Utilisez la stratégie de site privé parallèle pour comparer le comportement du monitor entre les environnements d’exécution avant de valider la mise à niveau.

Ce qui change

Utilisez ce tableau pour identifier si vos résultats de monitoring proviennent d'un SJM exécutant une image rc1.x.

Interrogation des versions de runtime

Chaque tag Docker Hub rc1.x correspond à une valeur nr.runtimeVersion spécifique rapportée dans les événements SyntheticCheck. Vous pouvez interroger l'attribut nr.runtimeVersion dans NRQL :

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

Principaux changements de comportement

Ces changements peuvent avoir un impact sur vos éléments monitorés existants :

• La valeur par défaut de HTTP keep-alive a changé. Node.js 22 définit par défaut http.globalAgent sur keepAlive: true (c'était false dans Node.js 16). Les scripts qui créent des agents HTTP personnalisés sans définir explicitement keepAlive: false peuvent subir des temps d'exécution plus longs ou des délais d'attente, car les connexions restent ouvertes et empêchent le processus de se terminer.

• Utilisation plus élevée des ressources. Chrome 147 nécessite plus de CPU et de mémoire que Chrome 134 pour le même workload. Les conteneurs de runtime Browser utilisent généralement de 625 à 980 MiB de leur limite de mémoire par défaut de 3,256 GiB lors de l'exécution, par rapport à une utilisation inférieure sur Chrome 134.

• Frais généraux de conteneur accrus. Les moniteurs de navigateur scriptés ont une surcharge moyenne de conteneur de 6 à 10 secondes. Les moniteurs d'API scriptés prennent en moyenne de 2 à 4 secondes pour monitorer. Les moniteurs qui étaient proches des seuils de timeout sur l'ancien environnement d'exécution peuvent désormais les dépasser.

Choisissez votre stratégie de migration

Il existe deux approches pour la migration des sites privés. Choisissez en fonction de votre tolérance au risque et de la taille de la flotte à monitorer.

Option A : mise à niveau sur place

Mettez à niveau tous les SJM vers les nouvelles images d'exécution. Tous les moniteurs s'exécutent immédiatement sur les nouveaux runtimes.

Idéal pour : les petites flottes de moniteurs, les environnements non critiques, ou lorsque vous pouvez tolérer quelques pannes de moniteur pendant la transition.

Mesures:

1. Mettez à jour la configuration DESIRED_RUNTIMES sur chaque SJM pour utiliser les nouveaux tags d'image.
2. Redémarrez ou redéployez le SJM.
3. Monitorez les résultats.

Risque : certains outils pour monitorer peuvent échouer jusqu'à ce que leurs scripts soient mis à jour pour fonctionner avec Node.js 22 et Chrome 147 ou supérieur.

Option B : site privé parallèle (recommandé)

Créez un deuxième site privé, déployez-y des SJM avec les nouvelles images d'exécution, et monitorez sur les deux sites simultanément pour une comparaison A/B.

Idéal pour : les environnements de production, les grandes flottes de moniteurs, ou lorsque vous avez besoin de zéro interruption du monitoring existant.

Mesures:

1. Créez un nouveau site privé dans New Relic. Donnez-lui un nom descriptif.

2. Déployez un ou plusieurs SJM pointant vers le nouveau site privé avec les nouvelles images de runtime.

3. Configurez une règle de mise en sourdine pour supprimer le bruit des alertes provenant du nouvel emplacement pendant les tests :

   Accédez à Alerts > Muting rules et créez une règle avec la condition tags.privateLocation EQUALS <your-new-location-name>.

4. Ajoutez le nouveau site privé à vos monitors. Chaque moniteur peut être affecté à plusieurs sites privés. Les jobs de chaque emplacement s'exécutent indépendamment — un échec sur le nouvel emplacement n'affecte pas les résultats de l'ancien emplacement.

5. Comparez les résultats entre les deux emplacements. Utilisez cette requête 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

   Copier

6. Corrigez tous les moniteurs en échec sur le nouvel emplacement en modifiant manuellement les scripts.

7. Une fois que tous les moniteurs réussissent sur le nouvel emplacement, supprimez l'ancien emplacement de vos moniteurs et mettez hors service l'ancienne infrastructure SJM.

Compromis : double coût d'infrastructure pendant la période de transition. Vous avez besoin d'hôtes ou de ressources de cluster distincts pour le deuxième ensemble de SJM.

Cette approche vous donne une image complète de la façon dont tous vos moniteurs s'exécutent sur les nouvelles exécutions, y compris les différences de résultats et de durée d'exécution, qui affectent tous deux la charge du gestionnaire de tâches et la planification des ressources.

Pour tester uniquement les échecs de script sans la comparaison complète de l'infrastructure, configurez un deuxième site privé avec un petit SJM de test et exécutez un sous-ensemble à monitorer. Cela montre comment les moniteurs existants se comportent sur les nouveaux runtimes, mais pas comment les runtimes s'adaptent à la capacité de votre infrastructure existante.

Déployer SJM avec de nouvelles images d'exécution

Mettez à jour votre déploiement SJM existant pour utiliser les nouveaux tags d'image d'exécution. Le SJM lui-même (newrelic/synthetics-job-manager:latest) ne change pas — seules les images d'exécution qu'il récupère changent.

Docker

Mettez à jour la variable d'environnement DESIRED_RUNTIMES pour référencer les nouveaux tags d'image :

$
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

Remplacez YOUR_PRIVATE_LOCATION_KEY par votre clé de site privé, et RC_IMAGE_TAG par le tag d'image de Docker Hub, comme rc1.17.

Si vous avez un conteneur SJM existant, arrêtez-le et supprimez-le d'abord, puis démarrez le nouveau :

$
docker stop YOUR_CONTAINER_NAME
$
docker rm YOUR_CONTAINER_NAME

Podman

Assurez-vous d’avoir installé toutes les dépendances Podman, y compris le service API Podman sur le port 8000. Ensuite, mettez à jour le 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

Remplacez YOUR_PRIVATE_LOCATION_KEY par votre clé de site privé, et RC_IMAGE_TAG par le tag d'image de Docker Hub, comme rc1.17.

Kubernetes

Mettez à jour les valeurs Helm pour le chart du gestionnaire de tâches Synthetics. Si vous utilisez un fichier values.yaml, mettez à jour les tags d'image d'exécution :

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

Pour une nouvelle installation :

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

Remplacez YOUR_PRIVATE_LOCATION_KEY par votre clé de site privé, et RC_IMAGE_TAG par le tag d'image de Docker Hub, comme rc1.17.

Requêtes NRQL pour le monitoring de la transition

Si vous avez configuré un deuxième site privé avec les mêmes monitorers — où les contrôles s'exécutent comme de vrais jobs, et non comme des validations de pré-migration — utilisez ces requêtes pour suivre la progression de votre migration :

Taux d'échec par moniteur sur le nouveau runtime :

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

Comparaison de la durée d'exécution entre les anciens et les nouveaux emplacements :

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

Identifier les moniteurs avec des temps d'exécution accrus :

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

Corriger les monitorer en échec

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

Dépannage

Problèmes courants

Requêtes NRQL utiles

Vérifier les moniteurs avec des taux d'échec accrus :

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

Comparez la durée d'exécution avant et après la migration :

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

Trouver les moniteurs avec des plantages d'onglets Chrome :

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

Recommandations de ressources

D'après les tests avec les exécutions rc1.15 :

HEAVY_WORKER_CPUS définit les parts de CPU Docker (un poids relatif), et non une limite stricte de cœurs de processeur. L'augmenter ne fait une différence que lorsque plusieurs conteneurs sont en concurrence pour le processeur simultanément.

Chronologie

Documentation associée

• Installer le gestionnaire de tâches Synthetics
• Configuration du gestionnaire de tâches
• Dépannage des moniteurs de navigateur scriptés
• Bulletin de sécurité NR26-04