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.
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.
Nome
Descrição
PRIVATE_LOCATION_KEY
REQUIRED. chave de localização privada, conforme encontrada na lista entidade privada de localização.
DOCKER_API_VERSION
Formato: "vX.Y" versão da API a ser usada com o serviço Docker fornecido.
Padrão: v1.35.
DOCKER_HOST
Aponta o gerenciador de tarefas Sintético para um determinado DOCKER_HOST. Se ausente, o valor padrão é /var/run/docker.sock.
HORDE_API_ENDPOINT
Para contas baseadas nos EUA, o endpoint é: https://synthetics-horde.nr-data.net.
Para contas baseadas na UE , o endpoint é: https://synthetics-horde.eu01.nr-data.net/
Certifique-se de que seu gerenciador de tarefas Sintético possa se conectar ao endpoint apropriado para atender seu monitor.
DOCKER_REGISTRY
O domínio Docker Registry onde as imagens de tempo de execução estão hospedadas. Use isto para substituir docker.io como padrão.
DOCKER_REPOSITORY
O docker repositório ou organização onde as imagens de tempo de execução estão hospedadas. Use isto para substituir newrelic como padrão.
HORDE_API_PROXY_HOST
Host do servidor proxy usado para comunicação da Horda. Formato: "localhost".
HORDE_API_PROXY_PORT
Porta do servidor proxy usada para comunicação da Horda. Formato: 8888.
HORDE_API_PROXY_USERNAME
Nome de usuário do servidor proxy usado para comunicação da Horda. Formato: "username".
HORDE_API_PROXY_PW
Senha do servidor proxy usada para comunicação da Horda. Formato: "password".
HORDE_API_PROXY_ACCEPT_SELF_SIGNED_CERT
Aceita certificados proxy autoassinados para a conexão do servidor proxy usada para comunicação do Horde? Valores aceitáveis: true
CHECK_TIMEOUT
A quantidade máxima de segundos que as verificações do seu monitor podem ser executadas. Este valor deve ser um número inteiro entre 0 segundos (excluído) e 900 segundos (incluído) (por exemplo, de 1 segundo a 15 minutos).
Padrão: 180 segundos
LOG_LEVEL
Padrão: INFO.
Opções adicionais: WARN, ERROR, DEBUG
HEAVYWEIGHT_WORKERS
O número de trabalhos pesados simultâneos (navegador/navegador com script e API com script) que podem ser executados ao mesmo tempo.
Padrão: CPUs disponíveis - 1.
DESIRED_RUNTIMES
Uma matriz que pode ser usada para executar imagens de tempo de execução específicas. Formato: ['newrelic/Sintético-ping-runtime:latest','newrelic/Sintético-node-API-runtime:latest','newrelic/Sintético-node-navegador-runtime:latest']
Padrão: todos os tempos de execução mais recentes.
VSE_PASSPHRASE
Se definido, ativa verified script execution e usa esse valor como passphrase.
USER_DEFINED_VARIABLES
Um conjunto hospedado localmente de pares de valores principais definidos pelo usuário.
ENABLE_WASM
Se definido, habilita o webassembly para o tempo de execução do navegador do nó. Para usar o webassembly, a versão mínima do seu gerenciador de tarefas Sintético deve ser release-367 ou superior e a versão do tempo de execução do navegador do nó deve ser 2.3.21 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
Nome
Descrição
synthetics.privateLocationKey
REQUIRED if synthetics.privateLocationKeySecretName is not set. localização privada chave da localização privada, conforme encontrado na página localização privada.
synthetics.privateLocationKeySecretName
REQUIRED if synthetics.privateLocationKey is not set. Nome do segredo do Kubernetes que contém a chave privateLocationKey, que contém a chave de autenticação associada ao seu Sintético localização privada.
imagePullSecrets
O nome do objeto secreto usado para extrair uma imagem de um registro de contêiner especificado.
fullnameOverride
Substituição de nome usada para sua implantação, substituindo o padrão.
appVersionOverride
Versão de lançamento do Sintético-job-manager para usar em vez da versão especificada em chart.yml.
synthetics.logLevel
Padrão: INFO.
Opções adicionais: WARN, ERROR
synthetics.hordeApiEndpoint
Para contas baseadas nos EUA, o endpoint é: https://synthetics-horde.nr-data.net.
Para contas baseadas na UE , o endpoint é: https://synthetics-horde.eu01.nr-data.net/
Certifique-se de que seu gerenciador de tarefas Sintético possa se conectar ao endpoint apropriado para atender seu monitor.
synthetics.minionDockerRunnerRegistryEndpoint
O registro e organização Docker onde a imagem do minion Runner está hospedada. Use isto para substituir quay.io/newrelic como padrão (por exemplo, docker.io/newrelic)
synthetics.vsePassphrase
Se definido, ele ativa verified script execution e usa esse valor como passphrase.
synthetics.vsePassphraseSecretName
Se definido, permite a execução verificada do script e usa esse valor para recuperar a senha de um segredo do Kubernetes com uma chave chamada vsePassphrase.
synthetics.enableWasm
Se definido, habilita o webassembly para o tempo de execução do navegador do nó. Para usar o webassembly, a versão mínima do seu gerenciador de tarefas Sintético deve ser release-367 ou superior e a versão do tempo de execução do navegador do nó deve ser 2.3.21 ou superior.
synthetics.apiProxyHost
Servidor proxy usado para comunicação da Horda. Formato: "host".
synthetics.apiProxyPort
Porta do servidor proxy usada para comunicação da Horda. Formato: port.
synthetics.hordeApiProxySelfSignedCert
Aceite certificados autoassinados ao usar um servidor proxy para comunicação do Horde. Valores aceitáveis: true.
synthetics.hordeApiProxyUsername
Nome de usuário do servidor proxy para comunicação da Horda. Formatar: "username"
synthetics.hordeApiProxyPw
Senha do servidor proxy para comunicação da Horda. Formato: "password".
synthetics.userDefinedVariables.userDefinedJson
Uma string JSON de variáveis definidas pelo usuário. O usuário pode acessar essas variáveis em seu script. Formato: '{"key":"value","key2":"value2"}'.
synthetics.userDefinedVariables.userDefinedFile
Um caminho local para o usuário para um arquivo JSON contendo variáveis definidas pelo usuário. Isso é transmitido por meio de --set-file e não pode ser definido no arquivo Valores.
synthetics.userDefinedVariables.userDefinedPath
Um caminho no PersistentVolume fornecido pelo usuário para o arquivo user_defined_variables.json. O usuário deverá fornecer um PersistentVolume ou PersistentVolumeClaim se esta variável for preenchida.
synthetics.persistence.existingClaimName
Se estiver montando um volume, o usuário poderá fornecer um nome para um PersistentVolumeClaim que já existe no cluster. Pressupõe a existência de um PersistentVolume correspondente.
synthetics.persistence.existingVolumeName
Se estiver montando um volume e não fornecer um PersistentVolumeClaim, o usuário deverá fornecer, no mínimo, um nome PersistentVolume. Helm irá gerar um PersistentVolumeClaim.
synthetics.persistence.storageClass
O nome do StorageClass para o PersistentVolumeClaim gerado. Isso deve corresponder ao StorageClassName no PV existente. Caso contrário, o Kubernetes usará a classe de armazenamento padrão, se presente.
synthetics.persistence.size
O tamanho do volume do PersistentVolumeClaim gerado. Formato: 10Gi. 2Gi padrão.
global.checkTimeout
A quantidade máxima de segundos que as verificações do seu monitor podem ser executadas. Este valor deve ser um número inteiro entre 0 segundos (excluído) e 900 segundos (incluído) (por exemplo, de 1 segundo a 15 minutos).
Padrão: 180 segundos
image.repository
O contêiner a ser puxado.
Padrão: docker.io/newrelic/synthetics-job-runner
image.pullPolicy
A política de puxar.
Padrão: IfNotPresent
podSecurityContext
Configure um contexto de segurança customizado para o pod Sintético-job-manager.
ping-runtime.enabled
Se o tempo de execução do ping persistente deve ou não ser implantado. Isso pode ser desativado se você não usar o monitor de ping.
Padrão: true
ping-runtime.replicaCount
O número de contêineres de tempo de execução de ping a serem implantados. Aumente o replicaCount para dimensionar a implantação com base nas suas necessidades de monitoramento de ping.
Padrão: 1
ping-runtime.image.repository
A imagem do contêiner a ser extraída para o tempo de execução do ping.
A política pull para o contêiner de tempo de execução de ping.
Padrão: IfNotPresent
node-api-runtime.enabled
Se o tempo de execução da API Node.js deve ou não ser implantado. Isso pode ser desativado se você não usar o monitor de API com script.
Padrão: true
node-api-runtime.parallelism
O número de ambientes de execução da API Node.js CronJobs a serem implantados. O número máximo de trabalhos simultâneos da API Node.js que serão executados a qualquer momento. Detalhes adicionais.
Padrão: 1
node-api-runtime.completions
O número de ambientes de execução da API Node.js CronJobs a serem concluídos por minuto. Aumentar esta configuração juntamente com o paralelismo para melhorar as taxas de transferência. Isto deve ser aumentado sempre que o paralelismo for aumentado e as conclusões devem sempre ser pelo menos maiores ou iguais ao paralelismo. . Aumente essa configuração se você observar períodos sem trabalhos de tempo de execução de API em execução. Detalhes adicionais.
Padrão: 6
node-api-runtime.image.repository
A imagem do contêiner a ser extraída para o ambiente de execução da API Node.js.
A política pull para o contêiner de tempo de execução da API Node.js.
Padrão: IfNotPresent
node-browser-runtime.enabled
Se o tempo de execução do navegador Node.js deve ou não ser implantado. Isso pode ser desativado se você não usar o script com simples ou monitor do navegador.
Padrão: true
node-browser-runtime.parallelism
O número de tempos de execução do navegador Chrome CronJobs a serem implantados. O número máximo de jobs simultâneos do navegador Chrome que serão executados a qualquer momento. Detalhes adicionais.
Padrão: 1
node-browser-runtime.completions
O número de tempos de execução do navegador Chrome CronJobs a serem concluídos por minuto. Aumentar esta configuração juntamente com o paralelismo para melhorar as taxas de transferência. Isto deve ser aumentado sempre que o paralelismo for aumentado e as conclusões devem sempre ser pelo menos maiores ou iguais ao paralelismo. Aumente essa configuração se você notar períodos de tempo sem tarefas de tempo de execução do navegador em execução. Detalhes adicionais.
Padrão: 6
node-browser-runtime.image.repository
A imagem do contêiner a ser extraída para o tempo de execução do navegador Node.js.
A política pull para o contêiner de tempo de execução do navegador Node.js.
Padrão: IfNotPresent
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.
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/
bash
$
docker run ... -v /variables:/var/lib/newrelic/synthetics/variables:rw ...
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.
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.
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.
bash
$
docker run ... -eUSER_DEFINED_VARIABLES='{"key":"value","name":"sjm"}'...
Exemplo de Kubernetes:
Use a sinalização --set-literal para transmitir a string formatada em JSON.
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):
Adicione seu diretório de módulos personalizados ao SJM para Docker ou Kubernetes
Para docker, lance o SJM montando o diretório em /var/lib/newrelic/synthetics/modules. Por exemplo:
bash
$
docker run ... -v /example-custom-modules-dir:/var/lib/newrelic/synthetics/modules:rw ...
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.
Dica
O modo de acesso PV deverá ser ReadWriteMany se você precisar compartilhar o armazenamento entre vários pods.
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
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
$
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
Mude para o namespace newrelic em seu ~/.kube/config.
Verifique se /var/lib/newrelic/synthetics/modules/custom-modules/package.json existe no PV.
bash
$
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:
Para verificar se os módulos foram instalados corretamente ou se ocorreu algum erro, procure as seguintes linhas no synthetics-job-managercontê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...
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:
Crie um diretório no host onde você está iniciando o Job Manager. Este é o seu diretório de origem.
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 ...
Kubernetes
Para definir o armazenamento permanente de dados no Kubernetes, o usuário tem duas opções:
Forneça um PersistentVolumeClaim (PVC) existente para um PersistentVolume (PV) existente, definindo o valor de configuração synthetics.persistence.existingClaimName . Exemplo:
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.
Considerações de dimensionamento para Kubernetes e Docker
Dica
considerações de dimensionamento específicas Docker estarão disponíveis em breve.
Se você estiver trabalhando em ambientes maiores, pode ser necessário customizar a configuração do gerenciador de tarefas para atender aos requisitos mínimos para executar o monitor Sintético com eficiência. Muitos fatores podem impactar os requisitos de dimensionamento para uma implantação do gerenciador de tarefas Sintético, incluindo:
Se todos os tempos de execução forem necessários com base no uso esperado
O número de trabalhos por minuto por tipo de monitor (ping, navegador simples ou com script e API com script)
Duração do trabalho, incluindo trabalhos que expiram em cerca de 3 minutos
O número de falhas de trabalho. Para falhas de trabalho, novas tentativas automáticas são agendadas quando um monitor começa a falhar ao fornecer lógica de repetição 3/3 integrada. Estes empregos adicionais somam-se aos requisitos de taxas de transferência do gestor de empregos Sintético.
Além das definições de configuração de dimensionamento listadas abaixo, gerenciadores de tarefas adicionais do Sintético podem ser implantados com a mesma chave de localização privada para balancear a carga de tarefas em vários ambientes.
Kubernetes
Cada tempo de execução usado pelo gerenciador de tarefas Kubernetes Sintético pode ser dimensionado de forma independente, definindo valores no gráfico do leme.
Tempos de execução de ping adicionais podem ser iniciados para ajudar a executar a carga do monitor de ping aumentando a configuração ping-runtime.replicaCount do valor padrão de 1.
Os tempos de execução da API Node.js e do navegador Node.js são dimensionados de forma independente usando uma combinação das configurações parallelism e completions . A configuração ideal para essas configurações irá variar de acordo com os requisitos do cliente.
A configuração parallelism controla quantos pods de um ambiente de execução específico são executados simultaneamente. A configuração parallelism é equivalente à configuração synthetics.heavyWorkers no minion privado conteinerizado (chamadas por minuto). Certifique-se de que seu cluster do Kubernetes tenha recursos suficientes disponíveis para executar esse número de pods com base em suas solicitações de recursos e valores limite.
A configuração completions controla quantos pods de um determinado ambiente de execução devem ser concluídos antes que o CronJob possa iniciar outro trabalho do Kubernetes para esse ambiente de execução. Observe a diferença entre um trabalho do Kubernetes (J maiúsculo) e um trabalho de monitor Sintético. Para maior eficiência, completions deve ser definido como 6 a 10x o valor de parallelism . Isso pode ajudar a minimizar a ineficiência de "próximo ao fim das conclusões", em que menos do que o pod de número parallelism pode acabar sendo executado enquanto o trabalho do Kubernetes aguarda a conclusão de todos os completions .
Quando completions for maior que 1, o pod com status "Concluído" permanecerá visível na saída de kubectl get pods -n YOUR_NAMESPACE até que todas as conclusões definidas no trabalho do Kubernetes tenham sido atendidas, por exemplo, 6/6 conclusões. Os recursos são liberados do nó quando um pod tem o status Concluído ou Com falha.
Um trabalho do Kubernetes com duração de 5 minutos (kubectl get jobs -n YOUR_NAMESPACE) é um destino conservador para levar em conta a variabilidade em quanto tempo leva para o pod ser concluído e quantos trabalhos Sintético precisam ser executados por minuto (taxa de trabalhos). As equações a seguir podem ser usadas como ponto de partida para completions e parallelism para cada tempo de execução. Talvez seja necessário fazer ajustes com base nas observações do crescimento da fila de localização privada.
completions = 300 / avg job duration (s)
parallelism = synthetics jobs per 5 minutes / completions
Tempos de execução diferentes provavelmente terão durações e taxas de trabalho Sintético diferentes. A consulta a seguir pode ser usada para obter duração média e taxa para uma localização privada.
-- non-ping average job duration by runtime type
FROM SyntheticCheck SELECT average(duration)AS'avg job duration'
WHEREtype!='SIMPLE'AND location ='YOUR_PRIVATE_LOCATION' FACET type SINCE 1hour ago
-- non-ping jobs per minute by runtime type
FROM SyntheticCheck SELECT rate(uniqueCount(id),5 minutes)AS'jobs per 5 minutes'
WHEREtype!='SIMPLE'AND location ='YOUR_PRIVATE_LOCATION' FACET type SINCE 1hour ago
Dica
As consultas acima são baseadas em resultados atuais. Se sua localização privada não tiver nenhum resultado ou o gerente de trabalho não estiver apresentando o melhor desempenho, os resultados da consulta poderão não ser precisos. Nesse caso, tente alguns valores diferentes para completions e parallelism até ver uma duração de kubectl get jobs -n YOUR_NAMESPACE de pelo menos 5 minutos (conclusões suficientes) e a fila não estiver crescendo (paralelismo suficiente).
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
O runtime executará 1 job Sintético por vez. Após a conclusão do trabalho, um novo trabalho será iniciado imediatamente. Depois que a configuração do número de jobs completions for concluída, a configuração CronJob iniciará um novo job do Kubernetes e redefinirá o contador de conclusões. Throughput will be limited, but slightly better. Um único trabalho Sintético de longa duração bloqueará o processamento de quaisquer outros trabalhos Sintético deste tipo.
parallelism=3
completions=24
O runtime executará 3 jobs Sintético de uma só vez. Após a conclusão de qualquer um desses trabalhos, um novo trabalho será iniciado imediatamente. Depois que a configuração do número de jobs completions for concluída, a configuração CronJob iniciará um novo job do Kubernetes e redefinirá o contador de conclusões. Throughput is much better with this or similar configurations. Um único trabalho Sintético de longa duração terá impacto limitado no processamento de outros trabalhos Sintético deste tipo.
Se os trabalhos Sintético demorarem mais para serem concluídos, serão necessárias menos conclusões para preencher 5 minutos com trabalhos, mas serão necessários mais pods paralelos. Da mesma forma, se mais trabalhos Sintético precisarem ser processados por minuto, mais pods paralelos serão necessários. A configuração parallelism afeta diretamente quantos jobs Sintético por minuto podem ser executados. Um valor muito pequeno e a fila poderá crescer. Um valor muito grande e os nós podem ficar com recursos limitados.
Se suas configurações parallelism estiverem funcionando bem para manter a fila em zero, definir um valor mais alto para completions do que o calculado em 300 / avg job duration pode ajudar a melhorar a eficiência de duas maneiras:
Acomode a variabilidade nas durações dos trabalhos de forma que pelo menos 1 minuto seja preenchido com trabalhos Sintético, que é a duração mínima do CronJob.
Reduza o número de ciclos de conclusões para minimizar a ineficiência de "próximo ao fim das conclusões", onde o próximo conjunto de conclusões não pode começar até que o trabalho final seja concluído.
É importante observar que o valor completions não deve ser muito grande ou o CronJob receberá um aviso como este:
8m40s Warning TooManyMissedTimes cronjob/synthetics-node-browser-runtime too many missed start times: 101. Set or decrease .spec.startingDeadlineSeconds or check clock skew
Dica
Tenha em mente que a New Relic não é responsável por quaisquer modificações que você fizer nos arquivos do gerenciador de tarefas do Sintético.