• /
  • 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 ...

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

ヒント

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

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

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

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

KubernetesとOpenShift

Kubernetes および OpenShift 合成ジョブ マネージャーによって使用される各ランタイムは、 Helm チャートで値を設定することで個別にサイズを変更できます。

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

合成ジョブの完了に時間がかかる場合、ジョブで 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責任を負わないことにご注意ください。

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

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