• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

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

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

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

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

環境変数を使用した設定

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

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

プライベート外形監視ジョブ マネージャーを使用すると、スクリプト化された監視の環境変数を構成できます。 これらの変数は SJM 上でローカルに管理され、 $env.USER_DEFINED_VARIABLESを介してアクセスできます。 ユーザー定義変数は 2 つの方法で設定できます。 JSON ファイルをマウントするか、リリースの SJM に環境変数を指定することができます。 両方が指定されている場合、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にカスタムモジュールディレクトリを追加します。

モジュールが正しくインストールされたかどうか、またはエラーが発生したかどうかを確認するには、 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 は設定の変更を認識し、クリーンアップと再インストール操作を自動的に実行して、更新されたモジュールが確実に適用されるようにします。

注意

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

データの永久保存

ユーザーは、 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にマウントします。

例：

bash
$
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 ...

Docker、Podman、Kubernetes、OpenShift のサイズ設定に関する考慮事項

DockerとPodman

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

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

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

式: C_req=(J_processed+Q_growth)×D_jC\_req = (J\_processed + Q\_growth) \times D\_j

  • C_reqC\_req =必要なCPUコア数
  • J_processedJ\_processed = 1 分あたりに処理されるジョブの速度。
  • Q_growthQ\_growth = jobManagerHeavyweightJobsキューが 1 分あたりに増加している速度。
  • D_jD\_j = ジョブの平均所要時間（分）。

仕組みは次のとおりです。この式は、システムが処理しているジョブとキューに蓄積されているジョブを追加して、実際のジョブ到着率を計算します。この合計負荷に平均ジョブ継続時間を掛けると、キューに入れずにすべての作業をクリアするために必要なコア数が正確にわかります。

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

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

方程式：

C_req=N_m×D_j×1P_mC\_req = N\_m \times D\_j \times \frac1P\_m

  • C_reqC\_req =必要なCPUコア数
  • N_mN\_m = 実行を計画している重量級モニターの合計数。
  • D_jD\_j = ジョブの平均所要時間（分）。
  • P_mP\_m = モニターの期間（分単位）（たとえば、5 分ごとに実行されるモニターの期間は 5 です）。

仕組みは次のとおりです。これは、基本的な原則（モニターの数、実行頻度、実行時間）から予想されるワークロードを計算します。

重要なサイズ決定要因

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

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

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

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

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

診断用のNRQL書き込み

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

1. 1 分あたりに処理されたジョブを検索します (J_processedJ\_processed):このクエリは、過去 1 日間に完了した非 ping (重量級) ジョブの数をカウントし、1 分あたりの平均レートを表示します。

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

2. 1 分あたりのキューの増加を見つける (Q_growthQ\_growth):このクエリは、時系列チャートでjobManagerHeavyweightJobsキューの 1 分あたりの平均増加を計算します。ゼロより上の線はキューが増加していることを示し、ゼロより下の線はキューが減少することを意味します。

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

ヒント

必ずプライベートロケーションが存在するアカウントを選択してください。 微分関数は大きく変化する可能性があるため、このクエリを時系列として表示するのが最適です。目標は、1 分あたりのキューの増加率を推定することです。さまざまな時間範囲をPlayて、最も効果的な方法を見つけてください。

3. 平均ジョブ実行時間を分単位で検索します (D_jD\_j):このクエリは、完了した非 ping ジョブの平均実行時間を検索し、結果をミリ秒から分に変換します。executionDuration 、ホスト上でジョブの実行にかかった時間を表します。

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

4. 重量級モニターの合計数 (N_mN\_m) を検索します。このクエリは、重量級モニターの一意の数を検索します。

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

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

ヒント

合成モニターは複数のサブアカウントに存在する場合があります。書き込みビルダーで選択できる数を超えるサブアカウントがある場合は、モニター数が最も多いアカウントを選択してください。

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

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

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

  • リソース モデル: Ping ジョブは専用の CPU コアではなくワーカー スレッドを利用します。これらにはジョブあたりのコア数の計算は適用されません。
  • タイムアウトと再試行:失敗した ping ジョブは、最大60 秒間ワーカー スレッドを占有する可能性があります。最初に HTTP HEAD リクエスト (30 秒のタイムアウト) を試行します。これが失敗した場合は、HTTP GETリクエストを使用してすぐに再試行します (さらに 30 秒のタイムアウト)。
  • スケーリング:サイズ設定の式は異なりますが、同じ原則が適用されます。大量の ping ジョブを処理するには、ホストのリソースをスケールアップするか、ジョブ マネージャーを追加してスケールアウトし、 pingJobsキューをクリアな状態に保ち、遅延を防ぐ必要がある場合があります。

KubernetesとOpenShift

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

ランタイムのサイズを決定する際の重要な考慮事項は、単一の SJM インスタンスの最大スループットが1 分あたり約 15 件の高負荷ジョブ(スクリプト API およびブラウザ モニター) であることです。これは、SJM ごとに処理されるジョブの数よりも、複数の SJM 間でのジョブの効率的な競争を優先する内部スレッド戦略によるものです。

平均ジョブ期間を使用して、このスループット上限に達する前に単一の SJM の最大有効parallelism計算できます。

Parallelism_max≈15×\mathrmajd_mParallelism\_max \approx 15 \times \mathrmajd\_m

ここで、\mathrmajd_m\mathrmajd\_m はジョブの平均所要時間（分）です。

監視ニーズがこの最大 15 ジョブ/分の制限を超える場合は、複数の SJM インスタンスを展開してスケールアウトする必要があります。 ジョブ キューが大きくなっているかどうかを確認し、さらにインスタンスが必要かどうかを確認できます。

parallelism設定は、特定のランタイムのポッドが同時にいくつ実行されるかを制御します。これは、Docker および Podman SJM のHEAVYWEIGHT_WORKERS環境変数に相当します。completions設定は、 CronJobそのランタイムに対して別の Kubernetes ジョブを開始する前に、特定のランタイムのポッドがいくつ完了する必要があるかを制御します。効率を向上させるには、 completions parallelism値の 6 ～ 10 倍に設定する必要があります。

次の式は、各ランタイムのcompletionsとparallelism開始点として使用できます。

完了=300ajd_s完了 = \frac300ajd\_s

ここで、\mathrmajd_s\mathrmajd\_s は平均ジョブ継続時間（秒）です。

並列性=\fracsj_5mCompletions並列性 = \fracsj\_5mCompletions

\mathrmsj_5m\mathrmsj\_5m は 5 分あたりの外部監視ジョブの数です。

次の文章を使用して、プライベートロケーションの平均所要時間と料金を取得できます。

-- 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 typeLabel 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 typeLabel 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.単一の長時間実行される外形監視ジョブが、このタイプの他の外形監視ジョブの処理に及ぼす影響は限定的です。

合成ジョブの完了に時間がかかる場合、ジョブで 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外形監視ジョブ マネージャー ファイルに加えた変更については責任を負いません。

複数のSJMインスタンスによるスケールアウト

より高い総スループットを達成するには、同じKubernetesネームスペースに複数の SJM Helmリリースをインストールします。 各 SJM は同じプライベート ロケーションからのジョブを競合し、負荷分散、フェイルオーバー保護、および合計ジョブ スループットの増加を実現します。

複数の SJM リリースをインストールする場合は、リリースごとに一意の名前を付ける必要があります。すべてのインスタンスは、 values.yamlファイル内で同じプライベートロケーションキーを使用して構成する必要があります。必須ではありませんが、より短く管理しやすいリソース名を作成するには、 fullnameOverrideを設定することをお勧めします。

たとえば、 sjm-alphaとsjm-betaという名前の 2 つの SJM をnewrelicネームスペースにインストールするには、次のようにします。

bash
$
helm upgrade --install sjm-alpha -n newrelic newrelic/synthetics-job-manager -f values.yaml --set fullnameOverride=sjm-alpha --create-namespace
bash
$
helm upgrade --install sjm-beta -n newrelic newrelic/synthetics-job-manager -f values.yaml --set fullnameOverride=sjm-beta

ジョブ キューが拡大しないように、必要な数の SJM に対してこのパターンを継続できます。各 SJM について、平均ジョブ期間とインスタンスあたり 1 分あたり約 15 ジョブの制限に基づいて、 parallelismとcompletions適切な値に設定します。

Copyright © 2025 New Relic株式会社。
採用情報サービス利用規約DMCAポリシープライバシー通知Cookie ポリシー英国現代奴隷法

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.