„nur alfred verwendet“ bedeutet
„site.mk der Domain-Firmware explit ohne ‚gluon-announced‘(2015.x), respektive ohne ‚gluon-respondd‘(2016.x)“?
Dann geht’s natürlich nicht so einfach.
(Wenn der bisherige Kartenserver einer Domain auf Alfred-Daten beruhte: Schadet nicht, die Knoten liefern auf beiden Kanälen Daten, wenn man sie freundlich darum bittet…)
genau so war es auch gemeint
Das ist natürlich ärgerlich. Denn der Vorteil des hopglass-Backends ist, dass er nicht willkürlich Knoten als „Offline“ markiert, nur weil zwei Minuten lang kein UDP/Broadcast via Alfred hineingekommen ist. Der fasst da aktiv nochmal nach, bevor er Knoten als „Offline“ stempelt. (Das reduziert die unbeliebten „Fehlalarme“ deutlich. Soll hier aber eigentlich gar nicht Thema sein)
mit dem hopglass Backend habe ich schlechte Erfahrungen gemacht, daher bin ich davon wieder weg zu alfred.
wie gehst du bei deiner Idee damit um, wenn bat14 und bat15 in den Domänen verwendet wird?
Da haben wir getrennte hosts die batman-versionen.
Und bridgen „von batman14-vm“ dann via vmbr zum Kartenserver (der die bat15-domains selbst direkt macht).
Ist zugegebenermaßen auch etwas umständlich, aber man muss wenigstens nicht hinter Datenformaten gärtnern.
Genauer? Noch was anderes as dass es keinen Alfred-Support gibt und bat14+bat15 nicht ohne Weiteres auf einem Server laufen kann (woran btw auch Alfred nichts ändert)?
2 Server jeder mit dem HopGlass Server, in der config.json beide als Datenquelle angeben. Die Dateien werden on the fly gemerged.
Alfred support ist geplant. Es macht nur alles viel komplizierter.
ja, was anderes: es ist mir zu träge && die Prometheus Metrics gefallen mir nicht.
Da ich node.js aber allzu grässlich finde mag ich mich dort auch nicht einlesen.
keine schlechte idee
InfluxDB ist in Arbeit, Graphite bräuchte ich mal einen Überblick wie das funktioniert…
hehe nice … ja ich hatte es in einer anderen Domäne im Einsatz. 