• /
  • EnglishEspañolFrançais日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

Configuração do gerenciador de tarefas Sintético

Este documento irá guiá-lo na configuração do seu gerenciador de tarefas Sintético , mostrando como:

Configuração usando variáveis de ambiente

As variáveis ambientais permitem ajustar a configuração do gerenciador de tarefas Sintético para atender às suas necessidades ambientais e funcionais específicas.

Variáveis definidas pelo usuário para monitor com script

Os gerenciadores de tarefas Private Sintético permitem configurar variáveis de ambiente para monitor com script. Essas variáveis são gerenciadas localmente no SJM e podem ser acessadas via $env.USER_DEFINED_VARIABLES. Você pode definir variáveis definidas pelo usuário de duas maneiras. Você pode montar um arquivo JSON ou fornecer uma variável de ambiente ao SJM no lançamento. Se ambos forem fornecidos, o SJM utilizará apenas valores fornecidos pelo ambiente.

Acessando variáveis de ambiente definidas pelo usuário a partir do script

Para fazer referência a uma variável de ambiente definida pelo usuário configurada, use o $env.USER_DEFINED_VARIABLES reservado seguido do nome de uma determinada variável com notação de ponto (por exemplo, $env.USER_DEFINED_VARIABLES.MY_VARIABLE).

Cuidado

Variáveis de ambiente definidas pelo usuário não são limpas do log. Considere usar o recurso de credenciais seguras para informações confidenciais.

Módulos de nós personalizados

Módulos de nós personalizados são fornecidos em chamadas por minuto e SJM. Eles permitem criar um conjunto customizado de módulos de nós e utilizá-los em monitoramento scriptado ( API script e browser script) para monitoramento sintético.

Configure seu diretório de módulos personalizados

Crie um diretório com um arquivo package.json seguindo as diretrizes oficiais do npm na pasta raiz. O SJM instalará qualquer dependência listada no arquivo package.json campo dependencies . Essas dependências estarão disponíveis ao executar o monitor no gerenciador de tarefas Sintético privado. Veja um exemplo disso abaixo.

Exemplo

Neste exemplo, um diretório de módulo customizado é usado com a seguinte estrutura:

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

O package.json define dependencies como um módulo local (por exemplo, counter) e qualquer módulo hospedado (por exemplo, smallest versão 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
    }
}

Adicione seu diretório de módulos personalizados ao SJM para Docker, Podman ou Kubernetes

Para verificar se os módulos foram instalados corretamente ou se ocorreu algum erro, procure as seguintes linhas no synthetics-job-manager contêiner ou log pod :

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.

Agora você pode adicionar "require('smallest');" ao script de monitor que você envia para esta localização privada.

Mudar package.json

Além dos módulos locais e hospedados, você também pode utilizar módulos Node.js. Para atualizar os módulos customizados usados pelo seu SJM, faça alterações no arquivo package.json e reinicie o SJM. Durante o processo de reinicialização, o SJM reconhecerá a alteração na configuração e executará automaticamente as operações de limpeza e reinstalação para garantir que os módulos atualizados sejam aplicados.

Cuidado

Módulos locais: embora seu package.json possa incluir qualquer módulo local, esses módulos devem residir na árvore no diretório do módulo personalizado. Se armazenado fora da árvore, o processo de inicialização falhará e você verá uma mensagem de erro no log docker após iniciar o SJM.

Armazenamento permanente de dados

O usuário pode querer usar o armazenamento permanente de dados para fornecer o arquivo user_defined_variables.json ou oferecer suporte a módulos de nós personalizados.

Docker

Para definir o armazenamento permanente de dados no Docker:

  1. Crie um diretório no host onde você está iniciando o Job Manager. Este é o seu diretório de origem.

  2. inicie o Job Manager, montando o diretório de origem no diretório de destino /var/lib/newrelic/synthetics.

    Exemplo:

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

Homem-Pod

Para definir o armazenamento permanente de dados no Podman:

  1. Crie um diretório no host onde você está iniciando o Job Manager. Este é o seu diretório de origem.
  2. inicie o Job Manager, montando o diretório de origem no diretório de destino /var/lib/newrelic/synthetics.

Exemplo:

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

Kubernetes

Para definir o armazenamento permanente de dados no Kubernetes, o usuário tem duas opções:

  1. Forneça um PersistentVolumeClaim (PVC) existente para um PersistentVolume (PV) existente, definindo o valor de configuração synthetics.persistence.existingClaimName . Exemplo:

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

  2. Forneça um nome PersistentVolume (PV) existente, definindo o valor de configuração synthetics.persistence.existingVolumeName . Helm irá gerar um PVC para o usuário. O usuário também pode definir opcionalmente os seguintes valores:

  • synthetics.persistence.storageClass: A classe de armazenamento do PV existente. Se não for fornecido, o Kubernetes usará a classe de armazenamento padrão.

  • synthetics.persistence.size: O tamanho da reivindicação. Se não for definido, o padrão atualmente é 2Gi.

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

Sizing considerations for Docker and Podman

Para garantir que sua localização privada seja executada com eficiência, você deve provisionar recursos de CPU suficientes em seu host para lidar com sua workload de monitoramento. Muitos fatores influenciam o dimensionamento, mas você pode estimar rapidamente suas necessidades. Você precisará de 1 núcleo de CPU para cada monitor pesado (por exemplo, navegador simples, navegador com script ou monitor de API com script). Abaixo estão duas fórmulas para ajudar você a calcular o número de núcleos necessários, seja para diagnosticar uma configuração atual ou planejar uma futura.

Fórmula 1: Diagnosticando um Local Existente

Se sua localização privada atual estiver com dificuldades para acompanhar e você suspeitar que há trabalhos na fila, use esta fórmula para descobrir quantos núcleos você realmente precisa. Baseia-se no desempenho observável do seu sistema.

$$ C_req = (R_proc + R_growth) \cdot D_avg,m $$

  • C_reqC\_req = Núcleos de CPU necessários.
  • R_procR\_proc = A taxa de trabalhos pesados sendo processados por minuto.
  • R_growthR\_growth = A taxa de crescimento da sua fila jobManagerHeavyweightJobs por minuto.
  • D_avg,mD\_avg,m = A duração média de trabalhos pesados em 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: Previsão de um local novo ou futuro

Se você estiver configurando uma nova localização privada ou planejando adicionar mais monitores, use esta fórmula para prever suas necessidades com antecedência.

$$ C_req = N_mon \cdot D_avg,m \cdot \frac1P_avg,m $$

  • C_reqC\_req = Núcleos de CPU necessários.
  • N_monN\_mon = O número total de monitores pesados que você planeja executar.
  • D_avg,mD\_avg,m = A duração média de um trabalho pesado em minutos.
  • P_avg,mP\_avg,m = O período médio para monitores pesados em minutos (por exemplo, um monitor que é executado a cada 5 minutos tem 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.

Fatores importantes de dimensionamento

Ao usar essas fórmulas, lembre-se de levar em conta estes fatores:

  • Duração do trabalho (D_avg,mD\_avg,m): Sua média deve incluir trabalhos que expiram (geralmente ~3 minutos), pois eles mantêm um núcleo durante toda a sua duração.
  • Falhas e novas tentativas de trabalho: quando um monitor falha, ele é automaticamente repetido. Essas tentativas são trabalhos adicionais que aumentam a carga total. Um monitor que falha consistentemente e tenta novamente multiplica efetivamente seu período, impactando significativamente as taxas de transferência.
  • Escalonamento: além de adicionar mais núcleos a um host (escalonamento vertical), você pode implantar gerenciadores de tarefas adicionais da Sintéticos com a mesma chave de localização privada para balancear a carga de tarefas em vários ambientes (escalonamento horizontal).

É importante observar que um único Sintéticos Job Manager (SJM) tem um limite de taxas de transferência de aproximadamente 15 trabalhos pesados por minuto. Isso se deve a uma estratégia de segmentação interna que favorece a competição eficiente de trabalhos entre vários SJMs em relação ao número bruto de trabalhos processados por SJM. Se seus cálculos indicarem a necessidade de taxas de transferência mais altas, você deverá expandir implantando SJMs adicionais. Você pode verificar se sua fila de tarefas está crescendo para determinar se mais SJMs são necessários.

Adicionar mais SJMs com a mesma chave de localização privada oferece diversas vantagens:

  • Balanceamento de carga: Os trabalhos para localização privada são distribuídos em todos os SJMs disponíveis.
  • Proteção contra failover: se uma instância do SJM ficar inativa, outras poderão continuar processando trabalhos.
  • Taxas de transferência totais mais altas: As taxas de transferência totais para sua localização privada tornam-se a soma das taxas de transferência de cada SJM (por exemplo, dois SJMs fornecem até ~30 trabalhos/minuto).

Consulta NRQL para diagnóstico

Você pode executar essas consultas no criador de consultas para obter as entradas para a fórmula de diagnóstico. Certifique-se de definir o intervalo de tempo para um período longo o suficiente para obter uma média estável.

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

Dica

Certifique-se de selecionar a conta onde existe a localização privada. É melhor visualizar essa consulta como uma série temporal porque a função derivada pode variar muito. O objetivo é obter uma estimativa da taxa de crescimento da fila por minuto. Play diferentes intervalos de tempo para ver o que funciona melhor.

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. Encontre o período médio do monitor de peso pesado (P_avg,mP\_avg,m): Se a fila jobManagerHeavyweightJobs da localização privada estiver crescendo, não será preciso calcular o período médio do monitor a partir dos resultados existentes. Isso precisará ser estimado a partir da lista de monitores na página Monitores Sintético. Certifique-se de selecionar a conta New Relic correta e talvez seja necessário filtrar por privateLocation.

Dica

Monitores Sintéticos podem existir em múltiplas subcontas. Se você tiver mais subcontas do que as que podem ser selecionadas no criador de consulta, escolha as contas com mais monitores.

Nota sobre monitores de ping e a fila pingJobs

Os monitores de ping são diferentes. São trabalhos leves que não consomem um núcleo de CPU completo cada. Em vez disso, eles usam uma fila separada (pingJobs) e são executados em um pool de threads de trabalho.

Embora consumam menos recursos, um alto volume de tarefas de ping, especialmente aquelas com falhas, ainda pode causar problemas de desempenho. Tenha estes pontos em mente:

  • Modelo de recursos: os trabalhos de ping utilizam threads de trabalho, não núcleos de CPU dedicados. O cálculo de núcleo por trabalho não se aplica a eles.
  • Tempo limite e nova tentativa: uma tarefa de ping com falha pode ocupar um thread de trabalho por até 60 segundos. Primeiro, ele tenta uma solicitação HTTP HEAD (tempo limite de 30 segundos). Se isso falhar, ele tenta imediatamente com uma solicitação HTTP GET (outro tempo limite de 30 segundos).
  • Dimensionamento: embora a fórmula de dimensionamento seja diferente, os mesmos princípios se aplicam. Para lidar com um grande volume de trabalhos de ping e evitar que a fila pingJobs cresça, talvez seja necessário aumentar e/ou diminuir a escala. Aumentar a escala significa aumentar os recursos de CPU e memória por host ou namespace. Escalar significa adicionar mais instâncias do tempo de execução do ping. Isso pode ser feito implantando mais gerenciadores de tarefas em mais hosts, em mais namespaces ou até mesmo dentro do mesmo namespace. Como alternativa, o ping-runtime no Kubernetes permite que você defina um número maior de réplicas por implantação.

Sizing considerations for Kubernetes and OpenShift

Cada tempo de execução usado pelo gerenciador de tarefas Kubernetes e do OpenShift Sintético pode ser dimensionado independentemente definindo valores no gráfico do helm. O node-api-runtime e o node-browser-runtime são dimensionados independentemente usando uma combinação das configurações parallelism e 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.

Dica

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.

Dica

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.

Exemplo

Descrição

parallelism=1 completions=1

O runtime executará 1 job Sintético por minuto. Após a conclusão de 1 trabalho, a configuração CronJob iniciará um novo trabalho no minuto seguinte. 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.

É importante observar que o valor completions não deve ser muito grande ou o CronJob receberá um aviso como este:

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

Dica

New Relic não se responsabiliza por quaisquer modificações que você fizer nos arquivos do gerenciador de tarefas do 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.
CarreirasTermos de serviçoPolítica do DMCAAviso de patenteAviso de privacidadePolítica de cookiesUK Slavery Act

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