Hallo ich habe gerade die knoten infos von Freifunk Karlsruhe entdeckt.
http://ffka.xylou.info/#/dashboard/file/pernode.json
gibt es irgendwo eine Anleitung wie ich solche Statistiken auch auf meinem knoten aufsetzen kann ?
Grüße Dero
habenwill!
Sieht wirklich klasse aus!
1 „Gefällt mir“
habenwill! 20zeichen…
auch haben will !!eins!elf sieht wie ein customized Kibana aus… richtig?
Wie sieht da das backend aus? Wie kommen die Daten darein, und was genau ist das „darein“? Braucht OpenTSDB agents auf den Knoten? Sorry, kenne OpenTSDB und InfluxDB noch gar nicht.
Irgendeine™ Monitoring Solution ballert einfach Daten in deine Datenerfassung (OpenTSDB oder InfluxDB) und mit Grafana kannst du die da wieder in schön rauspulen.
Was genau bei den Karlsruhern die Daten in die Datenerfassung einmassiert können uns nur die Karlsruher sagen.
Sehr fein, dann wird das auch mit Elasticsearch funktionieren. 
EDIT:
@FF-Karlsruhe: Welche Monitoringlösung nutzt ihr? Mit anderen Worten: Woher kommen die Daten, bzw. wie holt ihr die Daten aus den Knoten, die dann angezeigt werden?
Bei Elasticsearch, bzw Kibana gibt es dann nur noch das Problem, dass man das kostenpflichtige shield benötigt, um irgendeine Art von Zugriffsbeschränkungen zu haben, damit keiner die Dashboards und weiteres löscht oder über eine ungeschickte Abfrage deine Systemresourcen killt. Sonst hätte ich den Link zu der von mir betreuten Kibana Instanz, mit der ich die nodes.json visualisiere, vielleicht schon gepostet…
Alternativ könnte man auch mit d3.js die Daten aus Elasticsearch aufbereiten.
Was spricht dagegen, einen reverse proxy „davor“ zu setzen, damit die Zugriffe kontrolliert nur über 443/80 kommen und nicht auf elasticsearch/9001 direkt zugegriffen werden kann? …Hilft natürlich erstmal nicht wirklich gegen Kibana-View löschen, wenn Kinbana nicht „mandantenfähig“ ist und kein Rechte-Mgt hat… aber auch da könnte man filtern und zur Not über .htaccess auf Sub-Strings von Kibana den Zugriff einschränken. Hab ich jetzt bei Kibana noch nicht gemacht, müsste mir die Struktur von Kibana genauer ansehen dazu.
Habe ich per nginx schon realisiert, so ganz tollkühn bin ich ja doch nicht.
Das dann alles zu konfigurieren und zu testen ist mir ehrlich gesagt zu wartungsintensiv.
Deswegen wäre eine Idee die Daten aus ES per d3.js zu visualisieren. Das würde dann so ähmlich aussehen wie der Meshviewer für Troisdorf.
Wenn du mit ES rumspielen willst, kannst du dir gerne den folgenden Thread angucken, da habe ich mein Python Script für den Import sowie das Mapping für ES dokumentiert.
hmm… da find ichs spannender was mit grafana rumzubasteln werd ich bei nächster gelegenheit mal tun
Hi,
extra einen Account erstellt hier 
, war ja auch mal Zeit.
Ich betreibe das Grafana auf ffka.xylou.info - und kann Euch gerne ein paar Antworten geben zu Euren Fragen.
Das Ganze basiert auf Grafana 1.9.1 (noch, update auf 2.0.2 steht bald an) und Graphite als Backend für die Timeseries Daten und zwei kleinen selbstgeschriebenen Python Scripten.
Elastic Search ist auch mit Grafana 1.9.1 kein Muss, da es auch Dashboards aus dem Filesystem ausliefern kann. Elastic Search (ES) braucht man in 1.9.1, wenn man komfortabel Dashboards editeren und speichern will. Die Dasboards, die ihr auf ffka.xylou.info sehen könnt, kommen alle vom Filesystem, ES ist keines installiert. Ich habe das CSS von Grafana leicht angepasst, um Load- und Save-Symbole auszublenden (da Save bei 1.9.1 ES vorraussetzen würde und es sonst zu einer Fehlermeldung kommt, wenn man das Symbol klickt.) Entsprechend brauche ich auch kein „Shield“ vor ES, da es gar keins gibt . Das Ergebnis ist: Niemand (auch ich nicht) kann Dashboards direkt speichern. Wenn ich ein Dashboard ändern möchte, verwende ich dafür ganz normal die Grafana Oberfläche. Wenn es mir gefällt, lasse ich mir das „Dashboard JSON“ anzeigen, copy/paste das per ssh in das Dashboard file auf dem Server. Ja, umständlich Mit Grafana 2.0.2 ist das dann besser, das bringt eine User- und Rechteverwaltung mit (auf Basis von sqlite) und kann Dashboards in der lokalen sqlite speichern. ES ist dann nicht mehr nötig, um in Grafana Dashboards speichern und laden zu können. 2.0.2 kann auch als Proxy vor den Graphite Ports dienen.
Zu Graphite: Die Graphite Web-Ports müssen von aussen erreichbar bleiben (bei Grafana 1.9.1), da die Daten von den Dashboards per XHR nachgeladen werden. Das sieht man auch, wenn man FireBug mitlaufen lässt. Das ist OK, da für alles außer Metriken abholen ein User/Pass Schutz existiert. Die Ports zum Einliefern in Graphite (also carbon cache etc) sind NICHT von außen erreichbar bei meinem Setup.
Die Daten hole ich alle 5 Minuten vom https://www.freifunk-karlsruhe.de/ als json vom Server ab, wo sie von alfred bereits aufbereitet hingelegt werden (auch alle 5 Minuten, deswegen wäre häufigeres abholen meinerseits sinnlos.) Das ist das selbe JSON File, welches auch verwendet wird um zB https://www.freifunk-karlsruhe.de/map/alfred.html zu erzeugen. Das JSON parse ich dann mit einem selbst geschriebenen python script, welches die relevanten Daten extrahiert und textuell an den carbon-cache von Graphite schickt. Node- und Client-Anzahl, Total-Traffic, Hardware- und Firmware-Infos aggregiere ich bereits beim Parsen und schreibe es als globale Werte ins Graphite. Für jede Node dann noch zusätzlich Traffic, Clientanzahl und Load. Die Metriken der Nodes werden über die MAC der Nodes adressiert.
Zusätzlich erzeugt das Script ein Node-MAC-Adress → Node-Namen Mapping und speichert es ab. Alle 30 Minuten wird daraus das „pernode“ Dashboard neu erzeugt und alle Key-Value Paare des Mappings in der Template Variable des Dashboards ausgegeben. Dadurch können Nodes über ihren Namen in der Drop-Down Liste statt der MAC gefunden werden.
So, das wars erstmal. Bei weiteren Fragen einfach fragen Ich versuche, zeitnah zu antworten.
Viele Grüße,
ffka-xylou
6 „Gefällt mir“
Hi ffka-xylou,
Sehr cool! Vielen Dank für die ausführlichen Erklärungen, mein nächstes Projekt ist nun also was Ähnliches (direkt auf dem aktuellsten Grafana) zu basteln. Ich muss mal sehen, ob das der Trigger wird, dass ich endlich meine Python Skill auf- und ausbaue, oder das anders gestalte. Daher, ich denke ich, ich werde die ein oder andere Frage haben… 
Viele Grüße,
WutPanda
Wenn jemand Code schreibt, der das direkt vom ffmap-backend in influxdb schreibt, könnte ich demnächst mal ein Frontend dazu in den meshviewer einbauen. Als Key sollte dann aber die node_id statt der MAC verwendet werden.
2 „Gefällt mir“
Hi,
nur um den Technologiemix noch weiter zu zersplittern: Ich plane gerade, in Dortmund sowohl Daten von den Supernodes (System/Interfaces/Fastd/Batman-adv) als auch ggf. aus alfred in Prometheus zu füttern mit Grafana als Frontend.
Warum Prometheus und nicht InfluxDB? Prometheus ist eine reine Timeseries-Datenbank für float64-Reihen und speichert wesentlich effizienter als InfluxDB, kann Alarmierungen und hat ziemlich coole und schlanke Konzepte auch bzgl. der Art, wie die Daten reinkommen. Sonst ziemlich ähnlich.
Es gab dazu 'nen fantastischen Vortrag auf der letzten GPN, Videomittschnitt hier.
2 „Gefällt mir“
Der Vollständigkeit halber sollte hier noch collectd erwähnt werden. Es kann direkt nach influxDB schreiben und via verschiedener Output-Plugins auch zu Graphite/Prometheus, OpenTSDB, Redis, Riemann, Kafka, MongoDB.
collectd kommt bereits mit sehr vielen Plugins und kann durch Scripte einfach erweitert werden. Ebenso ist es möglich lokal auf dem httpd des Plastikrouters dezentral Statistik-Graphen mit RRD zu visualisieren. OpenWRT bringt das schon als fancy Webfrontend mit und gibt dem User sogar die Freiheit zu bestimmen, welche Metriken erfasst werden sollen.
Ich erwähne das hier u.a. weil alfred nur in Layer2-Netzen funktioniert. Wer eine Monitoring/Statistik Lösung für geroutete Netze sucht, wird in collectd eine umfangreiche Basis finden.
„kleinen Layer2-Netzen“ bitte. Und Netzen ohne rogue Alfred-Master.
Die in münchen scheinen da was geschrieben zu haben: http://map.freifunk-muenchen.de/meshviewer/#!n:c46e1ffe9f14
@WutPanda was macht deine Bastelei? Würde mich berennend beim nächsten Krefelder Stammtisch interessieren.