Also ich hätte interesse das über icinga zu realisieren.
Muss aber sagen das ich damit auch noch nicht so viel gemacht habe.
4 „Gefällt mir“
Was brauchst du, damit du loslegen kannst?
Werde es erstmal zuhause aufsetzen um mich damit genauer zu beschäftigen.
Wenn dann etwas brauchbares fertig ist melde ich mich.
Glaub das gilt hier für fast jeden, der irgendwas anfängt. Such dir ein System aus, sag uns was du brauchst und dann kriegst du die Infos und Ressourcen. Wäre echt super, wenn du dich damit beschäftigst, glaub das derzeitige Team wird da auf absehbare Zeit keine Zeit für haben.
Grüße
Matthias
Ich habe früher Fussball gespielt. War auch nur ein Hobby. Verlieren hat deswegen trotzdem kein Spass gemacht. Jedes Mal wenn der Zugang zum Internet via Freifunk nicht tut, kassieren wir ein Tor. Und wenn wir Eigentore schießen, und der wiederholte Überlauf der conntrack Tabelle ist ein Eigentor, dann ist das besonders schmerzlich. Wenn wir das Spiel gewinnen wollen, dann müssen wir das abstellen. Hobby hin oder her.
7 „Gefällt mir“
@paulinsche erinnerst du dich, worauf der Wert stand, bevor du ihn erhöht hast? Dann kann ich nämlich entweder die Rolle anpassen oder auf Fehlerhaftigkeit prüfen.
Ich habe den Wert nicht geändert, sondern nur die Tabelle gelöscht. Dazu habe ich conntrack installiert. Das Paket sollte überall installiert sein. Ich glaube -F ist dann die richtige Option um zu flushen.
Ich werde gleich mal den count und den max mit collectd erfassen und so ins Graphite schmeißen. Der Grenzwert wird ja nicht von jetzt auf gleich überschritten, dann sehe ich es das nächste mal, bis unser “echtes” monitoring bis dahin noch nicht steht.
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.
1 „Gefällt mir“
@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.
3 „Gefällt mir“
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?
2 „Gefällt mir“
@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.
1 „Gefällt mir“
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. 
1 „Gefällt mir“
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.