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.
Ich bin mir sicher, dass TCP wesentlich mehr Probleme machen wird als CoAP. Das schöne an CoAP ist, dass es sich recht einfach auf HTTP mappen lässt, sehr wenig Overhead hat und auch ein gewissen Maß an Transport Control mitbringt, ohne aber einen ekligen 3-Way-Handshake etc.
Im Prinzip haben wir hier ein recht klassisches Problem aus dem IoT-Bereich. Wenn wir schon was neues bauen, dann auch etwas was auf das Problem zugeschnitten ist und nicht wieder eine „Quick-and-Dirty“-Lösung. Das war für mich auch der ganze Grund den gluon-collector zur starten. Denn Alfred ist stark von BATMAN abhängig und BATMAN müssen wir abschaffen wenn wir weiter skalieren wollen. Außerdem sind Formate, Protokolle etc. schlecht bis gar nicht dokumentiert, nicht auf das Problem zugeschnitten und funktionieren auch eher so mittelprächtig. Aber aktuell funktionieren sie. Daher haben wir jetzt erstmal etwas Luft es besser zu machen.
Wir haben nunmal Mesh-Netzwerke, bei denen Routenqualität, Packet-Loss etc. sehr durchwachsen sein können. TCP funktioniert in solche Umständen nie zuverlässig genug. Mit UDP-basierten Protokollen bekommst du wesentlich mehr Kontrolle über Retransmissionverhalten etc. um intelligenter auf schlechte Netze reagieren zu können. Google quic-Protokoll basiert übrigens aus ähnlichen Gründen auf UDP und nicht auf TCP.
Nun es ging mir in diesem Fall hauptsächlich darum das momentan Problem etwas in den Griff zu bekommen. Das TCP bzw HTTP nicht bevorzugt ist, ist mir schon klar. Dennoch würde ich es als zusätzliches Feature anbieten, so das man aus mehreren Methoden wählen kann um die Daten abzurufen.
Für CoAP hab ich leider nichts gefunden was direkt out of the Box auf den Nodes zu verwenden ist, hier muss wohl selbst was mit libcoap geschrieben werden.
Ich kompiliere später mal libcoap mit den Examples um zu sehen wie das so strukturiert ist, leider bin ich nicht so der Fan von C und werde da wohl nicht bei helfen können dies zu implementieren.
Sinnvoll wäre ein mit Lua-Scripts erweiterbarer Daemon, so das man einfach neue Metriken hinzufügen kann.
Einen Fallback auf UDP-Unicast habe ich bereits implementiert. Jede Node die offline geht, wird zusätzlich nochmal per UDP-Unicast abgefragt. Da gehen dann genau zwei Pakete hin und her. Bei TCP wären es mindestens 5. Und wenn eines von den beiden verloren geht, passiert auch erstmal nichts, bis zur nächsten Abfrage.
Ich kann verstehen, dass C nicht so der bringer ist kann ich verstehen, bin ich auch kein großer Freund von. Andererseits sehe ich gerade wie respondd implementiert ist und das würde ich auch gerne vermeiden. Das Ding ist eine einzige große Sicherheitslücke. Wenn man also das sammeln der Metriken an Lua delegiert, dann muss das zumindest bedeutend sicherer implementiert sein.
Bezüglich der Labels an den Prometheus-Metriken habe ich das ganze jetzt mal konfigurierbar gemacht (GitHub - ffdo/node-informant at prometheus-node-names). Wenn das so passt, mache ich einen Pull Request, Merge und schließe das Issue.
Ja das sollte natürlich sicher gemacht werden 
Die Script-Funktionalität ist auf jeden Fall notwendig damit wir die Metriken nicht hardcoded haben. Gerade wegen der Gluon Pakete die neue Metriken hinzufügen. Wobei es praktisch wäre wenn wir kompatibel zu den Scripts von respondd bleiben, diese sollten nicht doppelt implementiert werden müssen.
Das sollte machbar sein. Aber andererseits ist das Format, dass diese Scripte ausgeben eher nicht optimal. Im Prinzip sammeln wir gerade drei Arten von Metriken:
- Statische Infos wie Hostname, Location, Sitecode, Modell etc.
- Periodische Infos wie Traffic, Speicherverbrauch, Uptime etc.
- Dynamische sich schnell ändernde Metriken wie Client-Anzahl, Mesh-Neighbours etc.
Ich stelle mir vor, dass sich Nodes in Zukunft beim Boot mit den statischen Infos am gluon-collector melden, dann regelmäßig (z.b. alle 1,2 oder 5 Minuten) Infos wie die Uptime, Traffic etc. senden. Und Informationen über Mesh-Neighbours, Clients etc. bei jeder Änderung gesetzt (evtl. mit Cooldown von ein paar Sekunden) gesendet werden. Dadurch verbrauchen wir weniger Traffic als jetzt und haben trotzdem aktuellere Infos.
Gude,
hab das tool jetzt mal auf meinem Server installiert und es läuft auch soweit solange ich die Shell Session offen habe.
Gibts es von euch einen guten Weg den irgendwie als Daemon laufen zu lassen?
Kann man mittlerweile die Gateways auch ihre eigenen Daten senden lassen?
Gruß
Fabian
Hi Fabian,
ob Dienste dämonisieren sollten oder nicht ist in der golang-Welt (und auch woanders) recht umstritten. Aktuell sieht es so aus, dass es keinen imho wirklich schönen Weg gibt golang-basierte Dienste zu dämonisieren. Das ist aber auch nicht schlimm. Moderne Prozessmanager wie Systemd, Upstart, supervisor etc. können sehr gut mit nicht-damönisierenden Diensten umgehen.
Für Supernodes wird an einer Lösung gearbeitet, aber das geht von meiner Seite aus erst weiter wenn ich wieder aus dem Urlaub zurück bin. Bei Neugier kannst du aber gerne schonmal in den Branch supernode gucken. Gibt zwar noch keine Doku, aber mit etwas arbeit sollte man da schon was brauchbares laufen lassen können.
Grüße,
Till
Moin Till,
schau ich mir mal an vielleicht bekomm ich das zum laufen.
Gruß
PetaByteBoy hat die Karte auf http://map.ffdus.de auf collectd/prometheus/grafana umgestellt.
Das scheint wirklich gut zu funktionieren, auch mit den darüber gerenderten Stat-PNGs.
2 „Gefällt mir“
Die per grafana serverseitig gerenderten Graphen im MV sind auch nur eine Zwischenlösung. Ich habe schon versucht, die Graphen aus Graphana per iframe einzubinden, aber das lädt auch alle Abhängigkeiten wie Angular, die die Ladezeiten ins Astronomische treiben.
Auf Dauer möchte ich die Graphen über eine Library names Flot im MV rendern. Flot deshalb, weil das auch Graphana nutzt. Alternative wäre d3, was schon im MV genutzt wird für die Physik und das Rendern des Graphen.