합성 작업 관리자 구성

변수는 시작 시 -e, --env 인수를 사용하여 제공됩니다.

다음 표는 합성 작업 관리자가 지원하는 모든 환경 변수를 보여줍니다. PRIVATE_LOCATION_KEY 은 필수이고 다른 모든 변수는 선택 사항입니다.

변수는 시작 시 -e, --env 인수를 사용하여 제공됩니다.

다음 표는 신세틱스 작업 관리자가 지원하는 모든 환경 변수를 표시합니다. PRIVATE_LOCATION_KEY 필수이고, 다른 모든 변수는 선택 사항입니다. Podman 환경에서 신세틱스 작업 관리자를 실행하려면 최소 버전이 release-418 이상이어야 합니다.

변수는 시작 시 --set 인수를 사용하여 제공됩니다.

다음 목록은 합성 작업 관리자가 지원하는 모든 환경 변수를 보여줍니다. synthetics.privateLocationKey 은 필수이고 다른 모든 변수는 선택 사항입니다.

많은 추가 고급 설정을 사용할 수 있으며 Helm 차트 README 에 완전히 문서화되어 있습니다.

변수는 시작 시 --set 인수를 사용하여 제공됩니다.

다음 목록은 합성 작업 관리자가 지원하는 모든 환경 변수를 보여줍니다. synthetics.privateLocationKey 은 필수이고 다른 모든 변수는 선택 사항입니다.

많은 추가 고급 설정을 사용할 수 있으며 Helm 차트 README 에 완전히 문서화되어 있습니다.

사용자는 JSON 형식의 파일을 생성하고 해당 파일이 있는 볼륨을 SJM 컨테이너의 지정된 바구니, 목표 경로에 마운트할 수 있습니다.

파일에는 읽기 권한이 있어야 하며 JSON 형식의 맵이 포함되어 있어야 합니다. 사용자 정의 변수 파일의 예:

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

파일을 호스트의 소스 디렉터리에 배치합니다. SJM은 파일 이름이 user_define_variables.json이 될 것으로 예상합니다.

도커 예시:

예상되는 목표 디렉토리는 다음과 같습니다: /var/lib/newrelic/synthetics/variables/

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

포드만 예:

SELinux의 경우 :z 또는 :Z 사용하여 볼륨을 추가로 마운트합니다. 자세한 내용은 Podman 문서를 참조하세요. 예상되는 목표 디렉토리는 다음과 같습니다: /var/lib/newrelic/synthetics/variables/

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

쿠버네티스 예시:

사용자는 Kubernetes 의 SJM 패드에 파일을 제공할 때 두 가지 옵션이 있습니다. 그들은 아마도:

• 로컬 파일을 전달합니다.
• user_defined_variables.json 포함하는 PersistentVolume을 제공합니다.

로컬 파일 전달

이 옵션은 ConfigMap Kubernetes 리소스를 생성하고 이를 SJM 패드에 탑재합니다.

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

마운트하다 PersistentVolume

이 옵션을 사용하려면 사용자가 user_defined_variables.json 파일을 포함하는 PersistentVolume 또는 동일한 파일에 대한 PersistentVolumeClaim 를 제공해야 합니다. PersistentVolume 사용하여 헬름 차트 설치에 대한 자세한 내용은 영구 데이터 저장소 의 지침을 따르세요.

사용자가 아래 설명한 대로 PersistentVolume 을 준비하면 user_defined_variables.json 파일이 있는 경로를 설정하고 필요에 따라 다른 synthetics.persistence 변수를 설정하여 SJM을 릴리스합니다.

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

변수는 환경 변수를 통해 해당 컨테이너 시스템으로 전달될 수 있습니다.

도커 예시:

-e 플래그를 사용하여 USER_DEFINED_VARIABLES 이라는 환경 변수를 설정하고 여기에 JSON 형식의 맵 문자열 값을 제공합니다.

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

포드만 예:

-e 플래그를 사용하여 USER_DEFINED_VARIABLES 이라는 환경 변수를 설정하고 여기에 JSON 형식의 맵 문자열 값을 제공합니다.

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

쿠버네티스 예시:

--set-literal 플래그를 사용하여 JSON 형식의 문자열을 전달합니다.

$
helm install newrelic/synthetics-job-manager ... --set-literal synthetics.userDefinedVariables.userDefinedJson='{"key":"value","name":"sjm"}' ...

docker 의 경우 SJM이 /var/lib/newrelic/synthetics/modules에 디렉터리를 마운트합니다. 예를 들어:

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

Podman의 경우 SJM이 /var/lib/newrelic/synthetics/modules 에 디렉토리를 마운트합니다. SELinux의 경우 :z 또는 :Z 사용하여 볼륨을 추가로 마운트합니다. 자세한 내용은 Podman 문서를 참조하세요. 예를 들어:

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

Kubernetes의 경우 사용자 정의 모듈이 활성화된 SJM을 시작하기 전에 /var/lib/newrelic/synthetics/modules 의 디렉토리가 PV에 존재해야 합니다.

한 가지 방법은 사용자 정의 모듈 디렉토리를 PV에 복사하기 위해 PV를 마운트하는 파드를 만드는 것입니다. 다음 예제에서는 Amazon EKS와 함께 Amazon EFS를 사용합니다.

네임스페이스, 영구 볼륨 및 영구 볼륨 클레임을 생성합니다.

1. 클러스터에 EFS 파일 시스템을 설정하고 EFS CSI 드라이버를 설치했는지 확인하세요. PV의 spec.csi.volumeHandle 에 대한 EFS 파일 시스템 ID도 필요합니다.

   bash

   카피

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Namespace
   $
   metadata:
   $
     name: newrelic
   $
   
   $
   ---
   $
   kind: StorageClass
   $
   apiVersion: storage.k8s.io/v1
   $
   metadata:
   $
     name: efs-sc
   $
   provisioner: efs.csi.aws.com
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolume
   $
   metadata:
   $
     name: custom-modules-pvc
   $
   spec:
   $
     capacity:
   $
       storage: 5Gi
   $
     volumeMode: Filesystem
   $
     accessModes:
   $
       - ReadWriteMany
   $
     persistentVolumeReclaimPolicy: Retain
   $
     storageClassName: efs-sc
   $
     csi:
   $
       driver: efs.csi.aws.com
   $
       volumeHandle: <your-efs-filesystem-id>
   $
   
   $
   ---
   $
   apiVersion: v1
   $
   kind: PersistentVolumeClaim
   $
   metadata:
   $
     name: custom-modules-pvc
   $
     namespace: newrelic
   $
   spec:
   $
     accessModes:
   $
       - ReadWriteMany
   $
     storageClassName: efs-sc
   $
     resources:
   $
       requests:
   $
         storage: 5Gi
   $
   EOF

2. ~/.kube/config 의 newrelic 네임스페이스로 전환합니다.

   bash

   카피

   $
   kubectl config get-contexts
   $
   kubectl config set-context YOUR_CONTEXT --namespace=newrelic
   $
   kubectl config view --minify | grep namespace:

3. 이 시점에서 PVC는 RWX 액세스 모드로 PV에 바인딩되어야 합니다.

   bash

   카피

   $
   kubectl get pv,pvc
   NAME                                  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                         STORAGECLASS   VOLUMEATTRIBUTESCLASS   REASON   AGE
   persistentvolume/custom-modules-pvc   5Gi        RWX            Retain           Bound    newrelic/custom-modules-pvc   efs-sc         <unset>                          4m46s
   NAME                                       STATUS   VOLUME               CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
   persistentvolumeclaim/custom-modules-pvc   Bound    custom-modules-pvc   5Gi        RWX            efs-sc         <unset>                 4m10s

   사용자 정의 모듈 디렉토리를 복사하려면 mount-custom-mods-pod 생성하세요.

   bash

   카피

   $
   kubectl apply -f - <<EOF
   $
   apiVersion: v1
   $
   kind: Pod
   $
   metadata:
   $
     name: mount-custom-mods-pod
   $
   spec:
   $
     containers:
   $
     - name: mount-custom-mods-pod
   $
       image: nginx
   $
       resources:
   $
         requests:
   $
           memory: "64Mi"
   $
           cpu: "250m"
   $
         limits:
   $
           memory: "128Mi"
   $
           cpu: "500m"
   $
       volumeMounts:
   $
         - mountPath: "/var/lib/newrelic/synthetics/modules"
   $
           name: custom-modules-storage
   $
     volumes:
   $
     - name: custom-modules-storage
   $
       persistentVolumeClaim:
   $
         claimName: custom-modules-pvc
   $
   EOF

   이 시점에서 mount-custom-mods-pod 을 생성하고 볼륨을 사용하도록 구성해야 합니다.

   bash

   카피

   $
   kubectl describe po mount-custom-mods-pod | grep -A4 Volumes:
   Volumes:
     custom-modules-storage:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  custom-modules-pvc
       ReadOnly:   false

   PV, PVC 또는 mount-custom-mods-pod 와 관련된 경고가 있는지 이벤트를 확인하세요.

   bash

   카피

   $
   kubectl get events --field-selector type=Warning --sort-by='.lastTimestamp'

   사용자 정의 모듈 디렉토리를 PV에 복사하세요.

   node_modules 은 SJM에서 npm install 에 생성되므로 복사할 필요가 없습니다.

   bash

   카피

   $
   cd custom-modules
   $
   rm -rf node_modules && cd ..

4. mount-custom-mods-pod 이 실행 중인지 확인하세요.

   bash

   카피

   $
   kubectl get po
   NAME                    READY   STATUS    RESTARTS   AGE
   mount-custom-mods-pod   1/1     Running   0          5m43s

5. PV에 복사합니다.

   bash

   카피

   $
   kubectl cp custom-modules newrelic/mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules

6. PV에 /var/lib/newrelic/synthetics/modules/custom-modules/package.json 이 있는지 확인하세요.

   bash

   카피

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l
   total 4
   drwxr-xr-x 2 root root 6144 Jun 29 03:49 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 4
   -rw-r--r-- 1 501 staff 299 Jun 29 03:49 package.json

   사용자 정의 모듈 기능이 활성화된 SJM을 설치하십시오.

   설치 중에 명령줄이나 YAML 파일에서 persistence.existingClaimName 및 customNodeModules.customNodeModulesPath 에 대한 값을 설정합니다. customNodeModules.customNodeModulesPath 값은 사용자 정의 모듈 파일이 있는 영구 볼륨의 하위 경로를 지정해야 합니다. 예를 들어:

   bash

   카피

   $
   helm upgrade --install synthetics-job-manager newrelic/synthetics-job-manager -n newrelic --set global.persistence.existingClaimName=custom-modules-pvc --set global.customNodeModules.customNodeModulesPath=custom-modules --set synthetics.privateLocationKey=YOUR_PRIVATE_LOCATION_KEY
   Release "synthetics-job-manager" does not exist. Installing it now.
   NAME: synthetics-job-manager
   LAST DEPLOYED: Fri Jun 28 16:53:28 2024
   NAMESPACE: newrelic
   STATUS: deployed
   REVISION: 1
   TEST SUITE: None

   이제 custom-modules 디렉토리에는 node_modules 에 설치된 패키지가 포함되어야 합니다.

   bash

   카피

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# ls -l custom-modules/
   total 16
   -rw-r--r--  1 root root   836 Jun 29 03:51 README
   drwxr-xr-x 18 root root  6144 Jun 29 03:51 node_modules
   -rw-r--r--  1  501 staff  299 Jun 29 03:49 package.json
   -rw-r--r--  1 root root   190 Jun 29 03:51 package.json.shasum

   사용자 정의 노드 모듈이 감지되지 않으면 custom-modules 디렉토리와 package.json 파일에 대한 권한을 조정합니다.

   bash

   카피

   $
   kubectl exec -it mount-custom-mods-pod -- bash
   root@mount-custom-mods-pod:/# cd /var/lib/newrelic/synthetics/modules/
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chmod -R 777 custom-modules
   root@mount-custom-mods-pod:/var/lib/newrelic/synthetics/modules# chown -R 2000:2000 custom-modules

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

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

공식 1: 기존 위치 진단

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

$$ C_{est} = (R_{proc} + R_{growth}) \cdot D_{avg,m} $$

• C\_\{est} = 예상 CPU 코어.

• R\_\{proc} = 분당 처리 되는 대용량 작업의 비율 입니다.

• R\_\{growth} = jobManagerHeavyweightJobs 큐가 분당 증가하는 속도 입니다.

• D\_\{avg,m} = 대용량 작업의 평균 소요 시간 (분).

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

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

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

  $$ C_{est} = N_{mon} \cdot D_{avg,m} \cdot \frac{1}P_{avg,m} $$

• C\_\{est} = 예상 CPU 코어.

• N\_\{mon} = 실행할 예정인 고성능 모니터 의 총 개수입니다.

• D\_\{avg,m} = 대용량 작업의 평균 소요 시간( 분).

• P\_\{avg,m} = 무거운 모니터의 평균 주기( 분) (예: 5분마다 작동하는 모니터는 P\_\{avg,m} = 5입니다).

  이는 기본 원칙, 즉 보유하고 있는 개체 수, 실행 빈도 및 소요 시간을 기반으로 예상 수량을 계산합니다.

  중요한 크기 요소

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

• 작업 기간(D\_\{avg,m}): 평균에는 시간 초과된 작업(대개 3분)도 포함되어야 합니다. 이러한 작업은 전체 기간 동안 핵심을 유지합니다.

• 작업 실패 및 재시도: 모니터가 실패하면 자동으로 재시도됩니다. 이러한 재시도는 전체 부하를 증가시키는 추가 작업입니다. 지속적으로 실패하고 재시도하는 모니터는 주기를 늘려 처리량에 상당한 영향을 미칩니다.

• 스케일 아웃: 호스트에 더 많은 코어를 추가하는 것(스케일 업) 외에도 동일한 독립 로케이션 키를 사용하여 추가 신세틱스 작업 관리자를 구현하고 배치하여 여러 환경에 걸쳐 작업의 로드 밸런싱을 수행할 수 있습니다(스케일 아웃).

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

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

• 로드 밸런싱: 고립로케이션에 대한 작업은 사용 가능한 모든 SJM에 분산됩니다.

• 장애 조치 보호: 하나의 SJM 인스턴스가 다운되더라도 다른 인스턴스가 작업을 계속 처리할 수 있습니다.

• 더 높은 총 처리량: 프라이빗 로케이션의 총 처리량은 각 SJM의 처리량의 합이 됩니다(예: 2개의 SJM은 최대 30 작업/분을 제공합니다).

  진단을 위한 NRQL 쿼리

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

  1. 분당 처리된 작업 비율(R\_\{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\_\{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\_\{mon}): 이 쿼리는 고용량 모니터의 고유 개수를 찾습니다.

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

  카피

  4. 평균 작업 지속 시간(분) 찾기(D\_\{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,m}) 찾기: 다루로케이션의 jobManagerHeavyweightJobs 대기열이 증가하는 경우 기존 결과에서 평균 감시 기간을 계산하는 것은 정확하지 않습니다. 이는 합성 모니터 페이지에 있는 모니터 목록을 참고하여 추정해야 합니다. 올바른 뉴렐릭 계정을 선택했는지 확인하고 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와 OpenShift 합성 작업 관리자가 사용하는 각 런타임은 helm 차트 에서 값을 설정하여 독립적으로 크기를 조정할 수 있습니다. node-api-runtime 과 node-browser-runtime은 parallelism 및 completions 설정의 조합을 사용하여 독립적으로 크기가 조정됩니다.

• parallelism 설정은 특정 런타임의 파드가 동시에 실행되는 수를 제어합니다.

• completions 설정은 CronJob 이 해당 런타임에 대해 다른 Kubernetes Job을 시작하기 전에 완료해야 하는 파드 수를 제어합니다.

  구현 크기 조정을 위한 모범 사례, 배포

  뉴렐릭에서 볼 수 있는 평균 실행 시간이 정확하지 않을 수 있기 때문에 필요한 병렬 처리 및 완료 값을 정확하게 계산하는 것이 불가능한 경우가 많습니다. 특히 기존 타이머 로케이션이 제대로 작동하지 않는 경우에는 더욱 그렇습니다. 병렬 처리와 자동 완성 기능을 최적화하려면 이 실용적인 접근 방식을 따르십시오. 아래 방정식을 사용하면 대략적인 시작값을 얻을 수 있습니다.

  1. 완료율 및 병렬 처리 추정

  평균 실행 시간과 5분당 작업 수를 최대한 정확하게 추정해 보세요. 이는 다음 단계의 대략적인 시작점을 제공하며, 다음 단계에서는 실제 클러스터 환경에서 시행착오를 거쳐 병렬 처리 및 완료 값을 조정하게 됩니다. 예를 들어 기본값인 1과 6에서 10과 60으로 변경할 때처럼 비례적으로 크기를 조정해야 합니다.

  예상 완료 시간: 이 값은 5분 분량의 작업이 완료되는 데 걸리는 시간을 나타냅니다.

  -- Get average execution duration in minutes
  FROM SyntheticCheck
  SELECT average(executionDuration / 60e3) AS 'Avg Duration (min)'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  카피

  $$ Completions = \frac{5}D_{avg,m} $$

  여기서 D\_\{avg,m}는 평균 작업 실행 시간(분) 입니다.

  예상 병렬 처리량: 이는 5분 작업 부하를 처리하는 데 필요한 동시 실행 작업자(워커) 수를 결정합니다.

  -- Get jobs per 5 minutes
  FROM SyntheticCheck
  SELECT rate(uniqueCount(id), 5 minutes) AS 'Number of monitor jobs per 5 minutes'
  WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 hour ago

  카피

  $$ P_{est} = \frac{N_m}{Completions} $$

  여기서 $N\_m$은 5분당 작업 수 입니다. 이 P\_\{est} 값은 예상 병렬 처리량 입니다.

  2. Helm 구현, 배포 수행

  Helm 구현을 수행하고 예상 병렬 처리 및 완료 값과 노드당 CPU 코어 수와 분당 실행해야 하는 ping 모니터 수를 고려하여 ping-runtime.replicaCount 에 대한 최적의 추측을 배포합니다.

  3. 대기열 증가를 모니터링합니다.

  작업을 상대 로케이션으로 보내도록 구성된 합성 모니터를 사용하여 pingJobs 및 jobManagerHeavyweightJobs 에 대한 시계열 선 차트에서 대기열 증가를 확인합니다.

• pingJobs 큐의 기울기가 양수이면 ping-runtime.replicaCount 증가시키고 재배포합니다.

• jobManagerHeavyweightJobs 큐의 기울기가 양수이면 큐가 더 이상 증가하지 않을 때까지(음의 기울기) parallelism 과 completions 비례적으로 증가시킵니다.

  음의 기울기는 작업 관리자가 작업 요구 사항을 처리할 수 있을 만큼 충분한 병렬 처리 능력을 갖추고 있음을 나타냅니다. 결국 음의 기울기로 0에 도달할 것입니다.

  FROM SyntheticsPrivateLocationStatus
  SELECT average(jobManagerHeavyweightJobs) AS 'Heavyweight Queue Growth', average(pingJobs) AS 'Ping Queue Growth'
  WHERE name = 'YOUR_PRIVATE_LOCATION'
  SINCE 1 day ago TIMESERIES

  카피

  4. 파드 실행 상태에 따라 튜닝

  큐가 줄어들거나 0이 되면 10분 이상 "실행 중" 상태인 node-api-runtime 및 node-browser-runtime 파드를 확인합니다. 이는 병렬 처리 수준이 너무 높게 설정되어 있어 필요한 것보다 파드가 더 많다는 것을 나타냅니다.

  불필요한 자원 낭비를 방지하기 위해 parallelism 과 completions 감소시켜 각 "실행 중인" 런타임 파드의 수명을 줄이십시오. Kubernetes 작업의 실행 시간을 5분으로 설정했다면, 런타임 파드는 5분 이내에 실행 상태를 유지해야 합니다. 즉, 파드가 생성되자마자 실행할 작업을 빠르게 수신하고 완료되어야 합니다.

  5. 필요한 경우 규모를 확장하십시오.

  대기열이 줄어들지 않고 있는데도 10분 이상 "실행 중" 상태인 파드가 많다면 작업 관리자가 성능 병목현상, 병목지점에 도달했을 가능성이 높습니다. 다음으로 할 일은 병렬 처리를 줄이고 하나 이상의 추가 구현을 통해 확장하는 것입니다.

  예를 들어, parallelism: 100, completions: 600 사용하면 큐가 계속 증가하지만 10분 이상 "실행 중" 상태인 파드가 많고 Kubernetes 작업 시간이 20분인 경우... parallelism: 50, completions: 200 설정하고 2개의 추가 구현 배포를 추가하여 수평 확장(확장)합니다. 이로써 총 150개의 병렬 파드가 생성되며, K8의 작업 시간을 20분 미만으로 단축하는 동시에 장시간 실행되는 "실행" 파드의 수도 줄일 수 있습니다. 5-10분의 K8s 작업 기간에 대한 AI 예측.

  구현, 배포 추가에 대한 자세한 내용은 여러 SJM 구현, 배포를 사용하여 확장을 참조하세요.

  팁

  다음 쿼리를 사용하여 확장이 필요한지 여부를 판단할 수 있습니다.

  참고: 모니터는 여러 하위 계정에 존재할 수 있습니다.

  -- monitors per minute per SJM
  FROM SyntheticCheck SELECT
    round(rate(uniqueCount(id), 1 minute)/uniqueCount(minionId),0.1) AS 'heavy jobs per minute per SJM',
    uniqueCount(minionId) AS 'number of SJMs (namespaces)',
    round(rate(uniqueCount(id), 1 minute),0.1) AS 'heavy jobs per minute total'
  WHERE minionContainerSystem = 'KUBERNETES' AND minionDeploymentMode = 'private' AND location = 'YOUR_PRIVATE_LOCATION' AND type != 'SIMPLE' FACET location SINCE 1 hour ago TIMESERIES

  카피

  팁

  Kubernetes 작업 주기 횟수를 줄이면 성능도 향상될 수 있습니다. 각 주기가 설정된 완료 횟수에 도달하면 새로운 신세틱스 작업을 수행할 "실행 중인" 파드의 수가 점점 줄어듭니다. 예를 들어, 완료 횟수를 200으로, 병렬 처리를 50으로 설정하면 처음에는 50개의 파드가 실행되지만, 완료 횟수가 150회를 넘어서면서 실행 중인 파드 수가 줄어들기 시작합니다. 199번의 완료 중, 현재 실행 중인 파드는 단 1개만 남았습니다.

  완료 값을 더 크게 설정하는 것은 나쁜 생각은 아니지만, cronjob에 대해 TooManyMissedTimes 과 관련된 K8s 경고 이벤트가 발생할 수 있습니다.

  여러 SJM 구현으로 확장, 배포

  단일 SJM의 15 작업/분 처리량을 넘어 확장하려면 여러 개의 별도 SJM Helm 릴리스를 설치해야 합니다.

  중요

  작업 관리자 확장을 위해 복제본을 사용하지 마십시오. SJM 아키텍처는 런타임 파드와 해당 파드의 상위 SJM 파드 간에 1:1 관계를 요구합니다. 런타임 파드가 결과를 잘못된 SJM 복제본(예: Kubernetes 서비스를 통해)으로 전송하는 경우 해당 결과가 손실됩니다. 하지만 ping-runtime.replicaCount는 사용해도 괜찮습니다.

  올바른 전략은 여러 SJM을 구현하고 배포하는 것입니다. 각각은 자체 Helm 릴리스입니다. 각 SJM은 로드 밸런싱, 장애 조치 보호 및 증가된 전체 작업 처리량을 제공하여 동일한 위치의 작업을 놓고 경쟁합니다.

  수평 확장 전략

  확장이 필요한 경우 각 SJM 구현 및 배포를 고정 용량 단위로 취급하여 유지 관리를 간소화할 수 있습니다.

1. 병렬 처리 설정: 각 SJM에 대해 parallelism 단일 SJM이 너무 많은 장기 실행 런타임 파드를 생성하지 않고 처리할 수 있는 최대값으로 설정합니다. 이를 통해 자원을 낭비하지 않고 각 SJM의 잠재적 처리량을 극대화할 수 있습니다.

2. 집합 완성: 각 SJM에 대해 completions 도 동일한 고정 값으로 설정합니다. 필요에 따라 조정하여 대상, 목표를 런타임별 Kubernetes 작업 유지 시간 5분(예: node-browser-runtime 및 node-api-runtime)으로 설정합니다.

3. 릴리스 설치: 전체 작업 수요를 처리하는 데 필요한 만큼의 Helm 릴리스를 설치하십시오. 즉, 대기열이 0이 되거나 선 그래프의 기울기가 음수가 될 때까지 설치하십시오.

4. 감시 및 추가: 반대방향 작업 대기열을 감시합니다. 증가 추세(양의 기울기)를 보이기 시작하면 동일한 고정 설정을 사용하여 다른 Helm 릴리스(예: sjm-delta)를 설치하기만 하면 됩니다.

   병렬 처리 및 자동 완성 기능을 고정 값으로 설정함으로써 용량 증가 또는 감소는 Helm 릴리스를 추가하거나 제거하는 간단한 프로세스가 됩니다. 이렇게 하면 SJM이 효과적으로 활용할 수 있는 것보다 높은 병렬 처리 값에 클러스터 리소스가 낭비되는 것을 방지할 수 있습니다.

   설치 예제

   여러 SJM 릴리스를 설치할 때는 각 릴리스에 고유한 이름을 지정해야 합니다. 모두 동일한 로그로케이션 키로 구성되어야 합니다.

   더 짧고 관리하기 쉬운 리소스 이름을 만들려면 fullnameOverride 을 설정하는 것이 좋습니다. 예를 들어, sjm-alpha 과 sjm-beta 라는 이름의 SJM 두 개를 newrelic 네임스페이스에 설치하려면 (둘 다 고정된 병렬 처리 및 자동 완성 기능을 사용하는 동일한 values.yaml 사용함):

   bash

   카피

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

   bash

   카피

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

   작업 큐가 커지지 않도록 필요한 만큼 SJM에 대해 이 패턴(sjm-charlie, sjm-delta, 등)을 계속할 수 있습니다.