[Berlin-wireless] monitor.berlin.freifunk.net: Unvollständige Übersichtsseite

[Bastian]

Am 2016-12-20 18:42, schrieb Malte:
> On Tue, 20 Dec 2016, Sven Roederer wrote:
> 
>> Also mir fallen da folgende Punkte ein:
>> - reguläre Updates
>> - untersuchung, was die "Übersichtsseite" immer mal kaputt macht
> 
> Auch gefühlt mindestens die Hälfte der Graphen ist leer. Das liegt
> glaube ich wenigstens teilweise an dem collectd-Versionsdurcheinander.
> Die leeren Graphen sollten entweder gar nicht erst angezeigt werden
> (ggf. mit Hinweis, warum) oder die Daten irgendwie live gefixt werden.
> Ist aber bestimmt nicht ganz einfach.

Naja, wir haben ja noch reichlich router mit einer 2013er Firmware im 
Umlauf und auf unseren gefoerderten BBB-Standorten.
Da ist dann halt auch ein uraltes collectd installiert...

>> - entschlackung der Übersichtsseite
>>  - ein paar Hosts sind ja gruppiert, aber eigentlich dümpeln die 
>> meisten
>>  un der "ungrouped" sektion umher
> 
> Bonuspunkte für automatische Gruppierung z.B. nach Stadtteil, PLZ oder
> Standort, aufgrund der Geokoordinaten (aus der OWM). Ist kein
> Hexenwerk, die Standort-Artikel im Wiki machen das auch so.

Wird mit RRD alleine schwer, bzw. wird viel Aufwand in 
PHP-Frontend-Logik.

Eine ordentliche Timeseries-Database (wie influxb, graphite, usw.) 
bringt zumindest die Möglichkeit für extra/custom meta-tags wie z.B. 
PLZ, Standort oder Maintainer. Mit Grafana als Frontend lässt sich 
soetwas auch relativ einfach templaten.

An Grafana wird ziemlich aktiv entwickelt, inzwischen ist sogar 
Alterting Funktionalität dazu gekommen. Und dank User-Mgmt könnten wir 
ggf. sogar eigene customized Dashboards für größere Standorte 
ermöglichen.

> Was auch noch fehlt, ist Verlinkung. Geht ganz einfach, nur einen Link 
> auf
> https://util.berlin.freifunk.net/knoteninfo?knoten=KNOTENNAME
> also z.B.
> https://util.berlin.freifunk.net/knoteninfo?knoten=Zwingli-Nord-2GHz
> auf die Seite des Knotens hinzufügen.
> 
>> Sonst halt noch, wie geschrieben, migration auf Nachfolgesystem.
> 
> Bin mir nicht ganz sicher, ob InfluxDB etc. wirklich nötig ist, zumal
> das ja auch wieder eine Dependency auf collectd auf den Routern hat
> (oder?). Brauchen wir überhaupt sekundengenaue Stats? Ich könnte mir
> auch vorstellen, dass ein leicht aufgebohrtes owm.lua eigentlich schon
> in den meisten Fällen reicht. Dann würden auch mehrere hundert KB
> ROM-Bedarf sowie einige dutzend MB RAM-Bedarf für collectd wegfallen.

Clients, die periodisch Metriken an eine Timeseries-DB senden, müssen 
nicht zwangsläufig collectd verwenden. AFAIK haben alle TSDBs auch ein 
eigenes, meist http-based wire-protocol.
Der Vorteil von collectd ist eher die einfache Möglichkeit zum 
Erweitern. collectd ist als opkg inkl. plugins schon verfügbar. Die 
Liste der Plugins ist auch sehr umfangreich und das Einbinden von 
Shell-Scripts ist auch möglich.
Persönlich finde ich die Hürde mit lua custom metrics zu verwenden dann 
schon bei weitem höher.

Aber ja, du hast schon recht mit dem Platzverbrauch durch collectd. Und 
wenn ich mich recht erinnere, ist collectd auch gerne mal auf Platz #1 
der Memory-Consumption.

Gruß, Bastian