[Freifunk Franken] Suche VM fuer monitoring

Tim Niemeyer tim at tn-x.org
Do Apr 5 21:09:36 CEST 2018


Moin Dominik

Am Donnerstag, den 05.04.2018, 20:58 +0200 schrieb Dominik Heidler:
> Haben wir eigentlich bereits eine grafana Instanz?
> Vielleicht könnten wir die Monitoring-statistiken dahin auslagern...
> Ich kenne mich mit grafana nicht wirklich aus - ka ob das sinnvoll
> geht.
So lange es Statistiken über das _gesamte_ Netz sind ok.

Aber alles andere:
Bitte nicht schon wieder eine zentrale Lösung für dezentrale Geräte!
Die Statistiken gehören nicht auf einen zentralen Server sondern sollen
bitte bei den jeweiligen Betreibern lokal verbleiben.

Wenn du da jetzt eh planst Arbeit zu investieren, dann bitte gleich so,
dass keine zentrale Instanz entsteht. Das ist einfach nicht nötig.

Tim

> Am 05.04.2018 um 16:24 schrieb Mister Crumble:
> > 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 <mailto: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.ne
> >     <mailto:franken-bounces at freifunk.ne>t] *On Behalf Of *Mister
> > Crumble
> >     *Sent:* Donnerstag, 5. April 2018 15:53
> > 
> > 
> >     *To:* Freifunk Franken <franken at freifunk.net
> >     <mailto: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:franke
> > n 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
> >         <http://lists.freifunk.net/mailman/listinfo/franken-freifun
> > k.net>
> > 
> >         _______________________________________________
> >         franken mailing list
> >         franken at freifunk.net <mailto:franken at freifunk.net>
> >         http://lists.freifunk.net/mailman/listinfo/franken-freifunk
> > .net
> >         <http://lists.freifunk.net/mailman/listinfo/franken-freifun
> > k.net>____
> > 
> >     __ __
> > 
> > 
> >     _______________________________________________
> >     franken mailing list
> >     franken at freifunk.net <mailto:franken at freifunk.net>
> >     http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> >     <http://lists.freifunk.net/mailman/listinfo/franken-freifunk.ne
> > t>
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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 Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20180405/a5db4f04/attachment.sig>


Mehr Informationen über die Mailingliste franken