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

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

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

環境変数を使用した設定

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

変数は、起動時に-e, --env引数を使用して提供されます。

次の表は、synthetics ジョブマネージャーがサポートするすべての環境変数を示しています。PRIVATE_LOCATION_KEYは必須で、その他の変数はすべてオプションです。

名前	説明
`PRIVATE_LOCATION_KEY`	REQUIRED. プライベートロケーションエンティティリストにあるプライベートロケーションキー。
`DOCKER_API_VERSION`	形式： `"vX.Y"`指定されたDockerサービスで使用されるAPIバージョン。デフォルト： `v1.35.`
`DOCKER_HOST`	合成ジョブマネージャーを特定の`DOCKER_HOST`にポイントします。存在しない場合、デフォルト値は `/var/run/docker.sock.`
`HORDE_API_ENDPOINT`	米国ベースのアカウントの場合、エンドポイントは次のとおりです。 `https://synthetics-horde.nr-data.net.` EUベースのアカウントの場合、エンドポイントは次のとおりです。 `https://synthetics-horde.eu01.nr-data.net/` モニターにサービスを提供するために、合成ジョブマネージャーが適切なエンドポイントに接続できることを確認します。
`DOCKER_REGISTRY`	ランタイムイメージがホストされる Docker レジストリドメイン。これを使用して、 `docker.io`をデフォルトとしてオーバーライドします。
`DOCKER_REPOSITORY`	ランタイムイメージがホストされる Docker リポジトリ / 組織。これを使用して、 `newrelic`をデフォルトとしてオーバーライドします。
`HORDE_API_PROXY_HOST`	Horde 通信に使用されるプロキシサーバーホスト。形式: `"localhost"` 。
`HORDE_API_PROXY_PORT`	Horde 通信に使用されるプロキシサーバーポート。形式: `8888` 。
`HORDE_API_PROXY_USERNAME`	Horde 通信に使用されるプロキシサーバーのユーザー名。形式: `"username"` 。
`HORDE_API_PROXY_PW`	Horde 通信に使用されるプロキシサーバーのパスワード。形式: `"password"` 。
`HORDE_API_PROXY_ACCEPT_SELF_SIGNED_CERT`	Horde 通信に使用されるプロキシサーバー接続の自己署名プロキシ証明書を受け入れますか?許容値: `true`
`CHECK_TIMEOUT`	モニターチェックの実行が許可される最大秒数。この値は、0 秒 (除く) から 900 秒 (含む) までの整数である必要があります (たとえば、1 秒から 15 分まで)。デフォルト: 180 秒
`LOG_LEVEL`	デフォルト： `INFO.` 追加オプション: `WARN` 、 `ERROR` 、 `DEBUG`
`HEAVYWEIGHT_WORKERS`	一度に実行できる同時重量ジョブ ( browser /スクリプト化されたbrowserおよびスクリプト化された API) の数。デフォルト: 使用可能な CPU - 1。
`DESIRED_RUNTIMES`	特定のランタイムイメージを実行するために使用される配列。形式: ['newrelic/外形監視-ping-runtime:latest','newrelic/外形監視-node- API -runtime:latest','newrelic/外形監視-node-browser-runtime:latest'] デフォルト: すべての最新のランタイム。
`VSE_PASSPHRASE`	設定すると、 verified script executionが有効になり、この値がpassphraseとして使用されます。
`USER_DEFINED_VARIABLES`	ユーザーが定義したキーバリューペアのセットをローカルにホストすること。
`ENABLE_WASM`	設定されている場合、ノードbrowserランタイムの Web アセンブリが有効になります。 WebAssembly を使用するには、外形監視ジョブマネージャーの最小バージョンが release-367 以上であり、ノードbrowserランタイムバージョンが 2.3.21 以上である必要があります。

変数は、起動時に--set引数を使用して提供されます。

次のリストは、synthetics ジョブマネージャーがサポートするすべての環境変数を示しています。synthetics.privateLocationKeyは必須で、その他の変数はすべてオプションです。

多数の追加の高度な設定が利用可能であり、Helm チャートの READMEに完全に記載されています。

名前	説明
`synthetics.privateLocationKey`	REQUIRED if `synthetics.privateLocationKeySecretName` is not set.プライベートロケーション Web ページにあるプライベートロケーションのキー。
`synthetics.privateLocationKeySecretName`	REQUIRED if `synthetics.privateLocationKey` is not set。キー`privateLocationKey`を含む Kubernetes シークレットの名前。これには、外形監視プライベートロケーションに関連付けられた認証キーが含まれます。
`replicaCount`	インストールで維持するレプリカの数デフォルト： `1.`
`imagePullSecrets`	指定されたコンテナレジストリからイメージを引き出すために使用されるシークレットオブジェクトの名前です。
`fullnameOverride`	デフォルトを置き換えて、デプロイメントに使用される名前のオーバーライド。
`appVersionOverride`	chart.ymlで指定されたバージョンの代わりに使用する、synthetics-job-manager のリリースバージョン。
`synthetics.logLevel`	デフォルト： `INFO.` 追加オプション: `WARN` 、 `ERROR`
`synthetics.hordeApiEndpoint`	米国ベースのアカウントの場合、エンドポイントは次のとおりです。 `https://synthetics-horde.nr-data.net.` EUベースのアカウントの場合、エンドポイントは次のとおりです。 `https://synthetics-horde.eu01.nr-data.net/` モニターにサービスを提供するために、合成ジョブマネージャーが適切なエンドポイントに接続できることを確認します。
`synthetics.minionDockerRunnerRegistryEndpoint`	MinionRunnerイメージがホストされているDockerレジストリと組織。これを使用して、デフォルトとして`quay.io/newrelic`をオーバーライドします（たとえば、 `docker.io/newrelic` ）
`synthetics.vsePassphrase`	設定すると、 verified script executionが有効になり、この値がpassphraseとして使用されます。
`synthetics.vsePassphraseSecretName`	設定すると、検証済みスクリプトの実行が有効になり、この値を使用して、 `vsePassphrase`というキーを持つ Kubernetes シークレットからパスフレーズを取得します。
`synthetics.enableWasm`	設定されている場合、ノードbrowserランタイムの Web アセンブリが有効になります。 WebAssembly を使用するには、外形監視ジョブマネージャーの最小バージョンが release-367 以上であり、ノードbrowserランタイムバージョンが 2.3.21 以上である必要があります。
`synthetics.apiProxyHost`	Horde 通信に使用されるプロキシサーバー。形式: `"host"` 。
`synthetics.apiProxyPort`	Horde 通信に使用されるプロキシサーバーポート。形式: `port` 。
`synthetics.hordeApiProxySelfSignedCert`	Horde 通信にプロキシサーバーを使用する場合は、自己署名証明書を受け入れます。許容値: `true` 。
`synthetics.hordeApiProxyUsername`	Horde 通信用のプロキシサーバーのユーザー名。フォーマット： `"username"`
`synthetics.hordeApiProxyPw`	Horde 通信用のプロキシサーバーのパスワード。形式: `"password"` 。
`synthetics.userDefinedVariables.userDefinedJson`	ユーザー定義変数の JSON 文字列。ユーザーはスクリプト内でこれらの変数にアクセスできます。形式: `'{"key":"value","key2":"value2"}'` 。
`synthetics.userDefinedVariables.userDefinedFile`	ユーザー定義変数を含む JSON ファイルへの、ユーザーにとってローカルなパス。これは`--set-file`経由で渡され、値ファイルで設定することはできません。
`synthetics.userDefinedVariables.userDefinedPath`	user_define_variables.json 파일에 대한 사용자가 제공한 PertantVolume의 경로입니다.この変数が設定されている場合、ユーザーは Persistent Volume または Persistent VolumeClaim を指定する必要があります。
`synthetics.persistence.existingClaimName`	ボリュームをマウントする場合、ユーザーはクラスター内に既に存在する PersistentVolumeClaim の名前を指定できます。対応する PersistentVolume が存在することを前提とします。
`synthetics.persistence.existingVolumeName`	ボリュームをマウントし、PersistentVolumeClaim を指定しない場合、ユーザーは少なくとも Persistent Volume 名を指定する必要があります。 Helm は PersistentVolumeClaim を生成します。
`synthetics.persistence.storageClass`	生成された PersistentVolumeClaim の StorageClass の名前。これは、既存の PV の StorageClassName と一致する必要があります。プロバイダーでない場合、Kubernetes はデフォルトのストレージクラスが存在する場合はそれを使用します。
`synthetics.persistence.size`	生成された PersistentVolumeClaim のボリュームのサイズ。フォーマット: `10Gi` 。デフォルトは2Giです。
`global.checkTimeout`	モニターチェックの実行が許可される最大秒数。この値は、0 秒 (除く) から 900 秒 (含む) までの整数である必要があります (たとえば、1 秒から 15 分まで)。デフォルト: 180 秒
`image.repository`	引くための容器です。デフォルト： `docker.io/newrelic/synthetics-job-runner`
`image.pullPolicy`	引きの方針です。デフォルト： `IfNotPresent`
`podSecurityContext`	Synthetics-job-manager ポッドのカスタムセキュリティコンテキストを設定します。
`ping-runtime.enabled`	永続的な ping ランタイムをデプロイする必要があるかどうか。ping モニターを使用しない場合は、これを無効にすることができます。デフォルト： `true`
`ping-runtime.replicaCount`	デプロイする ping ランタイムコンテナーの数。ping 監視のニーズに基づいてデプロイをスケーリングするには、replicaCount を増やします。デフォルト： `1`
`ping-runtime.image.repository`	ping ランタイム用にプルするコンテナーイメージ。デフォルト： `docker.io/newrelic/synthetics-ping-runtime`
`ping-runtime.image.pullPolicy`	ping-runtime コンテナーのプルポリシー。デフォルト： `IfNotPresent`
`node-api-runtime.enabled`	Node.js API ランタイムをデプロイする必要があるかどうか。スクリプト化された API モニターを使用しない場合、これを無効にすることができます。デフォルト： `true`
`node-api-runtime.parallelism`	デプロイする Node.js API ランタイム`CronJobs`の数。同時に実行される Node.js API ジョブの最大数。追加の詳細。デフォルト： `1`
`node-api-runtime.completions`	1 分あたりに完了する Node.js API ランタイム`CronJobs`の数。並列処理とともにこの設定を増やして、スループットを向上させます。これは、並列処理が増加するたびに増加する必要があり、完了は常に少なくとも並列処理以上である必要があります。 .API ランタイムジョブが実行されていない期間がある場合は、この設定を増やしてください。追加の詳細。デフォルト： `6`
`node-api-runtime.image.repository`	Node.js API ランタイム用にプルするコンテナーイメージ。デフォルト： `docker.io/newrelic/synthetics-node-api-runtime`
`node-api-runtime.image.pullPolicy`	Node.js API ランタイムコンテナーのプルポリシー。デフォルト： `IfNotPresent`
`node-browser-runtime.enabled`	Node.js ブラウザーランタイムをデプロイする必要があるかどうか。シンプルなブラウザモニタまたはスクリプト化されたブラウザモニタを使用しない場合は、これを無効にすることができます。デフォルト： `true`
`node-browser-runtime.parallelism`	デプロイする Chrome ブラウザーランタイム`CronJobs`の数。同時に実行される Chrome ブラウザジョブの最大数。追加の詳細。デフォルト： `1`
`node-browser-runtime.completions`	1 分あたりに完了する Chrome ブラウザランタイム`CronJobs`の数。並列処理とともにこの設定を増やして、スループットを向上させます。これは、並列処理が増加するたびに増加する必要があり、完了は常に少なくとも並列処理以上である必要があります。ブラウザーのランタイムジョブが実行されていない期間があることに気付いた場合は、この設定を増やしてください。追加の詳細。デフォルト： `6`
`node-browser-runtime.image.repository`	Node.js ブラウザーランタイム用にプルするコンテナーイメージ。デフォルト： `docker.io/newrelic/synthetics-node-browser-runtime`
`node-browser-runtime.image.pullPolicy`	Node.js ブラウザーランタイムコンテナーのプルポリシー。デフォルト： `IfNotPresent`

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

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

ユーザーは JSON 形式のファイルを作成し、そのファイルが配置されているボリュームを SJM コンテナ内の指定されたターゲットパスにマウントできます。

ファイルには読み取り権限が必要であり、JSON 形式のマップが含まれている必要があります。ユーザー定義変数ファイルの例:

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

ファイルをホスト上のソースディレクトリに配置します。 SJM은 파일 이름이 user_define_variables.json이 될 것으로 예상합니다.

Dockerの例です。

想定されるターゲットディレクトリは次のとおりです。 /var/lib/newrelic/synthetics/variables/

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

Kubernetesの例。

Kubernetes の SJM ポッドにファイルを提供する場合、ユーザーには 2 つのオプションがあります。以下の可能性があります:

ローカルファイルを渡します。
user_defined_variables.json を含む PersistentVolume を提供します。

ローカルファイルを渡す

このオプションは、ConfigMap Kubernetes リソースを作成し、それを SJM ポッドにマウントします。

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

### Mount a PersistentVolume
This option requires the user to provide a PersistentVolume that includes the user_defined_variables.json file or a PersistentVolumeClaim to the same. For more details on helm chart installation using a PersistentVolume, follow the instructions at [permanent data storage](/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration#permanent-data-storage).
    
Once the user has prepared a PersistentVolume as described below, launch the SJM, setting the path where the user_defined_variables.json file is located and setting any other `synthetics.persistence` variables as necessary.

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

変数は、環境変数を介してそれぞれのコンテナシステムに渡すことができます。 docker例:

-eフラグを使用して、 USER_DEFINED_VARIABLESという名前の環境変数を設定し、JSON 形式のマップ文字列の値を指定します。

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

Kubernetes の例: --set-literalフラグを使用して JSON 形式の文字列を渡します。

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
      }
    }

カスタムモジュールディレクトリと package.json を作成したら、それをdockerおよびKubernetesの SJM に適用します。
dockerの場合、リリース SJM はディレクトリを /var/lib/newrelic/synthetics/modules にマウントします。例えば：
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...
次の項目を完了します。
SJM をリリースし、インストール中にコマンドラインまたは YAML ファイルのいずれかでpersistence.customModules設定値を設定します。値には、カスタムモジュールファイルが存在する外形監視ジョブマネージャーの永続ボリューム上のサブパスを指定する必要があります。例えば：
helm install ... --set persistence.customModules=<custom-modules-subpath> ...
カスタムモジュールディレクトリがミニオンポッドで利用可能であることを確認してください。ホストからミニオンにディレクトリをコピーする1つの方法としてkubectl cpを使用できます。例えば：
kubectl cp /example-custom-modules-dir <namespace>/<pod_name>:/var/lib/newrelic/synthetics/modules
モジュールが正しくインストールされたかどうか、またはエラーが発生したかどうかを確認するには、 SJM ログの"... Initialization of Custom Modules ..."というセクションを確認します。これらのログには、インストレーションプロセスと発生した潜在的なエラーに関する情報を提供する npm インストレーションログが含まれます。

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

カスタムモジュールの`package.json`を変更

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

注意

ローカルモジュール: package.jsonには任意のローカルモジュールを含めることができますが、これらのモジュールはカスタムモジュールディレクトリの下のツリー内に存在する必要があります。ツリー外に保存すると、初期化プロセスが失敗し、SJM を起動した後にdockerログにエラーメッセージが表示されます。

データの永久保存

ユーザーは、永続データストレージを使用して、 user_defined_variables.jsonファイルを提供したり、カスタムノードモジュールをサポートしたりすることができます (プライベートの外形監視ジョブマネージャーはまだ利用できません)。

Docker

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

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

例：

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

Kubernetes

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

既存の Persistent Volume (PV) に既存の Persistent VolumeClaim (PVC) を指定し、 synthetics.persistence.existingClaimName構成値を設定します。

例：

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

既存の PersistentVolume (PV) 名を指定し、 synthetics.persistence.existingVolumeName構成値を設定します。 Helm はユーザー用の PVC を生成します。

ユーザーはオプションで次の値も設定できます。

synthetics.persistence.storageClass: 既存の PV のストレージクラス。指定しない場合、Kubernetes はデフォルトのストレージクラスを使用します。
synthetics.persistence.size: クレームのサイズ。設定されていない場合、現在のデフォルトは 2Gi です。

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

Kubernetes と Docker のサイジングに関する考慮事項

ヒント

Docker 固有のサイジングに関する考慮事項は、まもなく利用可能になります。

大規模な環境で作業している場合は、合成モニターを効率的に実行するための最小要件を満たすように、ジョブマネージャーの構成をカスタマイズする必要がある場合があります。次のような多くの要因が、合成ジョブマネージャーの展開のサイジング要件に影響を与える可能性があります。

予想される使用量に基づいてすべてのランタイムが必要な場合
モニターの種類 (ping、シンプルまたはスクリプト化されたブラウザー、およびスクリプト化された API) ごとの 1 分あたりのジョブ数
約 3 分でタイムアウトするジョブを含む、ジョブの所要時間
ジョブの失敗数。ジョブが失敗した場合、組み込みの 3/3 再試行ロジックを提供するためにモニターが失敗し始めると、自動再試行がスケジュールされます。これらの追加のジョブは、合成ジョブマネージャーのスループット要件に追加されます。

以下にリストされているサイジング構成設定に加えて、同じプライベートロケーションキーを使用して追加の合成ジョブマネージャーを展開し、複数の環境間でジョブの負荷を分散することができます。

Kubernetes

Kubernetes 合成ジョブマネージャーで使用される各ランタイムは、ヘルムチャートで値を設定することで個別にサイズを調整できます。

1のデフォルト値からping-runtime.replicaCount設定を増やすことで、追加の ping ランタイムを開始して、ping モニター負荷の実行を支援できます。

Node.js API と Node.js ブラウザランタイムは、 parallelismとcompletionsの設定の組み合わせを使用して個別にサイズ設定されます。これらの設定の理想的な構成は、お客様の要件によって異なります。

parallelism 設定は、特定のランタイムの同時実行ポッドの数を制御します。parallelism 設定は、コンテナ化されたプライベートミニオン (CPM) の synthetics.heavyWorkers 設定と同等です。リソース要求と制限値に基づいて、この数のポッドを実行するのに十分なリソースが Kubernetes クラスターにあることを確認してください。

completions 設定は、 CronJob がそのランタイムの別の Kubernetes ジョブを開始する前に、特定のランタイムのポッドの数を完了する必要があるかを制御します。Kubernetes ジョブ (大文字の J) と合成モニタージョブの違いに注目してください。効率を向上させるには、 completions parallelism 値の 6 ～ 10 倍に設定する必要があります。これは、Kubernetes ジョブがすべての completions が完了するのを待機するため、実行されるポッドの数が parallelism 未満になる可能性がある「完了の終わりに近づく」非効率を最小限に抑えるのに役立ちます。

completions が 1 より大きい場合、Kubernetes ジョブで定義されたすべての完了 (たとえば 6/6 完了) が満たされるまで、「Completed」ステータスのポッドが kubectl get pods -n YOUR_NAMESPACE の出力に表示されたままになります。ポッドのステータスが「完了」または「失敗」の場合、リソースはノードから解放されます。

Kubernetes ジョブの有効期間 5 分 (kubectl get jobs -n YOUR_NAMESPACE) は、ポッドが完了するまでにかかる時間と、1 分あたりに実行する必要がある合成ジョブの数 (ジョブレート) の変動を考慮した控えめな目標です。次の方程式は、各ランタイムの completions と parallelism の開始点として使用できます。プライベートロケーションキューの増加の観察に基づいて調整を行う必要がある場合があります。

completions = 300 / avg job duration (s)
parallelism = synthetics jobs per 5 minutes / completions

ランタイムが異なれば、合成ジョブの期間と速度も異なる可能性があります。次のクエリを使用して、プライベートロケーションの平均期間と料金を取得できます。

# non-ping average job duration by runtime type
FROM SyntheticCheck SELECT average(duration) AS 'avg job duration' WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago

# non-ping jobs per minute by runtime type
FROM SyntheticCheck SELECT rate(uniqueCount(id), 5 minutes) AS 'jobs per 5 minutes' WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago

ヒント

上記のクエリは現在の結果に基づいています。プライベートロケーションに結果がない場合、またはジョブマネージャーが最高のパフォーマンスを発揮していない場合、クエリ結果は正確ではない可能性があります。その場合、 kubectl get jobs -n YOUR_NAMESPACE 継続時間が少なくとも 5 分 (十分な完了)、キューが増大しない (十分な並列処理) ことが確認されるまで、 completions と parallelism にいくつかの異なる値を試します。

例	説明
`parallelism=1` `completions=1`	ランタイムは 1 分あたり 1 つの外形監視ジョブを実行します。 1 つのジョブが完了すると、 `CronJob`設定は次の瞬間に新しいジョブを開始します。 Throughput will be extremely limited with this configuration.
`parallelism=1` `completions=6`	ランタイムは一度に 1 つの外形監視ジョブを実行します。ジョブが完了すると、新しいジョブがすぐに開始されます。 `completions`設定数のジョブが完了すると、 `CronJob`構成によって新しい Kubernetes ジョブが開始され、完了カウンターがリセットされます。 Throughput will be limited, but slightly better.長時間実行される単一の外形監視ジョブは、このタイプの他の外形監視ジョブの処理をブロックします。
`parallelism=3` `completions=24`	ランタイムは一度に 3 つの外形監視ジョブを実行します。これらのジョブのいずれかが完了すると、新しいジョブがすぐに開始されます。 `completions`設定数のジョブが完了すると、 `CronJob`構成によって新しい Kubernetes ジョブが開始され、完了カウンターがリセットされます。 Throughput is much better with this or similar configurations.単一の長時間実行される外形監視ジョブが、このタイプの他の外形監視ジョブの処理に及ぼす影響は限定的です。

例

説明

parallelism=1

completions=1

ランタイムは 1 分あたり 1 つの外形監視ジョブを実行します。 1 つのジョブが完了すると、 CronJob設定は次の瞬間に新しいジョブを開始します。 Throughput will be extremely limited with this configuration.

parallelism=1

completions=6

ランタイムは一度に 1 つの外形監視ジョブを実行します。ジョブが完了すると、新しいジョブがすぐに開始されます。 completions設定数のジョブが完了すると、 CronJob構成によって新しい Kubernetes ジョブが開始され、完了カウンターがリセットされます。 Throughput will be limited, but slightly better.長時間実行される単一の外形監視ジョブは、このタイプの他の外形監視ジョブの処理をブロックします。

parallelism=3

completions=24

ランタイムは一度に 3 つの外形監視ジョブを実行します。これらのジョブのいずれかが完了すると、新しいジョブがすぐに開始されます。 completions設定数のジョブが完了すると、 CronJob構成によって新しい Kubernetes ジョブが開始され、完了カウンターがリセットされます。 Throughput is much better with this or similar configurations.単一の長時間実行される外形監視ジョブが、このタイプの他の外形監視ジョブの処理に及ぼす影響は限定的です。

合成ジョブの完了に時間がかかる場合、ジョブで 5 分間を埋めるために必要な完了数は少なくなりますが、より多くの並列ポッドが必要になります。同様に、1 分あたりにより多くの合成ジョブを処理する必要がある場合は、より多くの並列ポッドが必要になります。parallelism 設定は、1 分あたりに実行できる合成ジョブの数に直接影響します。値が小さすぎるとキューが増大する可能性があります。値が大きすぎると、ノードのリソースが制限される可能性があります。

parallelism 設定がうまく機能してキューをゼロに維持している場合は、 completions に 300 / avg job duration から計算される値よりも高い値を設定すると、次のいくつかの方法で効率を向上させることができます。

CronJob の最小期間である少なくとも 1 分間が合成ジョブで埋められるように、ジョブ期間の変動に対応します。
完了サイクルの数を減らして、最後のジョブが完了するまで次の完了セットを開始できない「完了が終わりに近づく」非効率を最小限に抑えます。

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

ヒント

New Relicは、外形監視ジョブマネージャーファイルに加えられた変更に対して責任を負わないことを覚えておいてください。

この機械翻訳は、参考として提供されています。

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

環境変数を使用した設定

Dockerの環境設定

Kubernetesの環境設定

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

JSONファイルの実装

ローカルファイルを渡す

環境変数として渡す

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

注意

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

カスタムモジュールのディレクトリ

Docker

Kubernetes

カスタムモジュールの`package.json`を変更

注意

データの永久保存

Docker

Kubernetes

Kubernetes と Docker のサイジングに関する考慮事項

ヒント

Kubernetes

ヒント

ヒント

この機械翻訳は、参考として提供されています。

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

環境変数を使用した設定 .css-21sua1{background:none;border:none;width:0;padding:0;}

Kubernetesの環境設定

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

JSONファイルの実装

環境変数として渡す

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

注意

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

カスタムモジュールのディレクトリ

Docker

Kubernetes

カスタムモジュールのpackage.jsonを変更

注意

データの永久保存

Docker

Kubernetes

Kubernetes と Docker のサイジングに関する考慮事項

ヒント

Kubernetes

ヒント

ヒント

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

環境変数を使用した設定

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

カスタムモジュールの`package.json`を変更