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

이 한글 문서는 사용자의 편의를 위해 기계 번역되었습니다.

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

문제 신고

합성 작업 관리자 구성

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

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

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

스크립트에서 사용자 정의 환경 변수에 액세스

구성된 사용자 정의 환경 변수를 참조하려면 예약된 $env.USER_DEFINED_VARIABLES 다음에 점 표기법으로 지정된 변수 이름을 사용하십시오.

예를 들어, $env.USER_DEFINED_VARIABLES.MY_VARIABLE

주의

사용자 정의 환경 변수는 로그에서 삭제되지 않습니다. 민감한 정보에는 보안 자격 증명 기능을 사용하는 것이 좋습니다.

커스텀 노드 모듈

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

모듈을 설정하려면:

  1. 루트 폴더에 npm 공식 지침에 따라 package.json 파일이 포함된 디렉터리를 만듭니다. SJM은 package.json에 나열된 의존성/종속성을 설치합니다. dependencies 필드. 이러한 의존성/종속성은 개인 신세틱스 작업 관리자에서 모니터를 실행할 때 사용할 수 있습니다. 아래의 예를 참조하세요.
  1. 사용자 정의 모듈 디렉터리와 package.json을 생성한 후 이를 docker 및 Kubernetes 용 SJM에 적용합니다.

  2. 모듈이 올바르게 설치되었는지 또는 오류가 발생했는지 확인하려면 SJM 로그 에서 "... Initialization of Custom Modules ..." 섹션을 검토하세요. 이러한 로그에는 npm 설치 로그가 포함되어 설치 프로세스 및 발생한 잠재적 오류에 관한 정보를 제공합니다.

이제 이 개인 위치로 보내는 모니터의 스크립트"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 에 마운트합니다.

예시:

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

Kubernetes

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

  1. 기존 PertantVolume(PV)에 대해 기존 PertantVolumeClaim(PVC)을 제공하고 synthetics.persistence.existingClaimName 구성 값을 설정합니다.

예시:

helm install ... --set synthetics.persistence.existingClaimName=sjm-claim ...
  1. 기존 PertantVolume(PV) 이름을 제공하고 synthetics.persistence.existingVolumeName 구성 값을 설정합니다. Helm은 사용자를 위해 PVC를 생성합니다.

사용자는 선택적으로 다음 값을 설정할 수도 있습니다.

  • synthetics.persistence.storageClass: 기존 PV의 스토리지 클래스입니다. 제공되지 않으면 Kubernetes는 기본 스토리지 클래스를 사용합니다.
  • synthetics.persistence.size: 청구의 크기입니다. 설정하지 않은 경우 기본값은 현재 2Gi입니다.
helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

환경 변수

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

Kubernetes 및 Docker에 대한 크기 조정 고려 사항

Docker 특정 크기 고려 사항은 곧 제공될 예정입니다.

대규모 환경에서 작업하는 경우 합성 모니터를 효율적으로 실행하기 위한 최소 요구 사항을 충족하도록 작업 관리자 구성을 사용자 지정해야 할 수 있습니다. 다음을 포함하여 많은 요소가 합성 작업 관리자 배포의 크기 요구 사항에 영향을 줄 수 있습니다.

  • 예상 사용량에 따라 모든 런타임이 필요한 경우
  • 모니터 유형(ping, 단순 또는 스크립트 브라우저, 스크립트 API)별 분당 작업 수
  • 작업 시간(약 3분에 시간 초과되는 작업 포함)
  • 작업 실패 횟수입니다. 작업 실패의 경우 모니터가 내장된 3/3 재시도 논리를 제공하는 데 실패하기 시작할 때 자동 재시도가 예약됩니다. 이러한 추가 작업은 합성 작업 관리자의 처리량 요구 사항에 추가됩니다.

아래 나열된 크기 조정 구성 설정 외에도 동일한 개인 위치 키로 추가 합성 작업 관리자를 배포하여 여러 환경에서 작업 부하를 분산할 수 있습니다.

Kubernetes

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

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

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

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 작업 기간은 포드를 완료하는 데 걸리는 시간과 분당 실행해야 하는 합성 작업 수(작업 속도)의 가변성을 설명하기 위한 보수적인 목표입니다. 다음 방정식은 각 런타임에 대한 completionsparallelism 의 시작점으로 사용될 수 있습니다. 개인 위치 대기열 증가에 대한 관찰을 기반으로 조정이 필요할 수 있습니다.

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분 이상이고(충분한 완료) 큐가 증가하지 않을 때까지(충분한 병렬 처리) completionsparallelism 에 대해 몇 가지 다른 값을 시도해 보십시오.

예시

설명

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 © 2024 New Relic Inc.

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