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

[Philipp Borgers]

Grafana fehlt Platz in /var, das gerade voll ist. Ich versuche es zu beheben.

On Sat, Jan 21, 2017 at 09:51:53AM +0000, Sven Röllig wrote:
> Läuft nicht mehr.
> 
> es erscheint ne fehlermeldung "Unexpected error"
> 
> Sven
> 
> Quoting Bastian <fly at d00m.org>:
> 
> > 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.
> > 
> > 
> > > 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.
> > 
> > > 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.
> > 
> > > 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).
> > 
> > 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
-------------- 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/20170122/0ad56509/attachment.sig>