gibt es eine Möglichkeit die aktuellen Clients, Load, Traffic eines bestimmten Nodes direkt abzufragen? Ich möchte nicht den Weg über die Map JSON Daten gehen sondern direkt vom Node abfragen. Das ganze soll von einem externen Server geschehen.
Die Status Page der Nodes liefern zwar Load aber keine Client sowie Traffic zahlen. „Nodeinfo“ per socat bringt auch keine wirkliche Lösung.
Im Forum habe ich leider keine wirkliche Lösung gefunden.
Du kannst direkt die Statusseite des Nodes aufrufen und dann parsen. Ist dann eben html und kein json. Und dein server braucht v6 sonst wird dass auch nix.
und die IPv6-Anbindung muss funktionieren „von außen“.
Ansonsten kann es passieren, dass man sich über „Freifunkausfälle“ beschwert, die in dieser Form gar nicht vorhanden sind.
Was bisher wunderbar funktioniert ist, Statistik-Daten von der Node selbst zu einem Collectd-Server zu senden.
Das ganze dann inklusive Anzahl der Clients (Skript für’s exec-Plugin), wobei man die auch schon fast über das iwinfo-Plugin (stations) auswerten könnte.
Die Darstellung der Statistiken kann dann beliebig erfolgen (CGP, Graphite, etc.).
Aktuell versuche ich das ganze mit Munin und dem OpenWRT-Paket muninlite.
Das, und die Abhängigkeit xinetd haben im Vergleich zu der Collectd-Lösung einen wesentlich geringeren Speicherplatzbedarf.
Diese beiden Varianten erfordern allerdings Eingriffe auf der Node und sind nicht updatesicher!
Die Alternative dazu wäre die passive Auswertung der Alfred-Daten, wie hier beschrieben:
In dem Thread gibt’s auch irgendwo 'nen Link zu einem Munin-Plugin, das sich um die Auswertung der Daten kümmert.
Mit muninlite und openwrt habe ich schon sehr gute Erfahrungen gemacht. Falls man das auch auf einem 841er problemlos unter bekommt können wir das eventuell auch allgemein ausrollen.
Muninlite-Plugin (in der „/usr/sbin/munin-node“ muss ggf. noch „plugindir_“ zu den Plugins hinzugefügt werden und „/usr/sbin/munin-node-plugin.d/ff_clients“ muss ausführbar sein):
root@ffac-monty-va1416-01:/# cat /usr/sbin/munin-node-plugin.d/ff_clients
#!/bin/sh
config_ff_clients() {
cat <<'EOM'
graph_title Number of Freifunk clients
graph_args --base 1000 -l 0
graph_vlabel number of Freifunk clients
graph_category freifunk
graph_info This graph shows the number of Freifunk clients connected.
clients.label clients
clients.draw LINE2
clients.info The current number of Freifunk clients.
EOM
}
fetch_ff_clients() {
echo "clients.value" $(/usr/sbin/batctl tl|grep -Eo "\[.*\]+"|grep W|wc -l)
}
case $1 in
config)
config_ff_clients
;;
*)
fetch_ff_clients
;;
esac
Die alfred_merged.json im Ruhrgebiet ist im Übrigen genau wie auch die nodes.json minütlich aktuell.
@johnyb arbeitet mit Hochdruck am neuen Map Server, der sämtliche Daten bekommt, inkl. Daten der Tunnel, Traffic, etc. und daraus dann ein Frontend erstellt. Sukzessive soll das Frontend dann auch tiefgreifende Statistiken zu jeder Node im zeitlichen Verlauf enthalten.
Mit anderen Worten, Julian baut gerade an einer Lösung, die selbst über ein Netmon weit hinaus geht und keine spezielle Firmware benötigt. Das wird hoffentlich in einer ersten Version, die erstmal nur die Karte und Liste darstellen kann zeitnah fertig sein. Danach wird dann Stück für Stück mehr Funktionalität eingebaut. Wenn die Daten gesammelt sind ist es imho nur noch eine Frage des Frontends diese dann irgendwann auch zu visualisieren.
Julian benutzt für unseren neuen ffmap Server auch Alfred Daten, Daten der fastd Sockets, etc. Wobei @CyrusFox aktuell die Möglichkeit eines direkten http push o.Ä. prüft, um ggfs. Alfred komplett abzuschaffen.
Wäre cool wenn @tata oder @baranator mal ne kurze Zusammenfassung geben könnten.
Hallo,
die Idee von netmon-ng war eine grundsätzliche Modularisierung zu schaffen:
Ein Modul, welches die Daten aller Router sammelt („aggregiert“) und diese in regelmäßigen Abständen an ein Modul, welches sich lediglich um die Speicherung, ggf. Archivierung und zur-Verfügung-Stellung dieser Daten kümmert (prinzipiell lediglich eine Datenbank mit einer Rest-Api davor), sendet. Ein drittes Modul soll dann für die Darstellung dieser Daten auf Internetseiten zuständig sein (zB mittels jqplot).
Das Modul, welches die Daten sammelt soll dabei ein Daemon sein, der seinerseits verschiedene Tools (wie zB Netmons Nodewatcher oder alfred-json, „crawler“) anstoßen können soll und deren Daten zusammenführen kann. Später soll das dann auch so funktionieren, dass bspw. die Datensätze aus dem Nodewatcher mit zusätzlichen Daten aus alfred-json ergänzt werden können, für’s Erste werden die crawler nacheinander ausgeführt und jeweils fehlende Router ergänzt. Die grundlegende Idee ist also vor allem ein Tool zu schreiben, welches Daten zusammenführt, die aus unterschiedlichen Quellen kommen, sodass bei einer Umstellung der Informationsgewinnung lediglich ein neuer crawler ergänzt werden muss und auch parallel verschiedene Systeme eingesetzt werden können.
In der Theorie haben wir uns da also bereits einige Gedanken gemacht, tatsächlich sind mangels Zeit allerdings nicht über die Planung hinausgekommen. Allerdings habe ich für den Daemon bereits ein paar Zeilen geschrieben und wollte mich demnächst damit mal wieder etwas mehr beschäftigen
Das ist tatsächlich sehr ähnlich dem, was der @johnyb für uns aktuell entwickelt.
Der Fokus stammt zwar aus der anderen Richtung, nämlich ursprünglich von der ffmap, wo er für den Upstream entwickelt, aber genau das von Dir skizzierte soll das derzeit bei uns noch „Map Server“ benannte Projekt auch machen.
Daten aus diversen Quellen und über unterschiedliche Wege zusammenführen und sammeln
Daten in eine Middleware normalisieren
Frontend benutzt die gesammelten und in der Middleware normalisierten Daten zur Visualisierung
Julian ist zwar schon relativ weit, aber vielleicht kann man an der Stelle gewinnbringend noch Ideen zusammenführen…