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

도커, Kubernetes, 오픈시프트 크기 고려 사항

도커

쿼터 로케이션이 효율적으로 실행되도록 하려면 도커 호스트에서 모니터링 워크로드를 처리할 수 있을 만큼 충분한 CPU 리소스를 프로비저닝해야 합니다. 사이즈에 영향을 미치는 요소는 많지만, 귀하의 필요 사항을 빠르게 예측할 수 있습니다.

동시에 실행되는 중량 모니터(즉, 스크립트화된 브라우저나 스크립트화된 API 테스트)마다 CPU 코어 1개가 필요합니다.

현재 설정을 진단하거나 향후 설정을 계획하는 경우 필요한 코어 수를 계산하는 데 도움이 되는 두 가지 공식은 다음과 같습니다.

공식 1: 기존 위치 진단용

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

방정식: $$C_req = (J_processed + Q_growth) \times D_j$$

  • $C_req$ = 필요한 CPU 코어 수
  • $J_processed$ = 분당 처리 되는 작업의 속도.
  • $Q_growth$ = jobManagerHeavyweightJobs 대기열이 분당 증가하는 속도입니다.
  • $D_j$ = 작업의 평균 소요 시간 (분)입니다.

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

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

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

방정식: $$C_req = N_m \times F_j \times D_j$$

  • $C_req$ = 필요한 CPU 코어 수
  • $N_m$ = 실행하려는 중량 모니터의 총 수입니다 .
  • $F_j$ = 분당 작업의 모니터 평균 빈도 (예: 5분마다 실행되는 모니터의 빈도는 1/5 또는 0.2입니다).
  • $D_j$ = 작업의 평균 소요 시간 (분)입니다.

작동 방식은 다음과 같습니다. 이는 첫 번째 원칙, 즉 쿼리 수, 실행 빈도, 실행 시간으로부터 예상되는 오류를 계산합니다.

중요한 크기 요소

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

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

진단을 위한 NRQL 쿼리

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

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

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. 분당 대기열 증가율 찾기($Q_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. 평균 작업 기간(분) 찾기($D_j$): 이 쿼리는 완료된 비핑 작업의 평균 실행 기간을 찾고 그 결과를 밀리초에서 분으로 변환합니다. executionDuration 사용하는 이유는 무엇입니까? 이는 호스트에서 작업을 실행하는 데 걸리는 시간을 나타내며, 이를 측정하고자 합니다.

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

4. 중량 모니터의 총 수($N_m$)를 찾습니다. 이 쿼리는 중량 모니터의 고유한 수를 찾습니다.

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

5. 평균 헤비급 모니터 빈도($F_j$) 찾기: 배열 위치의 jobManagerHeavyweightJobs 대기열이 증가하는 경우 기존 결과에서 평균 모니터 빈도를 계산하는 것은 정확하지 않습니다. 이는 Synthetic Monitor 페이지의 모니터 목록에서 추산해야 합니다. 올바른 뉴렐릭 계정을 선택했는지 확인하고 privateLocation 로 필터링해야 할 수도 있습니다.

팁

합성 모니터는 여러 하위 계정에 존재할 수 있습니다. 쿼리 빌더에서 선택할 수 있는 하위 계정보다 많은 하위 계정이 있는 경우, 모니터가 가장 많은 계정을 선택하세요.

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

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

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

  • 리소스 모델: Ping 작업은 전용 CPU 코어가 아닌 작업자 스레드를 활용합니다. 이러한 경우에는 작업당 코어 계산이 적용되지 않습니다.
  • 시간 초과 및 재시도: 실패한 ping 작업은 최대 60초 동안 작업자 스레드를 차지할 수 있습니다. 먼저 HTTP HEAD 요청을 시도합니다(제한 시간 30초). 실패하면 즉시 HTTP GET 요청으로 재시도합니다(30초의 시간 초과).
  • 크기 조정: 크기 조정 공식은 다르지만 동일한 원칙이 적용됩니다. 대량의 ping 작업을 처리하려면 호스트 리소스를 확장하거나 더 많은 작업 관리자를 구현, 배포하여 pingJobs 대기열을 비우고 지연을 방지해야 할 수도 있습니다.

Kubernetes 와 오픈시프트

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

기본값 1 에서 ping-runtime.replicaCount 설정을 늘려 핑 모니터 로드를 실행하는 데 도움이 되도록 추가 핑 런타임을 시작할 수 있습니다.

Node.js API 및 Node.js 브라우저 런타임은 parallelism 및 completions 설정의 조합을 사용하여 독립적으로 크기가 조정됩니다. 이러한 설정에 대한 이상적인 구성은 고객 요구 사항에 따라 달라집니다.

parallelism 설정은 특정 런타임의 Pod가 동시에 실행되는 수를 제어합니다. parallelism 설정은 컨테이너화된 프라이빗 미니언(CPM)의 synthetics.heavyWorkers 구성과 동일합니다. Kubernetes 클러스터에 리소스 요청 및 제한 값을 기반으로 이 수의 Pod를 실행하는 데 사용할 수 있는 충분한 리소스가 있는지 확인하세요.

completions 설정은 CronJob 가 해당 런타임에 대해 다른 Kubernetes 작업을 시작하기 전에 완료해야 하는 특정 런타임의 포드 수를 제어합니다. Kubernetes 작업(대문자 J)과 합성 모니터 작업의 차이점을 확인하세요. 효율성을 높이려면 completions parallelism 값의 6-10배로 설정해야 합니다. 이는 Kubernetes 작업이 모든 completions 가) 완료될 때까지 기다릴 때 parallelism 개 미만의 포드가 실행될 수 있는 "완료가 거의 끝나가는" 비효율성을 최소화하는 데 도움이 될 수 있습니다.

completions 가 1보다 크면 Kubernetes 작업에 정의된 모든 완료(예: 6/6 완료)가 충족될 때까지 '완료됨' 상태의 Pod가 kubectl get pods -n YOUR_NAMESPACE 출력에 계속 표시됩니다. Pod의 상태가 Completed 또는 Failed이면 노드에서 리소스가 해제됩니다.

5분(kubectl get jobs -n YOUR_NAMESPACE)의 Kubernetes 작업 기간은 포드를 완료하는 데 걸리는 시간과 분당 실행해야 하는 합성 작업 수(작업 속도)의 가변성을 설명하기 위한 보수적인 목표입니다. 다음 방정식은 각 런타임에 대한 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개의 작업이 완료된 후 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

팁

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

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

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