Solucionar problemas de ubicación privada

Si encuentra problemas al configurar ubicaciones privadas para el monitoreo sintético de New Relic, pruebe estos consejos de resolución de problemas para identificar problemas comunes de Synthetics Job Manager.

Demanda y consumo de empleo

Identifique su rendimiento actual y evalúe si su gestor de trabajos puede seguir el ritmo de la carga de trabajo.

Los trabajos exigen rendimiento por minuto:
```
SELECT rate(uniqueCount(jobId), 1 minute) FROM SyntheticRequest 
WHERE type != 'SIMPLE' FACET location SINCE 2 days ago
```

Trabajos por minuto a lo largo del tiempo:

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

Identificar el crecimiento de la cola:

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

Tasa de consumo:

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

Limpie el monitor defectuoso que consume recursos:

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

Resolución de problemas de uso de memoria

Asignación de memoria recomendada por administrador de trabajos de Sintético:

Docker: 3.256 GiB por núcleo de CPU para el administrador de trabajos docker Sintético
Gestor de trabajos de Kubernetes Sintético (los valores son configurables):
- 1,6 GiB para podde gestión de trabajos
- 1,0 GiB para podde tiempo de ejecución de ping
- 2 GiB por pod de tiempo de ejecución de API de Node.js
- 3 GiB por pod de tiempo de ejecución browser Node.js
Objetivo 60% de utilización máxima de memoria

Consulta útil para identificar el uso actual:

Uso de memoria por ubicación:

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

Uso de memoria por nombre de host:

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

Los monitores de Browser fallan debido al tamaño de la memoria compartida en Podman

Los monitores de Browser que se ejecutan en una ubicación privada basada en Podman pueden fallar intermitentemente con un error como este:

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

Por lo general, se trata de un bloqueo del proceso de renderizado de Chrome causado por memoria compartida insuficiente (/dev/shm), no por un problema de red o de script. Chrome depende en gran medida de la memoria compartida para el renderizado y tiende a agotarla más rápido que Firefox, especialmente en páginas que redirigen a través de orígenes durante los flujos de inicio de sesión —cada nuevo origen inicia procesos de renderizado adicionales que se extraen del mismo grupo de /dev/shm.

Cómo los pod de Podman asignan la memoria compartida

Cuando el administrador de trabajos de Sintéticos se ejecuta en Podman con --pod, cada contenedor unido a ese pod comparte un único namespace de IPC. El propio pod monta /dev/shm una vez, con el tamaño con el que creó el pod (64 MiB por defecto). Establece ese tamaño en el momento de podman pod create, y un contenedor individual no puede cambiarlo ni anularlo después.

Esto significa que los siguientes intentos comunes de solucionar problemas de memoria compartida no funcionan una vez que un contenedor se ha unido a un pod, porque el montaje /dev/shm del pod tiene prioridad sobre la configuración por contenedor:

Pasar --shm-size en podman run en lugar de podman pod create
Montaje de enlace con -v /dev/shm:/dev/shm en podman run

Diagnóstico

Antes de realizar cualquier cambio, ejecute estas comprobaciones para confirmar la causa:

Verifique el valor de --shm-size en el comando de creación del pod:
bash
```
$podman pod inspect YOUR_POD_NAME --format '{{.CreateCommand}}'
```
Esto imprime el comando podman pod create exacto que creó el pod. Busque --shm-size en esa salida. Si falta, el pod se está ejecutando en el valor predeterminado de 64 MiB independientemente de lo que pretendía configurar —esto puede suceder si no eliminó por completo un pod anterior con el mismo nombre antes de volver a crearlo, o si no reinició un contenedor en el pod después.
Busque el ID del contenedor de tiempo de ejecución del navegador:
bash
```
$podman ps --filter pod=YOUR_POD_NAME --filter ancestor=newrelic/synthetics-node-browser-runtime --format '{{.ID}}'
```
Utilice este ID como YOUR_BROWSER_RUNTIME_CONTAINER_ID en el siguiente paso.
Verifique la memoria compartida realmente disponible dentro de ese contenedor, idealmente capturada durante o inmediatamente antes de una ejecución fallida:
bash
```
$podman exec YOUR_BROWSER_RUNTIME_CONTAINER_ID df -h /dev/shm
```
Compare el resultado con el tamaño configurado:
- Si Size aún muestra 64M, el cambio de tamaño nunca tuvo efecto —vuelva a crear el pod como se describe en la siguiente sección.
- Si Size muestra el valor configurado (por ejemplo, 2.0G para un pod creado con --shm-size=2g), revise las columnas Used y Avail. Si Avail está cerca de cero, el grupo está agotado —cada contenedor en el pod consume de esta misma asignación compartida, por lo que si se ejecutan varios monitores simultáneamente en la misma ubicación privada, aumente el tamaño de --shm-size o reduzca la cantidad que se ejecuta a la vez. Si Avail todavía tiene margen, el grupo no es la causa de este fallo en particular y debe buscar en otra parte (por ejemplo, HEAVY_WORKER_MEMORY).

Arreglar

Elimine el pod existente y vuelva a crearlo con un --shm-size más grande, luego reinicie el administrador de trabajos de Sintéticos para que se vuelva a unir al nuevo 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

Comience con 2g, el valor que utilizan los documentos de instalación. Si la comprobación del paso 3 aún muestra que el grupo está agotado, auméntelo aún más (por ejemplo, a 4g) antes de reducir la concurrencia, y vuelva a comprobar df -h /dev/shm después de cada cambio.

Luego, vuelva a iniciar el administrador de trabajos de Sintéticos usando el comando podman run del procedimiento de inicio de Podman—eliminar el pod también elimina los contenedores que se estaban ejecutando en él.

Resolución de problemas de uso de CPU

Identifique períodos potenciales de alta demanda de CPU:

Uso general de la CPU:

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

Uso de CPU para una ubicación específica:

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

Resolución de problemas de red

Network access is red:

El Synthetics Job Manager realiza una comprobación en New Relic para verificar el acceso a la red pública. Si el acceso a la red pública no está disponible, el ícono Network Access en la página Overview de Synthetics Job Manager se pondrá en rojo, pero Synthetics Job Manager seguirá siendo totalmente funcional. Si este es el comportamiento esperado, puede ignorar este error con seguridad.

También puede ver entradas 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:

El Synthetics Job Manager debe tener acceso a https://synthetics-horde.nr-data.net para recuperar la lista de trabajos a ejecutar y publicar los resultados que puede ver en su interfaz de usuario de New Relic. Si sus reglas de firewall no permiten el acceso directo, puede configurar el acceso por proxy. Si es necesario, agregue el endpoint de DNS synthetics-horde.nr-data.net a su lista de permitidos.

Conflictos de puertos al ejecutar docker contenedor en el host

Si ejecuta múltiples contenedores de gestor de trabajos en el mismo host, tendrá conflictos de puertos y contención de recursos. Para evitar esto, asegúrese de ejecutar cada administrador de trabajos en un host separado.