Synthetics ジョブ マネージャーの構成

このドキュメントでは、次の方法を示して、外形監視ジョブ マネージャーの構成について説明します。

• 環境変数を使用して、外形監視ジョブ マネージャーを構成します。
• スクリプトAPI または スクリプトbrowser モニターの カスタム モジュール を設定します。
• 設定にユーザー定義の変数を提供します。

環境変数を使用した設定

環境変数を使用すると、合成ジョブ マネージャーの構成を微調整して、特定の環境および機能のニーズを満たすことができます。

スクリプト モニターのユーザー定義変数

プライベート外形監視ジョブ マネージャーを使用すると、スクリプト化された監視の環境変数を構成できます。 これらの変数は SJM 上でローカルに管理され、 $env.USER_DEFINED_VARIABLESを介してアクセスできます。 ユーザー定義変数は 2 つの方法で設定できます。 JSON ファイルをマウントするか、リリースの SJM に環境変数を指定することができます。 両方が指定されている場合、SJM は環境によって提供される値のみを使用します。

{
  "KEY": "VALUE",
  "user_name": "MINION",
  "my_password": "PASSW0RD123",
  "my_URL": "https://newrelic.com/",
  "ETC": "ETC"
}

$
docker run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw ...

$
podman run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw,z ...

$
helm install newrelic/synthetics-job-manager ... --set-file "synthetics.userDefinedVariables.userDefinedFile=[local-path]/user_defined_variables.json" ...

$
helm install newrelic/synthetics-job-manger ... --set synthetics.userDefinedVariables.userDefinedPath="variables"

$
docker run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

$
podman run ... -e USER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}' ...

$
helm install newrelic/synthetics-job-manager ... --set-literal synthetics.userDefinedVariables.userDefinedJson='{"key":"value","name":"sjm"}' ...

スクリプトからユーザー定義の環境変数にアクセスする

構成されたユーザー定義の環境変数を参照するには、予約語の$env.USER_DEFINED_VARIABLESに続けて、ドット表記の特定の変数の名前を使用します (例: $env.USER_DEFINED_VARIABLES.MY_VARIABLE )。

カスタムノードモジュール

カスタム ノード モジュールは、1分間あたりの呼出し回数と SJM の両方で提供されます。 これらを使用すると、カスタマイズされたノード モジュールのセットを作成し、外形監視用のスクリプト モニター (スクリプトAPIおよびスクリプトbrowser ) で使用できます。

カスタムモジュールディレクトリを設定する

ルート フォルダーにnpm の公式ガイドラインに従って、 package.jsonファイルを含むディレクトリを作成します。 SJMはpackage.jsonにリストされている依存関係をインストールします。 dependenciesフィールド。 これらの依存関係は、プライベート外形監視ジョブ マネージャーでモニターを実行するときに使用できます。 以下の例をご覧ください。

例

この例では、次のような構造のカスタムモジュールディレクトリを使用しています。

/example-custom-modules-dir/
    ├── counter
    │   ├── index.js
    │   └── package.json
    └── package.json            ⇦ the only mandatory file

package.jsonはdependenciesローカル モジュール (例: counter ) とホストされたモジュール (例: smallestバージョン1.0.1 ) の両方として定義します。

{
    "name": "custom-modules",
    "version": "1.0.0",                                ⇦ optional
    "description": "example custom modules directory", ⇦ optional
    "dependencies": {
    "smallest": "1.0.1",                               ⇦ hosted module
    "counter": "file:./counter"                        ⇦ local module
    }
}

Docker、Podman、KubernetesのSJMにカスタムモジュールディレクトリを追加します。

$
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...

$
podman run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw,z ...

モジュールが正しくインストールされたかどうか、またはエラーが発生したかどうかを確認するには、 synthetics-job-manager コンテナまたはポッドのログで次の行を探します。

2024-06-29 03:51:28,407{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Detected mounted path for custom node modules
2024-06-29 03:51:28,408{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Validating permission for custom node modules package.json file
2024-06-29 03:51:28,409{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Installing custom node modules...
2024-06-29 03:51:44,670{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Custom node modules installed successfully.

これで、このプライベートな場所に送信するモニターのスクリプトに"require('smallest');"を追加できます。

変化 package.json

ローカル モジュールとホスト モジュールに加えて、 Node.js モジュールも利用できます。 SJM で使用されるカスタム モジュールを更新するには、 package.jsonファイルに変更を加えて、SJM を再起動します。 再起動プロセス中に、SJM は設定の変更を認識し、クリーンアップと再インストール操作を自動的に実行して、更新されたモジュールが確実に適用されるようにします。

データの永久保存

ユーザーは、 user_defined_variables.jsonファイルを提供したり、カスタム ノード モジュールをサポートしたりするために、永続的なデータ ストレージを使用することがあります。

Docker

Dockerに恒久的なデータ保存を設定するには

1. ジョブ マネージャーを起動するホスト上にディレクトリを作成します。 これがソース ディレクトリです。

2. ジョブ マネージャーをリリースし、ソース ディレクトリをターゲット ディレクトリ/var/lib/newrelic/syntheticsにマウントします。

   例：

   bash

   コピー

   $
   docker run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw ...

ポッドマン

Podman で永続的なデータ ストレージを設定するには:

1. ジョブ マネージャーを起動するホスト上にディレクトリを作成します。 これがソース ディレクトリです。
2. ジョブ マネージャーをリリースし、ソース ディレクトリをターゲット ディレクトリ/var/lib/newrelic/syntheticsにマウントします。

例：

$
podman run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw,z ...

Kubernetes

Kubernetes に永続的なデータ ストレージを設定するには、ユーザーには 2 つのオプションがあります。

1. 既存の PersistentVolume (PV) に既存の PersistentVolumeClaim (PVC) を指定して、 synthetics.persistence.existingClaimName構成値を設定してください。例：

   bash

   コピー

   $
   helm install ... --set synthetics.persistence.existingClaimName=sjm-claim ...

2. 既存の PersistentVolume (PV) 名を指定して、 synthetics.persistence.existingVolumeName構成値を設定してください。Helm はユーザー用の PVC を生成します。ユーザーはオプションで次の値も設定できます。

• synthetics.persistence.storageClass: 既存の PV のストレージ クラス。指定されない場合、Kubernetes はデフォルトのストレージ クラスを使用します。

• synthetics.persistence.size: 請求のサイズ。設定されていない場合、デフォルトは現在 2Gi です。

  bash

  コピー

  $
  helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

Sizing considerations for Docker and Podman

プライベートロケーションを効率的に実行するには、監視ワークロードを処理するのに十分な CPU リソースをホスト上にプロビジョニングする必要があります。 サイズはさまざまな要因によって左右されますが、ニーズはすぐに見積もることができます。重量級のモニター (シンプル ブラウザー、スクリプト ブラウザー、スクリプト API モニターなど) ごとに 1 つの CPU コアが必要になります。現在のセットアップを診断する場合でも、将来のセットアップを計画する場合でも、必要なコアの数を計算するのに役立つ 2 つの式を以下に示します。

公式1：既存の場所の診断

現在のプライベートロケーションを維持するのが難しく、ジョブがキューに登録されているのではないかと思われる場合は、この式を使用して実際に必要なコアの数を調べてください。 これは、システムの観測可能なパフォーマンスに基づいています。

$$ C_req = (R_proc + R_growth) \cdot D_avg,m $$

• $C\_req$ =必要な CPU コア数。
• $R\_proc$ = 1 分あたりに処理される高負荷ジョブの速度。
• $R\_growth$ = jobManagerHeavyweightJobsキューが 1 分あたりに増加している**速度**。
• $D\_avg,m$ = 重いジョブの平均所要時間（分） 。

This formula calculates your true job arrival rate by adding the jobs your system is processing to the jobs that are piling up in the queue. Multiplying this total load by the average job duration tells you exactly how many cores you need to clear all the work without queuing.

公式2: 新しい場所または将来の場所の予測

新しいプライベートロケーションを設定している場合、またはモニターの追加を計画している場合は、この公式を使用して事前にニーズを予測してください。

$$ C_req = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

• $C\_req$ =必要な CPU コア数。
• $N\_mon$ = 実行を計画している重量級モニターの合計数。
• $D\_avg,m$ = 重いジョブの平均実行時間（分） 。
• $P\_avg,m$ = 重量モニターの平均期間(分単位) (たとえば、5 分ごとに実行されるモニターの場合、$P\_avg,m = 5$ になります)。

This calculates your expected workload from first principles: how many monitors you have, how often they run, and how long they take.

重要なサイズ決定要因

これらの数式を使用する場合は、次の要素を考慮してください。

• ジョブ期間 ($D\_avg,m$):平均には、タイムアウトするジョブ (多くの場合、約 3 分) を含める必要があります。これらのジョブは、期間全体にわたってコアを保持するためです。
• ジョブの失敗と再試行:モニターが失敗すると、自動的に再試行されます。これらの再試行は、合計負荷に追加される追加のジョブです。継続して失敗し再試行するモニターは、実質的にその期間が倍増し、スループットに大きな影響を与えます。
• スケールアウト:ホストにコアを追加する (スケールアップ) ことに加えて、同じプライベートロケーションキーを持つ追加の外部監視ジョブマネージャーを展開して、複数の環境間でジョブの負荷を分散する (スケールアウト) ことができます。

単一の外形監視ジョブ マネージャー (SJM) には、1 分あたり約 15 の重量ジョブというスループット制限があることに注意することが重要です。 これは、SJM ごとに処理されるジョブの数よりも、複数の SJM 間でのジョブの効率的な競争を優先する内部スレッド戦略によるものです。計算により、より高いスループットが必要であることが示された場合は、追加の SJM を展開してスケールアウトする必要があります。 ジョブ キューが大きくなっているかどうかを確認し、さらに SJM が必要かどうかを判断できます。

同じプライベートロケーションキーを持つ SJM を追加すると、いくつかの利点が得られます。

• 負荷分散: プライベートロケーションのジョブは、利用可能なすべての SJM に分散されます。
• フェイルオーバー保護: 1 つの SJM インスタンスがダウンしても、他のインスタンスがジョブの処理を続行できます。
• より高い合計スループット: プライベート ロケーションの合計スループットは、各 SJM からのスループットの合計になります (たとえば、2 つの SJM は最大 30 件/分までのジョブを提供します)。

診断用のNRQL書き込み

これらの書き込みを書き込みビルダーで実行して、診断式の入力を取得できます。 安定した平均値を得るために、時間範囲を十分に長い期間に設定してください。

1. Find the rate of jobs processed per minute ($R\_proc$): This query counts the number of non-ping (heavyweight) jobs completed over the last day and shows the average rate per minute.

FROM SyntheticCheck
SELECT rate(uniqueCount(id), 1 minute) AS 'job rate per minute'
WHERE location = 'YOUR_PRIVATE_LOCATION' AND typeLabel != 'Ping'
SINCE 1 day ago

2. Find the rate of queue growth per minute ($R\_growth$): This query calculates the average per-minute growth of the jobManagerHeavyweightJobs queue on a time series chart. A line above zero indicates the queue is growing, while a line below zero means it's shrinking.

FROM SyntheticsPrivateLocationStatus
SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'queue growth rate per minute'
WHERE name = 'YOUR_PRIVATE_LOCATION'
TIMESERIES SINCE 1 day ago

3. Find total number of heavyweight monitors ($N\_mon$): This query finds the unique count of heavyweight monitors.

FROM SyntheticCheck
SELECT uniqueCount(monitorId) AS 'monitor count'
WHERE location = 'YOUR_PRIVATE_LOCATION' AND typeLabel != 'Ping'
SINCE 1 day ago

4. Find average job duration in minutes ($D\_avg,m$): This query finds the average execution duration of completed non-ping jobs and converts the result from milliseconds to minutes. executionDuration represents the time the job took to execute on the host.

FROM SyntheticCheck
SELECT average(executionDuration)/60e3 AS 'avg job duration (m)'
WHERE location = 'YOUR_PRIVATE_LOCATION' AND typeLabel != 'Ping'
SINCE 1 day ago

5. 平均ヘビーウェイト モニター期間 ($P\_avg,m$) を見つける:プライベートロケーションのjobManagerHeavyweightJobsキューが増大している場合、既存の結果から平均モニター期間を計算することは正確ではありません。 これは、合成モニターページのモニターのリストから推定する必要があります。 正しい New Relic アカウントを選択してください。また、 privateLocationでフィルタリングする必要がある場合があります。

ping モニターとpingJobsキューに関する注意

Pingモニターは異なります。 これらは、それぞれ CPU コアを完全に消費しない軽量ジョブです。代わりに、別のキュー ( pingJobs ) を使用し、ワーカー スレッドのプールで実行されます。

リソースの消費量は少なくなりますが、大量の ping ジョブ、特に失敗するジョブは、パフォーマンスの問題を引き起こす可能性があります。次の点に留意してください。

• リソース モデル: Ping ジョブは専用の CPU コアではなくワーカー スレッドを利用します。これらにはジョブあたりのコア数の計算は適用されません。
• タイムアウトと再試行:失敗した ping ジョブは、最大60 秒間ワーカー スレッドを占有する可能性があります。最初に HTTP HEAD リクエスト (30 秒のタイムアウト) を試行します。これが失敗した場合は、HTTP GETリクエストを使用してすぐに再試行します (さらに 30 秒のタイムアウト)。
• スケーリング:サイズ設定の式は異なりますが、同じ原則が適用されます。大量の ping ジョブを処理し、 pingJobsキューが拡大しないようにするには、スケールアップまたはスケールアウト (あるいはその両方) が必要になる場合があります。スケールアップとは、ホストまたはネームスペースあたりの CPU リソースとメモリ リソースを増やすことを意味します。 スケール アウトとは、ping ランタイムのインスタンスを追加することを意味します。これは、より多くのホスト、より多くのネームスペース、または同じネームスペース内でさらに多くのジョブ マネージャーをデプロイすることによって実行できます。 あるいは、Kubernetes のping-runtime使用すると、デプロイメントごとにより多くのレプリカを設定できます。

Sizing considerations for Kubernetes and OpenShift

Kubernetes および OpenShift 合成ジョブ マネージャーによって使用される各ランタイムは、 Helm チャートで値を設定することで個別にサイズを変更できます。node-api-runtimeとnode-browser-runtime は、 parallelismとcompletions設定の組み合わせを使用して個別にサイズ設定されます。

• The parallelism setting controls how many pods of a particular runtime run concurrently.
• The completions setting controls how many pods must complete before the CronJob starts another Kubernetes Job for that runtime.

How to Size Your Deployment: A Step-by-Step Guide

Your goal is to configure enough parallelism to handle your job load without exceeding the throughput limit of your SJM instances.

Step 1: Estimate Your Required Workload

Completions: This determines how many runtime pods should complete before a new Kubernetes Job is started.

First, determine your private location's average job execution duration and job rate. Use executionDuration as it most accurately reflects the pod's active runtime.

-- Get average job execution duration (in seconds)
FROM SyntheticCheck
SELECT average(executionDuration / 60e3) AS 'D_avg_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ Completions = \frac5D_avg,m $$

Where $D\_avg,m$ is your average job execution duration in seconds.

Required Parallelism: This determines how many workers (pods) you need running concurrently to handle your 5-minute job load.

-- Get jobs per 5 minutes
FROM SyntheticCheck
SELECT rate(uniqueCount(id), 5 minutes) AS 'N_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ P_req = \fracN_mCompletions $$

Where $N\_m$ is your number of jobs per 5 minutes. This $P\_req$ value is your target total parallelism.

Step 2: Check Against the Single-SJM Throughput Limit

Max Parallelism: This determines how many workers (pods) your SJM can effectively utilize.

$$ P_max \approx 15 \cdot D_avg,m $$

This $P\_max$ value is your system limit for one SJM Helm deployment.

Step 3: Compare, Configure, and Scale

Compare your required parallelism ($P\_req$) from Step 1 to the maximum parallelism ($P\_max$) from Step 2.

Scenario A: $P\_req \le P\_max$

• Diagnosis: Your job load is within the limit of a single SJM instance.

• Action:

  1. You will deploy one SJM Helm release.
  2. In your Helm chart values.yaml, set parallelism to your calculated $P\_req$.
  3. Set completions to your calculated Completions. For improved efficiency, this value should typically be 6-10x your parallelism setting.

Scenario B: P\_req > P\_max

• Diagnosis: Your job load exceeds the ~15 jobs/minute limit of a single SJM.

• Action:

  1. You must scale out by deploying multiple, separate SJM Helm releases.
  2. See the Scaling Out with Multiple SJM Deployments section below for the correct procedure.
  3. Do not increase the replicaCount in your Helm chart.

Step 4: Monitor Your Queue

After applying your changes, you must verify that your job queue is stable and not growing. A consistently growing queue means your location is still under-provisioned.

Run this query to check the queue's growth rate:

-- Check for queue growth (a positive value means the queue is growing)
SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'Heavyweight Queue Growth Rate (per min)'
FROM SyntheticsPrivateLocationStatus
WHERE name = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago TIMESERIES

If the "Queue Growth Rate" is consistently positive, you need to install more SJM Helm deployments (Scenario B) or re-check your parallelism settings (Scenario A).

Configuration Examples and Tuning

The parallelism setting directly affects how many synthetics jobs per minute can be run. Too small a value and the queue may grow. Too large a value and nodes may become resource constrained.

If your parallelism setting is working well (keeping the queue at zero), setting a higher completions value (e.g., 6-10x parallelism) can improve efficiency by:

• Accommodating variability in job durations.
• Reducing the number of completion cycles to minimize the "nearing the end of completions" inefficiency where the next batch can't start until the final job from the current batch completes.

completions 値が大きすぎないように注意することが重要です。大きすぎると、CronJob で次のような警告イベントが発生します。

$
8m40s     Warning   TooManyMissedTimes   cronjob/synthetics-node-browser-runtime   too many missed start times: 101. Set or decrease .spec.startingDeadlineSeconds or check clock skew

Scaling out with multiple SJM deployments

To scale beyond the ~15 jobs/minute throughput of a single SJM, you must install multiple, separate SJM Helm releases.

The correct strategy is to deploy multiple SJM instances, each as its own Helm release. Each SJM will compete for jobs from the same private location, providing load balancing, failover protection, and an increased total job throughput.

Simplified Scaling Strategy

Assuming P\_req > P\_max and you need to scale out, you can simplify maintenance by treating each SJM deployment as a fixed-capacity unit.

1. Set Max Parallelism: For each SJM, set parallelism to the same $P\_max$ value. This maximizes the potential throughput of each SJM.

2. Set Completions: For each SJM, set completions to a fixed value as well. The $P\_req$ formula from Step 1 can be modified to estimate completions by substituting in the $P\_max$ value:

   $$ Completions = \fracN_mP_max $$

   Where $N\_m$ is your number of jobs per 5 minutes. Adjust as needed after deploying to target a 5 minute Kubernetes job age per runtime, i.e., node-browser-runtime and node-api-runtime.

3. Install Releases: Install as many separate Helm releases as you need to handle your total $P\_req$. For example, if your total $P\_req$ is 60 and you've fixed each SJM's parallelism at 20 ($P\_max$ from Step 2), you would need three separate Helm deployments to meet the required job demand.

4. Monitor and Add: Monitor your job queue (see Step 4). If it starts to grow, simply install another Helm release (e.g., sjm-delta) using the same fixed configuration.

By fixing parallelism and completions to static values based on $P\_max$, increasing or decreasing capacity becomes a simpler process of adding or removing Helm releases. This helps to avoid wasting cluster resources on a parallelism value that is higher than the SJM can effectively utilize.

Installation Example

When installing multiple SJM releases, you must provide a unique name for each release. All instances must be configured with the same private location key.

Setting the fullnameOverride is highly recommended to create shorter, more manageable resource names. For example, to install two SJMs named sjm-alpha and sjm-beta into the newrelic namespace (both using the same values.yaml with your fixed parallelism and completions):

$
# Install the first SJM deployment
$
helm upgrade --install sjm-alpha newrelic/synthetics-job-manager \
>
  -n newrelic \
>
  -f values.yaml \
>
  --set fullnameOverride=sjm-alpha \
>
  --set ping-runtime.fullnameOverride=sjm-alpha-ping \
>
  --set node-api-runtime.fullnameOverride=sjm-alpha-api \
>
  --set node-browser-runtime.fullnameOverride=sjm-alpha-browser

$
# Install the second SJM deployment to add capacity
$
helm upgrade --install sjm-beta newrelic/synthetics-job-manager \
>
  -n newrelic \
>
  -f values.yaml \
>
  --set fullnameOverride=sjm-beta
>
  --set ping-runtime.fullnameOverride=sjm-beta-ping \
>
  --set node-api-runtime.fullnameOverride=sjm-beta-api \
>
  --set node-browser-runtime.fullnameOverride=sjm-beta-browser

You can continue this pattern (sjm-charlie, sjm-delta, etc.) for as many SJMs as needed to keep the job queue from growing.