Freut mich, dass langsam von Alfred weg migriert wird. Das öffnet auch die Türen für alternative Meshing-Protokolle.
Der gluon-collector ist übrigens tatsächlich dafür ausgelegt aus ganz unterschiedlichen Quellen Infos sammeln zu können. Weitere Listener lassen sich recht einfach implementieren (was auch schon in vorbereitung ist).
Bald gibt es übrigens auch eine recht einfache ansible-Rolle, die die Installation für ansible-nutzende Communities noch einfacher machen sollte.
4 „Gefällt mir“
Wie sieht es aus mit OLSR als Quelle?
Afaik OLSR ist ein Routingprotokoll. Es spricht also nichts dagegen announced (oder einen Nachfolger) darüber laufen zu lassen. Aber Infos selber wird das eher nicht übermitteln. Man könnte aber mit einem passenden Agent Infos wie Linkqualität, Nachbarn etc. aus OLSR rausholen und in den gluon-collector schmeißen.
Doch, bei OLSR hat jeder Knoten eine Gesamtübersicht des Netzes und es werden weitere Informationen z.B. über interne Services vermittelt (wie genau weiß ich auch nicht, könnte auch ein zusätzliches Programm sein). Aus der kann man Daten für den Meshviewer generieren.
Hast du die Prometheus anbindung an Grafana geschafft? Ich bekomme den Fehler hier:
Unknown error
Cannot read property ‚message‘ of null
Das ist die Ausgabe:
http://5.9.174.75:8080/metrics
Das was du geschickt hast war der output von node-informant und der input für prometheus. Du musst zuerst Prometheus installieren und in der Konfiguration die http://5.9.174.75:8080/ als Quelle eintragen (standardmäßig hat Prometheus sich selbst als Quelle also http://localhost:9090/)
Ich schreibe bald™ einen Wiki-Artikel oder so
2 „Gefällt mir“
Kannst du mir deine Prometheus Config Datei zukommen lassen?
root@gl1 ~# cat /opt/prometheus-0.16.1.linux-amd64/prometheus.yml
global:
scrape_interval: 15s # By default, scrape targets every 15 seconds.
evaluation_interval: 15s # By default, scrape targets every 15 seconds.
# scrape_timeout is set to the global default (10s).
# Attach these labels to any time series or alerts when communicating with
# external systems (federation, remote storage, Alertmanager).
external_labels:
monitor: 'codelab-monitor'
# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'freifunk'
# Override the global default and scrape targets from this job every 5 seconds.
scrape_interval: 20s
scrape_timeout: 10s
target_groups:
- targets: ['localhost:8080']
Eine Kleinigkeit ist mir noch aufgefallen, die Metriken werden nur mit dem Label „nodeid“ bereitgestellt.
Sinnvoller wäre zusätzlich noch der Hostname sowie der Site-Code. Wir nutzen in Düsseldorf Grafana mit templating im Dashboard. Dort kann man seinen Router momentan einfach anhand des Hostnames in einem Drop-Down Menu auswählen.
Die Node-ID merkt sich leider keiner 
Moin,
über ähnliches hatte ich mit @dereulenspiegel schon mal gesprochen. Derzeit können ja mehrere Instanzen angegeben werden, die dann zusammen verarbeitet werden. Schön wäre jetzt noch das automatische „splitten“ der Daten, um die Daten auch pro Community bereit zu stellen. Da wäre deine Idee mit dem site-code im Prinzip schon die Lösung für die Graphen.
Gruß
Chrisno
Naja der Site-Code ist mir nicht ganz so wichtig wie die Hostnames. Den Split mit eigenem Job hab ich auch schon vorgenommen 
Aber so kann halt kein templated Dashboard genutzt werden.
Außerdem habe ich gemerkt das Announced noch schlechter performt als Alfred :(. Aber das mag mit den momentan schlechten Verbindungen zwischen den Gateways zusammenhängen.
Ich überlege gerade den gluon-collector auf beiden Gateways auszuführen und mittels ebtables die Multicast UDP Pakete nur über fastd/l2tp zu den Clients zu schicken. So wird nicht unnötig der Batbone Link zwischen den Supernodes verwendet.
Das „Problem“ bei announced ist tatsächlich, dass es grundsätzlich per multicast läuft. Hat man also Probleme Nutzdaten in seinem Mesh zu transportieren merkt man das recht stark an announced. Das wird mit anderen Lösung, die „routingprotokoll-agnostisch“ sind aber nicht anders werden.
Was multicast-Routing etc. angeht gibt es sicher noch Möglichkeiten die Performance von announced zu verbessern. Im gluon-collector sind die Möglichkeiten leider begrenzt, da ich im Prinzip nicht anderes mache als Pakete auf die Reise zu schicken und auf Antwort zu warten. Ich versuche das multicast-Problem in soweit abzufangen, dass potentiell unerreichbare Nodes (sofern sie einmal bekannt sind), per unicast abgefragt werden. Aber das bringt nur begrenzt viel.
Ich habe im Projekt node-informant mal ein Issue für den Wunsch nach Hostnames eröffnet (Export human readable node names to prometheus · Issue #9 · ffdo/node-informant · GitHub). Allerdings gefällt mir die Lösung nicht. Die Hostnames der Nodes müssen nicht zwingend einzigartig sein, was sie zu schlechten Schlüsseln macht und Statistiken für Nodes, die noch nicht in der Datenbank sind, müssen aktuell verworfen werden.
Meiner Meinung macht es eher Sinn das Mapping Node-ID → Hostname auf einer anderen Ebene zu machen. Der gluon-collector sollte sich keine Sorgen um Hostnames machen müssen. Leider weiß ich aktuell auch zu wenig über Grafana und Prometheus um jetzt eine gute Idee zu haben wie man das dort am elegantesten löst.
Naja Label müssen ja keine Keys sein, ein Label kann auch zusätzlich vergeben werden wenn ich das richtig verstanden habe. Zumindest habe ich das bei InfluxDB so gelöst, der Hauptkey ist dort die NodeID und es gibt zusätzliche Felder wie den Hostname oder auch Site-Code.
Edit:
Ich habe noch mal in der Prometheus Doku nachgeschaut:
Every time series is uniquely identified by its metric name and a set of key-value pairs, also known as labels.
Also scheint es wirklich so zu sein das man mehrere Label pro Metrik angeben kann 
Wäre also nur ein weiteres Feld und sollte leicht einzubauen sein.
Implementiert habe ich das in einem Branch ja bereits so (siehe Github-Issue). Es ist also möglich, hat aber einige imho sehr schwer gewichtige Nachteile:
- Der Hostname wird Teil des Keys, und da der Hostname nicht eindeutig ist, und pro Node einfach gewechselt werden kann, sind die Metriken auch nicht mehr zwingend eindeutig pro Node. Wechselt eine Node z.B. ihren Hostname gibt es einen neuen Satz Metriken, obwohl die Node die gleiche ist.
- Die Erfahrung zeigt, dass die BATMAN-adv basierten Netze in Teilbereichen einen recht hohen Packetloss haben. Dadurch passiert es öfter, dass zwar Statistik-Pakete ankommen (weil diese oft angefordert werden), aber die Nodeinfos länger auf sich warten lassen. Es würden also Daten verloren gehen.
- Sitecode, Hostname etc als Label sind nichts was ich hard coden möchte, da es nicht alle Communities in der Form brauchen. Da brauchen wir wenn also eine eher flexible Implementierung.
Hmm also ich würde Metriken ohne NodeInfo ohnehin verwerfen, das die beiden Sachen getrennt sind halte ich ohnehin für unnötig. Grafana und Co können nur die Labels verwenden um die Daten sortiert anzuzeigen. Alias-Files oder ähnliches sind nicht möglich und wir sollten uns nicht von Standard-Implmentierungen entfernen. Die Labels sind nun mal dafür da um eine gewisse Granularität bei der Speicherung der Daten zu gewährleisten. Ansonsten brauche ich kein Prometheus und kann die Daten in einer SQLite DB oder ähnlichem speichern. 
Das bei einer Hostnameänderung neue Metriken geschrieben werde halte ich sogar für sinnvoll. Wenn ich eine Node umziehe und den Namen ändere, möchte ich die alten Metriken ohnehin nicht mehr haben da diese nichts mehr mit dem neuen Standort zu tun haben. Natürlich kann es auch den Fall geben das eine Person die Node nur falsch benannt hat, aber irgendwo wird man sicher nicht um einen Kompromiss herumkommen.
Was das Problem des Packetloss angeht, ich bastele gerade an einer modifizierten Status-Page welche die Nodeinfo sowie Statistiken als Json via HTTP anbietet. Dann können wir UDP Multicast nur noch für die Node-Discovery verwenden und die eigentlichen Daten zuverlässig via HTTP abrufen.
Ich mache das ganze gerade konfigurierbar, zumindest auf einer einfachen Ebene. Dann kann man das Feature nach Wunsch aus, oder auch einschalten.
Die Statuspage brauchen wir imho dafür nicht. Zum sammeln von Metriken möchtest du ganz sicher nichts TCP-basiertes haben und noch viel weniger etwas mit so viel Overhead und Komplexität wie HTTP. Aktuell arbeite ich im Hintergrund an einem Receiver für CoAP und danach mache ich mich an die Clientseite (es sei denn jemand möchte das parallel tun).
Normalerweise würde ich dir was TCP angeht beipflichten, allerdings ist UDP für das meiste nicht nutzbar.
DHCP funktioniert selten zuverlässig weiter als 3-4 Hops, das gleiche gilt in diesem Fall für Metriken via UDP.
TCP basiert ist in diesem Fall wohl die einzige Wahl wenn man nicht bei jedem zweiten Abfragen der Daten nichts zurück bekommen möchte.
HTTP wäre in diesen Fall nur einfacher umzusetzen da wir schon einen Webserver auf den Nodes haben, ich würde auch eher was einfaches bevorzugen.