構成で環境変数を使用して、合成ジョブ マネージャーを構成する方法について説明します。
重要
カスタム モジュール、 永続データ ストレージ、およびユーザー定義の環境変数は、現時点では外形監視ジョブ マネージャーではサポートされていません。
注意として、New Relic は、Synthetics ジョブ マネージャー ファイルに加えた変更について責任を負いません。
環境変数
環境変数を使用すると、合成ジョブ マネージャーの構成を微調整して、特定の環境および機能のニーズを満たすことができます。
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 minute / completionsランタイムが異なれば、合成ジョブの期間と速度も異なる可能性があります。次のクエリを使用して、プライベート ロケーションの平均期間と料金を取得できます。
# non-ping average job duration by runtime typeFROM 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 typeFROM SyntheticCheck SELECT rate(uniqueCount(id), 1 minute) AS 'jobs per minute' WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour agoヒント
上記のクエリは現在の結果に基づいています。プライベート ロケーションに結果がない場合、またはジョブ マネージャーが最高のパフォーマンスを発揮していない場合、クエリ結果は正確ではない可能性があります。その場合、 kubectl get jobs -n YOUR_NAMESPACE 継続時間が少なくとも 5 分 (十分な完了)、キューが増大しない (十分な並列処理) ことが確認されるまで、 completions と parallelism にいくつかの異なる値を試します。
例 | 説明 |
|---|---|
| ランタイムは 1 分あたり 1 つの合成ジョブを実行します。1 つのジョブが完了すると、次の分に |
| ランタイムは一度に 1 つの合成ジョブを実行します。ジョブが完了すると、新しいジョブがすぐに開始されます。 |
| ランタイムは 3 つの合成ジョブを一度に実行します。これらのジョブのいずれかが完了すると、新しいジョブがすぐに開始されます。 |
合成ジョブの完了に時間がかかる場合、ジョブで 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