Monitoring von Nodes

Hi,

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.

Gruß
Lazybone

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.

Die Statusseite der Nodes geben leider nur die Informationen zur Load wieder. Keine Aussage von Clients oder Traffic

@Monty hat da was gebastelt.

Ich bastel immer noch ;-).

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.

Das Problem an den Munin Plugin is das er auch nur die JSON Dateien der Maps nutzt. Diese werden nur alle 5 Minuten aktualisiert.

Munin:
http://munin.stats.michael-ruettgers.de/freifunk-day.html

Collectd:
http://cgp.stats.michael-ruettgers.de/

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

Ihr könntet Euch auch Images mit Netmon bauen.
Da käme dann soetwas bei heraus.
Brauch natürlich noch ein Backend auf einem Server.
https://netmon.nordwest.freifunk.net/router.php?router_id=560

2 Likes

Setzt aber auch immer eine spezielle Firmware voraus. So wie ich das sehe kann das alles die Ruhrgebiet Firmware nicht.

Naja, Firmware kann man sich bauen, das ist kein Hexenwerk.

Gibt es irgendwo ein Tut, wie ich mir so eine hübsche Satusansicht auf den Router lade? Dann probiere ich das auf einem der 841 mal aus.

Das Ruhrgebiet wird auch kein Netmon einführen.

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.

3 Likes

Die momentane Lösung bei uns ist aber eher ein unschöner Workaround, das momentane Netmon hat keine Zukunft.

Ist Netmon-NG vom Ansatz her das was auch Julian baut? Zentrales Frontend ohne Daten selber auf dem Router zu sammeln?

Es soll Daten sowohl von Alfred als auch aus andere Quellen nutzen können, näheres dazu können wohl @tata oder @baranator sagen.

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.

1 Like

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…