[Freifunk Franken] Suche VM fuer monitoring

Tim Niemeyer tim at tn-x.org
So Apr 1 00:08:58 CEST 2018


Moin Adrian

Am Samstag, den 31.03.2018, 23:33 +0200 schrieb
mail at adrianschmutzler.de:
> Hallo Tim,
> 
> > -----Original Message-----
> > From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of
> > Tim
> > Niemeyer
> > Sent: Samstag, 31. März 2018 21:52
> > To: Freifunk Franken <franken at freifunk.net>
> > Subject: Re: [Freifunk Franken] Suche VM fuer monitoring
> > 
> > Am Samstag, den 03.03.2018, 15:55 +0100 schrieb Tim Niemeyer:
> > > Hi
> > > 
> > > Wir suchen gerade eine neue VM für das Monitoring.
> > 
> > Da sich da immer noch nichts ergeben hat.
> 
> Läuft das jetzt noch auf der alten Maschine oder hast du migriert?

Noch auf der selben Maschine wie vorher. Aber da fast ein Monat lang
nichts passierte, sah ich mich gezwungen der Situation einen neuen
Glanz zu verschaffen.

> > 
> > > Anforderungen:
> > > * min. 16 GB RAM
> > 
> > Wir probieren das ganz mal mit 8 GB Ram...
> 
> Ich habe jetzt den cache pool für innodb von 10 GB auf 4 GB
> reduziert. Mal sehen, was passiert.

Ich dachte immer der stellt sich automatisch ein. Wir müssen den
Verbrauch runter kriegen, sonst finden wir nie einen neuen Host.


> > 
> > > * min. 40 GB SSD Disk
> > > * 4 CPU's ab Generation Sandy Bridge
> > 
> > ... und 2 CPU's.
> > 
> > > Wenn wer da was über hat, gern mal melden.
> > 
> > Aktuell läuft auf der Maschine auch ein monin, welches übermäßig
> > viel Disk
> 
> Woran genau siehst du das?

In htop

> 
> > usage hat. Weiter verbrauchte die Datenbank mehr RAM als da war und
> > hat
> > bereits geswappt. Hier muss unbedingt nachjustiert werden.
> 
> Bis jetzt waren die Swaps immer winzig.
Winzig ist schon zu viel. Swap Nutzung wäre im Extrem-Fall (z.B. DOS)
ok, um einen Absturz zu verhindern. Im Regelbetrieb darf der nicht
beansprucht werden.

> Ich habe nie ganz verstanden, warum zusätzlich zu dem InnoDB cache
> pool nochmal so viel Caching stattfindet. Ich habe auch weder im
> Internet noch im Gespräch mit MySQL Experten hierzu Erleuchtung
> gefunden. Mit welchen Tools könnte ich untersuchen, woraus sich der
> (System-)Cache zusammensetzt? (Um herauszufinden, ob das von mysql
> kommt oder von anderen Programmen)
Caching ist für das Dateisystem. Das war nicht unser Problem, da der
Cache automatisch verfällt, wenn der Ram anderweitig verbraucht wird.

> Weiterhin konnte ich vor zwei Wochen einige Performance-Probleme im
> Code lösen, die hausgemacht waren. Seitdem lief das Monitoring sehr
> schön stabil (mit Ausnahme der langen Ladezeiten der
> Routerdetailseite).
Das ist gut. Vielleicht sollten wir auch überlegen das Feature-Set zu
reduzieren.

Was brauchen wir vom Monitoring wirklich, was kann weg und was ist nur
Spielerei?

z.B.:
- Muss wirklich der RAM Verbrauch der Knoten geloggt werden?
- Muss wirklich jedes Interface dargestellt werden?
- Was von der API kann weg?
- etc..

Aus meiner Sicht sollte das zentrale Monitoring sich auf ein paar
wesentliche Dinge beschränken:
- Karte mit Knoten, deren Verbindungen und den Hoods
- API, damit die freifunk-karte.de versorgt wird

Optional könnte folgendes sinnvoll sein:
- Anzahl aller Knoten
- Anzahl Knoten pro Hood

Nicht nötig sind (weil diese Dinge auch dezentral zur Verfügung
gestellt werden könnten und sollten):
- Statistiken pro Knoten
- Kontakt-Daten

Grüße
Tim

> Grüße
> 
> Adrian
> 
> > 
> > Tim
> > 
> > 
> > > Tim
> > > _______________________________________________
> > > 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/20180401/dd6d3dcd/attachment.sig>


Mehr Informationen über die Mailingliste franken