[Freifunk Franken] Status Monitoring

[Florian Schimmer]

Hi Leute,

ich schreibe aktuell an einen alfred-importer für prometheus 
(prometheus.io).
Aktueller Stand ist, dass es schon prinzipiell funktioniert, noch nicht 
stabil ist und noch aufgeräumt gehört.

Prometheus verwaltet die Daten intern in ner time-series-db, was fürs 
Monitoring wahrscheinlich
die geschicktere Lösung ist.

Mit Hilfe von grafana (http://grafana.org/) lassen sich dann ganz bequem 
eigene dashboards  erstellen.

Das Ganze war eigentlich für die aux gedacht um mich informieren zu 
lassen, wenn was nicht mehr geht 
(https://prometheus.io/docs/alerting/overview/).
Außerdem wollte ich ein System, mit dem ich auch die Gateways und ggf. 
auch nicht-Freifunk Geräte überwachen kann.

Was ich darüber hinaus aber noch brauche, ist ne Datenbank, die 
allgemeine Daten, wie Device-Name, gps-position etc. verwaltet, also 
das, was im monitoring eh schon gemacht wird.

Deshalb mein Vorschlag (nur mal zur Diskussion, noch nicht vollständig 
durchdacht):

* Die allgemeinen Daten werden über die mongo-db im Monitoring verwaltet
* Die statistischen Daten über prometheus
* Die Visualisierung findet über grafana statt, was wiederum ins 
Monitoring mit eingebunden wird

Was für Vorteile sehe ich:

* Für den normalen User ändert sich erst mal nichts, außer dass die 
graphen ein wenig mehr Funktionen haben und ein bisschen anders aussehen
* prometheus hat ne sehr schöne api um Daten abzufragen. Da kann jeder 
mit wenig Aufwand sich das abholen, was er möchte.
* alerting ist mit vorgesehen, könnte man also recht schnell über 
Monitoring mit anbieten
* mit grafana könnte jeder sich seine eigenen dashboard basteln, so wie 
er das möchte
* monitoring wird ein stück schlanker
* lässt sich sehr schön für weitere Geräte erweitern

Nachteile:

* das Ganze besteht aus mehr Komponenten, die mit einander interagieren 
müssen

Was gibts dazu für Meinungen?

Lg,
Flo






Am 30.04.2016 09:55 schrieb Christian Dresel:
> hi
> 
> Am 29.04.2016 um 16:04 schrieb Michael Fritscher:
>> Hallo ihr,
>> 
>> RAM hat die Kiste eigentlich genug - 2,5 GB, von denen derzeit 0,5 GB 
>> fürs
>> cachen verwendet wird. Wobei Mongo sich 1,1 GB genehmigt.
>> 
>> Das gröbere Problem war der HDD Durchsatz - Mongo hatte bis vorgestern
>> durchgängig 5 MB/s gelesen und 7 MB/s geschrieben . Daraufhin hatte
>> Dominik Mono aktualisiert und die Kompression aktiviert, was die Daten 
>> von
>> 10 GB auf 800 MB einstampfte - dadurch schrumpte es auf ca 0,6/1,6 
>> MB/s -
>> zwar meines Erachtens immer noch recht viel für die Aufgabe, aber
>> verkraftbar. Anscheinend sind das die alle 5-10 Minuten ablaufenden
>> Aktualisierungsläufe, wobei ich da nicht verstehe, wieso so viel 
>> gelesen
>> werden muss.
>> 
>> 1-1,5 GB RAM könnte ich noch problemlos reinstecken (wenns sein muss 
>> auch
>> noch mehr), darüber hinaus sollten wir uns wie schon ggüber Dominik 
>> mal
>> überlegen, ob wirklich so viel HW für das Monitoring nötig sein muss.
> 
> Ich könnte mir vorstellen das die Statistik evtl. einen großen Teil der
> Last ausmacht. Ich hab das Monitoring frisch aufgesetzt und lese 
> aktuell
> 6 Hoods selbst ein (zu den anderen hab ich leider keine Verbindung), 
> die
> Kiste langweilt sich eigentlich zu tote, ich hab ja auch praktisch noch
> keine großen Statistiken da das ganze erst seit gestern ununterbrochen
> läuft.
> 
>> Mein
>> Gefühl sagt ja, das die zu 99% hochgradig strukturierten Daten in was
>> tabellenartigem deutlich besser aufgehoben wären ;-)
> 
> du meinst sowas wie die 5NF Regeln einhalten, Normalisierung und so?
> 
> mfg
> 
> Christian
> 
>> 
>> Viele Grüße,
>> Michael
>> 
>> 
>> 
>> _______________________________________________
>> franken mailing list
>> franken at freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
>> 
> 
> 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net