Am 17.02.2016 haben wir beschlossen, dass wir weitere Statistiken der Knoten erfassen, respektive speichern, wollen. Derzeit wird nur die Anzahl der verbundenen Clients erfasst.
Es wurde ebenfalls beschlossen, dass diese Statistiken nicht unmittelbar für alle Knoten erfasst werden sollen, sondern der Knotenbetreiber selbst entscheiden kann, ob diese Daten gespeichert werden sollen oder nicht. (Anmerkung: Die entsprechenden Daten werden zwar sowieso vom Knoten übermittelt, aber derzeit verworfen und nicht gespeichert.)
Gründe für diese Entscheidung sind vielfältig, lassen sich jedoch unter dem Unterbegriff Diskriminierungsfrei zusammenfassen. Es sollen z. B. keine Knoten(-betreiber) bzgl. eines hohen Datenverbrauchs in Misskredit geraten. Aus diesem Grund haben wir uns für eine Whitelist/OptIn anstatt einer Blacklist/OptOut entschieden, da ein OptOut Knotenbetreiber ggf. ebenfalls als “schwarzes Schaf” markieren könnte.
Geplant ist, dass im Konfigurationsmodus ein Haken gesetzt werden kann, der die erweiterte Speicherung aktiviert.
Folgende Daten würde ich gerne erfassen:
Beschreibung findet sich hier.
statistics / datatype 159
-
traffic(jeweilspackets,bytes, sowie ggf.dropped) txrxmgmt_txmgmt_rxforwardclientswifitotaluptimeidletimeloadavgmemorycachedbufferstotalfreeprocessesrunningtotalmesh_vpn-
peers- Wert muss entsprechend fürs Graphite aufbereitet werden -
gateway- Dito, überlegen, ob Wert praktikabel erfasst werden kann.
neighbours / datatype 160
wifi-
neighbours[](jeweils)noisesignalinactive
-
count- Wert gibt es nicht, wird berechnet -
batadv-
neighbours[](jeweils)tqlastseen
-
count- Wert gibt es nicht, wird berechnet
-
(Anmerkung: Die aufgeführte Liste gibt in etwa die Struktur des alfred-json wieder und nicht die Struktur, wie es später in graphite abgelegt werden soll.)
Unter nodeinfo / datatype 158 gibt es noch Informationen, wie z. B. die verwendete FW-Version, etc. Ich bin mir aber nicht sicher, ob es viel Sinn macht diese ebenfalls hier zu erfassen (FW-Version wird je Domäne als count erfasst).
Es gab von @void die Anregung den Wert loadavg unabhängig vom Aktivieren des erweiterten Modus für alle Knoten zu speichern. Da man hierdurch vorzeitig erkennen kann, wenn ein Netz zu groß wird und die Knoten schlapp machen. Feedback?
Das sind zwar viele Werte, aber ich finde jeden für sich sehr interessant. Falls der aktuelle Graphite-Server das nicht verkraften sollte, können wir ja mal drüber nachdenken eine zweite Instanz davon aufzubauen dediziert für die Knoten-Statistik (das ist zumindest einer von zwei drei Wegen, die genannt werden, wenn Graphite in die Knie geht, der zweite wäre mehr Performance aka SSD, der dritte wäre auf eine performantere Software zu wechseln).
OptIn im Konfigurationsmodus des Knoten:
Beim letzten Treffen hieß es, das wäre super easy, da gäbe es passende Module für. Super esay, ok. Passende Module, habe ich nicht gefunden. Einen weiteren Eintrag ins die Konfigurations-Weboberfläche zu zaubern geht einfach, neues Modul erstellen, z. B. auf Basis des gluon-config-mode-geolocation Moduls (als Vorlage). Problem ist, dass diese Werte auch über respondd bzw. alfred rausgehauen werden müssen. Es gibt wohl das Modul gluon-respondd, was genau dafür verantwortlich ist oder zumindest dafür die erforderlichen Daten für nodeinfo / datatype 158 zusammenzusammeln. Das Ganze ist recht hardcoded, d. h. es werden nicht einfach alle Einträge gesendet, die sich unterhalb von gluon-node-info in der config befinden. Dieses Modul müsste entsprechend angepasst werden, auch das ist super easy. ABER: Es wird halt ein weiteres Modul angefasst. Was denkt unser Firmware-Buameister-Team aka @MPW @Alucardo darüber?
Habe ich etwas vergessen? Ich hoffe nicht! Euer Feedback bitte. Danke. 