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

[Jan Lühr]

Hallo,


Am 11/29/2014 04:43 AM, schrieb Kai 'wusel' Siering:
> 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.
> 
Ich denke, dass ist keine entweder-oder-Frage.
Viele Aufsteller von Nodes möchten gerne schön-Wetter-Informationen
(Nutzer, Traffic, etc.) die wir gut mit collectd-Erfassen können.

Daten über das Mesh selber (originators, LQ, etc.) sollten man auf
Zuverlössigen Punkten abgreifen (z.B. VM in das Backend integrieren um
batman-adv Kontrolldaten abzufragen).

Ich denke, dass dass es notwendig ist, jeden einzelnen Messwert über
einen Zuverlässigen ("pessimistischen") Transport einzusammeln.

Das auszuwerten, was da ist ("optimistic") hilft schon sehr viel.
Gleichzeit braucht man eine Datenquelle um den Mesh-Status sinnvoll zu
beurteilen.

Gruß, Jan