[ff-firmware-devel] ffmap/Gluon: per Node rrd-Graphen?

Kai 'wusel' Siering wusel at guetersloh.freifunk.net
Sa Nov 29 04:43:14 CET 2014


Moin,

On 23/11/14 20:41, Christof Schulze wrote:
>> Gluon liefert ja nun minütlich per Alfred Load-Average, Uptime sowie
>> Traffic-Counter mit; hat das jemand schon in ffmap-backend so eingebaut,
>> daß daraus z. B. Traffic-RRDs erzeugt werden (Counter, Zeitinterval =>
>> RRD)? Oder liegt hier ein Denkfehler meinerseits vor?
> Anstatt noch ein weiteres Tool zu schreiben, dass rrd-files erzeugt,
> sollte hierfür besser ein collectd-Plugin entstehen. Dadurch kriegt
> man ordentliches caching - bei Bedarf über memcollectd - und damit

Ja, caching auf dem Backend ist schick, keine Frage. Dafür gibt es aber 
auch Lösungen (rrdcached), genauso wie für intelligentes graphing (alle 
Graphen alle 5 Minuten sprengt *jede* Hardware ab einem genügend hohen 
"n"; been there, done that ;)).

Caching auf dem Node ist allerdings ein Thema, was durch die ähnliche 
Diskussion auf WLANware (Thread "Node-Management / 
Knotenpunkt-Verwaltung") grade wieder in meinen Fokus gerückt ist. Grade 
bei einem Maschennetz möchte ich glaube ich eher nicht auf 
munin/collectd setzen, die eine funktionierende Verbindung voraussetzen, 
welche hier eher nicht zwingend gegeben ist. (Das ist im RZ ein klein 
wenig anders, auch die Bandbreiten.) Ich habe früher viel mit Orca [1] 
gemacht, und schätze den store-and-deliver-Ansatz dort (ansonsten ist 
das Projekt, fürchte ich, noch auf dem Stand von vor 10 Jahren :()). 
Andererseits sollte man weder die kleinen Kistchen überfrachten noch 
nach wochenlanger fehlender Verbindung Gigabytes an obsoleten Daten über 
eine schwache Funkstrecke jagen.

Kurzum: Bevor man bestehende Mainstream-Tools auf Maschennetzwerke 
losläßt, sollte der Scope klar definiert werden. Will ich 
Schönwetter-Informationen (Link ist da => Daten sind da; Link ist weg => 
Daten ebenso) oder echtes Reporting, grade auch wenn es mal Probleme auf 
Server oder Client oder dem Weg dazwischen gibt? Ich tendiere eher zu 
letzterem, zumal dies auch Aufschluß darüber gibt, ob die 
Nichterreichbarkeit an Reboots oder anderen lokalen Problemen gelegen hat.

Insofern erscheint mir der Ansatz via Alfred auch nicht mehr 
zielführend. Mal gucken, ob sich da ein relativ simpler 
save-and-push-Dienst draus machen läßt. Alternativ wäre ein cachendes 
network-Plugin für collectd natürlich die schickere Lösung.

MfG,
-kai

[1] https://www.orcaware.com/orca/



Mehr Informationen über die Mailingliste firmware-devel