Collectd scheint mir sehr effizient, modular und durch sein exec plugin auch leicht erweiterbar.
Die Daten werden per UDP in binary format an einen Server geschickt.
Bei uns ist ein bisschen die Diskussion aufgekommen, ob wir nicht wechseln wollen.
Prometheus hat für mich das problem, dass wir alle nodes aktiv durchpollen müssten, was wir vll aber auch mit einem push-gateway umgehen könnten? Auch scheint mir das human-readable format für jeden einzelnen counter ein bisschen übertrieben und overhead lastig.
Ich finde die C-API von collectd auch gar nicht so schlimm, da man sich da halt nur ein bisschen reinarbeiten muss, wie man Plugins hinzufügt und schreibt. Leider muss man direkt 2 Plugins schreiben, da noch die luci-statistics app hinzukommt. Z.B. hab ich letztents endlich mal die dhcpleases hinzugefügt:
Die Serverseite ist aus heutiger Sicht ein frickeliges Zusammenspiel verschiedener Tools, was an sich ja Unix-Style wäre — aber ich zumindest hab’ mir damit einmal zuviel die Pfoten verbrannt. Der Prometheus-Ansatz gefällt mir da, u. a. wg. Pull start Push und nur ein Tool, deutlich besser.
Aber das Pull statt Push Prinzip bringt bei unserem Netz unglaublich viele Probleme, da wir ein sehr loses Netz haben, wo wir z.b. kein vxlan oder so drüber werfen. Manchmal bauen wir ip-tunnel für Inseln.
Du kannst halt z.b. prometheus-node-exporter schreiben, wie ich das auch schon gemacht habe, aber am Ende kannst du das nicht auf dem eig Node visualisieren? Und das binary + udp format hat halt sehr geringen overhead.
Push skaliert meines Erachtens auch schlecht(er), aber das war ja auch gar nicht die Frage. Klar, der Multicastansatz zur Abfrage der Daten skaliert auch eher schlecht, in chaotischen/hierarchischen Netzen mangels Broadcast gar nicht. War aber auch nicht Teil der Ursprungsfrage. Mangels Vertrauen in die Serverseite collectds kann ich dazu auch nicht mehr sagen; vermutlich ist es ganz toll und skaliert wie das Universum — ich halte halt aus meiner Erfahrung halt nichts von collectd.
Pull „von IP“ erzeugt bei „nicht im Netz auffindbaren Knoten“ in einem Layer2-Netz ziemlich bösen Arp-Traffic.
Wenn man Pull macht, dann sollte man in einem Batman-Netz zunächst schauen, ob der Knoten überhaupt in der Batman-Transglobal derzeit im Netz ist.
(Leute, die zusätzliche Firmwareserver auf IPv6-Adressen „auf Vorrat“ im Internen Netz gelegt haben in der Routerconfig, die haben sich mit ARP-Wellen einen Blackout gebaut in der Vergangenheit)
Für so ein „Vor Pull vom Knoten erstmal netzlastfrei schauen, ob er auch im Layer2-Netz aktuell ist“:
Dafür muss irgendeine Magie einen „neuen/frisch installierten“ Knoten überhaupt erstmal kennenlernen.
Problem: Für Neulinge eine weitere Statemachine, die die Lernkurve für den Einstieg nicht leichter macht, wenn mal etwas klemmt.
Wir hatten den Gedanken, dass mit Pulic IPv6 IPs die Sachen auch einfach gepulled werden können, enstprechend der Mesh-Informationen. Aber wir sind auch Layer 3 Netz.
ND, aber ja, ist ein latentes Problem. Für Push muß hingegen das Ziel entweder in der FW eingebacken sein oder zur Laufzeit konfiguriert werden können. Hat alles Vor- und Nachteile.
Im konkreten Fall (Freifunk-Netz) gibt es ja i. d. R. schon einen Inventarisierungsdienst: die Knotenkarte.
