[Freifunk Franken] Suche VM fuer monitoring

Adrian Schmutzler mail at adrianschmutzler.de
Do Apr 5 18:33:13 CEST 2018


Hallo Sebastian,

 

es ist ein bisschen komplizierter:

 

Die Router schicken die Daten alle 5 min. über ein bestimmtes Protokoll („alfred“) innerhalb der jeweiligen Hood zu einem Gateway. Die Gateways sammeln die Daten und synchronisieren sie untereinander; neue Daten überschreiben alte (= Ein Datensatz pro Router). Die Router wissen also vom Monitoring erstmal gar nichts und das ist auch so gewünscht, weil die Firmware keine Abhängigkeiten vom Monitoring haben soll.

Umgekehrt kann jeder Router (oder entsprechend konfigurierte PCs) die Daten innerhalb der Hood abgreifen.

 

Der nächste Schritt ist unterschiedlich je nach KeyXchange-Version:

 

KeyXchangeV2:

Hier schickt jedes Gateway die Daten weiter an das Monitoring, auf den Gateways ist der DNS-Name des Monitorings hinterlegt. Dadurch können wir z.B. den Monitoring-Server durch eine simple DNS-Änderung überall „austauschen“. Jeder Gateway-Betreiber kann aber hier z.B. auch mehrere Adressen eintragen, sodass dezentrale Monitoring-Dienste vorstellbar sind. Senden erfolgt über curl, das Monitoring hat hierfür eine API, die die Daten per POST entgegennimmt.

 

KeyXchangeV1:

Aus historischen Gründen existiert hier eine zentrale Stelle („NetmonVM“), die als Client in ALLEN V1-Hoods hängt. Diese VM sammelt die Alfred-Daten aller V1-Hoods ein und schickt die dann gebündelt alle 5 Minuten an das Monitoring weiter. Der Kontakt mit dem Monitoring funktioniert wie beim KeyXchangeV2.

 

In beiden Fällen ist das System aber bewusst so gebaut, dass man das Monitoring durch ein komplett anderes System ersetzen oder auch komplett entfernen kann, ohne dass am Freifunk-Netz etwas kaputt geht.

 

Soweit zum System, nun zum Problem:

 

Alle Schritte bis zum Monitoring funktionieren zur Zeit akzeptabel bis gut. Hier gibt es ein paar spezielle Probleme, aber jetzt keinen grundsätzlichen Umstellungsbedarf, insbesondere da dies viele Ressourcen binden würde und ohnehin parallel zum jetzigen Zustand laufen würde/müsste.

Für die Performance ist jetzt in erster Linie relevant, was das Monitoring dann mit den Daten macht. Hier ist bereits sehr viel geschehen, aber natürlich ist auch weiterhin viel Potential. Der diesbezügliche Vorteil beim Monitoring ist, dass es eine einzelne Stelle ist, ich also Änderungen nicht absprechen muss und quasi für alle umstellen kann (im Gegensatz zu den Vorstufen wie oben beschreiben).

Allerdings reden wir hier über Optimierungsprobleme, wo erstens jeder Optimierungsversuch i.d.R. zu Fehlern führt, die erstmal alles schlechter machen, bevor es besser wird. Zweitens sind solche Sachen recht hässlich zu testen, und ich habe auch nur begrenze Expertise und Zeit.

 

Unabhängig davon kann ich das Monitoring problemlos schnell machen, wenn ich einfach alle Routerstatistiken auf einen Tag verkürze. Dann ist die Datenbank klein und alles flutscht. Nur will ich das nicht, weil die dann in meinen Augen eben wesentlich weniger nützlich sind.

 

Beste Grüße

 

Adrian

 

From: Sebastian Beck [mailto:freifunk at beibecks.de] 
Sent: Donnerstag, 5. April 2018 18:08
To: Freifunk Franken <franken at freifunk.net>; Adrian Schmutzler <mail at adrianschmutzler.de>; 'Freifunk Franken' <franken at freifunk.net>
Subject: Re: [Freifunk Franken] Suche VM fuer monitoring

 

Hallo,

Ok, der Server ist fix.
Dann vielleicht doch der Ansatz mit einem zweiten Server.

Wenn ich es richtig verstanden habe, schicken die einzelnen Router die Daten direkt an den Monitoring Server.
Die IP wird vermutlich in der FW fest mitgeliefert.

Angenommen wir können diese mit wenig Aufwand ändern und auf ein "Datensammelgateway" umleiten.
Dort werden die Daten gebuffert, wenn nötig/möglich vorverarbeitet. 
Dieses hätte auch nicht so hohe HW Anforderungen, wäre vielleicht leichter zu bekommen, bzw. doch dediziert an einen verfügbaren Uplink gestellt werden.

Auf dem aktuellen Server würden nur ungepachte Router weiterhin direkt ihre Daten abladen.

Die letzte Frage ist jetzt, ob das effektiv etwas bringen würde, die Software kenn ich nicht.

Grüße Sebastian 

Am 5. April 2018 17:48:15 MESZ schrieb Adrian Schmutzler <mail at adrianschmutzler.de <mailto:mail at adrianschmutzler.de> >:

Hallo,

 

wir haben glücklicherweise einen gesponserten Server für das Monitoring bekommen.

 

Jetzt mal kucken, was da mit der Performance passiert. Gewisse Probleme wie die Ladezeiten der Routerdetailseite sind davon ja nur zum Teil abhängig, deshalb waren die Vorschläge diesbezüglich generell interessant.

 

Gerade Tim war es so wie es verstanden habe auch wichtig, dass man die integralen/notwendigen Komponenten von Freifunk von den optionalen wie dem Monitoring stärker trennt. Dies spricht eher gegen die Backboneuplinks (oder?) …

 

Grüße

 

Adrian

 

 

From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of Sebastian Beck
Sent: Donnerstag, 5. April 2018 17:39
To: Freifunk Franken <franken at freifunk.net <mailto:franken at freifunk.net> >; Mister Crumble <MisterCrumble at web.de <mailto:MisterCrumble at web.de> >
Subject: Re: [Freifunk Franken] Suche VM fuer monitoring

 

Hallo zusammen,

Wo läuft denn das Monitoring bisher?
Gibt es ne Möglichkeit aufzurüsten?

Es gibt ja anscheinend ganz gute Backboneuplinks, könnte man da einen Server aufbauen?

Grüße Sebastian 

Am 5. April 2018 15:53:11 MESZ schrieb Mister Crumble <MisterCrumble at web.de <mailto:MisterCrumble at web.de> >:

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/ea2a92d5/attachment.html>


Mehr Informationen über die Mailingliste franken