[Berlin-wireless] monitor.berlin.freifunk.net - Neues Monitoring System (influxdb, grafana)

Do Apr 20 16:06:32 CEST 2017

Die Potsdamer Community hat eine eigene Lösung für das Monitoring gebaut, die
für uns ev. auch von Interesse ist:

https://monitor.freifunk-potsdam.de/grafana/dashboard/db/home

https://wiki.freifunk-potsdam.de/StatusUpdates

Gruß Philipp

On Mon, Mar 13, 2017 at 01:30:17PM +0100, Philipp Borgers wrote:
> Es gibt jetzt unter http://stats.berlin.freifunk.net:3000/login ein halbherzig
> aufgesetztes Setup.
> 
> Es gibt zwei Personen aus der Glienicker Community, die sich des Monitorings
> annehmen wollen. Mehr dazu in den nächsten Tagen.
> 
> Gruß Philipp
> 
> On Mon, Jan 30, 2017 at 01:59:01PM +0100, Philipp Borgers wrote:
> > Hi,
> > 
> > danke. Ich versuche mir das zeitnah vorzunehmen. Ich freue mich auch über Hilfe
> > von anderen Interessierten.
> > 
> > Wenn wir eine einheitliche exim-Konfiguration haben, kann ich die auf anderen
> > Hosts auch konfigurieren/deployen. Ich hatte den Eindruck, dass es die noch
> > nicht gibt, deshalb habe ich erstmal nichts (mehr) unternommen. Vielleicht
> > können wir mal mit Nosy klären was konfiguriert werden sollte?
> > 
> > Ich glaube man kann irgendwo den domain name konfigurieren. Ich schaue mal.
> > 
> > Gruß Philipp
> > 
> > On Sat, Jan 28, 2017 at 03:41:29PM +0100, Bastian wrote:
> > > Hallo,
> > > 
> > > 77.87.50.10 ist mit 50G SSD eingerichtet. Dein Key ist bei root
> > > hinterlegt. Das System ist ansonsten untouched.
> > > 
> > > Ich war so frei und hab die config von exim auf
> > > monitor.berlin.freifunk.net angepasst, ist jetzt identisch zu den
> > > anderen Servern.
> > > In der grafana-config ist nun auch der smtp-Part aktiviert.
> > > Grafana's Password-Reset funktioniert jetzt grundsätzlich, verschickt
> > > aber mails mit einem Link auf localhost:3000 - dazu hab ich nicht weiter
> > > nachgeforscht.
> > > 
> > > 
> > > Best, Bastian
> > > 
> > > On 01/22/2017 05:09 PM, Philipp Borgers wrote:
> > > > On Wed, Jan 18, 2017 at 08:05:52PM +0100, Bastian wrote:
> > > >> Hi,
> > > >>
> > > >> Am 2017-01-17 18:29, schrieb Philipp Borgers:
> > > >>> anonymous-login sollte jetzt gehen.
> > > >>
> > > >> it works!
> > > >>
> > > >>> Zur Retention-Policy habe ich mir noch keine Gedanken gemacht.
> > > >>> Vorschläge?
> > > >>
> > > >> Siehe
> > > >> https://docs.influxdata.com/influxdb/v1.1/guides/downsampling_and_retention/
> > > >>
> > > >> Idealerweise fangen wir schon jetzt an auch influxdb eigene Metriken zu
> > > >> sammeln. Damit wissen wir dann den typischen workload, also wieviele
> > > >> datapoints per second und wie weit die DB z.B. pro Tag anwaechst.
> > > >>
> > > >> TSM ist eine sehr effiziente storage engine. Wir sollten problemlos 90 Tage
> > > >> aller jetzigen Metriken in 50GB unterbekommen.
> > > >> Storage ist eine endliche Resource und definitiv ein Grund für downsampling
> > > >> und retention-policy.
> > > >> Viel wichtiger ist aber IMHO die Problematik 1 Million datapoints im Browser
> > > >> darzustellen. Grafana ändert zwar intern schon automatisch die Anzahl der
> > > >> datapoints, aber ein Browser wird spürbar langsamer wenn ein Dashboard mit
> > > >> reichlich Panels für einen 30 Tage Zeitraum aufgerufen wird.
> > > >>
> > > >> Wir pushen momentan AFAIK alle 30s via collectd Metriken.
> > > >>
> > > >> Vorschlag:
> > > >> * die ersten 7 Tage ohne downsampling speichern
> > > >> * nach 7 Tagen auf 5min Auflösung reduzieren
> > > >> * nach 30 Tagen auf 15min Auflösung reduzieren
> > > >> * nach 90 Tagen auf 1h Auflösung reduzieren.
> > > >> * nach 3 Jahren Metriken löschen
> > > >>
> > > >> Obacht, als ich das letzte Mal damit gespielt hatte waren CQs und Derivates
> > > >> ein Problem.
> > > > 
> > > > Können wir versuchen.
> > > > 
> > > > Ich frage mich zur Zeit noch wie man Graphen anlegt, die auf beide Arten von
> > > > Daten (downsampled und nicht) zugreifen. Die Policies fürs downsampling
> > > > anzulegen scheint nicht so komplex zu sein.
> > > > 
> > > >>> Es ging erstmal darum eine gleichwertige Alternative zum jetzigen
> > > >>> Monitoring-System zu schaffen. Templates für Server und custom-Metriken
> > > >>> können
> > > >>> wir im Laufe der Zeit anlegen.
> > > >>>
> > > >>> Ich habe für den Traffic-Graphen noch ein group by type_instance aka.
> > > >>> interface
> > > >>> hinzugefügt, sodass der Graph jetzt Daten für alle Interfaces eines
> > > >>> Routers
> > > >>> enthält. Ein eigenes Dashboard ist ev. trotzdem nicht verkehrt.
> > > >>
> > > >> Sieht jetzt schon für die meisten Nodes sehr brauchbar aus. Manche Router,
> > > >> vermutlich alte mit collectd 4.x, zeigen aber noch immer keine iface-names
> > > >> in den meisten Panels an. Bei manchen Wifi panels aber schon. Siehe Node
> > > >> FraktionLINKE.
> > > > 
> > > > Wir haben auch Router mit Version 5.5.2 bei denen die Interfaces fehlen. Muss
> > > > man sich nochmal genauer angucken.
> > > > 
> > > >>> Memory (used) und Memoery-Distribution könnten wahrscheinlich auch in
> > > >>> einen
> > > >>> Graph. Das war default so in dem Dashboard was wir übernommen haben
> > > >>>
> > > >>> Uptime muss man noch fixen. Muss ich mir noch angucken wie genau.
> > > >>>
> > > >>> Das "Freifunk Traffic" Dashboard ist uns noch von der letzten
> > > >>> Grafana-Instanz
> > > >>> erhalten geblieben. Vielleicht einfach löschen?
> > > >>
> > > >> Ich häng da nicht dran, kann gerne gelöscht werden.
> > > > 
> > > > Dann lösche ich das mal.
> > > > 
> > > >>> Dein User sollte jetzt edit-Rechte haben.
> > > >>
> > > >> ACK.
> > > >>
> > > >>> Ich würde mit dem Umzug der VM bzw. in eine andere VM erstmal warten.
> > > >>
> > > >> Ich würde das gerne so früh wie möglich machen. Der Aufwand ist jetzt noch
> > > >> minimal, und wenn wenn wir es jetzt machen müssen IMHO auch keine TSM/DB
> > > >> Daten kopiert und importiert werden.
> > > >> Ich merke jetzt schon wie Langsam manche Abfragen sind. Die neue Location
> > > >> rennt auf SSD und moderner CPU.
> > > >> Redirect von monitor:3000 auf z.B. stats:443 sollte kein Problem sein,
> > > >> migration der Config und Daten sollte auch in weniger als 1h machbar sein.
> > > >> Also lieber jetzt als später (oder nie).
> > > > 
> > > > Willst du einfach mal ein Ubuntu mit genug Platz vorbereiten? Ich versuche das
> > > > dann zeitnah umzuziehen.
> > > > 
> > > > Ich fände es schön, wenn sich noch andere Personen an der Einrichtung und
> > > > Wartung beteiligen würden. Ich denke das ist ein gute Spielwiese, auch wenn man
> > > > noch nicht so viel Erfahrung mit Linux (Servern) hat.
> > > > 
> > > >> Best, Bastian
> > > >>
> > > >>> On Tue, Jan 17, 2017 at 04:15:08PM +0100, Bastian wrote:
> > > >>>> Hallo,
> > > >>>>
> > > >>>> +1
> > > >>>>
> > > >>>> Grafana erlaubt auch "unauthorized" access, also Read-only ganz ohne
> > > >>>> Angabe
> > > >>>> von username/password.
> > > >>>>
> > > >>>> Gibt es schon Pläne bzgl. Retention-Policy?
> > > >>>>
> > > >>>> Bzgl. Sinnhaftigkeit:
> > > >>>> Das aktuelle default-dashboard ist natürlich ein Problem fuer alles
> > > >>>> was
> > > >>>> nicht ein Plasik-Router mit wizard-based Konfiguration ist. Also VMs
> > > >>>> und
> > > >>>> andere Server, Router mit mehreren Interfaces die auch noch andere
> > > >>>> Namen
> > > >>>> haben usw....
> > > >>>>
> > > >>>> Ggf. macht es Sinn ein Template fuer die Interfaces anzulegen? Dabei
> > > >>>> evtl.
> > > >>>> sogar noch zwischen Ethernet und Wireless unterscheiden.
> > > >>>> Das passt momentan irgendwie alles nicht so richtig zusammen solange
> > > >>>> nicht
> > > >>>> klar ist fuer welches Interface ein jeweiliger Graph gilt. Network
> > > >>>> Utilization vs. Network Traffic?
> > > >>>>
> > > >>>> Memory und Memory-Distribution sollten doch zueinander in Relation
> > > >>>> stehen?
> > > >>>> Was zeigt das "Memory" Panel eigentlich genau an?
> > > >>>>
> > > >>>> Uptime bei mehr als 12 Monaten zeigt nur noch "1 year" an.
> > > >>>>
> > > >>>> Das "Freifunk Traffic" Dashboard ergibt IMHO keinen Sinn. Von 60
> > > >>>> Terrabit/s
> > > >>>> wüsste ich :)
> > > >>>> Aber wenn du bro-ff at d00m.org EDIT-permissions gibst, dann kann ich das
> > > >>>> entsprechend updaten.
> > > >>>>
> > > >>>> Sobald die puppet Sachen fertig sind sollte sich das Setup doch auch
> > > >>>> problemlos auf einem anderen Host aufsetzen lassen?
> > > >>>> Wir haben da noch weniger ausgelastete Maschinen die wesentlich besser
> > > >>>> geeignet sind als die derzeitige monitor-VM.
> > > >>>> Was brauchst du genau? Ubuntu 16.04.1 mit ~50GB space?
> > > >>>>
> > > >>>>
> > > >>>> Best, Bastian
> > > >>>>
> > > >>>> Am 2017-01-17 14:59, schrieb Philipp Borgers:
> > > >>>>> Moin,
> > > >>>>>
> > > >>>>> wir hatten in der Vergangenheit mehrfach darüber diskutiert das
> > > >>>>> Monitoring-System zu wechseln. Ich habe mich in den vergangenen Tagen
> > > >>>>> noch mal
> > > >>>>> "intensiver" mit Alternativen beschäftigt. Das vorläufige Ergebnis ist
> > > >>>>> eine
> > > >>>>> Kombination aus collectd, influxdb und grafana, die ich auf
> > > >>>>> monitor.berlin.freifunk.net [1] installiert habe. Die Router schicken
> > > >>>>> ihre Daten
> > > >>>>> wie gewohnt per collectd an eine collectd Server-Instanz auf
> > > >>>>> monitor.berlin*.
> > > >>>>> Der Server leitet die Daten direkt weiter an die Datenbank (influxdb).
> > > >>>>> Im
> > > >>>>> Frontend (grafana) wurde influxdb als Datenbank angelegt und ein
> > > >>>>> Dashboard
> > > >>>>> importiert und erweitert, dass die Daten, die wir vom collectd erhalten
> > > >>>>> visualisiert.
> > > >>>>>
> > > >>>>> Das Host-Overview Dashboard [2,3] erlaubt es einen Router auszuwählen
> > > >>>>> und
> > > >>>>> Meteriken über diesen abzurufen. Für den ersten Link müsst ihr einen
> > > >>>>> User
> > > >>>>> anlegen. Ich kann euch zum Admin/Editor/etc machen, wenn ihr mir euren
> > > >>>>> Username
> > > >>>>> schickt. Mit Editor rechten solltet ihr die Möglichkeit haben neue
> > > >>>>> Dashboards
> > > >>>>> anzulegen.
> > > >>>>>
> > > >>>>> Was noch getan werden müsste:
> > > >>>>>
> > > >>>>> * Konfiguration auf Sinnhaftigkeit überprüfen
> > > >>>>> * Konfiguration nach puppet überführen
> > > >>>>> * Default-Organization und Benutzerrechte anpassen
> > > >>>>> * Statistiken zu ausgewählten Systemen u. Standorten anlegen
> > > >>>>> * Alerting testen
> > > >>>>> * "Dropping point olsrd_value: NaN is an unsupported value for field
> > > >>>>> value"
> > > >>>>>   fixen
> > > >>>>> * Mail-Setup auf monitor.berlin.freifunk.net fixen
> > > >>>>> * IPv6 Routing auf monitor.berlin.freifunk.net fixen
> > > >>>>>
> > > >>>>> Ich freu mich auf euer Feedback!
> > > >>>>>
> > > >>>>> Gruß Philipp
> > > >>>>>
> > > >>>>> [1] http://monitor.berlin.freifunk.net:3000
> > > >>>>> [2] http://monitor.berlin.freifunk.net:3000/dashboard/db/host-overview
> > > >>>>> [3]
> > > >>>>> http://monitor.berlin.freifunk.net:3000/dashboard/snapshot/XcFyb0rarUXiNdCgmz6pVMSZi3Jar8CD
> > > 
> > > _______________________________________________
> > > Berlin mailing list
> > > Berlin at berlin.freifunk.net
> > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > > Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> 
> 
> 
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv
> 

> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20170420/581edfa4/attachment.sig>