Aller au contenu

Dépannage autonome

Comment vérifier les journaux

La première étape de tout dépannage consiste à consulter les journaux des conteneurs. Voici les commandes pertinentes :

QoS Agent :

docker compose -f lti_qos-agent.yml logs

Reflector :

docker compose -f lti_reflector.yml logs

Analyzer (à exécuter depuis le répertoire lti_analyzer) :

docker logs lti_analyzer_kafka_1
docker logs lti_analyzer_influxdb_1
docker logs lti_analyzer_influx-writer_1

Aucune donnée affichée dans le tableau de bord

Si le tableau de bord à l'adresse http://YOUR_ANALYZER_HOST_IP:12021 est accessible mais n'affiche aucune donnée, suivez la liste de vérification ci-dessous.

1. Les conteneurs de l'analyzer sont-ils en cours d'exécution ?

Depuis le répertoire lti_analyzer, vérifiez que les conteneurs Kafka, InfluxDB, influx-writer et Grafana sont actifs. Vérifiez les journaux pour détecter d'éventuelles erreurs.

2. L'agent peut-il atteindre l'analyzer ?

L'agent se connecte à l'analyzer via l'entrée d'hôte supplémentaire msgbus.latence.ca dans lti_qos-agent.yml. Assurez-vous que l'IP définie correspond bien à l'IP de l'hôte analyzer, et que le port 12092 (Kafka) est ouvert et accessible depuis l'hôte agent.

Pour confirmer que le trafic atteint bien Kafka, exécutez cette commande sur l'hôte analyzer (remplacez docker0 par votre interface bridge si différente) :

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

Si des paquets apparaissent, l'agent envoie bien des données. Si rien n'apparaît après quelques secondes, l'agent ne peut pas atteindre l'analyzer. Vous pouvez également exécuter cette commande sur l'hôte agent pour vérifier qu'il envoie des données :

# Remplacez ANALYZER_IP par l'IP réelle de votre hôte analyzer
sudo tcpdump -i docker0 "dst ANALYZER_IP and dst port 12092" -n -c 20

Note sur l'interface réseau : L'interface à utiliser avec tcpdump dépend de la configuration de vos conteneurs Docker. En mode bridge (par défaut), utilisez docker0. En mode réseau hôte, utilisez votre interface réseau principale, que vous pouvez trouver avec ip route | grep default.

3. L'IP du reflector est-elle correcte ?

Vérifiez que LTI_reflector dans lti_qos-agent.yml pointe vers l'IP ou le nom d'hôte correct de l'hôte reflector.

4. Les ports du reflector sont-ils ouverts ?

Les ports suivants doivent être ouverts sur l'hôte reflector en fonction des protocoles que vous utilisez :

Protocole Port(s)
HTTP TCP 12080
HTTPS TCP 12443
TCP TCP 12023
UDP UDP 12024
TWAMP TCP 12862, UDP 12800–12819
Traffic capacity TCP/UDP 12501
LIFBE TCP/UDP 12550
Packet Loss TCP/UDP 12555

5. La licence est-elle valide et couvre-t-elle le nombre d'agents en cours d'exécution ?

Vérifiez que LTI_license_key est correct dans lti_qos-agent.yml et lti_reflector.yml. Si vous exécutez plus d'agents que votre licence ne l'autorise, certains agents pourraient ne pas pouvoir envoyer des données.

6. Tous les agents ont-ils des ID uniques ?

Chaque agent doit avoir une valeur entière distincte pour LTI_agent_id. Deux agents partageant le même ID entraîneront des conflits de données.

Certains protocoles sont absents du tableau de bord

Ces protocoles sont-ils désactivés dans la configuration de l'agent ?

Un protocole est désactivé en définissant son intervalle à -1 dans lti_qos-agent.yml. Par exemple, LTI_iperf3_session_interval=-1 désactive iPerf3. Vérifiez que les protocoles attendus ne sont pas définis à -1.

Les ports correspondants du reflector sont-ils ouverts ?

Chaque protocole nécessite l'ouverture de ports spécifiques sur l'hôte reflector (voir le tableau ci-dessus). Si un port est bloqué, la mesure pour ce protocole échouera silencieusement.

Vous pouvez vérifier si le trafic est bien envoyé et reçu pour chaque protocole. Exécutez ces commandes sur l'hôte agent (remplacez REFLECTOR_IP et utilisez la bonne interface) :

# Vérifier le trafic sortant vers le reflector par protocole
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

# Vérifier que les réponses reviennent du reflector
sudo tcpdump -i docker0 "src REFLECTOR_IP" -n -c 20

Vous pouvez également vérifier depuis l'hôte reflector qu'il reçoit bien le trafic :

# Remplacez INTERFACE par l'interface correcte sur l'hôte 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 le trafic arrive au reflector mais qu'aucune réponse ne revient vers l'agent, le problème est probablement du côté du reflector (conteneur non démarré, port non publié). Si le trafic n'arrive jamais au reflector, le problème est au niveau réseau (pare-feu, routage, IP incorrecte).

Plusieurs interfaces réseau causant des problèmes de routage

Si la VM exécutant le reflector ou l'analyzer possède plusieurs interfaces réseau, la table de routage peut provoquer un routage asymétrique : le trafic arrive sur une interface mais la réponse est envoyée via une autre. L'agent ne reçoit jamais la réponse, ce qui entraîne l'échec ou le délai d'attente de la mesure.

Pour vérifier si cela se produit, exécutez tcpdump sur chaque interface de l'hôte reflector ou analyzer et voyez laquelle reçoit réellement le trafic entrant :

# Lister les interfaces disponibles
ip link show

# Surveiller chaque interface pour le trafic de mesure entrant
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
# Répéter pour chaque interface

Si le trafic arrive sur eth1 mais que la route par défaut envoie les réponses via eth0, les réponses n'atteindront jamais l'agent. La solution consiste à ajouter une règle de routage par politique qui force les réponses à sortir par la même interface que celle par laquelle la requête est arrivée. Cela se fait généralement avec ip rule et ip route sous Linux.

Le résultat iPerf3 est 0 ou affiche une erreur

iPerf3 transfère de grandes quantités de données en un seul test, ce qui le rend sensible aux limitations de MTU. Si le chemin entre l'agent et le reflector a un MTU inférieur à celui attendu, les grands paquets seront abandonnés ou fragmentés et le test renverra 0 ou échouera complètement, tandis que d'autres protocoles (qui utilisent des paquets plus petits) continueront à fonctionner normalement.

Pour vérifier le MTU effectif sur le chemin, exécutez un ping avec l'indicateur "ne pas fragmenter" et des tailles de paquets progressivement plus grandes depuis l'hôte agent :

# Essayez des tailles croissantes jusqu'à ce que les paquets commencent à échouer (-M do = ne pas fragmenter, -s = taille du 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

La plus grande taille qui réussit (plus 28 octets pour les en-têtes IP+ICMP) est le MTU effectif sur ce chemin. S'il est inférieur à 1500, il y a une restriction MTU quelque part dans le réseau.

Vous pouvez contourner ce problème en réduisant la longueur du buffer iPerf3 dans lti_qos-agent.yml pour qu'il corresponde au MTU effectif :

- LTI_iperf3_buffer_length=1200

Les métadonnées ne sont pas à jour dans le tableau de bord

Les métadonnées sont par défaut actualisées chaque semaine, ou à chaque redémarrage du QoS-Agent. Pour vous assurer qu'elles sont mises à jour, vous pouvez redémarrer le conteneur de l'agent avec :

# Arrêter le conteneur
docker compose -f lti_qos-agent.yml down

# Démarrer le conteneur
docker compose -f lti_qos-agent.yml up -d

Aucune donnée GPS/Radio affichée

L'agent en cours d'exécution doit être l'un de ces 2 types : - Agent application mobile - Agent Cradlepoint utilisant le conteneur lti-cradlepoint-data

Agent application mobile

Assurez-vous que l'application est configurée pour envoyer des données à votre propre analyzer :

  1. Ouvrez les Paramètres de l'application
  2. Renseignez le champ Clé de licence LTI avec votre clé de licence
  3. Définissez l'URL InfluxDB sur l'adresse de votre analyzer sur le port 12086 : http://YOUR_ANALYZER_IP:12086/
  4. Appuyez sur Enregistrer

Sans l'URL InfluxDB correcte, l'application n'enverra pas de données à votre analyzer et rien n'apparaîtra dans le tableau de bord.

Sur Android, vérifiez également que le Service de premier plan est activé dans les paramètres de l'application. Lorsqu'il est désactivé, l'application peut arrêter d'envoyer des mesures dès qu'elle est minimisée ou que l'écran est verrouillé.

Si l'application plante sur Android : 1. Allez dans Paramètres > Applications > MobileLatency > Forcer l'arrêt 2. Allez dans Stockage et cache > Vider le cache 3. Redémarrez l'application

Agent Cradlepoint

Les données GPS et radio nécessitent la configuration agent contextuel, qui inclut à la fois le conteneur lti-cradlepoint-data et le conteneur qos-agent dans le même fichier compose. La configuration standard à conteneur unique ne collecte pas les données GPS ou radio.

Vérifiez les éléments suivants dans votre configuration compose Cradlepoint :

  • Vous utilisez l'image qos-agent:cradlepoint, et non qos-agent:latest
  • Le conteneur lti-cradlepoint-data est présent dans le fichier compose
  • LTI_cradlepointapi_ip est défini sur lti-cradlepoint-data
  • Les deux conteneurs sont sur le même réseau (ex. cradle-network)
  • LTI_agent_id est identique dans les deux conteneurs

Vérifiez également que le GPS est activé sur l'appareil Cradlepoint lui-même :

  • Dans NetCloud Manager, accédez à DEVICES > Configuration > Edit > SYSTEM > GPS
  • Cochez l'option Enable GPS

Les conteneurs ne démarrent pas

La clé de licence est-elle correcte ?

L'agent et le reflector nécessitent tous deux un LTI_license_key valide. Une clé invalide ou expirée empêchera les conteneurs de démarrer.

Tous les paramètres requis sont-ils définis ?

Vérifiez qu'aucune valeur de remplacement REPLACE_BY_* ne subsiste dans vos fichiers de configuration. Les paramètres requis pour l'agent sont : LTI_agent_id, LTI_customer_id, LTI_license_key, LTI_reflector, et l'IP de msgbus.latence.ca. Les paramètres requis pour le reflector sont : LTI_reflector_id et LTI_license_key.

LTI_agent_id, LTI_customer_id et LTI_reflector_id doivent être des entiers.

Pouvez-vous récupérer les images depuis le registre ?

Si docker compose pull échoue, vérifiez que votre hôte peut atteindre registry.latence.ca.

Utilisez-vous Docker v2 ?

La commande correcte est docker compose (avec un espace, sans tiret). L'utilisation de docker-compose (v1) peut causer des problèmes.

Fonctionnalités IA

Le chatbot affiche une erreur "Bad Gateway"

Le chatbot dépend de trois éléments fonctionnant simultanément :

  1. Connectivité Internet — le chatbot utilise OpenAI et échouera sans accès Internet sortant depuis l'hôte analyzer.
  2. Le conteneur MCP — vérifiez qu'il est en cours d'exécution et en bonne santé.
  3. Le conteneur LatenceTech API — vérifiez qu'il est en cours d'exécution et en bonne santé.

Vérifiez l'état des conteneurs concernés depuis le répertoire lti_analyzer :

docker ps
docker logs lti_analyzer_latencetech_mcp_1
docker logs lti_analyzer_latencetech_api_1

Si un conteneur est arrêté, redémarrez-le :

docker compose up -d

Si les conteneurs sont en cours d'exécution mais que le chatbot échoue toujours, confirmez que l'hôte analyzer dispose d'un accès Internet sortant :

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

Les rapports ne se génèrent pas

La fonctionnalité de rapports utilise également OpenAI. Si l'hôte analyzer n'a pas accès à Internet sortant, la génération de rapports échouera. Confirmez la connectivité de la même manière :

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

Mise à niveau de l'analyzer

Avant d'installer une nouvelle version de l'analyzer, vous devez supprimer les fichiers téléchargés et générés de l'installation précédente pour éviter les incompatibilités. Envisagez d'installer chaque version dans un répertoire séparé.