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

[Sven Röllig]

Warum wird dann die ALTE Software nicht mal einer
Frischzellenkur unterzogen??

Sven

Quoting Bastian <fly at d00m.org>:

> 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
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv