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

Sa Jan 21 10:51:53 CET 2017

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