구성에서 환경 변수 를 사용하여 합성 작업 관리자 를 구성하는 방법을 알아봅니다.
중요
현재 신세틱스 작업 관리자에서는 사용자 정의 모듈, 영구 데이터 저장소 및 사용자 정의 환경 변수가 지원되지 않습니다.
참고로 New Relic은 합성 작업 관리자 파일에 대한 수정 사항에 대해 책임을 지지 않습니다.
환경 변수
환경 변수를 사용하면 특정 환경 및 기능 요구 사항을 충족하도록 합성 작업 관리자 구성을 미세 조정할 수 있습니다.
Kubernetes 및 Docker에 대한 크기 조정 고려 사항
팁
Docker 특정 크기 고려 사항은 곧 제공될 예정입니다.
대규모 환경에서 작업하는 경우 합성 모니터를 효율적으로 실행하기 위한 최소 요구 사항을 충족하도록 작업 관리자 구성을 사용자 지정해야 할 수 있습니다. 다음을 포함하여 많은 요소가 합성 작업 관리자 배포의 크기 요구 사항에 영향을 줄 수 있습니다.
- 예상 사용량에 따라 모든 런타임이 필요한 경우
- 모니터 유형(ping, 단순 또는 스크립트 브라우저, 스크립트 API)별 분당 작업 수
- 작업 시간(약 3분에 시간 초과되는 작업 포함)
- 작업 실패 횟수입니다. 작업 실패의 경우 모니터가 내장된 3/3 재시도 논리를 제공하는 데 실패하기 시작할 때 자동 재시도가 예약됩니다. 이러한 추가 작업은 합성 작업 관리자의 처리량 요구 사항에 추가됩니다.
아래 나열된 크기 조정 구성 설정 외에도 동일한 개인 위치 키로 추가 합성 작업 관리자를 배포하여 여러 환경에서 작업 부하를 분산할 수 있습니다.
Kubernetes
Kubernetes 합성 작업 관리자가 사용하는 각 런타임은 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 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개의 합성 작업을 실행합니다. 작업이 완료되면 새 작업이 즉시 시작됩니다. |
| 런타임은 한 번에 3개의 합성 작업을 실행합니다. 이러한 작업이 완료되면 새 작업이 즉시 시작됩니다. |
합성 작업을 완료하는 데 시간이 더 오래 걸리면 작업으로 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