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

Sizing considerations for Docker and Podman

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_req = (R_proc + R_growth) \cdot D_avg,m $$

  • C_reqC\_req = Núcleos de CPU requeridos.
  • R_procR\_proc = La tasa de trabajos pesados que se procesan por minuto.
  • R_growthR\_growth = La velocidad a la que su cola jobManagerHeavyweightJobs crece por minuto.
  • D_avg,mD\_avg,m = La duración promedio de trabajos pesados en minutos.

This formula calculates your true job arrival rate by adding the jobs your system is processing to the jobs that are piling up in the queue. Multiplying this total load by the average job duration tells you exactly how many cores you need to clear all the work without queuing.

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_req = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

  • C_reqC\_req = Núcleos de CPU requeridos.
  • N_monN\_mon = La cantidad total de monitores pesados que planea ejecutar.
  • D_avg,mD\_avg,m = La duración promedio de un trabajo pesado en minutos.
  • P_avg,mP\_avg,m = El periodo promedio para monitores pesados en minutos (por ejemplo, un monitor que se ejecuta cada 5 minutos tiene P_avg,m=5P\_avg,m = 5).

This calculates your expected workload from first principles: how many monitors you have, how often they run, and how long they take.

Factores de tamaño importantes

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

  • Duración del trabajo (D_avg,mD\_avg,m): 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 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 de su ubicación privada se convierte en la suma del rendimiento de cada SJM (por ejemplo, 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. Find the rate of jobs processed per minute (R_procR\_proc): This query counts the number of non-ping (heavyweight) jobs completed over the last day and shows the average rate per minute.

FROM SyntheticCheck
SELECT rate(uniqueCount(id), 1 minute) AS 'job rate per minute'
WHERE location = 'YOUR_PRIVATE_LOCATION' AND typeLabel != 'Ping'
SINCE 1 day ago

2. Find the rate of queue growth per minute (R_growthR\_growth): This query calculates the average per-minute growth of the jobManagerHeavyweightJobs queue on a time series chart. A line above zero indicates the queue is growing, while a line below zero means it's shrinking.

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. Find total number of heavyweight monitors (N_monN\_mon): This query finds the unique count of heavyweight monitors.

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

4. Find average job duration in minutes (D_avg,mD\_avg,m): This query finds the average execution duration of completed non-ping jobs and converts the result from milliseconds to minutes. executionDuration represents the time the job took to execute on the host.

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

5. Encuentre el periodo promedio del monitor de peso pesado (P_avg,mP\_avg,m): si la cola jobManagerHeavyweightJobs de la ubicación privada está creciendo, no es preciso calcular el periodo promedio del monitor 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 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.

Sizing considerations for Kubernetes and 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. El node-api-runtime y el node-browser-runtime se dimensionan de forma independiente empleando una combinación de las configuraciones parallelism y completions.

  • The parallelism setting controls how many pods of a particular runtime run concurrently.
  • The completions setting controls how many pods must complete before the CronJob starts another Kubernetes Job for that runtime.

How to Size Your Deployment: A Step-by-Step Guide

Your goal is to configure enough parallelism to handle your job load without exceeding the throughput limit of your SJM instances.

Step 1: Estimate Your Required Workload

Completions: This determines how many runtime pods should complete before a new Kubernetes Job is started.

First, determine your private location's average job execution duration and job rate. Use executionDuration as it most accurately reflects the pod's active runtime.

-- Get average job execution duration (in seconds)
FROM SyntheticCheck
SELECT average(executionDuration / 60e3) AS 'D_avg_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ Completions = \frac5D_avg,m $$

Where D_avg,mD\_avg,m is your average job execution duration in seconds.

Required Parallelism: This determines how many workers (pods) you need running concurrently to handle your 5-minute job load.

-- Get jobs per 5 minutes
FROM SyntheticCheck
SELECT rate(uniqueCount(id), 5 minutes) AS 'N_m'
WHERE typeLabel != 'Ping' AND location = 'YOUR_PRIVATE_LOCATION'
FACET typeLabel SINCE 1 hour ago

$$ P_req = \fracN_mCompletions $$

Where N_mN\_m is your number of jobs per 5 minutes. This P_reqP\_req value is your target total parallelism.

Step 2: Check Against the Single-SJM Throughput Limit

Max Parallelism: This determines how many workers (pods) your SJM can effectively utilize.

$$ P_max \approx 15 \cdot D_avg,m $$

This P_maxP\_max value is your system limit for one SJM Helm deployment.

Sugerencia

The above queries are based on current results. If your private location does not have any results or the job manager is not performing at its best, query results may not be accurate. In that case, start with the examples in the table below and adjust until your queue is stable.

Sugerencia

A key consideration is that a single SJM instance has a maximum throughput of approximately 15 heavyweight jobs per minute. You can calculate the maximum effective parallelism (P_maxP\_max) a single SJM can support before hitting this ceiling.

Step 3: Compare, Configure, and Scale

Compare your required parallelism (P_reqP\_req) from Step 1 to the maximum parallelism (P_maxP\_max) from Step 2.

Scenario A: P_req≤P_maxP\_req \le P\_max

  • Diagnosis: Your job load is within the limit of a single SJM instance.

  • Action:

    1. You will deploy one SJM Helm release.
    2. In your Helm chart values.yaml, set parallelism to your calculated P_reqP\_req.
    3. Set completions to your calculated Completions. For improved efficiency, this value should typically be 6-10x your parallelism setting.

Scenario B: P\_req > P\_max

  • Diagnosis: Your job load exceeds the ~15 jobs/minute limit of a single SJM.

  • Action:

    1. You must scale out by deploying multiple, separate SJM Helm releases.
    2. See the Scaling Out with Multiple SJM Deployments section below for the correct procedure.
    3. Do not increase the replicaCount in your Helm chart.

Step 4: Monitor Your Queue

After applying your changes, you must verify that your job queue is stable and not growing. A consistently growing queue means your location is still under-provisioned.

Run this query to check the queue's growth rate:

-- Check for queue growth (a positive value means the queue is growing)
SELECT derivative(jobManagerHeavyweightJobs, 1 minute) AS 'Heavyweight Queue Growth Rate (per min)'
FROM SyntheticsPrivateLocationStatus
WHERE name = 'YOUR_PRIVATE_LOCATION'
SINCE 1 hour ago TIMESERIES

If the "Queue Growth Rate" is consistently positive, you need to install more SJM Helm deployments (Scenario B) or re-check your parallelism settings (Scenario A).

Configuration Examples and Tuning

The parallelism setting directly affects how many synthetics jobs per minute can be run. Too small a value and the queue may grow. Too large a value and nodes may become resource constrained.

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

The runtime will execute 1 synthetics job at a time. After the job completes, a new job will start immediately. After 6 jobs complete, the CronJob configuration will start a new Kubernetes Job. Throughput will be limited. A single long-running synthetics job will block the processing of any other synthetics jobs of this type.

parallelism=3 completions=24

The runtime will execute 3 synthetics jobs at once. After any of these jobs complete, a new job will start immediately. After 24 jobs complete, the CronJob configuration will start a new Kubernetes Job. Throughput is much better with this or similar configurations.

If your parallelism setting is working well (keeping the queue at zero), setting a higher completions value (e.g., 6-10x parallelism) can improve efficiency by:

  • Accommodating variability in job durations.
  • Reducing the number of completion cycles to minimize the "nearing the end of completions" inefficiency where the next batch can't start until the final job from the current batch completes.

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

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

Sugerencia

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

Scaling out with multiple SJM deployments

To scale beyond the ~15 jobs/minute throughput of a single SJM, you must install multiple, separate SJM Helm releases.

Importante

Do not use replicaCount to scale the job manager pod. You cannot scale by increasing the replicaCount for a single Helm release. The SJM architecture requires a 1:1 relationship between a runtime pod and its parent SJM pod. If runtime pods send results back to the wrong SJM replica (e.g., through a Kubernetes service), those results will be lost.

The correct strategy is to deploy multiple SJM instances, each as its own Helm release. Each SJM will compete for jobs from the same private location, providing load balancing, failover protection, and an increased total job throughput.

Simplified Scaling Strategy

Assuming P\_req > P\_max and you need to scale out, you can simplify maintenance by treating each SJM deployment as a fixed-capacity unit.

  1. Set Max Parallelism: For each SJM, set parallelism to the same P_maxP\_max value. This maximizes the potential throughput of each SJM.

  2. Set Completions: For each SJM, set completions to a fixed value as well. The P_reqP\_req formula from Step 1 can be modified to estimate completions by substituting in the P_maxP\_max value:

    $$ Completions = \fracN_mP_max $$

    Where N_mN\_m is your number of jobs per 5 minutes. Adjust as needed after deploying to target a 5 minute Kubernetes job age per runtime, i.e., node-browser-runtime and node-api-runtime.

  3. Install Releases: Install as many separate Helm releases as you need to handle your total P_reqP\_req. For example, if your total P_reqP\_req is 60 and you've fixed each SJM's parallelism at 20 (P_maxP\_max from Step 2), you would need three separate Helm deployments to meet the required job demand.

  4. Monitor and Add: Monitor your job queue (see Step 4). If it starts to grow, simply install another Helm release (e.g., sjm-delta) using the same fixed configuration.

By fixing parallelism and completions to static values based on P_maxP\_max, increasing or decreasing capacity becomes a simpler process of adding or removing Helm releases. This helps to avoid wasting cluster resources on a parallelism value that is higher than the SJM can effectively utilize.

Installation Example

When installing multiple SJM releases, you must provide a unique name for each release. All instances must be configured with the same private location key.

Setting the fullnameOverride is highly recommended to create shorter, more manageable resource names. For example, to install two SJMs named sjm-alpha and sjm-beta into the newrelic namespace (both using the same values.yaml with your fixed parallelism and completions):

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

You can continue this pattern (sjm-charlie, sjm-delta, etc.) for as many SJMs as needed to keep the job queue from growing.

Copyright © 2025 New Relic Inc.
CarrerasTérminos de servicioPolítica de DMCAAviso de PatenteAviso 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.