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

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

In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.

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.

Para configurar os módulos:

  1. 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.
  1. Depois de criar o diretório de módulos personalizados e o package.json, aplique-os ao seu SJM para docker e Kubernetes.

  2. Para verificar se os módulos foram instalados corretamente ou se ocorreu algum erro, revise o log SJM da seção intitulada "... Initialization of Custom Modules ...". Esse log incluirá o log de instalação do npm, fornecendo informações sobre o processo de instalação e quaisquer erros potenciais encontrados.

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

Altere package.json para módulos personalizados

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:

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:

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

Exemplo:

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

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' WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago
# non-ping jobs per minute by runtime type
FROM SyntheticCheck SELECT rate(uniqueCount(id), 5 minutes) AS 'jobs per 5 minutes' WHERE type != 'SIMPLE' AND location = 'YOUR_PRIVATE_LOCATION' FACET type SINCE 1 hour ago

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

Por favor, lembre-se de que New Relic não se responsabiliza por quaisquer modificações que você fizer nos arquivos do gerenciador de tarefas Sintético.

Copyright © 2024 New Relic Inc.

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