Saltar a contenido

Autodiagnóstico

Cómo consultar los registros

El primer paso de cualquier diagnóstico consiste en consultar los registros de los contenedores. Estos son los comandos pertinentes:

QoS Agent:

docker compose -f lti_qos-agent.yml logs

Reflector:

docker compose -f lti_reflector.yml logs

Analyzer (ejecutar desde el directorio lti_analyzer):

docker logs lti_analyzer_kafka_1
docker logs lti_analyzer_influxdb_1
docker logs lti_analyzer_influx-writer_1

No se muestra ningún dato en el panel de control

Si el panel de control en la dirección http://YOUR_ANALYZER_HOST_IP:12021 es accesible pero no muestra ningún dato, siga la lista de comprobación que figura a continuación.

1. ¿Están en ejecución los contenedores del analyzer?

Desde el directorio lti_analyzer, compruebe que los contenedores Kafka, InfluxDB, influx-writer y Grafana están activos. Consulte los registros para detectar posibles errores.

2. ¿Puede el agente llegar al analyzer?

El agente se conecta al analyzer mediante la entrada de host adicional msgbus.latence.ca en lti_qos-agent.yml. Asegúrese de que la IP definida corresponde a la IP del host del analyzer y de que el puerto 12092 (Kafka) está abierto y es accesible desde el host del agente.

Para confirmar que el tráfico llega a Kafka, ejecute este comando en el host del analyzer (sustituya docker0 por su interfaz bridge si es diferente):

sudo tcpdump -i docker0 "dst port 12092" -n -c 20

Si aparecen paquetes, el agente está enviando datos. Si no aparece nada al cabo de unos segundos, el agente no puede llegar al analyzer. También puede ejecutar este comando en el host del agente para verificar que está enviando datos:

# Sustituya ANALYZER_IP por la IP real de su host del analyzer
sudo tcpdump -i docker0 "dst ANALYZER_IP and dst port 12092" -n -c 20

Nota sobre la interfaz de red: La interfaz que debe utilizarse con tcpdump depende de la configuración de sus contenedores Docker. En modo bridge (predeterminado), utilice docker0. En modo de red host, utilice su interfaz de red principal, que puede encontrar con ip route | grep default.

3. ¿Es correcta la IP del reflector?

Verifique que LTI_reflector en lti_qos-agent.yml apunta a la IP o al nombre de host correcto del host del reflector.

4. ¿Están abiertos los puertos del reflector?

Los siguientes puertos deben estar abiertos en el host del reflector en función de los protocolos que utilice:

Protocolo Puerto(s)
HTTP TCP 12080
HTTPS TCP 12443
TCP TCP 12023
UDP UDP 12024
TWAMP TCP 12862, UDP 12800–12819
Capacidad de tráfico TCP/UDP 12501
LIFBE TCP/UDP 12550
Pérdida de paquetes TCP/UDP 12555

5. ¿Es válida la licencia y cubre el número de agentes en ejecución?

Verifique que LTI_license_key es correcto en lti_qos-agent.yml y en lti_reflector.yml. Si ejecuta más agentes de los que permite su licencia, es posible que algunos agentes no puedan enviar datos.

6. ¿Tienen todos los agentes ID únicos?

Cada agente debe tener un valor entero distinto para LTI_agent_id. Dos agentes que compartan el mismo ID provocarán conflictos de datos.

Faltan algunos protocolos en el panel de control

¿Están desactivados estos protocolos en la configuración del agente?

Un protocolo se desactiva estableciendo su intervalo en -1 en lti_qos-agent.yml. Por ejemplo, LTI_iperf3_session_interval=-1 desactiva iPerf3. Verifique que los protocolos esperados no estén definidos en -1.

¿Están abiertos los puertos correspondientes del reflector?

Cada protocolo requiere la apertura de puertos específicos en el host del reflector (véase la tabla anterior). Si un puerto está bloqueado, la medición de ese protocolo fallará sin avisar.

Puede comprobar si el tráfico se envía y se recibe correctamente para cada protocolo. Ejecute estos comandos en el host del agente (sustituya REFLECTOR_IP y utilice la interfaz correcta):

# Verificar el tráfico saliente hacia el reflector por protocolo
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst port 12080" -n -c 20   # HTTP
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst port 12443" -n -c 20   # HTTPS
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst port 12023" -n -c 20   # TCP
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst port 12024" -n -c 20   # UDP
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst port 12862" -n -c 20   # TWAMP control
sudo tcpdump -i docker0 "dst REFLECTOR_IP and dst portrange 12800-12819" -n -c 20  # TWAMP data

# Verificar que las respuestas vuelven del reflector
sudo tcpdump -i docker0 "src REFLECTOR_IP" -n -c 20

También puede verificar desde el host del reflector que está recibiendo el tráfico:

# Sustituya INTERFACE por la interfaz correcta en el host del reflector
sudo tcpdump -i INTERFACE "dst port 12080 or dst port 12443 or dst port 12023 or dst port 12024" -n -c 20
sudo tcpdump -i INTERFACE "dst portrange 12800-12819" -n -c 20  # TWAMP data ports

Si el tráfico llega al reflector pero no vuelve ninguna respuesta al agente, es probable que el problema esté en el lado del reflector (contenedor no iniciado, puerto no publicado). Si el tráfico nunca llega al reflector, el problema está a nivel de red (cortafuegos, enrutamiento, IP incorrecta).

Varias interfaces de red que causan problemas de enrutamiento

Si la VM que ejecuta el reflector o el analyzer tiene varias interfaces de red, la tabla de enrutamiento puede provocar un enrutamiento asimétrico: el tráfico llega por una interfaz pero la respuesta se envía por otra. El agente nunca recibe la respuesta, lo que provoca el fallo o el agotamiento del tiempo de espera de la medición.

Para comprobar si esto ocurre, ejecute tcpdump en cada interfaz del host del reflector o del analyzer y vea cuál recibe realmente el tráfico entrante:

# Listar las interfaces disponibles
ip link show

# Supervisar cada interfaz para el tráfico de medición entrante
sudo tcpdump -i eth0 "dst port 12080 or dst port 12023 or dst port 12862" -n -c 10
sudo tcpdump -i eth1 "dst port 12080 or dst port 12023 or dst port 12862" -n -c 10
# Repetir para cada interfaz

Si el tráfico llega por eth1 pero la ruta predeterminada envía las respuestas por eth0, las respuestas nunca llegarán al agente. La solución consiste en añadir una regla de enrutamiento basada en políticas que obligue a las respuestas a salir por la misma interfaz por la que llegó la solicitud. Esto se hace normalmente con ip rule e ip route en Linux.

El resultado de iPerf3 es 0 o muestra un error

iPerf3 transfiere grandes cantidades de datos en una sola prueba, lo que lo hace sensible a las limitaciones de MTU. Si la ruta entre el agente y el reflector tiene una MTU inferior a la esperada, los paquetes grandes se descartarán o se fragmentarán y la prueba devolverá 0 o fallará por completo, mientras que otros protocolos (que utilizan paquetes más pequeños) seguirán funcionando con normalidad.

Para comprobar la MTU efectiva en la ruta, ejecute un ping con el indicador "no fragmentar" y tamaños de paquete progresivamente mayores desde el host del agente:

# Pruebe tamaños crecientes hasta que los paquetes empiecen a fallar (-M do = no fragmentar, -s = tamaño del payload)
ping -M do -s 1400 REFLECTOR_IP -c 3
ping -M do -s 1450 REFLECTOR_IP -c 3
ping -M do -s 1472 REFLECTOR_IP -c 3

El mayor tamaño que funciona (más 28 bytes de las cabeceras IP+ICMP) es la MTU efectiva en esa ruta. Si es inferior a 1500, existe una restricción de MTU en algún punto de la red.

Puede sortear este problema reduciendo la longitud del búfer de iPerf3 en lti_qos-agent.yml para que se ajuste a la MTU efectiva:

- LTI_iperf3_buffer_length=1200

Los metadatos no están actualizados en el panel de control

Por defecto, los metadatos se actualizan cada semana o en cada reinicio del QoS-Agent. Para asegurarse de que se actualizan, puede reiniciar el contenedor del agente con:

# Detener el contenedor
docker compose -f lti_qos-agent.yml down

# Iniciar el contenedor
docker compose -f lti_qos-agent.yml up -d

No se muestran datos de GPS/Radio

El agente en ejecución debe ser de uno de estos 2 tipos: - Agente de la aplicación móvil - Agente Cradlepoint que utiliza el contenedor lti-cradlepoint-data

Agente de la aplicación móvil

Asegúrese de que la aplicación está configurada para enviar datos a su propio analyzer:

  1. Abra los Ajustes de la aplicación
  2. Rellene el campo Clave de licencia LTI con su clave de licencia
  3. Defina la URL de InfluxDB con la dirección de su analyzer en el puerto 12086: http://YOUR_ANALYZER_IP:12086/
  4. Pulse Guardar

Sin la URL de InfluxDB correcta, la aplicación no enviará datos a su analyzer y no aparecerá nada en el panel de control.

En Android, compruebe también que el Servicio en primer plano está activado en los ajustes de la aplicación. Cuando está desactivado, la aplicación puede dejar de enviar mediciones en cuanto se minimiza o se bloquea la pantalla.

Si la aplicación se bloquea en Android: 1. Vaya a Ajustes > Aplicaciones > MobileLatency > Forzar detención 2. Vaya a Almacenamiento y caché > Borrar caché 3. Reinicie la aplicación

Agente Cradlepoint

Los datos de GPS y de radio requieren la configuración de agente contextual, que incluye tanto el contenedor lti-cradlepoint-data como el contenedor qos-agent en el mismo archivo compose. La configuración estándar de un solo contenedor no recopila datos de GPS ni de radio.

Compruebe los siguientes elementos en su configuración compose de Cradlepoint:

  • Utiliza la imagen qos-agent:cradlepoint, y no qos-agent:latest
  • El contenedor lti-cradlepoint-data está presente en el archivo compose
  • LTI_cradlepointapi_ip está definido como lti-cradlepoint-data
  • Ambos contenedores están en la misma red (p. ej. cradle-network)
  • LTI_agent_id es idéntico en ambos contenedores

Compruebe también que el GPS está activado en el propio dispositivo Cradlepoint:

  • En NetCloud Manager, vaya a DEVICES > Configuration > Edit > SYSTEM > GPS
  • Marque la opción Enable GPS

Los contenedores no arrancan

¿Es correcta la clave de licencia?

Tanto el agente como el reflector requieren un LTI_license_key válido. Una clave no válida o caducada impedirá que los contenedores arranquen.

¿Están definidos todos los parámetros obligatorios?

Compruebe que no quede ningún valor de sustitución REPLACE_BY_* en sus archivos de configuración. Los parámetros obligatorios para el agente son: LTI_agent_id, LTI_customer_id, LTI_license_key, LTI_reflector y la IP de msgbus.latence.ca. Los parámetros obligatorios para el reflector son: LTI_reflector_id y LTI_license_key.

LTI_agent_id, LTI_customer_id y LTI_reflector_id deben ser números enteros.

¿Puede descargar las imágenes desde el registro?

Si docker compose pull falla, compruebe que su host puede llegar a registry.latence.ca.

¿Utiliza Docker v2?

El comando correcto es docker compose (con un espacio, sin guion). El uso de docker-compose (v1) puede causar problemas.

Funcionalidades de IA

El chatbot muestra un error "Bad Gateway"

El chatbot depende de tres elementos que deben funcionar simultáneamente:

  1. Conectividad a Internet: el chatbot utiliza OpenAI y fallará si el host del analyzer no tiene acceso saliente a Internet.
  2. El contenedor MCP: compruebe que está en ejecución y en buen estado.
  3. El contenedor LatenceTech API: compruebe que está en ejecución y en buen estado.

Compruebe el estado de los contenedores correspondientes desde el directorio lti_analyzer:

docker ps
docker logs lti_analyzer_latencetech_mcp_1
docker logs lti_analyzer_latencetech_api_1

Si un contenedor está detenido, reinícielo:

docker compose up -d

Si los contenedores están en ejecución pero el chatbot sigue fallando, confirme que el host del analyzer dispone de acceso saliente a Internet:

curl -s https://api.openai.com

Los informes no se generan

La funcionalidad de informes también utiliza OpenAI. Si el host del analyzer no tiene acceso saliente a Internet, la generación de informes fallará. Confirme la conectividad de la misma manera:

curl -s https://api.openai.com

Actualización del analyzer

Antes de instalar una nueva versión del analyzer, debe eliminar los archivos descargados y generados de la instalación anterior para evitar incompatibilidades. Considere instalar cada versión en un directorio distinto.