Zum Inhalt

Selbstdiagnose

Protokolle prüfen

Der erste Schritt jeder Fehlerbehebung besteht darin, die Container-Protokolle zu prüfen. Hier die relevanten Befehle:

QoS Agent:

docker compose -f lti_qos-agent.yml logs

Reflector:

docker compose -f lti_reflector.yml logs

Analyzer (im Verzeichnis lti_analyzer ausführen):

docker logs lti_analyzer_kafka_1
docker logs lti_analyzer_influxdb_1
docker logs lti_analyzer_influx-writer_1

Im Dashboard werden keine Daten angezeigt

Wenn das Dashboard unter http://YOUR_ANALYZER_HOST_IP:12021 erreichbar ist, aber keine Daten anzeigt, gehen Sie die folgende Checkliste durch.

1. Laufen die Container des Analyzer?

Prüfen Sie im Verzeichnis lti_analyzer, ob die Container Kafka, InfluxDB, influx-writer und Grafana aktiv sind. Prüfen Sie die Protokolle auf mögliche Fehler.

2. Kann der Agent den Analyzer erreichen?

Der Agent verbindet sich über den zusätzlichen Host-Eintrag msgbus.latence.ca in lti_qos-agent.yml mit dem Analyzer. Stellen Sie sicher, dass die festgelegte IP der IP des Analyzer-Hosts entspricht und dass Port 12092 (Kafka) geöffnet und vom Agent-Host aus erreichbar ist.

Um zu bestätigen, dass der Verkehr Kafka erreicht, führen Sie diesen Befehl auf dem Analyzer-Host aus (ersetzen Sie docker0 gegebenenfalls durch Ihre Bridge-Schnittstelle):

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

Wenn Pakete erscheinen, sendet der Agent Daten. Erscheint nach einigen Sekunden nichts, kann der Agent den Analyzer nicht erreichen. Sie können diesen Befehl auch auf dem Agent-Host ausführen, um zu prüfen, ob er Daten sendet:

# Ersetzen Sie ANALYZER_IP durch die tatsächliche IP Ihres Analyzer-Hosts
sudo tcpdump -i docker0 "dst ANALYZER_IP and dst port 12092" -n -c 20

Hinweis zur Netzwerkschnittstelle: Welche Schnittstelle Sie mit tcpdump verwenden, hängt von der Konfiguration Ihrer Docker-Container ab. Im Bridge-Modus (Standard) verwenden Sie docker0. Im Host-Netzwerkmodus verwenden Sie Ihre Hauptnetzwerkschnittstelle, die Sie mit ip route | grep default ermitteln können.

3. Ist die IP des Reflector korrekt?

Prüfen Sie, ob LTI_reflector in lti_qos-agent.yml auf die korrekte IP oder den korrekten Hostnamen des Reflector-Hosts zeigt.

4. Sind die Ports des Reflector geöffnet?

Je nach verwendeten Protokollen müssen die folgenden Ports auf dem Reflector-Host geöffnet sein:

Protokoll Port(s)
HTTP TCP 12080
HTTPS TCP 12443
TCP TCP 12023
UDP UDP 12024
TWAMP TCP 12862, UDP 12800–12819
Verkehrskapazität TCP/UDP 12501
LIFBE TCP/UDP 12550
Paketverlust TCP/UDP 12555

5. Ist die Lizenz gültig und deckt sie die Anzahl der laufenden Agents ab?

Prüfen Sie, ob LTI_license_key in lti_qos-agent.yml und lti_reflector.yml korrekt ist. Wenn Sie mehr Agents betreiben, als Ihre Lizenz erlaubt, können einige Agents möglicherweise keine Daten senden.

6. Haben alle Agents eindeutige IDs?

Jeder Agent muss einen eigenen ganzzahligen Wert für LTI_agent_id haben. Zwei Agents mit derselben ID führen zu Datenkonflikten.

Einige Protokolle fehlen im Dashboard

Sind diese Protokolle in der Konfiguration des Agents deaktiviert?

Ein Protokoll wird deaktiviert, indem sein Intervall in lti_qos-agent.yml auf -1 gesetzt wird. Beispielsweise deaktiviert LTI_iperf3_session_interval=-1 iPerf3. Prüfen Sie, ob die erwarteten Protokolle nicht auf -1 gesetzt sind.

Sind die entsprechenden Ports des Reflector geöffnet?

Jedes Protokoll erfordert das Öffnen bestimmter Ports auf dem Reflector-Host (siehe Tabelle oben). Wenn ein Port blockiert ist, schlägt die Messung für dieses Protokoll stillschweigend fehl.

Sie können für jedes Protokoll prüfen, ob der Verkehr gesendet und empfangen wird. Führen Sie diese Befehle auf dem Agent-Host aus (ersetzen Sie REFLECTOR_IP und verwenden Sie die richtige Schnittstelle):

# Ausgehenden Verkehr zum Reflector pro Protokoll prüfen
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

# Prüfen, ob Antworten vom Reflector zurückkommen
sudo tcpdump -i docker0 "src REFLECTOR_IP" -n -c 20

Sie können auch auf dem Reflector-Host prüfen, ob er den Verkehr empfängt:

# Ersetzen Sie INTERFACE durch die richtige Schnittstelle auf dem Reflector-Host
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

Wenn der Verkehr beim Reflector ankommt, aber keine Antwort zum Agent zurückkehrt, liegt das Problem wahrscheinlich beim Reflector (Container nicht gestartet, Port nicht veröffentlicht). Wenn der Verkehr den Reflector nie erreicht, liegt das Problem auf Netzwerkebene (Firewall, Routing, falsche IP).

Mehrere Netzwerkschnittstellen verursachen Routing-Probleme

Wenn die VM, auf der Reflector oder Analyzer laufen, mehrere Netzwerkschnittstellen hat, kann die Routing-Tabelle asymmetrisches Routing verursachen: Der Verkehr kommt über eine Schnittstelle an, die Antwort wird aber über eine andere gesendet. Der Agent erhält die Antwort nie, sodass die Messung fehlschlägt oder in eine Zeitüberschreitung läuft.

Um zu prüfen, ob dies der Fall ist, führen Sie tcpdump auf jeder Schnittstelle des Reflector- bzw. Analyzer-Hosts aus und sehen Sie nach, welche tatsächlich den eingehenden Verkehr empfängt:

# Verfügbare Schnittstellen auflisten
ip link show

# Jede Schnittstelle auf eingehenden Messverkehr überwachen
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
# Für jede Schnittstelle wiederholen

Wenn der Verkehr über eth1 ankommt, die Standardroute die Antworten aber über eth0 sendet, erreichen die Antworten den Agent nie. Die Lösung besteht darin, eine Policy-Routing-Regel hinzuzufügen, die Antworten über dieselbe Schnittstelle hinausschickt, über die die Anfrage eingegangen ist. Unter Linux geschieht dies in der Regel mit ip rule und ip route.

Das Ergebnis von iPerf3 ist 0 oder zeigt einen Fehler

iPerf3 überträgt in einem einzigen Test große Datenmengen und ist daher empfindlich gegenüber MTU-Einschränkungen. Wenn der Pfad zwischen Agent und Reflector eine kleinere MTU als erwartet hat, werden große Pakete verworfen oder fragmentiert, und der Test liefert 0 oder schlägt vollständig fehl, während andere Protokolle (die kleinere Pakete verwenden) normal weiterarbeiten.

Um die effektive MTU auf dem Pfad zu prüfen, führen Sie vom Agent-Host aus einen Ping mit dem Flag "nicht fragmentieren" und schrittweise größeren Paketen aus:

# Größen schrittweise erhöhen, bis Pakete fehlschlagen (-M do = nicht fragmentieren, -s = Größe der Nutzlast)
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

Die größte erfolgreiche Größe (plus 28 Byte für die IP+ICMP-Header) ist die effektive MTU auf diesem Pfad. Liegt sie unter 1500, gibt es irgendwo im Netz eine MTU-Einschränkung.

Sie können dieses Problem umgehen, indem Sie die iPerf3-Pufferlänge in lti_qos-agent.yml an die effektive MTU anpassen:

- LTI_iperf3_buffer_length=1200

Die Metadaten im Dashboard sind nicht aktuell

Die Metadaten werden standardmäßig wöchentlich oder bei jedem Neustart des QoS-Agent aktualisiert. Um sicherzustellen, dass sie aktualisiert werden, können Sie den Container des Agents neu starten mit:

# Container stoppen
docker compose -f lti_qos-agent.yml down

# Container starten
docker compose -f lti_qos-agent.yml up -d

Es werden keine GPS-/Funkdaten angezeigt

Der laufende Agent muss einer dieser 2 Typen sein: - Agent der mobilen App - Cradlepoint-Agent mit dem Container lti-cradlepoint-data

Agent der mobilen App

Stellen Sie sicher, dass die App so konfiguriert ist, dass sie Daten an Ihren eigenen Analyzer sendet:

  1. Öffnen Sie die Einstellungen der App
  2. Tragen Sie Ihren Lizenzschlüssel in das Feld LTI-Lizenzschlüssel ein
  3. Setzen Sie die InfluxDB-URL auf die Adresse Ihres Analyzer an Port 12086: http://YOUR_ANALYZER_IP:12086/
  4. Tippen Sie auf Speichern

Ohne die korrekte InfluxDB-URL sendet die App keine Daten an Ihren Analyzer, und im Dashboard erscheint nichts.

Prüfen Sie unter Android außerdem, ob der Vordergrunddienst in den Einstellungen der App aktiviert ist. Ist er deaktiviert, kann die App das Senden von Messungen einstellen, sobald sie minimiert oder der Bildschirm gesperrt wird.

Wenn die App unter Android abstürzt: 1. Gehen Sie zu Einstellungen > Apps > MobileLatency > Beenden erzwingen 2. Gehen Sie zu Speicher und Cache > Cache leeren 3. Starten Sie die App neu

Cradlepoint-Agent

GPS- und Funkdaten erfordern die Konfiguration als kontextbezogener Agent, die sowohl den Container lti-cradlepoint-data als auch den Container qos-agent in derselben Compose-Datei enthält. Die Standardkonfiguration mit nur einem Container erfasst keine GPS- oder Funkdaten.

Prüfen Sie die folgenden Punkte in Ihrer Cradlepoint-Compose-Konfiguration:

  • Sie verwenden das Image qos-agent:cradlepoint, nicht qos-agent:latest
  • Der Container lti-cradlepoint-data ist in der Compose-Datei vorhanden
  • LTI_cradlepointapi_ip ist auf lti-cradlepoint-data gesetzt
  • Beide Container befinden sich im selben Netz (z. B. cradle-network)
  • LTI_agent_id ist in beiden Containern identisch

Prüfen Sie außerdem, ob GPS auf dem Cradlepoint-Gerät selbst aktiviert ist:

  • Gehen Sie in NetCloud Manager zu DEVICES > Configuration > Edit > SYSTEM > GPS
  • Aktivieren Sie die Option Enable GPS

Die Container starten nicht

Ist der Lizenzschlüssel korrekt?

Agent und Reflector benötigen beide einen gültigen LTI_license_key. Ein ungültiger oder abgelaufener Schlüssel verhindert den Start der Container.

Sind alle erforderlichen Parameter gesetzt?

Prüfen Sie, ob in Ihren Konfigurationsdateien keine Platzhalter REPLACE_BY_* übrig sind. Die erforderlichen Parameter für den Agent sind: LTI_agent_id, LTI_customer_id, LTI_license_key, LTI_reflector und die IP von msgbus.latence.ca. Die erforderlichen Parameter für den Reflector sind: LTI_reflector_id und LTI_license_key.

LTI_agent_id, LTI_customer_id und LTI_reflector_id müssen Ganzzahlen sein.

Können Sie die Images aus der Registry abrufen?

Wenn docker compose pull fehlschlägt, prüfen Sie, ob Ihr Host registry.latence.ca erreichen kann.

Verwenden Sie Docker v2?

Der korrekte Befehl lautet docker compose (mit Leerzeichen, ohne Bindestrich). Die Verwendung von docker-compose (v1) kann Probleme verursachen.

KI-Funktionen

Der Chatbot zeigt einen Fehler "Bad Gateway" an

Der Chatbot hängt von drei Elementen ab, die gleichzeitig funktionieren müssen:

  1. Internetverbindung — der Chatbot verwendet OpenAI und schlägt ohne ausgehenden Internetzugang vom Analyzer-Host fehl.
  2. Der MCP-Container — prüfen Sie, ob er läuft und fehlerfrei ist.
  3. Der Container LatenceTech API — prüfen Sie, ob er läuft und fehlerfrei ist.

Prüfen Sie den Status der betreffenden Container im Verzeichnis lti_analyzer:

docker ps
docker logs lti_analyzer_latencetech_mcp_1
docker logs lti_analyzer_latencetech_api_1

Wenn ein Container gestoppt ist, starten Sie ihn neu:

docker compose up -d

Wenn die Container laufen, der Chatbot aber weiterhin fehlschlägt, prüfen Sie, ob der Analyzer-Host über ausgehenden Internetzugang verfügt:

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

Die Berichte werden nicht erstellt

Die Berichtsfunktion verwendet ebenfalls OpenAI. Wenn der Analyzer-Host keinen ausgehenden Internetzugang hat, schlägt die Berichterstellung fehl. Prüfen Sie die Verbindung auf dieselbe Weise:

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

Upgrade des Analyzer

Bevor Sie eine neue Version des Analyzer installieren, müssen Sie die heruntergeladenen und erzeugten Dateien der vorherigen Installation löschen, um Inkompatibilitäten zu vermeiden. Erwägen Sie, jede Version in einem eigenen Verzeichnis zu installieren.