外形監視プライベートロケーションのランタイム移行ガイド

New Relicは、syntheticランタイムイメージをNode.js 16およびChrome 134から、Node.js 22およびChrome 147以降に移行しています。このアップデートはCVE-2026-5281に対処し、ランタイムを現在サポートされているバージョンに更新します。Chrome 134はGoogleのサポート対象チャネル外であり、Node.js 16は2023年9月に有効期限を迎えました。

新しいランタイムイメージはDocker Hubで利用可能です：

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

パブリックロケーションとプライベートロケーションの違い

移行パスは、モニターがパブリックロケーションとプライベートロケーションのどちらで実行されるかによって異なります。

パブリックロケーション: モニターの設定ページで、BrowserバージョンのドロップダウンをChrome 134からLatestに変更します。インフラストラクチャの変更は必要ありません。

プライベートロケーション: 外形監視ジョブマネージャー（SJM）インフラストラクチャに新しいランタイムイメージをデプロイする必要があります。

Synthetics > Runtime UpgradesのRuntime Upgradesページは、パブリックモニター向けに設計されています。プライベートロケーションの場合、そのツールによる自動化された移行前検証はありません。それぞれ異なるランタイムを実行している複数のジョブマネージャーに同じプライベートロケーションキーを指定した場合、表示される結果は独立した互換性チェックではなく、実際のジョブ実行になります。アップグレードを確定する前に、並行プライベートロケーション戦略を使用して、ランタイム間でモニターの動作を比較してください。

何が変わるのか

モニター結果がrc1.xイメージを実行しているSJMからのものかどうかを確認するには、このテーブルを使用します。

ランタイムバージョンのクエリ

各rc1.x Docker Hubタグは、SyntheticCheckイベントでレポートされる特定のnr.runtimeVersion値に対応します。NRQLでnr.runtimeVersion属性をクエリできます：

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

主な動作の変更

これらの変更は、既存のモニターに影響を与える可能性があります：

• HTTP keep-aliveのデフォルトが変更されました。Node.js 22では、http.globalAgentがデフォルトでkeepAlive: trueになります（Node.js 16ではfalseでした）。keepAlive: falseを明示的に設定せずにカスタムHTTPエージェントを作成するスクリプトは、接続が開いたままになりプロセスが終了できなくなるため、実行時間が長くなったりタイムアウトが発生したりする可能性があります。

• リソース使用量の増加。同じワークロードの場合、Chrome 147はChrome 134よりも多くのCPUとメモリを必要とします。Chrome 134での使用量が低いのと比較して、Browser ランタイム コンテナは通常、実行中にデフォルトのメモリ制限3.256 GiBのうち625～980 MiBを使用します。

• コンテナのオーバーヘッドの増加。スクリプト化ブラウザモニターの平均コンテナオーバーヘッドは6～10秒です。Scripted APIモニターは平均2～4秒です。古いランタイムでタイムアウトの閾値に近かったモニターは、現在その閾値を超える可能性があります。

移行戦略を選択する

プライベートロケーションの移行には2つのアプローチがあります。リスク許容度とモニターフリートの規模に基づいて選択してください。

オプションA：インプレースアップグレード

すべてのSJMを新しいランタイムイメージにアップグレードします。すべてのモニターは直ちに新しいランタイムで実行されます。

最適な用途: 小規模なモニター群、非クリティカルな環境、または移行中に一部のモニター障害を許容できる場合。

ステップ

1. 新しいイメージタグを使用するように、各SJMのDESIRED_RUNTIMESの設定を更新します。
2. SJMを再起動または再デプロイします。
3. モニター結果。

リスク: スクリプトがNode.js 22およびChrome 147以降で動作するように更新されるまで、一部のモニターが失敗する可能性があります。

オプションB：並列プライベートロケーション（推奨）

2つ目のプライベートロケーションを作成し、そこに新しいランタイムイメージのSJMをデプロイして、A/B比較のために両方のロケーションで同時にモニターを実行します。

最適な用途: 本番環境、大規模なモニター群、または既存の監視をまったく中断させたくない場合。

ステップ

1. New Relicで新しいプライベートロケーションを作成します。分かりやすい名前を付けます。

2. 新しいランタイムイメージを使用して、新しいプライベートロケーションを指定した1つ以上のSJMをデプロイします。

3. テスト中に新しいロケーションからの集計ノイズを抑制するために、ミュートルールを設定します：

   Alerts > Muting rulesに移動し、条件tags.privateLocation EQUALS <your-new-location-name>でルールを作成します。

4. 新しいプライベートロケーションをモニターに追加します。各モニターは複数のプライベートロケーションに割り当てることができます。各ロケーションのジョブは独立して実行されます。新しいロケーションでの失敗は、旧ロケーションからの結果に影響しません。

5. 2つの場所の間の結果を比較する。以下の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

   コピー

6. スクリプトを手動で編集して、新しいロケーションで失敗しているモニターを修正します。

7. 新しいロケーションですべてのモニターがパスしたら、モニターから旧ロケーションを削除し、旧SJMインフラストラクチャを廃止します。

トレードオフ: 移行期間中はインフラストラクチャコストが2倍になります。2つ目のSJMセットには、別のホストまたはクラスタリソースが必要です。

このアプローチにより、結果と実行時間の違い（どちらもジョブマネージャーの負荷とリソース計画に影響します）を含め、すべてのモニターが新しいランタイムでどのように実行されるかの全体像を把握できます。

完全なインフラストラクチャの比較を行わずにスクリプトの失敗のみをテストするには、小規模なテストSJMを使用して2つ目のプライベートロケーションをセットアップし、モニターのサブセットを実行します。これは、新しいランタイムで既存のモニターがどのように動作するかを示していますが、ランタイムが既存のインフラストラクチャのキャパシティにどのように適合するかを示すものではありません。

新しいランタイム イメージを使用してSJMをデプロイする

新しいランタイムイメージタグを使用するように、既存のSJMデプロイメントを更新してください。SJM自体（newrelic/synthetics-job-manager:latest）は変更されません — プルするランタイムイメージのみが変更されます。

Docker

新しいイメージタグを参照するように環境変数DESIRED_RUNTIMESを更新します：

$
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

YOUR_PRIVATE_LOCATION_KEYをプライベートロケーションキーに、RC_IMAGE_TAGをDocker Hubのイメージタグ（rc1.17など）に置き換えます。

既存のSJMコンテナがある場合は、まずそれを停止して削除してから、新しいコンテナを起動します：

$
docker stop YOUR_CONTAINER_NAME
$
docker rm YOUR_CONTAINER_NAME

ポッドマン

ポート8000のPodman APIサービスなど、すべてのPodmanの依存関係を完了していることを確認してください。次に、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

YOUR_PRIVATE_LOCATION_KEYをプライベートロケーションキーに、RC_IMAGE_TAGをDocker Hubのイメージタグ（rc1.17など）に置き換えます。

Kubernetes

SyntheticsジョブマネージャーチャートのHelmの値を更新します。values.yamlファイルを使用する場合は、ランタイム イメージ タグを更新してください：

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

新規インストレーションの場合：

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

YOUR_PRIVATE_LOCATION_KEYをプライベートロケーションキーに、RC_IMAGE_TAGをDocker Hubのイメージタグ（rc1.17など）に置き換えます。

移行を監視するためのNRQLクエリ

チェックが移行前の検証としてではなく、実際のジョブとして実行される、同じモニターを備えた2つ目のプライベートロケーションをセットアップした場合は、これらのクエリを使用して移行の進捗状況を追跡します：

新しいランタイムでのモニター別の失敗率：

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

旧ロケーションと新しいロケーションの実行時間の比較：

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

実行時間が増加したモニターの特定：

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

失敗しているモニターを修正

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

トラブルシューティング

よくある問題

役立つNRQLクエリ

失敗率が増加しているモニターを確認します：

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

移行前後の実行時間を比較します：

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

Chromeタブのクラッシュが発生しているモニターを見つける：

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

リソースの推奨事項

rc1.15ランタイムでのテストに基づく：

HEAVY_WORKER_CPUS 厳密なCPUコア制限ではなく、DockerのCPUシェア（相対的な重み）を設定しますこれを増やしても、複数のコンテナが同時にCPUを競合している場合にのみ違いが生じます。

時系列

関連ドキュメント

• 外形監視ジョブマネージャーをインストールする
• ジョブマネージャーの設定
• スクリプト化ブラウザモニターのトラブルシューティング
• セキュリティ速報 NR26-04