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


#21

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.


#22

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


#23

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.


#24

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?


#25

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:


#26

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


#27

Keine Ahnung wo ich die Logs finde, unter /var/logs sehe ich nichts. Ich kann dir nicht mal sagen, wie es genau gestartet wird, wie kann ich das herausbekommen?

Wie gesagt, du kannst dir gerne den Server anschauen, wenn du magst. Eine passende Firmware zum Testen ist vorhanden. Ich denke nur, dass das Problem eher auf Seiten des Knotens zu suchen ist, da es ja nur mit LEDE-Knoten und nicht mit Openwrt auftritt,.


#28

Kleine Anmerkung am rand:
Es gibt inzwischen Gluon 2017.1.1 wo ein Workaround für einen Bug in Batman eingeflossen ist, evtl ist das Problem dadurch gelöst?


#29

Schon getestet, leider keine Änderung. Auch das Paket gluon-ebtables-segment-mld, das ich auf Anraten von neoraider eingebaut habe, hatte keine Auswirkungen.


#30

Das Problem besteht mit der 2017.1.4 nach wie vor. Hat eventuell noch jemand eine Idee?


#31

Glaube beinahe das es nicht an LEDE liegt. Zumindest haben die Münsteraner keine Probleme mit der neuen LEDE und ihrem Setup. Seltsamerweise benutzen wir auch das Münsteraner Ansible-Setup.
https://karte.freifunk-muensterland.de/map/#!v:m;n:98ded0ab68fe
Vergleich zu unseren Knoten…
https://karte.freifunk-lippe.de/map/#!v:m;n:f09fc2e4117e

Woran kann es liegen?


#32

Das ist mir aber was ganz was neues? Wir arbeiten immer noch mit Gluon-2.7.3 basierend auf OpenWRT.

Wir haben nur testweise mal LEDE gebaut und den Router auch nicht getestet. Warum der Freifunker an der von dir verlinkten Stelle schon LEDE einsetzt, weiß ich nicht. Ist auch seine persönliche Sache ;).

Zu den Statistiken: Ich weiß, dass da irgendwann mal die Puffer für die eingehenden Daten hochgedreht wurden. Evtl. hat es damit was zu tun. War aber nicht meine Baustelle, sondern @descilla s.


#33

Okay, das konnte ich nicht wissen…hatte nur gesehen das die neu LEDE bei euch schon eingesetzt wird und damit keine Anzeigefehler existieren…was ja schon mal Mut macht :wink:


#34

Hat @descilla vielleicht noch ein Tipp für uns auf Lager…wir kommen da leider nicht weiter.