합성 작업 관리자 구성

이 문서는 다음 방법을 보여줌으로써 신세틱스 작업 관리자를 구성하는 과정을 안내합니다.

• 환경 변수를 사용하여 신세틱스 작업 관리자를 구성하세요.
• 스크립트 API 또는 스크립트 브라우저 모니터에 대한 사용자 정의 모듈을 설정합니다.
• 설정에 사용자 정의 변수를 제공하세요.

환경변수를 이용한 설정

환경 변수를 사용하면 특정 환경 및 기능 요구 사항을 충족하도록 합성 작업 관리자 구성을 미세 조정할 수 있습니다.

스크립트 모니터에 대한 사용자 정의 변수

개인 신세틱스 작업 관리자를 사용하면 스크립트된 모니터에 대한 환경 변수를 구성할 수 있습니다. 이러한 변수는 SJM에서 로컬로 관리되며 $env.USER_DEFINED_VARIABLES 통해 액세스할 수 있습니다. 사용자 정의 변수는 두 가지 방법으로 설정할 수 있습니다. 등장에서 JSON 파일을 마운트하거나 SJM에 환경 변수를 제공할 수 있습니다. 둘 다 제공되는 경우 SJM은 환경에서 제공되는 값만 사용합니다.

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

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

$
podman run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw,z ...

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

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

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

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

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

커스텀 노드 모듈

맞춤형 노드 모듈은 분당호출수와 SJM 모두에서 제공됩니다. 이를 통해 사용자 정의된 노드 모듈 세트를 생성하고 이를 신세틱 모델링을 위한 스크립트 모니터(스크립트 API 및 스크립트 브라우저)에서 사용할 수 있습니다.

사용자 정의 모듈 디렉토리 설정

루트 폴더에 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에 사용자 정의 모듈 디렉토리를 추가합니다.

$
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...

$
podman run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw,z ...

모듈이 올바르게 설치되었는지 또는 오류가 발생했는지 확인하려면 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은 설정 변경을 인식하고 자동으로 정리 및 재설치 작업을 수행하여 업데이트된 모듈이 적용되도록 합니다.

영구 데이터 저장

사용자는 user_defined_variables.json 파일을 제공하거나 사용자 정의 노드 모듈을 지원하기 위해 영구 데이터 저장소를 사용하고 싶어할 수 있습니다.

도커

Docker에서 영구 데이터 저장소를 설정하려면:

1. 작업 관리자를 실행하는 호스트에 디렉터리를 만듭니다. 이것이 소스 디렉터리입니다.

2. Job Manager에서 소스 디렉터리를 뻐, 목표 디렉터리 /var/lib/newrelic/synthetics 에 마운트합니다.

   예시:

   bash

   카피

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

포드만

Podman에 영구 데이터 저장소를 설정하려면:

1. 작업 관리자를 실행하는 호스트에 디렉터리를 만듭니다. 이것이 소스 디렉터리입니다.
2. Job Manager에서 소스 디렉터리를 뻐, 목표 디렉터리 /var/lib/newrelic/synthetics 에 마운트합니다.

예시:

$
podman run ... -v /sjm-volume:/var/lib/newrelic/synthetics:rw,z ...

Kubernetes

Kubernetes에 영구 데이터 저장소를 설정하기 위해 사용자에게는 두 가지 옵션이 있습니다.

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

Sizing considerations for Docker and Podman

방정식이 효율적으로 실행되도록 하려면 호스트에서 모니터링 워크로드를 처리할 만큼 충분한 CPU 리소스를 프로비저닝해야 합니다. 사이즈에 영향을 미치는 요소는 많지만, 귀하의 필요 사항을 빠르게 예측할 수 있습니다. 중량급 모니터(예: 간단한 브라우저, 스크립트 브라우저 또는 스크립트 API 모니터) 하나당 CPU 코어 1개가 필요합니다. 현재 설정을 진단하거나 향후 설정을 계획하는 경우 필요한 코어 수를 계산하는 데 도움이 되는 두 가지 공식은 다음과 같습니다.

공식 1: 기존 위치 진단

현재 사용하고 있는 가상화 로케이션이 따라잡기 힘들고 작업이 대기하고 있다고 의심되는 경우, 이 공식을 사용하여 실제로 필요한 코어 수를 확인하세요. 이는 시스템의 관찰 가능한 성능에 따라 결정됩니다.

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

• $C\_req$ = 필요한 CPU 코어.
• $R\_proc$ = 분당 처리 되는 중량 작업의 비율 입니다.
• $R\_growth$ = jobManagerHeavyweightJobs 대기열이 분당 증가하는 속도 입니다.
• $D\_avg,m$ = 중량 작업의 평균 소요 시간 (분) 입니다.

This formula calculates your true job arrival rate by adding the jobs your system is processing to the jobs that are piling up in the queue. Multiplying this total load by the average job duration tells you exactly how many cores you need to clear all the work without queuing.

공식 2: 새 위치 또는 미래 위치 예측

새로운 위치 위치를 설정하거나 더 많은 모니터를 추가할 계획이라면 이 공식을 사용하여 요구 사항을 미리 예측하세요.

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

• $C\_req$ = 필요한 CPU 코어.
• $N\_mon$ = 실행하려는 중량 모니터 의 총 수 입니다.
• $D\_avg,m$ = 중량 작업의 평균 소요 시간 (분) 입니다.
• $P\_avg,m$ = 중량 모니터의 평균 기간 (분) (예: 5분마다 실행되는 모니터의 경우 $P\_avg,m = 5$).

This calculates your expected workload from first principles: how many monitors you have, how often they run, and how long they take.

중요한 크기 요소

이러한 공식을 사용할 때는 다음 요소를 고려해야 합니다.

• 작업 기간($D\_avg,m$): 평균에는 시간 초과 된 작업(대개 ~3분)도 포함되어야 합니다. 이러한 작업은 전체 기간 동안 핵심을 유지합니다.
• 작업 실패 및 재시도: 모니터가 실패하면 자동으로 재시도됩니다. 이러한 재시도는 전체 부하를 증가시키는 추가 작업입니다. 지속적으로 실패하고 재시도하는 모니터는 주기를 늘려 처리량에 상당한 영향을 미칩니다.
• 스케일 아웃: 호스트에 더 많은 코어를 추가하는 것(스케일 업) 외에도 동일한 독립 로케이션 키를 사용하여 추가 신세틱스 작업 관리자를 구현하고 배치하여 여러 환경에 걸쳐 작업의 로드 밸런싱을 수행할 수 있습니다(스케일 아웃).

단일 신세틱스 Job Manager(SJM)는 분당 약 15개의 중량 작업을 처리할 수 있는 처리량 제한이 있다는 점에 유의하는 것이 중요합니다. 이는 SJM당 처리되는 작업의 순수한 개수보다 여러 SJM 간의 작업의 효율적인 경쟁을 선호하는 내부 스레딩 전략 때문입니다. 계산 결과 더 높은 처리량이 필요하다는 것을 나타내는 경우 추가 SJM을 구현, 배포하여 확장 해야 합니다. 작업 대기열이 늘어나는지 확인하여 더 많은 SJM이 필요한지 확인할 수 있습니다.

동일한 위치 위치 키를 사용하여 더 많은 SJM을 추가하면 다음과 같은 이점이 있습니다.

• 로드 밸런싱: 고립로케이션에 대한 작업은 사용 가능한 모든 SJM에 분산됩니다.
• 장애 조치 보호: 하나의 SJM 인스턴스가 다운되더라도 다른 인스턴스가 작업을 계속 처리할 수 있습니다.
• 더 높은 총 처리량: 상대 로케이션에 대한 총 처리량은 각 SJM의 처리량의 합이 됩니다(예: 2개의 SJM은 분당 최대 30개의 작업을 제공합니다).

진단을 위한 NRQL 쿼리

진단 공식에 대한 입력을 얻으려면 쿼리 빌더 에서 이러한 쿼리를 실행할 수 있습니다. 안정적인 평균을 얻으려면 시간 범위를 충분히 길게 설정하세요.

1. Find the rate of jobs processed per minute ($R\_proc$): This query counts the number of non-ping (heavyweight) jobs completed over the last day and shows the average rate per minute.

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

2. Find the rate of queue growth per minute ($R\_growth$): This query calculates the average per-minute growth of the jobManagerHeavyweightJobs queue on a time series chart. A line above zero indicates the queue is growing, while a line below zero means it's shrinking.

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

3. Find total number of heavyweight monitors ($N\_mon$): This query finds the unique count of heavyweight monitors.

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

4. Find average job duration in minutes ($D\_avg,m$): This query finds the average execution duration of completed non-ping jobs and converts the result from milliseconds to minutes. executionDuration represents the time the job took to execute on the host.

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

5. 평균 헤비급 감시 기간($P\_avg,m$) 찾기: 처리로케이션의 jobManagerHeavyweightJobs 큐가 증가하는 경우 기존 결과에서 평균 감시 기간을 계산하는 것은 정확하지 않습니다. 이는 Synthetic Monitor 페이지의 모니터 목록에서 추산해야 합니다. 올바른 뉴렐릭 계정을 선택했는지 확인하고 privateLocation 로 필터링해야 할 수도 있습니다.

ping 모니터 및 pingJobs 대기열에 대한 참고 사항

Ping 모니터는 다릅니다. 각각 전체 CPU 코어를 소모하지 않는 가벼운 작업입니다. 대신 별도의 대기열(pingJobs)을 사용하고 작업자 스레드 풀에서 실행됩니다.

ping 작업은 리소스를 덜 사용하지만, 특히 실패하는 작업의 경우 ping 작업량이 많으면 여전히 성능 문제가 발생할 수 있습니다. 다음 사항을 명심하세요.

• 리소스 모델: Ping 작업은 전용 CPU 코어가 아닌 작업자 스레드를 활용합니다. 이러한 경우에는 작업당 코어 계산이 적용되지 않습니다.
• 시간 초과 및 재시도: 실패한 ping 작업은 최대 60초 동안 작업자 스레드를 차지할 수 있습니다. 먼저 HTTP HEAD 요청을 시도합니다(제한 시간 30초). 실패하면 즉시 HTTP GET 요청으로 재시도합니다(30초의 시간 초과).
• 크기 조정: 크기 조정 공식은 다르지만 동일한 원칙이 적용됩니다. 대량의 ping 작업을 처리하고 pingJobs 대기열이 커지는 것을 방지하려면 확장 및/또는 확장이 필요할 수 있습니다. 확장은 호스트나 네임스페이스당 CPU와 메모리 리소스를 늘리는 것을 의미합니다. 확장은 ping 런타임 인스턴스를 더 추가하는 것을 의미합니다. 이는 더 많은 호스트, 더 많은 라벨스페이스 또는 동일한 라벨스페이스 내에서 구현하다, 배포하다 더 많은 작업 관리자를 통해 수행될 수 있습니다. 또는 Kubernetes 의 ping-runtime 을 사용하면 구현, 배포당 더 많은 수의 복제본을 설정할 수 있습니다.

Sizing considerations for Kubernetes and OpenShift

Kubernetes와 OpenShift 합성 작업 관리자가 사용하는 각 런타임은 helm 차트 에서 값을 설정하여 독립적으로 크기를 조정할 수 있습니다. node-api-runtime 과 node-browser-runtime은 parallelism 및 completions 설정의 조합을 사용하여 독립적으로 크기가 조정됩니다.

• The parallelism setting controls how many pods of a particular runtime run concurrently.
• The completions setting controls how many pods must complete before the CronJob starts another Kubernetes Job for that runtime.

How to Size Your Deployment: A Step-by-Step Guide

Your goal is to configure enough parallelism to handle your job load without exceeding the throughput limit of your SJM instances.

Step 1: Estimate Your Required Workload

Completions: This determines how many runtime pods should complete before a new Kubernetes Job is started.

First, determine your private location's average job execution duration and job rate. Use executionDuration as it most accurately reflects the pod's active runtime.

-- Get average job execution duration (in seconds)
FROM SyntheticCheck
SELECT average(executionDuration / 60e3) AS 'D_avg_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ Completions = \frac5D_avg,m $$

Where $D\_avg,m$ is your average job execution duration in seconds.

Required Parallelism: This determines how many workers (pods) you need running concurrently to handle your 5-minute job load.

-- Get jobs per 5 minutes
FROM SyntheticCheck
SELECT rate(uniqueCount(id), 5 minutes) AS 'N_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ P_req = \fracN_mCompletions $$

Where $N\_m$ is your number of jobs per 5 minutes. This $P\_req$ value is your target total parallelism.

Step 2: Check Against the Single-SJM Throughput Limit

Max Parallelism: This determines how many workers (pods) your SJM can effectively utilize.

$$ P_max \approx 15 \cdot D_avg,m $$

This $P\_max$ value is your system limit for one SJM Helm deployment.

Step 3: Compare, Configure, and Scale

Compare your required parallelism ($P\_req$) from Step 1 to the maximum parallelism ($P\_max$) from Step 2.

Scenario A: $P\_req \le P\_max$

• Diagnosis: Your job load is within the limit of a single SJM instance.

• Action:

  1. You will deploy one SJM Helm release.
  2. In your Helm chart values.yaml, set parallelism to your calculated $P\_req$.
  3. Set completions to your calculated Completions. For improved efficiency, this value should typically be 6-10x your parallelism setting.

Scenario B: P\_req > P\_max

• Diagnosis: Your job load exceeds the ~15 jobs/minute limit of a single SJM.

• Action:

  1. You must scale out by deploying multiple, separate SJM Helm releases.
  2. See the Scaling Out with Multiple SJM Deployments section below for the correct procedure.
  3. Do not increase the replicaCount in your Helm chart.

Step 4: Monitor Your Queue

After applying your changes, you must verify that your job queue is stable and not growing. A consistently growing queue means your location is still under-provisioned.

Run this query to check the queue's growth rate:

-- Check for queue growth (a positive value means the queue is growing)
SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'Heavyweight Queue Growth Rate (per min)'
FROM SyntheticsPrivateLocationStatus
WHERE name = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago TIMESERIES

If the "Queue Growth Rate" is consistently positive, you need to install more SJM Helm deployments (Scenario B) or re-check your parallelism settings (Scenario A).

Configuration Examples and Tuning

The parallelism setting directly affects how many synthetics jobs per minute can be run. Too small a value and the queue may grow. Too large a value and nodes may become resource constrained.

If your parallelism setting is working well (keeping the queue at zero), setting a higher completions value (e.g., 6-10x parallelism) can improve efficiency by:

• Accommodating variability in job durations.
• Reducing the number of completion cycles to minimize the "nearing the end of completions" inefficiency where the next batch can't start until the final job from the current batch completes.

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

Scaling out with multiple SJM deployments

To scale beyond the ~15 jobs/minute throughput of a single SJM, you must install multiple, separate SJM Helm releases.

The correct strategy is to deploy multiple SJM instances, each as its own Helm release. Each SJM will compete for jobs from the same private location, providing load balancing, failover protection, and an increased total job throughput.

Simplified Scaling Strategy

Assuming P\_req > P\_max and you need to scale out, you can simplify maintenance by treating each SJM deployment as a fixed-capacity unit.

1. Set Max Parallelism: For each SJM, set parallelism to the same $P\_max$ value. This maximizes the potential throughput of each SJM.

2. Set Completions: For each SJM, set completions to a fixed value as well. The $P\_req$ formula from Step 1 can be modified to estimate completions by substituting in the $P\_max$ value:

   $$ Completions = \fracN_mP_max $$

   Where $N\_m$ is your number of jobs per 5 minutes. Adjust as needed after deploying to target a 5 minute Kubernetes job age per runtime, i.e., node-browser-runtime and node-api-runtime.

3. Install Releases: Install as many separate Helm releases as you need to handle your total $P\_req$. For example, if your total $P\_req$ is 60 and you've fixed each SJM's parallelism at 20 ($P\_max$ from Step 2), you would need three separate Helm deployments to meet the required job demand.

4. Monitor and Add: Monitor your job queue (see Step 4). If it starts to grow, simply install another Helm release (e.g., sjm-delta) using the same fixed configuration.

By fixing parallelism and completions to static values based on $P\_max$, increasing or decreasing capacity becomes a simpler process of adding or removing Helm releases. This helps to avoid wasting cluster resources on a parallelism value that is higher than the SJM can effectively utilize.

Installation Example

When installing multiple SJM releases, you must provide a unique name for each release. All instances must be configured with the same private location key.

Setting the fullnameOverride is highly recommended to create shorter, more manageable resource names. For example, to install two SJMs named sjm-alpha and sjm-beta into the newrelic namespace (both using the same values.yaml with your fixed parallelism and completions):

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

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

You can continue this pattern (sjm-charlie, sjm-delta, etc.) for as many SJMs as needed to keep the job queue from growing.