[Freifunk Franken] Suche VM fuer monitoring

Do Apr 5 16:12:37 CEST 2018

Hallo,

interessanter Ansatz.

Mein erster Eindruck:

Die Trennung der Daten bringt uns erstmal nichts, wenn wir am Schluss (= Monitoring) trotzdem alle verarbeiten. Man könnte höchstens zeitlich entzerren. Dies wäre zu überlegen, wenn weiterhin alle Daten über die NetmonVM laufen. Da wir aber ja hoffentlich irgendwann über den KeyXchange v2 die Alfred-Weiterleitung dezentralisieren, schickt dann im besten Fall jedes GW die Daten zu einem anderen Zeitpunkt, und wir erreichen die zeitlich Entzerrung von selbst.

Weiterhin könnte man natürlich versuchen, bei der Auswertung zu priorisieren. Die Frage ist nur, wie ich feststellen soll, wann die Last für die Statistik-Daten zu hoch ist (sodass ich sie in der Folge verwerfe). Diesen Parameter könnte ich dann aber wiederum auch einfach abfragen, wenn alle Daten auf einmal kommen, und dann einfach die Statistik-Daten nicht wegschreiben.

Für das Last-Problem mit dem Monitoring sehe ich also erstmal eher keine Hebel. Wir sollten uns das aber für den Fall vormerken, dass wir Stabilitätsprobleme mit alfred und/oder zu viel Daten beim nodewatcher generieren.

Beste Grüße

Adrian

From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Mister Crumble
Sent: Donnerstag, 5. April 2018 15:53
To: Freifunk Franken <franken at freifunk.net>
Subject: Re: [Freifunk Franken] Suche VM fuer monitoring

Hallo, grundsätzlich gäbe es die Möglichkeit die Statistik Daten zu Trennen ( mit 2 Unterschiedlichen Datentypen zu senden) und die Auswertung zu trennen.

Bei einigen  anderen Communitys wird das meines wissens nach schon gemacht. Das ganze wichtige kommt in den ersten Datentyp, die ganze Statistik in den zweiten Datentyp.

MFG MisterCrumble

Falls ich mal Doku dazu finde schicke ich sie an die ML

Am 5. April 2018 um 15:10 schrieb Adrian Schmutzler <mail at adrianschmutzler.de <mailto:mail at adrianschmutzler.de> >:

Hallo Miki,

ich überlege schon seit einiger Zeit, ob man die Statistik-Daten nicht
irgendwie "nachladen" kann.

Neben dem Button gibt es bestimmt auch nette Möglichkeiten, per Skript erst
die Seite aufzubauen und dann erst die Statistiken zu laden. Dies ist aber
einerseits relativ viel Arbeit zwecks Einlesen, Testen und Umbauen;
andererseits löst es das Problem nur teilweise:

Man kann zwar so den Stress zwecks Lesen auf die Datenbank wegkriegen. Die
Daten müssen aber ja immer noch geschrieben werden (alle 5 min.) und alte
Daten müssen entfernt werden (einmal pro Tag nachts). Vor allem das
Schreiben der Daten, wenn sie von den Gateways kommen, machen eine Grundlast
an der DB, die sich aber nur bei leseintensiven Prozessen wie der
Routerdetailseite niederschlägt.

InnoDB optimiert intern relativ intelligent, man kann also davon ausgehen,
dass alle Nicht-Statistik-Daten (alles ohne Zeitachse) ohnehin im RAM
liegen, da diese ja alle 5 Minuten aktualisiert werden (und insgesamt auch
nur einige MB sind). Lediglich die alten Statistik-Daten fallen dann
irgendwann aus dem RAM raus. Nichtsdestotrotz muss natürlich jede Änderung
irgendwann auf die Festplatte geschrieben werden, siehe Grundlast im letzten
Absatz.
Ich habe auch schon überlegt, mal den MEMORY-Tabellentyp auszuprobieren; im
Prinzip hat das dann aber mehr Nachteile, weil ich entweder beim Neustart
die Daten verliere oder sie zusätzlich manuell wegschreiben muss (wodurch
ich dann keinen Gewinn mehr habe). Letzteres macht aber InnoDB im Prinzip
implizit selbst.

Um also auf deinen Vorschlag zurückzukommen:
Für das Backend glaube ich nicht, dass uns das viel bringt. Für das Frontend
werde ich früher oder später irgendwas in der Richtung bauen (müssen), auch
weil es mir selbst auf die Nerven geht, das die Routerseiten jetzt schon
ewig laden. Vorher werde ich aber erstmal noch etwas umfangreicher debuggen
(müssen), was da eigentlich wie viel Zeit braucht. Alles, wenn ich mal Zeit
habe, ich bin froh, dass jetzt endlich mal alle deadlocks in der alfred-api
weg sind.

Beste Grüße

Adrian

> -----Original Message-----
> From: franken [mailto:franken-bounces at freifunk.net <mailto:franken-bounces at freifunk.net> ] On Behalf Of Miki
> Sent: Mittwoch, 4. April 2018 22:24
> To: Freifunk Franken <franken at freifunk.net <mailto:franken at freifunk.net> >
> Subject: Re: [Freifunk Franken] Suche VM fuer monitoring
>

> Hallo,
>
> vielleicht können die Daten auf zwei Datenbanken aufgeteilt werden?
>
> 1) Eine kleine Datenbank, die ins RAM gewöhnlicher VM's passt, für die
> aktuellen Daten. Damit meine ich alles, was spontan angezeigt werden muss,
> wenn man auf die Seiten klickt.
>
> 2) Eine riesige Datenbank, die wie herkömmlich auf einer Festplatte liegt.
> Darin wären dann die Historiendaten, also z.B. was die letzten Tage/Wochen
> auf den Knoten los war. Wenn sich jemand nun für die Historie eines
> bestimmten Routers interessiert, ist es meiner Meinung nach zumutbar, dass
> man auf einen Button "Historie laden" klicken muss und ggf. ein paar
> Sekunden lang einen Fortschrittsbalken sieht.
>
> Viele Grüße,
> Miki
>
> _______________________________________________
> franken mailing list
> franken at freifunk.net <mailto:franken at freifunk.net> 
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

_______________________________________________
franken mailing list
franken at freifunk.net <mailto:franken at freifunk.net> 
http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20180405/248504f4/attachment.html>