[Freifunk Franken] Suche VM fuer monitoring

Do Apr 5 16:24:50 CEST 2018

bei den anderen communities gibt es halt 2 getrennte Server 1 x für karten
der sich die karten nötigen Infos holt und 1 für Statistik mit nem grafana
oder so

mfg MisterCrumble

Am 5. April 2018 um 16:12 schrieb Adrian Schmutzler <
mail at adrianschmutzler.de>:

> 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>:
>
> 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] On Behalf Of Miki
> > Sent: Mittwoch, 4. April 2018 22:24
> > To: Freifunk Franken <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
> > 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
>
>
>
> _______________________________________________
> franken mailing list
> 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/c7942e33/attachment.html>