• /
  • EnglishEspañolFrançais日本語한국어Português
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하시기 바랍니다.

문제 신고

합성 작업 관리자 구성

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

환경변수를 이용한 설정

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

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

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

모듈이 올바르게 설치되었는지 또는 오류가 발생했는지 확인하려면 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에서 영구 데이터 저장소를 설정하려면:

  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 에 마운트합니다.

예시:

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

도커, Podman, Kubernetes 및 OpenShift에 대한 크기 고려 사항

도커와 포드맨

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

공식 1: 기존 위치 진단

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

방정식:

C_req=(R_proc+R_growth)×D_avg,mC\_req = (R\_proc + R\_growth) \times D\_avg,m

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

작동 원리는 다음과 같습니다. 이 공식은 시스템 에서 처리 중인 작업과 대기열에 쌓인 작업을 더하여 실제 작업 도착률을 계산합니다. 이 총 부하를 평균 작업 기간에 곱하면 대기열에 넣지 않고 모든 작업을 완료하는 데 필요한 코어 수를 정확히 알 수 있습니다.

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

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

방정식:

C_req=N_mon×D_avg,m×1P_avg,mC\_req = N\_mon \times D\_avg,m \times \frac1P\_avg,m

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

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

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

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

진단을 위한 NRQL 쿼리

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

1. 분당 처리된 작업 속도 찾기(R_procR\_proc): 이 쿼리는 지난 하루 동안 완료된 핑이 없는(중량급) 작업의 수를 세고 분당 평균 속도를 보여줍니다.

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. 분당 대기열 증가율(R_growthR\_growth) 찾기: 이 쿼리는 시계열 차트에서 jobManagerHeavyweightJobs 대기열의 분당 평균 증가율을 계산합니다. 0보다 큰 선은 대기열이 늘어나고 있음을 나타내고, 0보다 작은 선은 대기열이 줄어들고 있음을 나타냅니다.

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

팁

해당 로그인이 존재하는 계정을 선택하세요. 파생 함수가 크게 달라질 수 있으므로 이 쿼리를 시계열로 보는 것이 가장 좋습니다. 목표는 분당 대기열 증가율을 추정하는 것입니다. 다양한 시간 범위를 적용해 보고 어떤 것이 가장 효과적인지 확인 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): 이 쿼리는 완료된 비핑 작업의 평균 실행 기간을 찾고 결과를 밀리초에서 분으로 변환합니다. 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 큐가 증가하는 경우 기존 결과에서 평균 감시 기간을 계산하는 것은 정확하지 않습니다. 이는 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 을 사용하면 구현, 배포당 더 많은 수의 복제본을 설정할 수 있습니다.

Kubernetes 와 오픈시프트

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

런타임 크기를 조정할 때 고려해야 할 주요 사항은 단일 SJM 인스턴스의 최대 처리량이 분당 약 15개의 중량 작업 (스크립트 API 및 브라우저 모니터)이라는 것입니다. 이는 SJM당 처리되는 작업의 순수한 개수보다 여러 SJM 간의 작업의 효율적인 경쟁을 선호하는 내부 스레딩 전략 때문입니다.

이 처리량 상한에 도달하기 전에 단일 SJM에 대한 최대 유효 parallelism 계산하려면 평균 작업 기간을 사용할 수 있습니다.

평행도∗최대\약15×D∗avg,m평행도*최대 \약 15 \times D*avg,m

여기서 D_avg,mD\_avg,m은 분 단위 의 평균 중량 작업 기간 입니다.

모니터링 요구 사항이 이 최대 15개 작업/분 제한을 초과하는 경우 구현하다, 배포하다 여러 SJM을 사용하여 확장 해야 합니다. 작업 대기열이 커지는지 확인하여 더 많은 인스턴스가 필요한지 알아볼 수 있습니다.

parallelism 설정은 특정 런타임의 파드가 동시에 실행되는 횟수를 제어하며, 도커 및 Podman SJM의 HEAVYWEIGHT_WORKERS 환경 변수와 동일합니다. completions 설정은 CronJob 이 해당 런타임에 대해 다른 Kubernetes 작업을 시작하기 전에 특정 런타임의 파드가 얼마나 완료되어야 하는지 제어합니다. 효율성을 향상시키려면 completions parallelism 값의 6~10배로 설정해야 합니다.

다음 방정식은 각 런타임에 대한 completions 및 parallelism 의 시작점으로 사용할 수 있습니다.

완료=300D_avg,s완료 = \frac300D\_avg,s

여기서 D_avg,sD\_avg,s는 평균 작업 기간 초 입니다.

평행도=\fracN_m완료평행도 = \fracN\_m완료

여기서 N_mN\_m은 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개의 작업이 완료된 후 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분을 채우는 데 필요한 완료 횟수가 줄어들지만 더 많은 병렬 포드가 필요합니다. 마찬가지로, 분당 더 많은 합성 작업을 처리해야 하는 경우 더 많은 병렬 포드가 필요합니다. parallelism 설정은 분당 실행할 수 있는 합성 작업 수에 직접적인 영향을 미칩니다. 값이 너무 작으면 대기열이 커질 수 있습니다. 값이 너무 크면 노드에 리소스가 제한될 수 있습니다.

parallelism 설정이 제대로 작동하여 대기열을 0으로 유지하는 경우 300 / avg job duration 에서 계산된 값보다 completions 에 더 높은 값을 설정하면 몇 가지 방법으로 효율성을 향상시키는 데 도움이 될 수 있습니다.

  • 최소 1분은 최소 CronJob 기간인 합성 작업으로 채워지도록 작업 기간의 가변성을 수용합니다.
  • 완료 주기 수를 줄여 최종 작업이 완료될 때까지 다음 완료 세트를 시작할 수 없는 "완료가 거의 끝나가는" 비효율성을 최소화합니다.

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

팁

뉴렐릭은 신세틱스 작업 관리자 파일에 대한 수정 사항에 대해 책임을 지지 않습니다.

여러 SJM 인스턴스로 확장

더 높은 총 처리량을 달성하려면 동일한 Kubernetes 네임스페이스에 여러 SJM Helm 릴리스를 설치할 수 있습니다. 각 SJM은 로드 밸런싱, 장애 조치 보호 및 증가된 총 작업 처리량을 제공하여 동일한 위치의 작업을 놓고 경쟁합니다.

여러 개의 SJM 릴리스를 설치하는 경우 각 릴리스에 고유한 이름을 제공해야 합니다. 모든 외부는 해당 values.yaml 파일에서 동일한 독립 로케이션 키로 구성되어야 합니다. 필수는 아니지만 더 짧고 관리하기 쉬운 리소스 이름을 만들려면 fullnameOverride 설정하는 것이 좋습니다.

예를 들어, sjm-alpha 및 sjm-beta 이라는 두 개의 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에 대해 평균 작업 기간과 인스턴스당 분당 약 15개 작업 제한을 기준으로 parallelism 및 completions 합리적인 값으로 설정합니다.

Copyright © 2025 New Relic Inc.
채용정보서비스 이용약관DMCA 정책개인정보 고지쿠키 정책영국 현대판 노예법

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