Configuração do gerenciador de tarefas Sintético

As variáveis são fornecidas na inicialização usando o argumento -e, --env .

A tabela a seguir mostra todas as variáveis de ambiente suportadas pelo gerenciador de tarefas Sintético. PRIVATE_LOCATION_KEY é obrigatório e todas as outras variáveis são opcionais.

As variáveis são fornecidas na inicialização usando o argumento -e, --env .

A tabela a seguir exibe todas as variáveis de ambiente que o gerenciador de tarefas Sintéticos suporta. PRIVATE_LOCATION_KEY é obrigatório e todas as outras variáveis são opcionais. Para executar o gerenciador de tarefas Sintéticos em um ambiente Podman, a versão mínima deve ser release-418 ou superior.

As variáveis são fornecidas na inicialização usando o argumento --set .

A lista a seguir mostra todas as variáveis de ambiente suportadas pelo gerenciador de tarefas Sintético. synthetics.privateLocationKey é obrigatório e todas as outras variáveis são opcionais.

Uma série de configurações avançadas adicionais estão disponíveis e totalmente documentadas em nosso README do gráfico do Helm

As variáveis são fornecidas na inicialização usando o argumento --set .

A lista a seguir mostra todas as variáveis de ambiente suportadas pelo gerenciador de tarefas Sintético. synthetics.privateLocationKey é obrigatório e todas as outras variáveis são opcionais.

Uma série de configurações avançadas adicionais estão disponíveis e totalmente documentadas em nosso README do gráfico do Helm

O usuário pode criar um arquivo no formato JSON e montar o volume onde o arquivo está localizado em um caminho de destino especificado no contêiner SJM.

O arquivo deve ter permissões de leitura e conter um mapa formatado em JSON. Exemplo de arquivo de variáveis definidas pelo usuário:

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

Coloque o arquivo no diretório de origem do host. O SJM espera que o nome do arquivo seja user_defined_variables.json

Exemplo de Docker :

O diretório de destino esperado é: /var/lib/newrelic/synthetics/variables/

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

Exemplo de Podman:

No caso do SELinux, monte o volume adicionalmente com :z ou :Z. Para mais informações, consulte a documentação do Podman. O diretório de destino esperado é: /var/lib/newrelic/synthetics/variables/

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

Exemplo de Kubernetes:

O usuário tem duas opções ao fornecer um arquivo ao pod SJM no Kubernetes. Eles podem:

• Passe um arquivo local.
• Forneça um PersistentVolume que inclua o user_defined_variables.json.

Passe um arquivo local

Esta opção cria um recurso ConfigMap Kubernetes e o monta no pod SJM.

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

Monte um PersistentVolume

Esta opção exige que o usuário forneça um PersistentVolume que inclua o arquivo user_defined_variables.json ou um PersistentVolumeClaim para o mesmo. Para obter mais detalhes sobre a instalação do helm chart usando um PersistentVolume, siga as instruções em armazenamento permanente de dados.

Depois que o usuário tiver preparado um PersistentVolume conforme descrito abaixo, inicie o SJM, definindo o caminho onde o arquivo user_defined_variables.json está localizado e defina quaisquer outras variáveis synthetics.persistence conforme necessário.

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

As variáveis poderão ser passadas para seu respectivo sistema contêiner via variável de ambiente.

Exemplo de Docker :

Use a sinalização -e para configurar uma variável de ambiente chamada USER_DEFINED_VARIABLES e atribua a ela o valor de uma string de mapa formatada em JSON.

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

Exemplo de Podman:

Use a sinalização -e para configurar uma variável de ambiente chamada USER_DEFINED_VARIABLES e atribua a ela o valor de uma string de mapa formatada em JSON.

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

Exemplo de Kubernetes:

Use a sinalização --set-literal para transmitir a string formatada em JSON.

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

Para docker, lance o SJM montando o diretório em /var/lib/newrelic/synthetics/modules. Por exemplo:

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

Para podman, inicie o SJM montando o diretório em /var/lib/newrelic/synthetics/modules. No caso do SELinux, monte o volume adicionalmente com :z ou :Z. Para mais informações, consulte a documentação do Podman. Por exemplo:

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

Para Kubernetes, o diretório em /var/lib/newrelic/synthetics/modules precisa existir em um PV antes de iniciar o SJM com módulos customizados habilitados.

Um método é criar um pod que monte o PV apenas com a finalidade de copiar o diretório de módulos personalizados para o PV. O exemplo a seguir usa Amazon EFS com Amazon EKS:

Criar o namespace, o volume persistente e a declaração de volume persistente

1. Certifique-se de já ter configurado seu sistema de arquivos EFS e instalado o driver EFS CSI em seu cluster. Você também precisará do ID do sistema de arquivos EFS para os PVs spec.csi.volumeHandle.

   bash

   Copiar

   $
   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. Mude para o namespace newrelic em seu ~/.kube/config.

   bash

   Copiar

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

3. Neste ponto, o PVC deve estar vinculado ao PV com modo de acesso RWX.

   bash

   Copiar

   $
   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

   Crie mount-custom-mods-pod para copiar seu diretório de módulos personalizados

   bash

   Copiar

   $
   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

   Neste ponto, o mount-custom-mods-pod deve ser criado e configurado para usar o volume.

   bash

   Copiar

   $
   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

   Verifique se há algum aviso relacionado ao PV, PVC ou mount-custom-mods-pod.

   bash

   Copiar

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

   Copie seu diretório de módulos personalizados para o PV

   Não é necessário copiar node_modules pois ele será gerado pelo SJM em npm install.

   bash

   Copiar

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

4. Verifique se o mount-custom-mods-pod está em execução.

   bash

   Copiar

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

5. Copie para o PV.

   bash

   Copiar

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

6. Verifique se /var/lib/newrelic/synthetics/modules/custom-modules/package.json existe no PV.

   bash

   Copiar

   $
   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

   lançar o SJM com recurso de módulos customizados habilitado

   Configure valores para persistence.existingClaimName e customNodeModules.customNodeModulesPath na linha de comando ou em um arquivo YAML durante a instalação. O valor customNodeModules.customNodeModulesPath deve especificar o subcaminho no Volume Persistente onde existem seus arquivos de módulos personalizados. Por exemplo:

   bash

   Copiar

   $
   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

   O diretório custom-modules agora deve conter os pacotes instalados em node_modules.

   bash

   Copiar

   $
   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

   Se os módulos de nós customizados não forem detectados, ajuste as permissões no diretório custom-modules e no arquivo package.json .

   bash

   Copiar

   $
   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

Monte o diretório do host local contendo seus arquivos PEM no caminho do contêiner SJM /var/lib/newrelic/synthetics/certs como um volume somente leitura.

$
docker run \
>
  -v /PATH/TO/YOUR_CA_CERTS:/var/lib/newrelic/synthetics/certs:ro \
>
  newrelic/synthetics-job-manager

Como isso funciona: o SJM detecta essa montagem na inicialização e propaga os certificados como somente leitura para cada contêiner dinâmico que ele gera.

Para ambientes Podman — especialmente aqueles executados com o SELinux ativado — você deve anexar o sinalizador :z ou :Z à montagem de volume para configurar o contexto de segurança correto.

$
podman run \
>
  -v /PATH/TO/YOUR_CA_CERTS:/var/lib/newrelic/synthetics/certs:ro,z \
>
  newrelic/synthetics-job-manager

Ao implantar o SJM em um cluster do Kubernetes via Helm, você pode gerenciar seu pacote de certificados de CA personalizado como um secret genérico do Kubernetes.

1. Crie o segredo do Kubernetes

Armazene seu(s) arquivo(s) de certificado PEM em um secret dentro do namespace do agente da New Relic:

$
kubectl create secret generic my-ca-bundle \
>
  --from-file=/PATH/TO/YOUR_CA_CERTS/ \
>
  -n newrelic

2. Atualize seus valores do Helm

Referencie o segredo recém-criado em sua configuração values.yaml personalizada:

global:
  customCertificates:
    volume:
      secret:
        secretName: my-ca-bundle

Como isso funciona: na inicialização, o SJM monta esse secret e o repassa automaticamente para todos os pods de execução recém-criados.

Montar um diretório contendo cert-map.json e os arquivos de certificado e chave referenciados:

$
docker run \
>
  -v /path/to/ca-certs:/var/lib/newrelic/synthetics/certs:ro \
>
  -v /path/to/client-certs:/var/lib/newrelic/synthetics/client-cert:ro \
>
  newrelic/synthetics-job-manager

Se os nomes do host do servidor mTLS não puderem ser resolvidos via DNS dentro dos contêineres de tempo de execução, adicione mapeamentos de nome do host usando RUNTIME_EXTRA_HOSTS:

$
docker run \
>
  -e 'RUNTIME_EXTRA_HOSTS=api.internal.company.com:10.0.0.1,svc.internal:10.0.0.2' \
>
  -v /path/to/client-certs:/var/lib/newrelic/synthetics/client-cert:ro \
>
  newrelic/synthetics-job-manager

Montar o diretório de certificados do cliente. Para o SELinux, adicionar :z ou :Z:

$
podman run \
>
  -v /path/to/client-certs:/var/lib/newrelic/synthetics/client-cert:ro,z \
>
  newrelic/synthetics-job-manager

Crie um Kubernetes Secret contendo cert-map.json e todos os arquivos de certificado e chave referenciados:

$
kubectl create secret generic my-mtls-certs \
>
  --from-file=cert-map.json=/path/to/cert-map.json \
>
  --from-file=client.crt=/path/to/client.crt \
>
  --from-file=client.key=/path/to/client.key \
>
  -n newrelic

Referenciar o secret nos valores do Helm:

global:
  clientCertificates:
    volume:
      secret:
        secretName: my-mtls-certs

O secret é montado como somente leitura em todos os pods de tempo de execução automaticamente.

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

   Copiar

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

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

   Copiar

   $
   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

   Copiar

   $
   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

  Copiar

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

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_{est} = (R_{proc} + R_{growth}) \cdot D_{avg,m} $$

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

• R\_\{proc} = A taxa de trabalhos pesados sendo processados por minuto.

• R\_\{growth} = A taxa em que sua fila jobManagerHeavyweightJobs está crescendo por minuto.

• D\_\{avg,m} = A duração média de trabalhos pesados em minutos.

  Esta fórmula calcula a sua taxa real de chegada de tarefas, somando as tarefas que o seu sistema está processando às tarefas que estão se acumulando na fila. Multiplicar essa carga total pela duração média da tarefa indica exatamente quantos núcleos são necessários para concluir todo o trabalho sem enfileiramento.

  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_{est} = N_{mon} \cdot D_{avg,m} \cdot \frac{1}P_{avg,m} $$

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

• N\_\{mon} = O número total de monitores pesados que você planeja executar.

• D\_\{avg,m} = A duração média de uma tarefa pesada em minutos.

• P\_\{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} = 5).

  Este cálculo parte dos princípios básicos para determinar a sua workload esperada: quantos monitores você tem, com que frequência eles são executados e quanto tempo levam para serem concluídos.

  Fatores importantes de dimensionamento

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

• Duração do job (D\_\{avg,m}): Sua média deve incluir jobs que excedem o tempo limite (geralmente 3 minutos), pois eles ocupam 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 totais de transferência maiores: as taxas totais de transferência para sua localização privada se tornam a soma das taxas de transferência de cada SJM (p. ex., 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. Encontre a taxa de jobs processados por minuto (R\_\{proc}): Esta consulta conta o número de jobs não-ping (pesados) concluídos no último dia e mostra a taxa média 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

  Copiar

  2. Encontre a taxa de crescimento da fila por minuto (R\_\{growth}): Esta consulta calcula o crescimento médio por minuto da fila jobManagerHeavyweightJobs em um gráfico de série temporal. Uma linha acima de zero indica que a fila está aumentando, enquanto uma linha abaixo de zero significa que ela está diminuindo.

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

  Copiar

  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. Encontre o número total de monitores pesados (N\_\{mon}): Esta consulta encontra a contagem única de monitores pesados.

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

  Copiar

  4. Encontre a duração média do job em minutos (D\_\{avg,m}): Esta consulta encontra a duração média de execução de jobs não-ping concluídos e converte o resultado de milissegundos para minutos. executionDuration representa o tempo que o job levou para executar no host.

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

  Copiar

  5. Encontre o período médio do monitor heavyweight (P\_\{avg,m}): Se a fila de jobManagerHeavyweightJobs da localização privada estiver aumentando, não é exato 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éticos. Certifique-se de selecionar a conta New Relic correta e pode ser 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.

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.

• A configuração parallelism controla quantos pods de um determinado runtime são executados simultaneamente.

• A configuração completions controla quantos pods devem ser concluídos antes que o CronJob inicie outro Job Kubernetes para esse runtime.

  Melhores práticas para o dimensionamento da sua implantação

  Muitas vezes não é possível calcular com precisão os valores de paralelismo e conclusões necessários porque a duração média vista no New Relic pode não ser precisa, especialmente se o local privado existente não estiver funcionando bem. Siga esta abordagem prática para ajustar o paralelismo e as conclusões. As equações abaixo podem ser usadas para obter valores aproximados como ponto de partida.

  1. Estimar conclusões e paralelismo

  Faça o possível para estimar a duração média de execução e o número de jobs por 5 minutos. Isso fornece um ponto de partida aproximado para a próxima etapa, que envolverá tentativa e erro para ajustar os valores de paralelismo e conclusões em um cluster em funcionamento. Certifique-se de escalá-los proporcionalmente, por exemplo, indo dos padrões de 1 e 6 para 10 e 60.

  Conclusões Estimadas: Isso determina quanto tempo sua carga de jobs de 5 minutos levará para ser concluída.

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

  Copiar

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

  Onde D\_\{avg,m} é a sua duração média de execução do job em minutos.

  Paralelismo Estimado: Isso determina quantos workers (pods) você precisa executar simultaneamente para lidar com sua carga de trabalho 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

  Copiar

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

  Onde $N\_m$ é o seu número de jobs por 5 minutos. Este valor P\_\{est} é o seu paralelismo estimado.

  2. Execute um deploy do Helm

  Execute um deploy do Helm com valores estimados de paralelismo e conclusões, e sua melhor estimativa para ping-runtime.replicaCount considerando o número de núcleos de CPU por nó e o número de monitores de ping que precisam ser executados por minuto.

  3. Monitore o crescimento da fila

  Com os monitores sintéticos configurados para enviar tarefas para o local privado, verifique o crescimento da fila em um gráfico de linha de série temporal para pingJobs e jobManagerHeavyweightJobs.

• Se a fila pingJobs tiver uma inclinação positiva, aumente ping-runtime.replicaCount e reimplante.

• Se a fila jobManagerHeavyweightJobs tiver uma inclinação positiva, aumente parallelism e completions proporcionalmente até que a fila pare de crescer (inclinação negativa).

  Uma inclinação negativa indica que o gerenciador de jobs tem paralelismo suficiente para lidar com a demanda do job. Eventualmente atingirá zero com uma inclinação 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

  Copiar

  4. Ajuste com base no estado de execução do pod

  Com a fila diminuindo ou zerada, verifique se há pods node-api-runtime e node-browser-runtime que estejam em um estado "running" há mais de 10 minutos. Isso indica que o paralelismo está definido muito alto e há mais pods do que o necessário.

  Para evitar o desperdício desnecessário de recursos, diminua parallelism e completions para reduzir a idade de cada pod de runtime "em execução". Se o objetivo for uma idade de job do Kubernetes de 5 minutos, os pods de runtime devem estar em estado de execução por menos de 5 minutos, o que significa que o pod foi criado, recebeu rapidamente um job para executar e foi concluído.

  5. Escale horizontalmente se necessário

  Se a fila não estiver diminuindo, mas houver muitos pods em um estado "running" por mais de 10 minutos, é provável que o gerenciador de jobs esteja atingindo seu gargalo de desempenho. A próxima etapa é reduzir o paralelismo e escalar horizontalmente com uma ou mais implantações adicionais.

  Por exemplo, com parallelism: 100, completions: 600 a fila ainda está crescendo, mas há muitos pods em um estado "running" há mais de 10 minutos, e a idade do Job do Kubernetes é de 20 minutos ... defina parallelism: 50, completions: 200 e escale horizontalmente (out) adicionando 2 deployments adicionais. Isso resulta em um total de 150 pods paralelos e deve reduzir a duração do job do K8s para menos de 20 minutos, reduzindo também o número de pods "running" de longa duração. Busque uma idade de job do K8s de 5 a 10 minutos.

  Para mais informações sobre como adicionar implantações, consulte Escalonamento horizontal com múltiplas implantações do SJM.

  Dica

  Você pode usar a seguinte consulta para ajudar a determinar se precisa escalar horizontalmente.

  Observação: Monitores podem existir em várias subcontas.

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

  Copiar

  Dica

  Reduzir o número de ciclos de jobs do K8s também pode melhorar o desempenho. À medida que cada ciclo atinge o número definido de conclusões, há cada vez menos pods "em execução" para assumir novos jobs do Synthetics. Por exemplo, com completions definido como 200 e parallelism definido como 50, temos inicialmente 50 pods em execução, mas isso começa a diminuir à medida que passamos de 150 completions. Com 199 conclusões, resta apenas 1 pod em execução.

  Definir um valor maior para completions não é uma má ideia, mas pode levar a eventos de aviso no K8s sobre TooManyMissedTimes para o cronjob.

  Expandindo com múltiplas implantações SJM

  Para escalar além das taxas de transferência de 15 jobs/minuto de um único SJM, você deve instalar várias versões separadas do SJM Helm.

  Importante

  Não use réplicas para escalar o pod do job manager. A arquitetura SJM requer uma relação 1:1 entre um pod de runtime e seu pod SJM pai. Se os pods de runtime enviarem resultados de volta para a réplica do SJM incorreta (por exemplo, por meio de um serviço do Kubernetes), esses resultados serão perdidos. No entanto, ping-runtime.replicaCount pode ser usado.

  A estratégia correta é implantar múltiplos SJMs instância, cada um como sua própria versão Helm. Cada SJM competirá por trabalhos da mesma localização privada, fornecendo balanceamento de carga, proteção contra failover e um aumento nas taxas de transferência totais de trabalho.

  Estratégia de escalonamento horizontal

  Se você precisar escalar horizontalmente, pode simplificar a manutenção tratando cada implantação do SJM como uma unidade de capacidade fixa.

1. Definir Paralelismo: Para cada SJM, defina parallelism para o mesmo máximo que um único SJM pode suportar sem criar muitos pods de runtime "em execução" de longa duração. Isso maximiza o throughput potencial de cada SJM sem desperdiçar recursos.

2. Definir Conclusões: Para cada SJM, defina completions para o mesmo valor fixo também. Ajuste conforme necessário para atingir uma idade de job do Kubernetes de 5 minutos por runtime, ou seja, node-browser-runtime e node-api-runtime.

3. Instalar Releases: Instale quantas releases do Helm separadas forem necessárias para lidar com sua demanda total de jobs, ou seja, zerar a fila ou obter uma inclinação negativa no gráfico de linha.

4. Monitore e adicione: Monitore a fila de tarefas da localização privada. Se começar a aumentar (inclinação positiva), basta instalar outra release do Helm (por exemplo, sjm-delta) usando a mesma configuração fixa.

   Ao fixar o paralelismo e as conclusões em valores estáticos, aumentar ou diminuir a capacidade torna-se um processo mais simples de adicionar ou remover releases do Helm. Isso ajuda a evitar o desperdício de recursos do cluster com um valor de paralelismo superior ao que o SJM pode utilizar efetivamente.

   Exemplo de instalação

   Ao instalar várias versões do SJM, você deve fornecer um nome exclusivo para cada versão. Todas as instâncias devem ser configuradas com a mesma chave de localização privada.

   É altamente recomendável definir o fullnameOverride para criar nomes de recursos mais curtos e fáceis de gerenciar. Por exemplo, para instalar dois SJMs chamados sjm-alpha e sjm-beta no namespace newrelic (ambos usando o mesmo values.yaml com seu paralelismo e autocompletares fixos):

   bash

   Copiar

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

   Copiar

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

   Você pode continuar este padrão (sjm-charlie, sjm-delta, etc.) para quantos SJMs forem necessários para impedir que a fila de trabalho cresça.