Configuración del gestor de trabajos sintético

Este documento lo guiará a través de la configuración de su administrador de trabajos Sintético mostrándole cómo:

• Configure módulos personalizados para API con script o monitor browser con script .
• Proporcione variables definidas por el usuario en su configuración.
• Actualice otras variables de entorno al iniciar su administrador de trabajos Sintético.

Variables definidas por el usuario para monitor con script

Los administradores de trabajos de Private Sintético le permiten configurar variables de entorno para el monitor con script. Estas variables se administran localmente en SJM y se puede acceder a ellas a través de $env.USER_DEFINED_VARIABLES. Puede configurar variables definidas por el usuario de dos maneras. Puede montar un archivo JSON o puede proporcionar una variable de entorno al SJM en el lanzamiento. Si se proporcionan ambos, el SJM solo utilizará valores proporcionados por el entorno.

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

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

### Mount a PersistentVolume
This option requires the user to provide a PersistentVolume that includes the user_defined_variables.json file or a PersistentVolumeClaim to the same. For more details on helm chart installation using a PersistentVolume, follow the instructions at [permanent data storage](/docs/synthetics/synthetic-monitoring/private-locations/job-manager-configuration#permanent-data-storage).
    
Once the user has prepared a PersistentVolume as described below, launch the SJM, setting the path where the user_defined_variables.json file is located and setting any other `synthetics.persistence` variables as necessary.

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

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

Acceder a variables de entorno definidas por el usuario desde un script

Para hacer referencia a una variable de entorno configurada definida por el usuario, utilice el $env.USER_DEFINED_VARIABLES reservado seguido del nombre de una variable determinada con notación de puntos.

Por ejemplo, $env.USER_DEFINED_VARIABLES.MY_VARIABLE

Módulos de nodo personalizados

Se proporcionan módulos de nodo personalizados tanto en llamadas por minuto como en SJM. Le permiten crear un conjunto personalizado de módulos de nodo y usarlos en un monitor con script ( API con script y browser con script) para monitoreo sintético.

Para configurar los módulos:

1. Cree un directorio con un archivo package.json siguiendo las pautas oficiales de npm en la carpeta raíz. El SJM instalará cualquier dependencia enumerada en el paquete.json. campo dependencies . Estas dependencias estarán disponibles cuando se ejecute el monitor en el administrador de trabajos privado de Sintético. Vea un ejemplo de esto a continuación.

/example-custom-modules-dir/
      ├── counter
      │   ├── index.js
      │   └── package.json
      └── package.json            ⇦ the only mandatory file

{
      "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
      }
    }

2. Una vez que haya creado el directorio de módulos personalizados y el package.json, aplíquelo a su SJM para docker y Kubernetes.

   Docker

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

   Copia

   Kubernetes

   Complete lo siguiente:

   1. lance el SJM, estableciendo un valor para el valor de configuración persistence.customModules ya sea en la línea de comando o en un archivo YAML durante la instalación. El valor debe especificar la subruta en el volumen persistente de su administrador de trabajos Sintético donde existen sus archivos de módulos personalizados. Por ejemplo:

      helm install ... --set persistence.customModules=<custom-modules-subpath> ...

      Copia

   2. Asegúrese de que su directorio de módulos personalizados esté disponible en el minion pod. Puede utilizar kubectl cp como método para copiar el directorio de su host al minion. Por ejemplo:

      kubectl cp /example-custom-modules-dir <namespace>/<pod_name>:/var/lib/newrelic/synthetics/modules

      Copia

3. Para comprobar si los módulos se instalaron correctamente o si se produjo algún error, revise el registro de SJM para la sección titulada "... Initialization of Custom Modules ...". Estos registros incluirán el registro de instalación de npm, proporcionando información sobre el proceso de instalación y cualquier posible error encontrado.

Ahora puede agregar "require('smallest');" al script del monitor que envía a esta ubicación privada.

Cambiar package.json para módulos personalizados

Además de los módulos locales y alojados, también puede utilizar módulos de Node.js. Para actualizar los módulos personalizados utilizados por su SJM, realice cambios en el archivo package.json y reinicie SJM. Durante el proceso de reinicio, el SJM reconocerá el cambio de configuración y realizará automáticamente operaciones de limpieza y reinstalación para garantizar que se apliquen los módulos actualizados.

Almacenamiento permanente de datos

Es posible que el usuario desee utilizar el almacenamiento de datos permanente para proporcionar el archivo user_defined_variables.json o admitir módulos de nodo personalizados (aún no disponibles para los administradores de trabajos privados de Sintético).

Docker

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:

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

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, estableciendo el valor de configuración synthetics.persistence.existingClaimName .

Ejemplo:

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á un PVC para el usuario.

Opcionalmente, el usuario también puede establecer los siguientes valores:

• synthetics.persistence.storageClass: la clase de almacenamiento del fotovoltaico existente. Si no se proporciona, Kubernetes utilizará la clase de almacenamiento predeterminada.
• synthetics.persistence.size: el tamaño del reclamo. Si no se establece, el valor predeterminado es actualmente 2Gi.

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

Variables de entorno

Las variables ambientales le permiten ajustar la configuración del administrador de trabajos de Sintético para satisfacer sus necesidades ambientales y funcionales específicas.

Consideraciones de tamaño para Kubernetes y Docker

Si está trabajando en entornos más grandes, es posible que necesite personalizar la configuración del administrador de trabajos para cumplir con los requisitos mínimos para ejecutar el monitor Sintético de manera eficiente. Muchos factores pueden afectar los requisitos de tamaño para el despliegue de un administrador de trabajos de Sintético, entre ellos:

• Si se requieren todos los tiempos de ejecución según el uso esperado
• El número de trabajos por minuto por tipo de monitor (ping, browser simple o con secuencias de comandos y API con secuencias de comandos)
• Duración del trabajo, incluidos los trabajos cuyo tiempo de espera es de aproximadamente 3 minutos
• El número de fracasos laborales. En el caso de errores de trabajo, se programan reintentos automáticos cuando un monitor comienza a fallar para proporcionar una lógica de reintento 3/3 incorporada. Estos trabajos adicionales se suman a los requisitos de rendimiento del administrador de trabajos de Sintético.

Además de los ajustes de configuración de tamaño que se enumeran a continuación, se pueden implementar administradores de trabajos de Sintético adicionales con la misma clave de ubicación privada para equilibrar la carga de trabajos en múltiples entornos.

Kubernetes

Cada tiempo de ejecución utilizado por el administrador de trabajos de Kubernetes Sintético se puede dimensionar de forma independiente estableciendo valores en el gráfico de timón.

Se pueden iniciar tiempos de ejecución de ping adicionales para ayudar a ejecutar la carga del monitor de ping aumentando la configuración ping-runtime.replicaCount del valor predeterminado de 1.

La API de Node.js y los tiempos de ejecución browser Node.js se dimensionan de forma independiente mediante una combinación de las configuraciones parallelism y completions. La configuración ideal para estas configuraciones variará según los requisitos del cliente.

La configuración parallelism controla cuántos pods de un tiempo de ejecución particular se ejecutan simultáneamente. La configuración parallelism es el equivalente a la configuración synthetics.heavyWorkers en el minion privado en contenedor (llamadas por minuto). Asegúrese de que su clúster de Kubernetes tenga suficientes recursos disponibles para ejecutar esta cantidad de pods según su solicitud de recursos y sus valores límite.

La configuración completions controla cuántos pods de un tiempo de ejecución particular deben completarse antes de que CronJob pueda iniciar otro trabajo de Kubernetes para ese tiempo de ejecución. Tenga en cuenta la diferencia entre un trabajo de Kubernetes (J mayúscula) y un trabajo de monitor Sintético. Para mejorar la eficiencia, completions debe establecerse entre 6 y 10 veces el valor parallelism . Esto puede ayudar a minimizar la ineficiencia de "cerca del final de las finalizaciones", donde menos del grupo de parallelism podrían terminar ejecutándose mientras el trabajo de Kubernetes espera a que finalicen los completions .

Cuando completions es mayor que 1, el pod con estado "Completado" permanecerá visible en la salida de kubectl get pods -n YOUR_NAMESPACE hasta que se hayan cumplido todas las finalizaciones definidas en el trabajo de Kubernetes, por ejemplo, 6/6 finalizaciones. Los recursos se liberan del nodo cuando un pod tiene el estado Completado o Fallido.

Una duración del trabajo de Kubernetes de 5 minutos (kubectl get jobs -n YOUR_NAMESPACE) es un objetivo conservador para tener en cuenta la variabilidad en el tiempo que tarda el pod en completarse y cuántos trabajos de Sintético deben ejecutarse por minuto (tasa de trabajos). Las siguientes ecuaciones se pueden utilizar como punto de partida para completions y parallelism para cada tiempo de ejecución. Es posible que sea necesario realizar ajustes en función de las observaciones del crecimiento de la cola de ubicación privada.

completions = 300 / avg job duration (s)
parallelism = synthetics jobs per 5 minutes / completions

Es probable que diferentes tiempos de ejecución tengan diferentes duraciones y tarifas de trabajo de Sintético. La siguiente consulta se puede utilizar para obtener la duración y la tarifa promedio para una ubicación privada.

# 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

Si los trabajos de Sintético tardan más en completarse, se necesitarán menos terminaciones para llenar 5 minutos con trabajos, pero se necesitarán más módulos paralelos. De manera similar, si es necesario procesar más trabajos de Sintético por minuto, se necesitarán más pods paralelos. La configuración parallelism afecta directamente la cantidad de trabajos de Sintético por minuto que se pueden ejecutar. Un valor demasiado pequeño y la cola puede crecer. Un valor demasiado grande y los nodos pueden verse limitados en recursos.

Si su configuración parallelism funciona bien para mantener la cola en cero, establecer un valor más alto para completions que el calculado a partir de 300 / avg job duration puede ayudar a mejorar la eficiencia de dos maneras:

• Adáptese a la variabilidad en la duración de los trabajos de modo que al menos 1 minuto esté ocupado con trabajos de Sintético, que es la duración mínima de CronJob.
• Reduzca el número de ciclos de terminación para minimizar la ineficiencia de "acercarse al final de las terminaciones", donde el siguiente conjunto de terminaciones no puede comenzar hasta que se complete el trabajo final.

Es importante tener en cuenta que el valor completions no debe ser demasiado grande o CronJob experimentará un evento de advertencia como el siguiente:

8m40s       Warning   TooManyMissedTimes     cronjob/synthetics-node-browser-runtime                  too many missed start times: 101. Set or decrease .spec.startingDeadlineSeconds or check clock skew