Dezentrale Hoods im Monitoring

Di Feb 26 13:28:06 CET 2019

Hallo Tim,

ich sträube mich etwas, ein komplett neues paralleles System aufzubauen.

1) Einbettung in das alte System

Allerdings ist im Rahmen des bestehenden Systems ja ohne weiteres möglich, einfach sehr wenig Daten zu schicken.

Du hast das ja vor einiger Zeit schon Mal selbst ausprobiert. Dann braucht man keine extra Struktur, sondern schreibt einfach ganz viele NULLer in die bestehende Tabelle.

(Die Routertabelle selbst hat auch kein Größenproblem, nur die History ist da kritisch).

Was in dieser Hinsicht zu verbessern wäre, wäre eine konkrete Sichtung des API-Codes vor diesem Hintergrund, sodass die Einteilung der Parameter in notwendig/optional nicht so sehr auf Zufall basiert.

Weiterhin könnte man den minimalen Datensatz, der notwendig ist, (besser/überhaupt) dokumentieren. Dies sollte ja im Moment schon nicht viel mehr sein, als das, was du vorschlägst.

Auch kann man im bestehenden Format ja bereits Daten bündeln, nur wären das in der Alfred API halt dann ein XML pro Gerät, die aber ja gesammelt geschickt werden können.

Man bräuchte dann aber immer zumindest irgendein Interface (ggf. Fake) pro Gerät, da die MAC-Adresse zur Zuordnung der Datensätze neu zu alt fungieren soll. Sonst gibt es mit jedem Datensatz ein neues Gerät :-)

Dementsprechend halte ich es nicht für so dramatisch, sich im bestehenden System einzufügen, wenn man das etwas besser dokumentiert.

2) Einfaches neues System

Deine vorgeschlagene Lösung könnte ich mir so vorstellen, dass man einfach mit den Daten für das Gateway dann einen Block im XML mitschickt (Syntax nur als Beispiel):

<dependentnodes>

<node><lat>10</lat><lon>10</lon><name>xy</name></node>

<node><lat>11</lat><lon>12</lon><name>yz</name></node>

</dependentnodes>

Damit kann man dann Punkte malen und die alle mit dem GW verbinden (ggf. mit neuer Farbe). Dabei würde dann KEINE Information über die tatsächlichen Verbindungen der Knoten oder die Qualität einhergehen, weiterhin gäbe es KEINE „Routerdetailseite“. Wer zusätzliche Daten braucht, soll zum GW schauen (ggf. kann man das dann direkt verlinken).

Wenn man das derart primitiv umsetzt, gibt es dafür eine eigene Subtabelle mit 1:n, neue zusätzliche Funktion bei Erstellen der Karte und fertig. Den Aufwand schätze ich gering ein.

Ich werde dann auch nicht über ein einzelnes Attribut streiten, wenn jetzt jemand unbedingt noch ein Feld description will. Aber ich werde jetzt nicht anfangen, dann noch eine Verknüpfungslogik für die Knoten zu bauen, dafür kann man dann das bestehende System benutzen.

Prinzipiell sehe ich kein Problem darin, eine solche neue Lösung zu schaffen, sofern dafür Interesse besteht (= sobald 2 Leute sagen, dass sie das aktiv benutzen möchten).

3) Statistik-Menge generell

Grundsätzlich habe ich auch kein Problem damit, wenn jemand aktiv weniger Statistik-Daten schickt als der Standard-nodewatcher. Mir war/ist nur wichtig, das die Standard-Knoten-Firmware hinreichend Daten liefert, sodass man bei einem 0-8-15 Nutzer mit Standard-Firmware ggf. einigermaßen Remote-Support leisten kann.

Beste Grüße

Adrian

From: Tim Niemeyer [mailto:tim at tn-x.org] 
Sent: Montag, 25. Februar 2019 21:24
To: Freifunk Franken <franken at freifunk.net>; Adrian Schmutzler <mail at adrianschmutzler.de>
Subject: Re: Dezentrale Hoods im Monitoring

Moin Adrian 

Am Montag, den 25.02.2019, 17:46 +0100 schrieb Adrian Schmutzler: 
> Die Daten müssen halt irgendwie zum Monitoring kommen. Wie du das 
> machst, ist relativ egal, du kannst das XML auch von Hand bauen. 
>   
> Wichtig ist aber die Frage, was du möchtest. Das Monitoring benötigt 
> relativ wenige „Pflicht-Daten“. Wenn es dir nur um den Punkt auf der 
> Karte geht, kannst du einen minimalen Datensatz schicken. Wenn du das 
Wäre es an der Stelle nicht ggfs sehr gut, wenn man ein ganz neues 
Datenschema für AP's machen würde? 
Damit könnte man auf seinem Gateway einfach ein paar zusätzliche XML 
Files gegen das Monitoring werfen (ggfs sogar en'block) und es würden 
einfache Punkte (muss ja man ja nicht mal zwingend anklicken können, 
aber ggfs in einer abweichenden Farbe) angezeigt werden. 

Vorschlag für Attribute: 
Mandatory: 
- Position 
- ID des zugehörigen Gateways 
Optional: 
- Name 
- Ansprechpartner 
- Beschreibung 

Es wäre mit Absicht einfach und schlank gehalten. Wer seine AP 
Landschaft intensiver überwachen will, sollte dann ein eigenes 
Monitoring (z.B. hat sich Zabbix bewährt) verwenden. Viele AP- 
Controller bringen ja auch bereits ein eigenes System mit. Insofern 
wäre unser Monitoring wirklich nur für "guck mal da, da sind Punkte". 

Was denkst du dazu, Adrian? 

Tim 

> Monitoring (wie für die klassischen Knoten auch möglich) zum Debuggen 
> nutzen willst, hast du mehr Aufwand, da du dann das ganze Zeug auch 
> schicken musst. 
>   
> In letzterem Fall ist es wohl am einfachsten, wenn du einfach das 
> nodewatcher Skript nimmst, und entsprechend umbaust. Am Schluss dann 
> halt nicht zum Alfred, sondern ans Monitoring schicken. 
> In ersterem Fall ist ggf. auch bottom-up einfacher, oder auch 
> nodewatcher und ganz viel löschen. 
>   
> Grüße 
>   
> Adrian 
>   
> From: franken [mailto:franken-bounces at freifunk.net <mailto:franken-bounces at freifunk.net> ] On Behalf Of frei 
> funk at beibecks.de <mailto:funk at beibecks.de>  
> Sent: Montag, 25. Februar 2019 16:54 
> To: Freifunk Franken <franken at freifunk.net <mailto:franken at freifunk.net> > 
> Subject: Dezentrale Hoods im Monitoring 
>   
> Hallo zusammen, 
>   
> wenn ich eine größere Installation mit mehreren APs von zentral auf 
> dezentral umstelle, und auf diesen keine FFF-FW mehr verwende, 
> verschwinden ja erstmal alle Knoten  aus dem Monitoring. 
>   
> Ich meine mal gehört zu haben, es gäbe einen Weg, diese Knoten 
> manuell reinzufaken. 
>   
> Ist dies richtig? Und wie? 
> Wenn ja, sollte man dies tun, oder hat das negative Effekte? 
>   
> Es wäre schade, wenn am Schluss sehr viel weniger Punkte vorhanden 
> sind.  
> Klar ist es wieder "nur" das Monitoring, aber ich denke eben an die 
> Außenwirkung. 
> Die coolsten Installationen würde somit einfacher aussehen als zuvor. 
> Auch fehlt einfach was ;) 
>   
> Grüße, 
> Sebastian 
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://{'listname': 'franken-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-freifunk.net/attachments/20190226/35009042/attachment-0001.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://{'listname': 'franken-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-freifunk.net/attachments/20190226/35009042/attachment-0001.sig>