Solução de problemas de localização privada

Se você encontrar problemas ao configurar locais privados para o monitoramento sintético do New Relic, tente estas dicas de resolução de problemas para identificar problemas comuns do Synthetics Job Manager.

Demanda de trabalho e consumo

Identifique seu throughput atual e avalie se o seu gerenciador de jobs é capaz de acompanhar a carga de trabalho.

Os trabalhos exigem taxas de transferência por minuto:
```
SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 days ago
```

Trabalhos por minuto ao longo do tempo:

SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 weeks ago TIMESERIES

Identifique o crescimento da fila:

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

Taxa de consumo:

SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 weeks ago TIMESERIES

Limpe o monitor com falha que está consumindo recursos:

SELECT 100*latest(minionJobsFailed)/latest(minionJobsReceived) AS 'job failure rate (%)' 
FROM SyntheticsPrivateMinion FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

Resolução de problemas de uso de memória

Alocação de memória recomendada por gerenciador de tarefas Sintético:

Docker: 3,256 GiB por núcleo de CPU para docker Sintético job manager
Gerenciador de tarefas Kubernetes Sintético (os valores são configuráveis):
- 1,6 GiB para pod do gerenciador de tarefas
- 1,0 GiB para pod de tempo de execução de ping
- 2 GiB por pod de tempo de execução da API Node.js
- 3 GiB por pod de tempo de execução do browser Node.js.
Destino 60% de utilização máxima de memória

Consulta útil para identificar o uso atual:

Uso de memória por local:

SELECT latest(minionPhysicalMemoryUsedPercentage) FROM SyntheticsPrivateMinion
FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

Uso de memória por nome do host:

SELECT latest(minionPhysicalMemoryUsedPercentage) FROM SyntheticsPrivateMinion 
WHERE minionLocation = 'YOUR_PRIVATE_LOCATION' FACET minionHostname SINCE 2 weeks ago TIMESERIES MAX

Monitores do Browser apresentam falha devido ao dimensionamento de memória compartilhada no Podman

Os monitores de Browser em execução em uma localização privada baseada em Podman podem falhar intermitentemente com um erro como este:

NoSuchSessionError: invalid session id: session deleted as the browser has closed the connection, disconnected: Unable to receive message from renderer

Isso é tipicamente uma falha no processo de renderização do Chrome causada por memória compartilhada insuficiente (/dev/shm), não um problema de script ou de rede. O Chrome depende muito da memória compartilhada para renderização e tende a esgotá-la mais rápido que o Firefox, especialmente em páginas que redirecionam entre origens durante os fluxos de login — cada nova origem inicia processos de renderização adicionais que extraem do mesmo pool /dev/shm.

Como os pod do Podman alocam memória compartilhada

Quando o gerenciador de trabalhos de Sintéticos é executado no Podman com --pod, cada contêiner associado a esse pod compartilha um único namespace IPC. O próprio pod monta /dev/shm uma vez, no tamanho com o qual você criou o pod (64 MiB por padrão). Você define esse tamanho no momento de podman pod create, e um contêiner individual não pode alterá-lo ou substituí-lo posteriormente.

Isso significa que as seguintes tentativas comuns de corrigir problemas de memória compartilhada não funcionam depois que um contêiner é associado a um pod, porque a montagem /dev/shm do pod tem precedência sobre as configurações por contêiner:

Passando --shm-size em podman run em vez de podman pod create
Montagem de bind com -v /dev/shm:/dev/shm em podman run

Diagnóstico

Antes de realizar qualquer alteração, estas verificações devem ser executadas para confirmar a causa:

Verifique o valor --shm-size no comando de criação do pod:
bash
```
$podman pod inspect YOUR_POD_NAME --format '{{.CreateCommand}}'
```
Isto exibe o comando podman pod create exato que criou o pod. Procure por --shm-size nessa saída. Caso esteja ausente, o pod estará sendo executado no padrão de 64 MiB, independentemente do que se pretendia definir — isso pode ocorrer caso um pod anterior com o mesmo nome não tenha sido totalmente removido antes de ser recriado, ou caso um contêiner no pod não tenha sido reiniciado posteriormente.
Encontre o ID do contêiner de runtime do navegador:
bash
```
$podman ps --filter pod=YOUR_POD_NAME --filter ancestor=newrelic/synthetics-node-browser-runtime --format '{{.ID}}'
```
Este ID deve ser utilizado como YOUR_BROWSER_RUNTIME_CONTAINER_ID na próxima etapa.
Verifique a memória compartilhada realmente disponível dentro desse contêiner, idealmente capturada durante ou imediatamente antes de uma execução com falha:
bash
```
$podman exec YOUR_BROWSER_RUNTIME_CONTAINER_ID df -h /dev/shm
```
Compare a saída com o tamanho que você configurou:
- Se Size ainda mostrar 64M, o redimensionamento nunca entrou em vigor — recrie o pod conforme descrito na próxima seção.
- Se Size mostrar o valor configurado (por exemplo, 2.0G para um pod criado com --shm-size=2g), verifique as colunas Used e Avail. Se Avail estiver próximo de zero, o pool está esgotado — cada contêiner no pod extrai dessa mesma alocação compartilhada, portanto, se vários monitores forem executados simultaneamente na mesma localização privada, dimensione --shm-size para um valor maior ou reduza quantos são executados de uma vez. Se Avail ainda tiver espaço livre, o pool não é a causa dessa falha específica e você deve procurar em outro lugar (por exemplo, HEAVY_WORKER_MEMORY).

Consertar

O pod existente deve ser removido e recriado com um --shm-size maior e, em seguida, o gerenciador de trabalhos de Sintéticos deve ser reiniciado para que ele ingresse novamente no novo pod:

bash

$podman pod stop YOUR_POD_NAME
$podman pod rm YOUR_POD_NAME
$podman pod create --network slirp4netns --name YOUR_POD_NAME --add-host=podman.service:HOST_IP_ADDRESS --shm-size=2g

Deve-se começar com 2g, o valor utilizado na documentação de instalação. Caso a verificação na etapa 3 ainda mostre que o pool está esgotado, ele deve ser aumentado ainda mais (por exemplo, para 4g) antes de se reduzir a simultaneidade, e df -h /dev/shm deve ser verificado novamente após cada alteração.

Em seguida, inicie o gerenciador de trabalhos de Sintéticos novamente usando o comando podman run do procedimento de inicialização do Podman— a remoção do pod também remove os contêineres que estavam em execução nele.

Resolução de problemas de uso da CPU

Identifique possíveis períodos de alta demanda de CPU:

Uso geral da CPU:

SELECT latest(minionProcessorsUsagePercentage) FROM SyntheticsPrivateMinion 
FACET minionLocation SINCE 2 weeks ago TIMESERIES MAX

Uso de CPU para um local especificado:

SELECT latest(minionProcessorsUsagePercentage) FROM SyntheticsPrivateMinion 
WHERE minionLocation = 'YOUR_PRIVATE_LOCATION' FACET minionHostname SINCE 2 weeks ago TIMESERIES MAX

Resolução de problemas de rede

Network access is red:

O Synthetics Job Manager faz uma verificação na New Relic para verificar o acesso à rede pública. Se o acesso à rede pública não estiver disponível, o ícone Network Access na página Overview do Synthetics Job Manager ficará vermelho, mas o Synthetics Job Manager permanecerá totalmente funcional. Se este for o comportamento esperado, você pode ignorar este erro com segurança.

Você também pode ver entradas de log como esta:

2016-01-21 21:47:09,401 [dw-22 - GET /private-location/status] c.n.s.m.util.PrivateMinionUtils WARN Unable to detect Public Network Access trying to fetch https://newrelic.com/synthetics: java.net.ConnectException: Connection refused

New Relic access is red:

O Synthetics Job Manager deve ter acesso a https://synthetics-horde.nr-data.net para recuperar a lista de jobs a serem executados e publicar resultados que você pode visualizar na sua interface de usuário do New Relic. Se as regras do seu firewall não permitirem acesso direto, você pode configurar o acesso via proxy. Se necessário, adicione o endpoint de DNS synthetics-horde.nr-data.net à sua lista de permissões.

Conflitos de porta executando docker contêineres no host

Se você estiver executando vários contêineres de gerenciador de jobs no mesmo host, terá conflitos de porta e contenção de recursos. Para evitar isso, certifique-se de executar cada gerenciador de jobs em um host separado.