Hallo zusammen, habe vom aktuellen Gluon Master gebaut, was ja nun LEDE ist.
Meine Config: GitHub - freifunklippe/site-ffl at v2017.1.x
Seit LEDE kommen im Graphite keine Statistikdaten mehr von den Knote mit der neuen LEDE-Firmware an. Alle Knoten, die auf Openwrt (v2016.2.5) basieren liefern ihre Daten klaglos ab.
Bei der LEDE-Config habe ich alfred entfernt, da ja eigentlich alles über respondd läuft.
Jemand eine Idee?
Hier ein Beispielknoten:
Läuft bei euch denn Server der die Daten über respondd auswertet?
Würde wetten ihr nutzt noch Alfred.
Ja, wir nutzen das Münsteraner Ansible-Setup. Da ist respondd drin.
Wird das vielleicht von der Firewall rausgefiltert?
Siehe:
Meinst du explizit die statistics Daten oder die respondd Daten im Allgemeinen?
Magst du verraten, ab wann wir da etwas sehen sollten?
Ich sehe dort bei den Graphen auch weiterhin Datenpunkte. Das einzige, was ich erkennen kann: Die Daten scheinen nicht mehr regelmäßig anzukommen. Daher wird keine Konstante Linie gezeichnet, sondern nur einzelne Punkte.
Wir hatte man das Problem, dass der Buffer des UDP Sockets voll gelaufen ist, da zu viele Knoten geantwortet haben. Da kam dann auch nicht immer alles im Programm an. Das erklärt aber nicht, warum das augenscheinlich nur bei LEDE Knoten auftritt.
…wir haben das graphite-collector script irgendwann mal von alfred auf respondd umgestellt (und dann später auf hopglass server) als Datenquelle. Welche Version nutzt ihr denn?
ich habe das Betreff mal angepasst, dass es offentlich nicht nur an LEDE hängt, sondern am Client mit dem man die Kartendaten abfragt. („keine“ beim Threadstarter vs „lückenhaft“ bei Dir.)
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
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:
n Zeiteinheiten nach der letzten Nachricht, die rein gekommen ist, bevor sich der Port schließt.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. 
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
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:
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.