Lückenhafte Statistiken (node-stats) (Gluon 2017.x/LEDE)

Hallo

Den Knoten habe ich gestern Abend ca. um 21:00 Uhr, auf die neue FW (basierend auf LEDE) umgestellt.
Da sieht man es noch ganz genau…
https://karte.freifunk-lippe.de/map/#!v:m;n:30b5c2e2fec4

Ich habe, wie descilla auch, da einen lückenhafte Übertragung.
Wenn Du jedoch gar keine Statistikdaten mehr hast, dann liegt es an Eurer Hoppglas-Installation.
Denn am Collector kann es nciht liegen, sondern nur am FrontEnd, wenn Du etwas anderes angezeigt bekommst als wir.

Die Hopglass-Installation funktioniert mit den Openwrt-Knoten tadellos. Die Verluste treten nur bei den paar LEDE-Knoten auf.

Tippe es liegtr eher an der LEDE-Firmware. Nach dem Update sind darauf sofort die Daten lückenhaft oder nicht vorhanden.

@adorfer @collimas Eigentlich geht es hier gar nicht um die Karte. Es geht um respondd bzw respondd->script->graphite (carbon-cache).

Aufgrund von

  • es tritt nur bei manchen (aber nicht beliebigen) Knoten auf (die nachvollziehbar anders sind) und
  • Es kommen grundsätzlich Daten an, nur halt nicht so oft

schließe ich Graphite mal als Ursache aus.

Es wird also ein Problem zwischen respondd client auf dem Knoten und respondd server aka node-stats script sein.

Aufgrund des konkreten Fehlerbildes würde ich möglicherweise ein anderes zeitliches Verhalten unter LEDE als Ursache vermuten.

Da du aber sagst, dass es auf der Karte (also auch beim hopglass server) keine Probleme gibt und die Daten dort regelmäßig eintreffen, würde ich eine schlechte Programmierung unseres Scriptes als Ursache vermuten.

Das prinzipielle Problem:

  • Das Script wird per cron einmal die Minute aufgerufen.
  • Wir senden eine Multicast respondd Anfrage (udp).
    • Daher wissen wir nicht, wer antwortet.
    • Wir müssen also einen Timeout abwarten und danach den Socket wieder schließen.
    • Die Implementation wartet n Zeiteinheiten nach der letzten Nachricht, die rein gekommen ist, bevor sich der Port schließt.
    • Ich hatte das Timeout anfangs auf 750 ms gesetzt, hatte hier aber auch das Problem, dass häufig Daten nicht ankamen, habe es daher auf 1250 ms gesetzt.
  • Dieses Problem hätten wir nicht, wenn wir das ganze als Dienst laufen lassen würden und Empfang (respondd) und Senden (graphite) in separate Threads aufteilen würde (oder „nonblocking“ code, wie z. B. bei hopglass-server).

Prüfe also bitte mal welcher Wert dort eingestellt ist.

Anmerkung: Das Script stammt aus den Anfangstagen von Freifunk Münster, ich habe es recht stümperhaft von alfred auf respondd als Datenquelle umgestellt. Da ich sowie vor hatte/habe das Teil neu zu schreiben.

Da die Daten, die wir brauchen eh schon vom Hopglass-Server erfasst werden, nutze ich in der Neuimplementation direkt diese Daten, damit sparen wir dann redundante respondd Abfragen ein.

Du findest die neue Version hier:

Diese läuft bei FFMS auch schon produktiv, ist aber noch nicht im Ansible eingebaut, da ich hier und da ggf. noch die resultierende Datenstruktur geändert werden könnte. Außerdem wird das Script momentan auch noch per Cron minütlich aufgerufen. Geplant ist es das Programm als Dienst laufen zu lassen.

Bei Bedarf ließe sich sicherlich auch ein „respondd-server“ als alternative Datenquelle zum hopglass server realisieren…

Aber wenn ein User keine Statistikdaten bekommt und einer (oder mehrere) andere zumindest lückenhafte, dann würde ich erstmal dort suchen. Das kann unmöglich an LEDE (oder dem Node) liegen.

Das stimmt. Ich habe dem TE einfach mal unterstellt sich unklar ausgedrückt zu haben. :stuck_out_tongue:

Nun ist v2017.1 released worden und dieses Problem ist noch immer vorhanden.

Ich könnte etwas Hilfestellung gebrauchen. Am Verhalten hat sich nichts geändert. Das Hopglass-Backend schließe ich aus, da es mit den Openwrt-Knoten überhaupt keine Probleme gibt.

Im Moment ist mir nicht klar, an welcher Stelle ich ansetzen könnte, um die Ursache zu ermitteln.

In Düsseldorf haben wir beobachten können das respondd bei schon ausgelasteten Verbindungen schnell Pakete auf dem Weg verliert. Einen Unterschied zwischen Lede und OpenWRT haben wir bisher nicht beobachten können.

Wir sind daher zurück auf Alfred gewechselt weil dieser mit Transaktionen zwischen den Slaves & Mastern arbeitet und die Daten so zwar auch mal verloren gehen, aber mit wesentlich geringerer Wahrscheinlichkeit.

Für Hopglass-Server habe ich ein Alfred Backend geschrieben:

Der Branch-Name beinhaltet „Hack“ weil dieses Backend alfred-json als Binary benötigt, eine zukünftige Version wird die Daten selbst vom Socket abholen.

Hallo, kurze Zwischenfrage: welches alfred-json verwendet ihr?
GitHub - ffnord/alfred-json: Simple alfred client with JSON output oder GitHub - kratz00/alfred-json: Simple alfred client with JSON output ?

MFG

Wir verwenden GitHub - ffnord/alfred-json: Simple alfred client with JSON output

Ok, dass es mit respondd Probleme geben kann, sehe ich ein. Ich weiß gerade nur nicht, warum das Problem bei mir NUR mit LEDE-basierten Knoten auftritt.

Vielleicht könnte da ja jemand Licht ins Dunkel bringen. Eine entsprechende Test-Firmware gibt es hier:

Download
Unser Hopglass

Ich denke ohne Zugriff auf die Supernodes bzw Map-Server ist so etwas schwer zu debuggen.
Evtl. einfach mal respondd Daten von den Supernodes aus abfragen und schauen ob das Problem dort auch auftritt oder erst auf dem Map-Server.

Ich kann dir gerne Zugriff geben, wenn das weiterhelfen könnte. Vielleicht könnte mir jemand etwas auf die Sprünge helfen, wie ich beim Debuggen vorgehen muss. Solche eine Installation per Ansible ist bequem, aber wenn man nicht alles manuell selber installiert oder nachvollzogen hat, ist es nicht leicht, einen Überblick zu bekommen.

Ich habe den Wert auf 1250 ms gesetzt, leider ohne Veränderung. Mir erschließt sich nicht, weshalb es ein serverseitiges Problem sein soll, wenn der Großteil der Knoten problemlos seine Daten übermittelt und nur die wenigen LEDE-Testknoten dies nicht schaffen.

Benutzt ihr den HopGlass Server? Verschwinden die Knoten nur in den (wenn ich das richtig verstanden habe um den HopGlass Server herum generierten) Statistiken oder auch auf der Karte generell?

Beim HopGlass Server kann man die Zeit, nach der ein Knoten als offline angesehen wird, wenn keine Nachricht empfangen wurde, in der Konfiguration einstellen unter dem Namen „offlineTime“. Der Standardwert liegt bei 900 Sekunden also 15 Minuten. Nach Standardkonfiguration werden einmal pro Minute jewails statistics und neighbours abgefragt. Es müssten also mit der Standardkonfiguration mal eben mehr als 30 aufeinander folgende Pakete auf dem Weg verloren gehen.

Ja, ist der HopGlass-Server. Nicht der ganze Knoten verschwindet, sondern es fehlen Statistikdaten: https://karte.freifunk-lippe.de/map/#!v:m;n:14cc20918ba6

Okay, der node-stats nimmt sich die raw.json vom HopGlass Server, da sind die Daten auch noch drin und die lastseen ist weniger als 5 minuten her. Die Daten verschwinden also höchstwahrscheinlich irgendwo im node-stats.

  • Läuft node-stats auf der gleichen Kiste? Ist vielleicht NTP abgeschaltet und die Zeit ungenau?
  • In der config von node-stats die offline time auf 900 sekunden erhöhen?
  • Sonst ist was anderes im node-stats kaputt oder graphite verliert daten

Generell: Ja, es ist schwierig, das Problem zu lösen ohne Zugriff auf den Mapserver aber man kann das Problem grob lokalisieren. In der raw.json sind die Daten drin und aktuell. Es liegt also auch nicht an respondd an sich, sondern das Problem liegt erst deutlich danach auf dem Mapserver nämlich.
Ich habe mir demensprechend mal erlaubt den Fred noch einmal umzubenennen. Sollte irgendjemand einen Einwand haben wird das selbstverständlich sofort wieder rückgängig gemacht.

Da das Problem nur mit einer bestimmten Gluon-Version auftritt köntte es am Parsen der Daten in node-stats liegen.

Die Zeit ist richtig und wird per NTP synchronisiert.

Wo kann ich die Offline-Time einstellen? Habe das nicht gefunden. Die node-stats laufen unter /opt/node-stats.

Dass node-stats generell kaputt ist oder graphite Daten verliert, halte ich für unwahrscheinlich, da ja alle Daten der Openwrt-Knoten korrekt verarbeitet werden.

Wurde etwas am Parsen der Daten in LEDE geändert? Weiß das jemand?

Hab nicht gesagt dass node-stats generell kaputt ist sondern „was anderes im node-stats“

Das Parsen der Daten findet in node-stats statt. Mit der neuen Gluon-Version werden möglicherweise manche Daten in einem anderen Format geliefert.

wahrscheinlich /opt/node-stats/config.json


jetzt bin ich an dem punkt angekommen an dem ich nichts mehr feststellen kann ohne mir logs anzugucken oder evtl. debug prints einzubauen falls die logs nicht genug auskunft geben

wie wird node-stats gestartet? per systemd-service? per init script? manuell?
sind logs von node-stats vorhanden? möchtest du die mal posten?

ansonsten werde ich gleich mal versuchen bei mir in einem container node-stats und graphite aufzusetzen, das problem zu reproduzieren und dann lokal zu debuggen. das aber erst nach einer verdienten mittagspause :slight_smile:

1 „Gefällt mir“

Ich gebe dir gerne Zugriff auf Hopglass und Gateway, wenn das hilft. Schick mir dazu deinen SSH-Key an michael@collimas.net.

Hier gibt es passende Firmware zum Testen:

https://www.hidrive.strato.com/share/3z6.zwm755#$/Firmware/Release%20-LEDE%20