So, auf der Detailseite Backbone gibt es jetzt wie versprochen entsprechende Daten zu sehen:
https://freifunk-muensterland.de/grafana/dashboard/db/backbone-details?panelId=27&fullscreen
Zukünftig will ich die auszulesenden Werte direkt in der collectd.conf angeben lassen, so ist das ganze dann einfach erweiterbar auf beliebige werte von sysctl. Ist aber noch nicht eingebaut, derzeit müssen diese Werte im pythonscript angegeben werden.
@paulinsche
Ich arbeite aktuell daran wieder ein icinga Monitoring sauber aufzusetzen, und zwar so dass es entsprechend in das gesamtkonzept eingebunden ist.
Insbesondere eine saubere Integration in das deployment per ansible ist dabei wichtig damit wir auch langfristig eine saubere Struktur haben.
Wenn du schon mal weitere Kennzahlen wie in dem Post oben mit entsprechenden Schwellwerten zusammensammeln kannst hilft mir das dabei.
Also gerne mehr davon.
Hier und da ein Raspberry, der sich ins Netz einbucht, eine IP bezieht und ein wget auf eine Gegenstelle absetzt.Wann immer das nicht performant klappt, ist was im Busch.
Alle die ihr Netz im Auge haben sollten bei sich so ein Teil hinstellen. Die Burse wäre so ein Kandidat, oder?
@paulinsche Warum geht das nicht anders herum? Kann nicht einfach der Server auf quasi alle Knoten mal einen Ping absetzten und ggf. andere SachenTM machen, um zu sehen dass der Knoten noch da und sauber läuft.
Ich denke, dass bei wachsendem Netz eine Überwachung Serverseitig besser ist als noch zusätzliche Geräte verteilen zu müssen. Oder wir sollten irgendwas (z.B. Script) in die FF-Firmeware einbacken die dass dann automatisch macht und an den Server “meldet”?! Geht doch vielleicht.
Darüber hab ich auch schon für die von mir „verwalteten“ Knoten nachgedacht… Quasie ein Script das alle paar Minuten ein wget gegen eine API absetzt z.B.
http://xyz.xy/api.php?hostname=Knoten-01&ram=80&cpu=0.5 oder ähnlich…
Der Server hinter der API könnte dann auswerten wann kam der Letzte Aufruf von Knoten-01 und ist das Zeitfenster zwischen den aufrufen um X überschritten dann mache dies das jenes…
Jedoch ist mir noch nicht ganz klar was, wie und wann in der Firmware update-sicher ist…
Andere Möglichkeit währe von einem Server eine SSH Verbindung zu dem Knoten aufzubauen und ihm die Anweisung ein wget auszuführen via SSH zukommen lässt oder sowas in der Richtung. Diese Lösung ist vlt für 10-20 Knoten machbar und handhabbar aber wohl ehr nicht für 2000+ Knoten…
Ne eigentlich nicht, denn dann bräuchtest Du einen SSH Schlüssel auf allen Knoten und damit könnte jemand der den Schlüssel hat auf alle (privaten) Netzwerke zugreifen.
korrekt… Denkfehler…
Vom Server kannst die Knoten und damit ipv6 testen. DHCPv4 und damit routing und DNS eher nicht. Das ja das häufigste Problem.
Wir haben z. B. Knoten, die auch pingbar sind, aber die keine Standardroute haben. Die sind dann immerhalb des Netzes pingbar, aber nicht aus dem Internet. Dann ist z. B. IPV6 kaputt.
Und wie @paulinsche richtig sagte, können wir IPV4, was eigentlich das Hauptproblem ist, nicht richtig mit den Knoten testen. Daher ist so ein Testgerät gar nicht schlecht.
Dann lass unsTM ein Image für einen Raspi bauen, den jeder aufsetzen kann bzw. den wir als Standardgerät “vertreiben” können.
Ich hab einen alten Raspi rum liegen, den ich dann so flashen würde. Programmieren kann ich das allerdings nicht. 
Das Gerät soll sich als Client verhalten. Also Debian drauf, WLAN-Modul dran, optimaler Weise auch per LAN verbinden, und dann kann man testen.
@mpw, klar kann ich machen. Wie bringe ich debian drauf (das ist son Linux Derivat, wa 
)? Was soll das Ding dann machen? Mit nur einem OS wird ja nix getestet.
Du siehst meine Ahnungslosigkeit. 
Ich hab nur versucht zu erklären, worum es geht. Debian auf dem Raspberry heißt Raspian und ist quasi das Standardbetriebssystem. Das ist schnell gemacht. Die Frage ist, was wir dann genau damit machen?
@void und @wurmi bauen am Monitoring, eventuell haben die eine Idee, wie man das ins Icinga einbauen könnte?
Grüße
Matthias
Man kann mit Icinga z.b. eine IP von einem haupt System aus überwachen,
wenn man eine zweite sicht aus einem anderen Provider Netz haben will kann man dort auch icinga laufen lassen und dieses vom haupt System abfragen damit alle Ergebnisse in einem System liegen.
Ohne nachgeschaut zu haben behaupte ich mal dies in der icinga Dokumentation im Netz gesehen zu haben.
Hi,
ich würde würde Dir helfen bzw. es zeigen, wenn Du das möchtest?
aber auch schönes Beispiel ist hier:
Gruß
Nicklas
Danke fürs Angebot. Naja die Installation würde ich mit der Anleitung hin bekommen, aber was macht man dann mit dem OS? Son fertiges “Image drauf und Freifunktestgerät ist fertig für Plug-and-Play” wäre auch für andere was feines, oder?!
Hi,
ich bin mir nicht ganz sicher wo jetzt die „Reise“ mit dem Monitoring hingehen soll und was Deine/Unsere Anforderungen sind, aber grunzsätlich hast Du Recht.
Gruß
Nicklas
Prinzipiell sollten wir auch die Frage „Gluon oder nicht Gluon“ (oder Batman oder nicht Batman) diskutieren. Das sind ja noch mal zwei Sichten auf das Netz. Einmal als „Router“ und einmal als Client.
Ich hatte eine Zeitlang collectd auf meinen Knoten laufen, und habe damit u. a. Pings auf diverse Ziele abgefeuert. icinga sollte es auch für gluon/openWRT geben. Ist dann halt nicht mehr updatesicher. Aber man könnte ja auch einen raspi nehmen.
Das ist halt dann die Sicht als Router und nicht als Client.
Kann man das nicht mit „einbacken“? völligAhnungslos
Ich tendiere ganz klar zu einem vollständigen Raspbian, da wir wissen wollen, ob die Clients im Netz eine Verbindung haben. Die Router können wir auch direkt über IPV6 überwachen.