• /
  • 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のサイズ設定に関する考慮事項

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

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

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

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

  • C_estC\_est =推定 CPU コア数。
  • R_procR\_proc = 1 分あたりに処理される高負荷ジョブの速度。
  • R_growthR\_growth = jobManagerHeavyweightJobsキューが 1 分あたりに増加している**速度**。
  • D_avg,mD\_avg,m = 重いジョブの平均所要時間（分） 。

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

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

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

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

  • C_estC\_est =推定 CPU コア数。
  • N_monN\_mon = 実行を計画している重量級モニターの合計数。
  • D_avg,mD\_avg,m = 重いジョブの平均実行時間（分） 。
  • P_avg,mP\_avg,m = 重量モニターの平均期間(分単位) (たとえば、5 分ごとに実行されるモニターの場合、P_avg,m=5P\_avg,m = 5 になります)。

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

重要なサイズ決定要因

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

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

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

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

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

診断用のNRQL書き込み

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

1. 1 分あたりに処理されるジョブのレートを確認します (R_procR\_proc) : このクエリは、過去 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 分あたりのキュー増加率 (R_growthR\_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. 重量級モニターの合計数 (N_monN\_mon) を検索します。このクエリは、重量級モニターの一意の数を検索します。

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

4. 平均ジョブ実行時間を分単位で計算します (D_avg,mD\_avg,m) : このクエリは、完了した非 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

5. 平均ヘビーウェイト モニター期間 (P_avg,mP\_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使用すると、デプロイメントごとにより多くのレプリカを設定できます。

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

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

  • parallelism設定は、特定のランタイムのポッドが同時にいくつ実行されるかを制御します。
  • completions設定は、 CronJobがそのランタイムに対して別の Kubernetes ジョブを開始する前に完了する必要があるポッドの数を制御します。

デプロイメントのサイジングに最適なプラクティス

New Relicに表示される平均期間は正確ではない可能性があり、特に既存のプライベートロケーションがうまく機能していない場合は、必要な並列処理と完了の値を正確に計算できないことがよくあります。 並列処理と補完を調整するには、この実用的なアプローチに従ってください。以下の式を使用すると、開始時の大まかな値を取得できます。

1. 完了と並列性を見積もる

平均実行時間と 5 分あたりのジョブ数をできるだけ見積もってください。これにより、次のステップの大まかな開始点が提供されます。次のステップでは、動作中のクラスターで並列処理と完了の値を調整するために試行錯誤を行うことになります。たとえば、デフォルトの 1 と 6 から 10 と 60 に変更するなど、必ず比例して拡大縮小してください。

推定完了数: 5 分間のジョブ ロードが完了するまでにかかる時間を決定します。

-- Get average execution duration in minutes
FROM SyntheticCheck
SELECT average(executionDuration / 60e3) AS 'Avg Duration (min)'
WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago

$$ 完了数 = \frac5D_avg,m $$

ここで、D_avg,mD\_avg,m はジョブの平均実行時間（分）です。

推定並列処理: 5 分間のジョブ負荷を処理するために同時に実行する必要があるワーカー (ポッド) の数を決定します。

-- Get jobs per 5 minutes
FROM SyntheticCheck
SELECT rate(uniqueCount(id), 5 minutes) AS 'Number of monitor jobs per 5 minutes'
WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago

$$ P_est = \fracN_mCompletions $$

ここで、N_mN\_m は5 分あたりのジョブ数です。この P_estP\_est 値は推定された並列性です。

2. Helmデプロイを実行する

推定された並列処理と完了値、およびノードあたりの CPU コア数と 1 分あたりに実行する必要がある ping モニターの数に基づいて、 ping-runtime.replicaCount最適な推測を使用して Helm デプロイを実行します。

3. キューの増加を監視する

プライベートロケーションにジョブを送信するように合成モニターを構成し、 pingJobsとjobManagerHeavyweightJobsの時系列折れ線グラフでキューの増加を確認します。

  • pingJobsキューの傾きが正の場合、 ping-runtime.replicaCountを増やして再デプロイします。
  • jobManagerHeavyweightJobsキューの傾きが正の場合、キューの成長が止まるまで（負の傾き） parallelismとcompletions比例して増やします。

負の傾きは、ジョブ マネージャーがジョブの要求を処理するのに十分な並列処理能力を持っていることを示します。最終的には負の傾きでゼロに達します。

FROM SyntheticsPrivateLocationStatus
SELECT average(jobManagerHeavyweightJobs) AS 'Heavyweight Queue Growth', average(pingJobs) AS 'Ping Queue Growth'
WHERE name = 'YOUR_PRIVATE_LOCATION'
SINCE 1 day ago TIMESERIES

4. ポッドの実行状態に基づいて調整する

キューが減少しているかゼロになっている場合は、10 分以上「実行中」状態にあるポッドnode-api-runtimeとnode-browser-runtimeをチェックします。これは、並列処理が高すぎる設定になっており、必要以上のポッドがあることを示しています。

不必要にリソースを浪費しないようにするには、 parallelismとcompletionsを減らして、各「実行中」ランタイム ポッドの存続期間を短縮します。Kubernetes ジョブの経過時間を 5 分にすることを目標としている場合、ランタイム ポッドが実行状態にある時間は 5 分未満である必要があります。つまり、ポッドが作成され、実行するジョブをすぐに受信して完了している必要があります。

5. 必要に応じてスケールアウトする

キューが減少していないのに、10 分以上「実行中」状態にあるポッドが多数ある場合は、ジョブ マネージャーがパフォーマンスのボトルネックになっている可能性があります。次に行うことは、並列処理を減らし、1 つ以上の追加デプロイメントでスケール アウトすることです。

たとえば、 parallelism: 100 、 completions: 600ではキューがまだ増え続けていますが、10 分以上「実行中」状態のポッドが多数あり、Kubernetes ジョブの経過時間は 20 分です... parallelism: 50 、 completions: 200を設定し、さらに 2 つのデプロイメントを追加して水平方向にスケールアウトします。これにより、合計 150 個の並列ポッドが生成され、K8s ジョブの存続期間が 20 分未満に短縮されるとともに、長期間「実行中」のポッドの数も削減されます。K8s ジョブの AI モニタリングは 5 ～ 10 分です。

デプロイメントの追加の詳細については、 「複数の SJM デプロイメントによるスケールアウト」を参照してください。

ヒント

次のクエリを使用すると、スケールアウトする必要があるかどうかを判断できます。

注:モニターは複数のサブアカウントに存在できます。

-- monitors per minute per SJM
FROM SyntheticCheck SELECT
  round(rate(uniqueCount(id), 1 minute)/uniqueCount(minionId),0.1) AS 'heavy jobs per minute per SJM',
  uniqueCount(minionId) AS 'number of SJMs (namespaces)',
  round(rate(uniqueCount(id), 1 minute),0.1) AS 'heavy jobs per minute total'
WHERE minionContainerSystem = 'KUBERNETES' AND minionDeploymentMode = 'private' AND location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE' FACET location SINCE 1 hour ago TIMESERIES

ヒント

K8s ジョブ サイクルの数を減らすと、パフォーマンスも向上します。各サイクルが設定された完了数に達するにつれて、新しい外形監視ジョブを引き受ける「実行中の」ポッドはますます少なくなります。 たとえば、完了数を 200 に設定し、並列処理を 50 に設定すると、最初は 50 個のポッドが実行されますが、完了数が 150 を超えるとこの数は減少し始めます。199 回の完了で、実行中のポッドは 1 つだけ残ります。

補完に大きな値を設定することは悪い考えではありませんが、K8s で cronjob のTooManyMissedTimesに関する警告イベントが発生する可能性があります。

複数の SJM デプロイメントによるスケールアウト

単一の SJM の 1 分あたり約 15 ジョブのスループットを超えて拡張するには、複数の個別の SJM Helm リリースをインストールする必要があります。

重要

ジョブ マネージャー ポッドをスケーリングするためにレプリカを使用しないでください。SJMアーキテクチャーでは、ランタイムPodとその親SJM Podの間に1:1の関係が必要です。 ランタイム ポッドが間違った SJM レプリカ (Kubernetes サービス経由など) に結果を送り返すと、その結果は失われます。ただし、ping-runtime.replicaCount は使用しても問題ありません。

正しい戦略は、それぞれ独自の Helm リリースとして複数の SJM インスタンスをデプロイすることです。各 SJM は同じプライベート ロケーションからのジョブを巡って競合し、負荷分散、フェイルオーバー保護、および合計ジョブ スループットの増加を実現します。

水平スケーリング戦略

スケールアウトする必要がある場合は、各 SJM デプロイメントを固定容量ユニットとして扱うことでメンテナンスを簡素化できます。

  1. 並列処理の設定:*各*SJM について、 parallelism 、長期間実行される「実行中」のランタイム ポッドをあまり多く作成せずに単一の SJM が処理できるのと同じ最大値に設定します。これにより、リソースを無駄にすることなく、各 SJM の潜在的なスループットが最大化されます。
  2. 設定の完了:*各*SJM に対して、 completionsも同じ固定値に設定します。必要に応じて調整し、ランタイム (node-browser-runtime と node-api-runtime) ごとに 5 分の Kubernetes ジョブの経過時間をターゲットにします。
  3. リリースのインストール:ジョブの総需要を処理するために必要な数の個別の Helm リリースをインストールします。つまり、キューをゼロにしたり、折れ線グラフを負の傾きにしたりします。
  4. 監視および追加:プライベートロケーション ジョブ キューを監視します。 増加し始めた場合 (正の傾き)、同じ固定設定を使用して別のHelmリリース (例: sjm-delta) をインストールするだけです。

並列処理と完了を静的な値に固定することで、容量の増減がHelm リリースの追加または削除のプロセスとして簡単になります。これにより、SJM が効果的に利用できる並列処理値よりも高い並列処理値でクラスター リソースが無駄に消費されることを回避できます。

導入例

複数の SJM リリースをインストールする場合は、リリースごとに一意の名前を付ける必要があります。すべてのインスタンスは同じプライベートロケーションキーを使用して構成する必要があります。

より短く、管理しやすいリソース名を作成するには、 fullnameOverrideを設定することを強くお勧めします。たとえば、 sjm-alphaとsjm-betaという名前の 2 つの SJM をnewrelicネームスペースにインストールするには (両方とも固定並列処理と補完で同じvalues.yaml を使用します):

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

ジョブ キューが拡大しないように、必要な数の SJM に対してこのパターン (sjm-charlie 、 sjm-deltaなど) を継続できます。

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

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