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

Mi Jan 18 20:05:52 CET 2017

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