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

[Bastian]

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