Erweiterte Knotenstatistik erfassen

Am 17.02.2016 haben wir beschlossen, dass wir weitere Statistiken der Knoten erfassen, respektive speichern, wollen. Derzeit wird nur die Anzahl der verbundenen Clients erfasst.

Es wurde ebenfalls beschlossen, dass diese Statistiken nicht unmittelbar für alle Knoten erfasst werden sollen, sondern der Knotenbetreiber selbst entscheiden kann, ob diese Daten gespeichert werden sollen oder nicht. (Anmerkung: Die entsprechenden Daten werden zwar sowieso vom Knoten übermittelt, aber derzeit verworfen und nicht gespeichert.)

Gründe für diese Entscheidung sind vielfältig, lassen sich jedoch unter dem Unterbegriff Diskriminierungsfrei zusammenfassen. Es sollen z. B. keine Knoten(-betreiber) bzgl. eines hohen Datenverbrauchs in Misskredit geraten. Aus diesem Grund haben wir uns für eine Whitelist/OptIn anstatt einer Blacklist/OptOut entschieden, da ein OptOut Knotenbetreiber ggf. ebenfalls als “schwarzes Schaf” markieren könnte.
Geplant ist, dass im Konfigurationsmodus ein Haken gesetzt werden kann, der die erweiterte Speicherung aktiviert.

Folgende Daten würde ich gerne erfassen:
Beschreibung findet sich hier.

statistics / datatype 159

  • traffic (jeweils packets, bytes, sowie ggf. dropped)
  • tx
  • rx
  • mgmt_tx
  • mgmt_rx
  • forward
  • clients
  • wifi
  • total
  • uptime
  • idletime
  • loadavg
  • memory
  • cached
  • buffers
  • total
  • free
  • processes
  • running
  • total
  • mesh_vpn
  • peers - Wert muss entsprechend fürs Graphite aufbereitet werden
  • gateway - Dito, überlegen, ob Wert praktikabel erfasst werden kann.

neighbours / datatype 160

  • wifi
  • neighbours[] (jeweils)
    • noise
    • signal
    • inactive
  • count - Wert gibt es nicht, wird berechnet
  • batadv
    • neighbours[] (jeweils)
      • tq
      • lastseen
    • count - Wert gibt es nicht, wird berechnet

(Anmerkung: Die aufgeführte Liste gibt in etwa die Struktur des alfred-json wieder und nicht die Struktur, wie es später in graphite abgelegt werden soll.)

Unter nodeinfo / datatype 158 gibt es noch Informationen, wie z. B. die verwendete FW-Version, etc. Ich bin mir aber nicht sicher, ob es viel Sinn macht diese ebenfalls hier zu erfassen (FW-Version wird je Domäne als count erfasst).

Es gab von @void die Anregung den Wert loadavg unabhängig vom Aktivieren des erweiterten Modus für alle Knoten zu speichern. Da man hierdurch vorzeitig erkennen kann, wenn ein Netz zu groß wird und die Knoten schlapp machen. Feedback?

Das sind zwar viele Werte, aber ich finde jeden für sich sehr interessant. Falls der aktuelle Graphite-Server das nicht verkraften sollte, können wir ja mal drüber nachdenken eine zweite Instanz davon aufzubauen dediziert für die Knoten-Statistik (das ist zumindest einer von zwei drei Wegen, die genannt werden, wenn Graphite in die Knie geht, der zweite wäre mehr Performance aka SSD, der dritte wäre auf eine performantere Software zu wechseln).

OptIn im Konfigurationsmodus des Knoten:
Beim letzten Treffen hieß es, das wäre super easy, da gäbe es passende Module für. Super esay, ok. Passende Module, habe ich nicht gefunden. Einen weiteren Eintrag ins die Konfigurations-Weboberfläche zu zaubern geht einfach, neues Modul erstellen, z. B. auf Basis des gluon-config-mode-geolocation Moduls (als Vorlage). Problem ist, dass diese Werte auch über respondd bzw. alfred rausgehauen werden müssen. Es gibt wohl das Modul gluon-respondd, was genau dafür verantwortlich ist oder zumindest dafür die erforderlichen Daten für nodeinfo / datatype 158 zusammenzusammeln. Das Ganze ist recht hardcoded, d. h. es werden nicht einfach alle Einträge gesendet, die sich unterhalb von gluon-node-info in der config befinden. Dieses Modul müsste entsprechend angepasst werden, auch das ist super easy. ABER: Es wird halt ein weiteres Modul angefasst. Was denkt unser Firmware-Buameister-Team aka @MPW @Alucardo darüber?

Habe ich etwas vergessen? Ich hoffe nicht! Euer Feedback bitte. Danke. :blush:

Die Anpassungen müssten wir zusammen machen, da ich beim Coden noch nicht so ganz dabei bin. So wie ich aber das Paket verstehe müssen die Objekte erweitert werden, damit man die Daten einfacher abrufen kann. Nur müssen wir darauf achten, dass wir nicht die magischen 4MB überschreiten.^^ Sonst haben wir 90% unserer Knoten aus der Statistik raus.

Wollen wir am Mittwoch noch einmal die genaue Erfassungsweite, sprich, welche datatypes wir genau erfassen wollen, beschließen? Das wäre dann eine Ergänzung zum vorangegangenen Beschluss.

Aus technischer Sicht oder aus Privatsphäre/Datenschutz/whatever-Sicht?

Ich habe 3 Beiträge in ein neues Thema verschoben: Abstimmungs-Overhead und Troll-Abstimmungen

Kurzes Update:

  • In [ffms-packages][1] findet ihr die nötigen Module für die Firmware
  • Ich habe die [site-ffms][2] geforked, der Domäne-01 branch ist bereits entsprechend modifiziert.
  • Einen Branch im [node-stats][3] repo gibt es auch bereits.

Status:

  • Konfigurationsmodus läuft.
  • respondd läuft
  • firmware ist gebaut, announced korrekt, läuft
  • Bin gerade dabei die node-stats anzupassen. Läuft prinzipiell auch schon, habe die stats für traffic schon drin, rest muss noch, läuft.
  • Was nicht läuft: Ich musste das gluon modul gluon-node-info abändern und habe es daher in ein eigenes Repo geschoben. Ich will den package name nicht ändern, da es abhängigkeiten gibt, diese müsste ich sonst auch mit ins ffms-packages repo werfen. Leider verwendet der build-prozess weiterhin das originale gluon-node-info paket aus dem gluon repo. Auch wenn ich PKG_VERSION oder PKG_RELEASE hoch ziehe. Da muss ich noch eine Lösung finden. Damit ich zum Test eine FW bauen konnte, habe ich einfach das paket gluon-node-info aus dem gluon/package/ Verzeichnis gelöscht.

…dauert also nicht mehr lange. :blush:
[1]: https://github.com/descilla/ffms-packages
[2]: https://github.com/descilla/site-ffms/tree/Domäne-01
[3]: https://github.com/FreiFunkMuenster/node-stats/tree/advanced_stats

Oben aufgeführte Statistiken werden nun von node-stats erfasst, Pullrequest erstellt.

Die Daten werden nun ins graphite geschrieben. Ein Beispiel in Grafana findet man hier.

Leider gehen die Daten, wie bei den client stats nach kurzer Zeit wieder verloren. Möglicherweise liegt es daran, dass das regex nicht auf die komplette zeile matcht. Habe mal einen pull request für services-ffms erstellt.

@void Magst du das vielleicht mal ausprobieren. Und in jedem Fall einen db sync (oder was das problem beim letzten mal behoben hat) ausführen?

Der branch von node-stats wurde jetzt nach master gemerged und via Ansible ausgerollt.

Bzgl. der Problematik beim Firmwarebau habe ich

  • Einen Thread im “großen” Forum eröffnet
  • Die Frage ebenfalls auf der gluon-Mailingliste gestellt

PS: Wer zeitnah eine Firmware zum testen haben möchte, kann sich einfach hier melden oder mir eine PN schicken, am besten mit Router-Modell, dann kann ich direkt den passenden Link posten, wenn es soweit ist.

Was muss ich tun, um diese erweiterten Daten ohne Whitelist zu erfassen?

2 Like

Dankeschön! Ich habe den Wert geändert aber leider scheinen keine weiteren Daten erfasst zu werden.

https://graphite.freifunk-lippe.de/

Es gibt nach wie vor nur den Wert “count”.

Was mache ich falsch?

Von welchem Host reden wir? Die node-stats gibt es sowohl auf der Services-VM als auch auf dem Mapserver.
Allerdings habe ich den Wert bei beiden auf “True” gesetzt und es kommen nach wie vor nur “count”-Daten.

Ok, habe es selbst gefunden. Es ist der Mapserver. Dass man die Karte mit ‘grunt’ deswegen neu erzeugen muss, war mir nicht klar. Jetzt aber schon. Alles funktioniert jetzt.