• /
  • EnglishEspañolFrançais日本語한국어Português
  • Inicia sesiónComenzar ahora

Te ofrecemos esta traducción automática para facilitar la lectura.

En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.

Crea una propuesta

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:

configuración usando 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.

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.

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

Para hacer referencia a una variable de entorno definida por el usuario configurada, emplee el $env.USER_DEFINED_VARIABLES reservado seguido del nombre de una variable dada con notación de punto (por ejemplo, $env.USER_DEFINED_VARIABLES.MY_VARIABLE).

Advertencia

Las variables de entorno definidas por el usuario no se desinfectan del log. Considere utilizar la característica de credenciales seguras para información confidencial.

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.

Configurar su directorio de módulos personalizados

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.

Ejemplo

En este ejemplo, se utiliza un directorio de módulo personalizado con la siguiente estructura:

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

package.json define dependencies como un módulo local (por ejemplo, counter) y cualquier módulo alojado (por ejemplo, smallest versión 1.0.1):

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

Agregue su directorio de módulos personalizados al SJM para Docker, Podman o Kubernetes

Para comprobar si los módulos se instalaron correctamente o si se produjo algún error, busque las siguientes líneas en los registros del contenedor o pod synthetics-job-manager :

2024-06-29 03:51:28,407{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Detected mounted path for custom node modules
2024-06-29 03:51:28,408{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Validating permission for custom node modules package.json file
2024-06-29 03:51:28,409{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Installing custom node modules...
2024-06-29 03:51:44,670{UTC} [main] INFO  c.n.s.j.p.options.CustomModules - Custom node modules installed successfully.

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

Cambiar package.json

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.

Advertencia

Módulos locales: si bien su package.json puede incluir cualquier módulo local, estos módulos deben residir dentro del árbol debajo de su directorio de módulos personalizados. Si se almacena fuera del árbol, el proceso de inicialización fallará y verá un mensaje de error en el log docker después de iniciar SJM.

Almacenamiento permanente de datos

Es posible que el usuario desee emplear almacenamiento de datos permanente para proporcionar el archivo user_defined_variables.json o admitir módulos de nodo personalizados.

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:

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

Podman

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
$
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
    $
    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
    $
    helm install ... --set synthetics.persistence.existingVolumeName=sjm-volume --set synthetics.persistence.storageClass=standard ...

Consideraciones de tamaño para Docker, Kubernetes y OpenShift

Docker

Para garantizar que su ubicación privada funcione de manera eficiente, debe aprovisionar suficientes recursos de CPU en su host Docker 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 simultáneo (es decir, cada navegador con script o prueba 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: Para diagnosticar 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.

La ecuación: $$C_req = (J_processed + Q_growth) \times D_j$$

  • $C_req$ = Núcleos de CPU requeridos
  • $J_processed$ = La tasa de trabajos que se procesan por minuto.
  • $Q_growth$ = La velocidad a la que su cola jobManagerHeavyweightJobs crece por minuto.
  • $D_j$ = La duración promedio de un trabajo en minutos.

Así es como funciona: esta fórmula calcula su tasa real de llegada de trabajos agregando los trabajos que su sistema está procesando a los trabajos que se acumulan en la cola. Al multiplicar esta carga total por la duración promedio del trabajo, obtendrá exactamente cuántos núcleos necesita para borrar todo el trabajo sin ponerlo en cola.

Fórmula 2: Para 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.

La ecuación: $$C_req = N_m \times F_j \times D_j$$

  • $C_req$ = Núcleos de CPU requeridos
  • $N_m$ = La cantidad total de monitores pesados que planea ejecutar.
  • $F_j$ = La frecuencia promedio de los monitores en trabajos por minuto (por ejemplo, un monitor que se ejecuta cada 5 minutos tiene una frecuencia de 1/5 o 0,2).
  • $D_j$ = La duración promedio de un trabajo en minutos.

Así es como funciona: calcula su carga de trabajo esperada a partir de los principios básicos: cuántos monitores tiene, 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_j$): su promedio debe incluir trabajos que expiran (generalmente ~3 minutos), ya que estos mantienen 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 frecuencia, 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).

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. Buscar trabajos procesados por minuto ($J_processed$): esta consulta cuenta la cantidad de trabajos sin ping (de gran peso) 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

2. Encontrar el crecimiento de la cola por minuto ($Q_growth$): esta consulta calcula el crecimiento promedio por minuto de la cola jobManagerHeavyweightJobs en un gráfico de seriales 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

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 la duración promedio del trabajo en minutos ($D_j$): esta consulta encuentra la duración promedio de ejecución de trabajos sin ping completados y convierte el resultado de milisegundos a minutos. ¿Por qué emplear executionDuration? Representa el tiempo que tardó el trabajo en ejecutar en el host, que es lo que queremos medir.

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

4. Encontrar el número total de monitores pesados ($N_m$): esta consulta encuentra el recuento único de monitores pesados.

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

5. Encuentre la frecuencia promedio de monitorización de peso pesado ($F_j$): si la cola jobManagerHeavyweightJobs de la ubicación privada está creciendo, no es preciso calcular la frecuencia promedio de monitorización a partir de los resultados existentes. Esto deberá estimar a partir de la lista de monitores en la página Monitores Sintéticos. Cerciórate de seleccionar la cuenta New Relic correcta y es posible que debas 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, es posible que necesite ampliar los recursos de su host o escalar horizontalmente implementando más administradores de trabajos para mantener la cola pingJobs limpia y evitar demoras.

Kubernetes y OpenShift

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.

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

Sugerencia

Las consultas anteriores se basan en resultados actuales. Si su ubicación privada no tiene ningún resultado o el administrador de trabajos no está funcionando al máximo, es posible que los resultados de la consulta no sean precisos. En ese caso, pruebe con algunos valores diferentes para completions y parallelism hasta que vea una duración de kubectl get jobs -n YOUR_NAMESPACE de al menos 5 minutos (suficientes finalizaciones) y la cola no crezca (suficiente paralelismo).

Ejemplo

Descripción

parallelism=1

completions=1

El tiempo de ejecución ejecutará 1 trabajo Sintético por minuto. Después de que se complete 1 trabajo, la configuración CronJob comenzará un nuevo trabajo en el siguiente minuto. Throughput will be extremely limited with this configuration.

parallelism=1

completions=6

El tiempo de ejecución ejecutará 1 trabajo de Sintético a la vez. Una vez finalizado el trabajo, se iniciará un nuevo trabajo inmediatamente. Una vez que se complete el número de trabajos de configuración completions , la configuración CronJob iniciará un nuevo trabajo de Kubernetes y restablecerá el contador de finalización. Throughput will be limited, but slightly better. Un único trabajo de Sintético de larga duración bloqueará el procesamiento de cualquier otro trabajo de Sintético de este tipo.

parallelism=3

completions=24

El tiempo de ejecución ejecutará 3 trabajos de Sintético a la vez. Una vez completado cualquiera de estos trabajos, se iniciará un nuevo trabajo inmediatamente. Una vez que se complete el número de trabajos de configuración completions , la configuración CronJob iniciará un nuevo trabajo de Kubernetes y restablecerá el contador de finalización. Throughput is much better with this or similar configurations. Un único trabajo de Sintético de larga duración tendrá un impacto limitado en el procesamiento de otros trabajos de Sintético de este tipo.

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

Sugerencia

Tenga en cuenta que New Relic no es responsable de ninguna modificación que realice en los archivos del administrador de trabajos de Sintéticos.

Copyright © 2025 New Relic Inc.
CarrerasTérminos de servicioPolítica de DMCAAviso de privacidadPolítica de cookiesUK Slavery Act (Ley contra la esclavitud del RU)

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