Configuración del gestor de trabajos sintético

Las variables se proporcionan al inicio utilizando el argumento -e, --env .

La siguiente tabla muestra todas las variables de entorno que soporta Sintético job manager. PRIVATE_LOCATION_KEY es obligatorio y todas las demás variables son opcionales.

Las variables se proporcionan al inicio utilizando el argumento -e, --env .

La siguiente tabla muestra todas las variables de entorno que admite el administrador de trabajos de Sintéticos. Se requiere PRIVATE_LOCATION_KEY y todas las demás variables son opcionales. Para ejecutar el administrador de trabajos Sintéticos en un entorno Podman, la versión mínima debe ser release-418 o superior.

Las variables se proporcionan al inicio utilizando el argumento --set .

La siguiente lista muestra todas las variables de entorno que admite Sintético job manager. synthetics.privateLocationKey es obligatorio y todas las demás variables son opcionales.

Una serie de configuraciones avanzadas adicionales están disponibles y completamente documentadas en nuestro archivo README del gráfico Helm.

Las variables se proporcionan al inicio utilizando el argumento --set .

La siguiente lista muestra todas las variables de entorno que admite Sintético job manager. synthetics.privateLocationKey es obligatorio y todas las demás variables son opcionales.

Una serie de configuraciones avanzadas adicionales están disponibles y completamente documentadas en nuestro archivo README del gráfico Helm.

El usuario puede crear un archivo con formato JSON y montar el volumen donde se encuentra el archivo en una ruta de destino especificada en el contenedor SJM.

El archivo debe tener permisos de lectura y contener un mapa con formato JSON. Ejemplo de archivo de variables definidas por el usuario:

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

Coloque el archivo en el directorio de origen del host. El SJM espera que el nombre del archivo sea user_defined_variables.json

Ejemplo Docker:

El directorio objetivo esperado es: /var/lib/newrelic/synthetics/variables/

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

Ejemplo de Podman:

En el caso de SELinux, monte el volumen adicionalmente con :z o :Z. Para obtener más información, consulte la documentación de Podman. El directorio objetivo esperado es: /var/lib/newrelic/synthetics/variables/

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

Ejemplo de Kubernetes:

El usuario tiene dos opciones al proporcionar un archivo al pod SJM en Kubernetes. Que puede:

• Pasar un archivo local.
• Proporcione un PersistentVolume que incluya user_defined_variables.json.

Pasar en un archivo local

Esta opción crea un recurso ConfigMap Kubernetes y lo monta en el pod SJM.

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

Montar una PersistentVolume

Esta opción requiere que el usuario proporcione un PersistentVolume que incluya el archivo user_defined_variables.json o un PersistentVolumeClaim al mismo. Para obtener más detalles sobre la instalación del gráfico de Helm usando un PersistentVolume, siga las instrucciones en almacenamiento de datos permanente.

Una vez que el usuario preparó un PersistentVolume como se describe a continuación, inicie el SJM, configure la ruta donde se encuentra el archivo user_defined_variables.json y configure cualquier otra variable synthetics.persistence según sea necesario.

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

Las variables pueden pasar a su respectivo sistema contenedor a través de la variable de entorno.

Ejemplo Docker:

Utilice la bandera -e para configurar una variable de entorno denominada USER_DEFINED_VARIABLES y asígnele el valor de una cadena de mapa con formato JSON.

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

Ejemplo de Podman:

Utilice la bandera -e para configurar una variable de entorno denominada USER_DEFINED_VARIABLES y asígnele el valor de una cadena de mapa con formato JSON.

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

Ejemplo de Kubernetes:

Emplee la bandera --set-literal para pasar la cadena con formato JSON.

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

Para docker, lanza SJM montando el directorio en /var/lib/newrelic/synthetics/modules. Por ejemplo:

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

Para podman, inicie SJM montando el directorio en /var/lib/newrelic/synthetics/modules. En el caso de SELinux, monte el volumen adicionalmente con :z o :Z. Para obtener más información, consulte la documentación de Podman. Por ejemplo:

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

Para Kubernetes, el directorio en /var/lib/newrelic/synthetics/modules debe existir en un PV antes de iniciar SJM con módulos personalizados habilitados.

Un método es crear un pod que monte el PV solo con el propósito de copiar el directorio de módulos personalizados al PV. El siguiente ejemplo emplea Amazon EFS con Amazon EKS:

Cree el namespace, el volumen persistente y la reclamación del volumen persistente

1. Cerciorar de que ya configuró su sistema de archivos EFS e instaló el controlador CSI de EFS en su clúster. También necesitará su ID de sistema de archivos EFS para los PV spec.csi.volumeHandle.

   bash

   Copia

   $
   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. Cambie al namespace newrelic en su ~/.kube/config.

   bash

   Copia

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

3. En este punto, el PVC debe estar vinculado al PV con el modo de acceso RWX.

   bash

   Copia

   $
   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

   Crea mount-custom-mods-pod para copiar tu directorio de módulos personalizados

   bash

   Copia

   $
   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

   En este punto, se debe crear y configurar el mount-custom-mods-pod para usar el volumen.

   bash

   Copia

   $
   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

   Consulte el evento para ver si hay advertencias relacionadas con PV, PVC o mount-custom-mods-pod.

   bash

   Copia

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

   Copie su directorio de módulos personalizados al PV

   No es necesario copiar node_modules ya que lo generará el SJM en npm install.

   bash

   Copia

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

4. Compruebe que mount-custom-mods-pod se esté ejecutando.

   bash

   Copia

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

5. Copiar al PV.

   bash

   Copia

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

6. Compruebe que /var/lib/newrelic/synthetics/modules/custom-modules/package.json exista en el PV.

   bash

   Copia

   $
   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

   lanzar el SJM con la característica de módulos personalizados habilitada

   Establezca valores para persistence.existingClaimName y customNodeModules.customNodeModulesPath en la línea de comando o en un archivo YAML durante la instalación. El valor customNodeModules.customNodeModulesPath debe especificar la subruta en el volumen persistente donde existen sus archivos de módulos personalizados. Por ejemplo:

   bash

   Copia

   $
   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

   El directorio custom-modules ahora debería contener los paquetes instalados en node_modules.

   bash

   Copia

   $
   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

   Si no se detectan módulos de nodo personalizados, ajuste las licencias en el directorio custom-modules y el archivo package.json .

   bash

   Copia

   $
   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

Para configurar el almacenamiento permanente de datos en Docker:

1. Cree un directorio en el host donde está iniciando Job Manager. Este es su directorio de origen.

2. Inicie el Administrador de trabajos, montando el directorio de origen en el directorio de destino /var/lib/newrelic/synthetics.

   Ejemplo:

   bash

   Copia

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

Para configurar el almacenamiento de datos permanente en Podman:

1. Cree un directorio en el host donde está iniciando Job Manager. Este es su directorio de origen.

2. Inicie el Administrador de trabajos, montando el directorio de origen en el directorio de destino /var/lib/newrelic/synthetics.

   Ejemplo:

   bash

   Copia

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

Kubernetes

Para configurar el almacenamiento permanente de datos en Kubernetes, el usuario tiene dos opciones:

1. Proporcione un PersistentVolumeClaim (PVC) existente para un PersistentVolume (PV) existente y establezca el valor de configuración synthetics.persistence.existingClaimName . Ejemplo:

   bash

   Copia

   $
   helm install ... --set synthetics.persistence.existingClaimName=sjm-claim ...

2. Proporcione un nombre de PersistentVolume (PV) existente y establezca el valor de configuración synthetics.persistence.existingVolumeName . Helm generará una PVC para el usuario. El usuario también puede configurar opcionalmente los siguientes valores:

• synthetics.persistence.storageClass:La clase de almacenamiento del PV existente. Si no se proporciona, Kubernetes empleará la clase de almacenamiento predeterminada.

• synthetics.persistence.size:El tamaño de la reclamación. Si no se configura, el valor predeterminado actualmente es 2Gi.

  bash

  Copia

  $
  helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

Para garantizar que su ubicación privada funcione de manera eficiente, debe aprovisionar suficientes recursos de CPU en su host para manejar su carga de trabajo de monitoreo. Muchos factores influyen en el tamaño, pero puedes estimar rápidamente tus necesidades. Necesitará 1 núcleo de CPU para cada monitor pesado (es decir, navegador simple, navegador con script o monitor de API con script). A continuación se muestran dos fórmulas que lo ayudarán a calcular la cantidad de núcleos que necesita, ya sea que esté diagnosticando una configuración actual o planeando una futura.

Fórmula 1: Diagnóstico de una ubicación existente

Si su ubicación privada actual tiene dificultades para mantener el ritmo y sospecha que hay cola de trabajos, emplee esta fórmula para descubrir cuántos núcleos necesita realmente. Se basa en el rendimiento observable de su sistema.

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

• C\_\{est} = Núcleos de CPU estimados.

• R\_\{proc} = La tasa de trabajos pesados procesados por minuto.

• R\_\{growth} = La tasa a la que su cola jobManagerHeavyweightJobs está creciendo por minuto.

• D\_\{avg,m} = La duración promedio de los trabajos pesados en minutos.

  Esta fórmula calcula la tasa real de llegada de trabajos sumando los trabajos que su sistema está procesando a los trabajos que se están acumulando en la cola. Multiplicar esta carga total por la duración media del trabajo le indicará exactamente cuántos núcleos necesita para completar todo el trabajo sin colas.

  Fórmula 2: Pronosticar una ubicación nueva o futura

  Si está configurando una nueva ubicación privada o planea agregar más monitores, use esta fórmula para pronosticar sus necesidades con anticipación.

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

• C\_\{est} = Núcleos de CPU estimados.

• N\_\{mon} = El número total de monitores pesados que planea ejecutar.

• D\_\{avg,m} = La duración promedio de un trabajo pesado en minutos.

• P\_\{avg,m} = El período promedio para monitores pesados en minutos (p. ej., un monitor que se ejecuta cada 5 minutos tiene P\_\{avg,m} = 5).

  Esto calcula tu carga de trabajo prevista a partir de principios básicos: cuántos monitores tienes, con qué frecuencia se ejecutan y cuánto tiempo tardan.

  Factores de tamaño importantes

  Al emplear estas fórmulas, recuerde tener en cuenta estos factores:

• Duración del trabajo (D\_\{avg,m}): su promedio debe incluir los trabajos que agotan el tiempo de espera (a menudo 3 minutos), ya que estos ocupan un núcleo durante toda su duración.

• Errores de trabajo y reintentos: cuando un monitor falla, se vuelve a intentar automáticamente. Estos reintentos son trabajos adicionales que se suman a la carga total. Un monitor que falla y vuelve a intentarlo constantemente multiplica efectivamente su periodo, lo que afecta significativamente el rendimiento.

• Escalamiento horizontal: además de agregar más núcleos a un host (escalamiento vertical), puede implementar administradores de trabajos sintéticos adicionales con la misma clave de ubicación privada para equilibrar la carga de trabajos en múltiples entornos (escalamiento horizontal).

  Es importante tener en cuenta que un solo Sintéticos Job Manager (SJM) tiene un límite de rendimiento de aproximadamente 15 trabajos pesados por minuto. Esto se debe a una estrategia de subprocesamiento interno que favorece la competencia eficiente de trabajos entre múltiples SJM sobre la cantidad bruta de trabajos procesados por SJM. Si sus cálculos indican la necesidad de un mayor rendimiento, deberá ampliar la escala implementando SJM adicionales. Puede verificar si su cola de trabajos está creciendo para determinar si se necesitan más SJM.

  Agregar más SJM con la misma clave de ubicación privada ofrece varios beneficios:

• Equilibrio de carga: los trabajos para la ubicación privada se distribuyen entre todos los SJM disponibles.

• Protección contra conmutación por error: si una instancia de SJM deja de funcionar, las demás pueden continuar procesando trabajos.

• Mayor rendimiento total: el rendimiento total para su ubicación privada se convierte en la suma del rendimiento de cada SJM (p. ej., dos SJM proporcionan hasta 30 trabajos/minuto).

  Consulta de NRQL para diagnóstico

  Puede ejecutar estas consultas en el generador de consultas para obtener los insumos para la fórmula de diagnóstico. Cerciorar de establecer el rango de tiempo en un periodo lo suficientemente largo para obtener un promedio estable.

  1. Encuentre la tasa de trabajos procesados por minuto (R\_\{proc}): Esta consulta cuenta el número de trabajos que no son de ping (pesados) completados durante el último día y muestra la tasa promedio por minuto.

  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

  Copia

  2. Encuentre la tasa de crecimiento de la cola por minuto (R\_\{growth}): Esta consulta calcula el crecimiento promedio por minuto de la cola jobManagerHeavyweightJobs en un gráfico de series de tiempo. Una línea por encima de cero indica que la cola está creciendo, mientras que una línea por debajo de cero significa que se está reduciendo.

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

  Copia

  Sugerencia

  Cerciorar de seleccionar la cuenta donde existe la ubicación privada. Es mejor ver esta consulta como un serial de tiempo porque la función derivada puede variar mucho. El objetivo es obtener una estimación de la tasa de crecimiento de la cola por minuto. Play con diferentes rangos de tiempo para ver qué funciona mejor.

  3. Encontrar el número total de monitores pesados (N\_\{mon}): Esta consulta encuentra el conteo único de monitores pesados.

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

  Copia

  4. Encontrar la duración promedio del trabajo en minutos (D\_\{avg,m}): Esta consulta encuentra la duración promedio de ejecución de los trabajos completados que no son de ping y convierte el resultado de milisegundos a minutos. executionDuration representa el tiempo que tardó el trabajo en ejecutarse en el host.

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

  Copia

  5. Encuentre el período promedio del monitor de peso pesado (P\_\{avg,m}): Si la cola de jobManagerHeavyweightJobs de la ubicación privada está aumentando, no es preciso calcular el período promedio del monitor a partir de los resultados existentes. Esto deberá estimarse a partir de la lista de monitores en la página Monitores sintéticos. Asegúrese de seleccionar la cuenta de New Relic correcta y es posible que deba filtrar por privateLocation.

  Sugerencia

  Los monitores sintéticos pueden existir en múltiples subcuentas. Si tienes más subcuentas de las que se pueden seleccionar en el generador de consultas, elige las cuentas con más monitores.

  Nota sobre los monitores de ping y la cola pingJobs

  Los monitores de ping son diferentes. Son trabajos ligeros que no consumen un núcleo de CPU completo cada uno. En su lugar, emplean una cola separada (pingJobs) y se ejecutan en un grupo de subprocesos de trabajo.

  Si bien consumen menos recursos, un gran volumen de trabajos de ping, especialmente los fallidos, aún pueden causar problemas de rendimiento. Tenga en cuenta estos puntos:

• Modelo de recursos: los trabajos de ping emplean subprocesos de trabajo, no núcleos de CPU dedicados. En estos casos no se aplica el cálculo de núcleo por puesto de trabajo.

• Tiempo de espera y reintento: un trabajo de ping fallido puede ocupar un hilo de trabajo durante hasta 60 segundos. Primero intenta una solicitud HTTP HEAD (tiempo de espera de 30 segundos). Si eso falla, vuelve a intentarlo inmediatamente con una solicitud HTTP GET (otro tiempo de espera de 30 segundos).

• Escalamiento: aunque la fórmula de dimensionamiento es diferente, se aplican los mismos principios. Para manejar un gran volumen de trabajos de ping y evitar que la cola pingJobs crezca, es posible que necesite escalar verticalmente u horizontalmente. Escalar significa aumentar los recursos de CPU y memoria por host o namespace. Escalar horizontalmente significa agregar más instancias del tiempo de ejecución de ping. Esto se puede hacer implementando más administradores de trabajos en más hosts, en más espacios de nombres o incluso dentro del mismo namespace. Alternativamente, el ping-runtime en Kubernetes le permite establecer una mayor cantidad de réplicas por implementación.

Cada entorno de ejecución empleado por el administrador de trabajos Kubernetes y OpenShift Sintético se puede dimensionar de forma independiente configurando valores en el gráfico de Helm. El node-api-runtime y el node-browser-runtime se dimensionan de forma independiente empleando una combinación de las configuraciones parallelism y completions.

• La configuración parallelism controla cuántos pods de un entorno de ejecución particular se ejecutan simultáneamente.

• La configuración completions controla cuántos pods deben completar antes de que CronJob inicie otro trabajo Kubernetes para ese tiempo de ejecución.

  Mejores prácticas para dimensionar su implementación

  A menudo no es posible calcular con precisión los valores necesarios de paralelismo y finalizaciones porque la duración promedio observada en New Relic podría no ser exacta, especialmente si la ubicación privada existente no funciona correctamente. Siga este enfoque práctico para ajustar el paralelismo y las finalizaciones. Las siguientes ecuaciones se pueden utilizar para obtener valores aproximados como punto de partida.

  1. Estimar finalizaciones y paralelismo

  Haga lo posible por estimar la duración promedio de ejecución y el número de trabajos cada 5 minutos. Esto le proporciona un punto de partida aproximado para el siguiente paso, que implicará prueba y error para ajustar los valores de paralelismo y finalizaciones en un clúster en funcionamiento. Asegúrese de escalarlos proporcionalmente, por ejemplo, pasando de los valores predeterminados de 1 y 6 a 10 y 60.

  Finalizaciones estimadas: Esto determina cuánto tiempo tardará en completarse su carga de trabajo de 5 minutos.

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

  Copia

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

  Donde D\_\{avg,m} es su duración promedio de ejecución del trabajo en minutos.

  Paralelismo estimado: Esto determina cuántos trabajadores (pods) necesita que se ejecuten simultáneamente para manejar su carga de trabajo de 5 minutos.

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

  Copia

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

  Donde $N\_m$ es su número de trabajos por cada 5 minutos. Este valor P\_\{est} es su paralelismo estimado.

  2. Realice un despliegue de Helm

  Realice un despliegue de Helm con valores estimados de paralelismo y finalizaciones, y su mejor estimación para ping-runtime.replicaCount dada la cantidad de núcleos de CPU por nodo y el número de monitores de ping que deben ejecutarse por minuto.

  3. Monitorear el crecimiento de la cola

  Con los monitores sintéticos configurados para enviar trabajos a la ubicación privada, verifique el crecimiento de la cola en un gráfico de líneas de serie de tiempo para pingJobs y jobManagerHeavyweightJobs.

• Si la cola pingJobs tiene una pendiente positiva, aumente ping-runtime.replicaCount y vuelva a desplegar.

• Si la cola jobManagerHeavyweightJobs tiene una pendiente positiva, aumente parallelism y completions proporcionalmente hasta que la cola deje de crecer (pendiente negativa).

  Una pendiente negativa indica que el administrador de trabajos tiene suficiente paralelismo para manejar la demanda de trabajos. Eventualmente llegará a cero con una pendiente negativa.

  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

  Copia

  4. Ajustar según el estado de ejecución del pod

  Con la cola disminuyendo o en cero, busque pods node-api-runtime y node-browser-runtime que estén en estado "running" durante más de 10 minutos. Esto indica que el paralelismo está configurado demasiado alto y hay más pods de los necesarios.

  Para evitar desperdiciar recursos innecesariamente, disminuya parallelism y completions para reducir la antigüedad de cada pod de runtime "running". Si el objetivo es una antigüedad de trabajo de Kubernetes de 5 minutos, los pods de tiempo de ejecución deben estar en estado de ejecución durante menos de 5 minutos, lo que significa que el pod se creó, recibió rápidamente un trabajo para ejecutar y se completó.

  5. Escalar horizontalmente si es necesario

  Si la cola no disminuye, pero hay muchos pods en estado "running" durante más de 10 minutos, es probable que el gestor de trabajos esté alcanzando su cuello de botella de rendimiento. Lo siguiente que debe hacer es disminuir el paralelismo y escalar horizontalmente con una o más implementaciones adicionales.

  Por ejemplo, con parallelism: 100, completions: 600 la cola sigue creciendo, pero hay muchos pods en estado "running" durante más de 10 minutos, y la antigüedad del Job de Kubernetes es de 20 minutos ... configure parallelism: 50, completions: 200 y escale horizontalmente (hacia afuera) agregando 2 despliegues adicionales. Esto genera un total de 150 pods paralelos y debería reducir la antigüedad del trabajo de K8s a menos de 20 minutos, a la vez que reduce la cantidad de pods "running" de larga duración. Apunte a una antigüedad del trabajo de K8s de 5 a 10 minutos.

  Para obtener más información sobre cómo agregar implementaciones, consulte Escalamiento con múltiples implementaciones de SJM.

  Sugerencia

  Puede utilizar la siguiente consulta para ayudar a determinar si necesita escalar horizontalmente.

  Nota: Los monitores pueden existir en múltiples subcuentas.

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

  Copia

  Sugerencia

  Reducir el número de ciclos de trabajo de K8s también puede mejorar el rendimiento. A medida que cada ciclo alcanza el número establecido de finalizaciones, hay cada vez menos pods "en ejecución" para asumir nuevos trabajos de Synthetics. Por ejemplo, con completions establecido en 200 y parallelism establecido en 50, inicialmente tenemos 50 pods en ejecución, pero esto comienza a disminuir a medida que superamos los 150 completions. A las 199 finalizaciones, solo queda 1 pod en ejecución.

  Configurar un valor mayor para las finalizaciones no es una mala idea, pero puede generar eventos de advertencia en K8s sobre TooManyMissedTimes para el cronjob.

  Escalado horizontal con múltiples despliegues de SJM

  Para escalar más allá del rendimiento de 15 trabajos/minuto de un solo SJM, debe instalar varias versiones separadas de SJM Helm.

  Importante

  No utilice réplicas para escalar el pod del administrador de trabajos. La arquitectura SJM requiere una relación 1:1 entre un pod de tiempo de ejecución y su pod SJM padre. Si los pods de tiempo de ejecución envían resultados a la réplica de SJM incorrecta (p. ej., a través de un servicio de Kubernetes), esos resultados se perderán. Sin embargo, se puede usar ping-runtime.replicaCount.

  La estrategia correcta es desplegar múltiples instancias de SJM, cada una como su propia versión Helm. Cada SJM competirá por los trabajos desde la misma ubicación privada, lo que proporcionará equilibrio de carga, protección contra fallos y un mayor rendimiento total de trabajos.

  Estrategia de escalado horizontal

  Si necesita escalar horizontalmente, puede simplificar el mantenimiento tratando cada implementación de SJM como una unidad de capacidad fija.

1. Establecer paralelismo: Para cada SJM, establezca parallelism en el mismo máximo que un solo SJM pueda manejar sin crear demasiados pods de tiempo de ejecución "en ejecución" de larga duración. Esto maximiza el rendimiento potencial de cada SJM sin desperdiciar recursos.

2. Establecer finalizaciones: Para cada SJM, establezca completions en el mismo valor fijo también. Ajuste según sea necesario para lograr una antigüedad de job de Kubernetes de 5 minutos por runtime, es decir, node-browser-runtime y node-api-runtime.

3. Instalar lanzamientos: Instale tantos lanzamientos de Helm separados como necesite para manejar su demanda total de trabajos; es decir, lleve la cola a cero o el gráfico de líneas a una pendiente negativa.

4. Monitorear y agregar: Monitoree la cola de trabajos de la ubicación privada. Si comienza a crecer (pendiente positiva), simplemente instale otro release de Helm (p. ej., sjm-delta) usando la misma configuración fija.

   Al fijar el paralelismo y las finalizaciones en valores estáticos, aumentar o disminuir la capacidad se convierte en un proceso más sencillo de agregar o eliminar releases de Helm. Esto ayuda a evitar el desperdicio de recursos del clúster en un valor de paralelismo superior al que el SJM puede utilizar eficazmente.

   Ejemplo de instalación

   Al instalar varias versiones de SJM, debe proporcionar un nombre único para cada versión. Todas las instancias deben configurar con la misma clave de ubicación privada.

   Se recomienda encarecidamente establecer fullnameOverride para crear nombres de recursos más cortos y manejables. Por ejemplo, para instalar dos SJM llamados sjm-alpha y sjm-beta en el namespace newrelic (ambos usando el mismo values.yaml con su paralelismo y autocompletado fijos):

   bash

   Copia

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

   Copia

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

   Puedes continuar este patrón (sjm-charlie, sjm-delta etc.) para tantos SJM como sea necesario para evitar que la cola de trabajos crezca.