Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[MartinP]

Durch ein kaputtes LAN-Kabel ist die LAN Geschwindigkeit meines Mini-PC seit unbekannter Zeit auf 100 MBit/s gewesen. Das ist ärgerlich, und soll nicht wieder vorkommen - deshalb soll eine Überwachung her...

Gibt es eine Möglichkeit, das irgendwie einfach zu Überwachen, oder wäre der Weg über Cronjob und Simple Api das gefilterte Ergebnis von

ethtool enp5s0

in Userdata Datenpunkte zu schreiben die einfachste Möglichkeit?

[hahne]

@martinp
Bin mir nicht sicher , aber vllt. hilft dir der Linux Adapter Klick weiter.

Dort kann man eigene Commands als Datenpunkte speichern. So hab ich es z.B. mit der Servertemperatur (CPU) gemacht.

[BananaJoe]

@martinp Alternativ: ist der Switch an dem die Büchse hängt managebar? Dann könntest du den per SNMP abfragen

[David G.]

@martinp

Mit Linuxcontrol und dem Befehl

sudo ethtool enp5s0 | grep "Speed" | awk '{print $2}'

wäre easy.

[hahne]

sudo ethtool eno1 | grep Speed

gibt bei mir den Passenden Wert aus.
eno1 muss dann bei dir durch den namen der Karte ersetzt werden.

[MartinP]

@hahne Die Handhabung scheint mir etwas eingeschränkt ...

Habe aber nur 15 Minuten rumgeklickert mit dem Adapter ...

Selbst-Definierte Datenpunkte (Was Network-Speed wohl wäre) kann man nur relativ eingeschränkt definieren ...

[David G.]

@martinp

Du kannst mit dem Adapter ALLES abfragen.
Füg meinen Befehl bei den eigenen befehlen hinzu und du erhältst einen DP mit dem Ergebnis.

Ich frage Festplatten, Ram, CPU, Temperatur etc ab.
Selbst den Staus von Docker Containern.

[MartinP]

@david-g Natürlich ist die Sache etwas eingeschränkt ... Ein Befehl kann immer nur einen Datenpunkt beeinflussen.
Hier passt es aber...

Wenn es kompliziert wird, kann man ja auf dem belauschten System ein Script aufrufen, was dann per SimpleApi einen ganzen Batzen von Datenpunkten aktualisiert..

Wenn man sich durch mehrere Smartmontool Aufrufe die Festplattengesundheitsparameter zusammenklaubt, ist das overkill...

[David G.]

@martinp

Ja, manchmal ist da was gebastel möglich.
Bei den Docker Sachen baue ich mir eine Json in dem Befehl zusammen wo ich alles mit Abfrage.

[MartinP]

@david-g Das heißt, im Datenpunkt liegt das Json, das man mit iobroker Bordmitteln auseinanderfieseln muss...

Naja, einem Tod muss man sterben ;-)

[MartinP]

@david-g Ich finde den Adapter gefährlich...

Wenn man die Settings aus dem "Lieferzustand" belässt, sorgt der auf meinem PVE alle 5 Minuten für einen Anstieg der Prozessorlast um 30 % für ca 2 Minuten ...

https://forum.iobroker.net/topic/77590/proxmox-top-ranglist-apt-get-ist-dabei/10?_=1729527453087

Da muss man wirklich mit gespitzem Bleistift erstmal die Einstellungen "einkürzen", wenn man ein schwaches System hat, wie ich ...

Alle 5 Minuten ein apt-get update .... was soll das?

[David G.]

@martinp

Man kann den Intervall ja verändern und wie gesagt auch gewisse Optionen deaktivieren.

Da muss jeder seinen Mittelweg finden.
CPU und RAM am liebstes sekündlich. Auf Updates prüfen einmal am Tag.

[MartinP]

@david-g sagte in Proxmox Basissystem: LAN-Speed überwachen:

CPU und RAM am liebstes sekündlich. Auf Updates prüfen einmal am Tag.

Hmm... Das Polling-Interval lässt sich aber zwar individuell für jedem Server einstellen, aber auf dem Server unterschiedliche Domänen (Updates, Ressourcen, usw) unterschiedlich zu pollen ist nicht möglich ...

Jedenfalls war das Ding, solange es lief mit den Voreinstellungen für einen deutlich sichtbaren Anteil der Serverlast auf meinen schmalbrüstigen PVE System verantwortlich ...

[David G.]

@martinp

So sieht es bei mir aus.
Angefragt werden 9 Maschinen alle 5min und ca 30 eigene Befehle alle 5min.

Gegen 22 Uhr hab ich den Adapter mal testweise abgeschaltet.

[MartinP]

@david-g das kommt natürlich auf den Wumms des Basissystems an... Der N3000 erreicht kaum die Performance eines Pi4.

Da kann man nicht nach der Devise "wird schon passen" verfahren...

Sind das alles Maschinen auf einer Virtualisierungsplattform?
Vom Arbeitsauftäge verteilen alleine kommt man nicht ins Schwitzen....

[David G.]

@martinp

Alles auf einem proxmox System.
Ist aber auch ein i3 12100.

[MartinP]

@david-g sagte in Proxmox Basissystem: LAN-Speed überwachen:

i3 12100.

Deine CPU ist um den Faktor 23 schneller als mein N3000 ....
Selbst der SoC des Pi4 ist ca um Faktor 1,4 schneller,als mein lahmer N3000 ...

OFFTOPIC: Die 60 Watt TDP sind zwar erstmal beängstigend, aber die werden im Homeserver-Betrieb wahrscheinlich nur selten ausgereizt (außer man lässt die Bewegungserkennung von Überwachungskameras durch die CPU "rechnen"), trotzdem die Frage: Was schluckt Dein System pro Tag an Strom? Das letzte Mal, als ich den Gigabyle N3000 "Nuc" alleine gemessen habe, waren es 0,116 kWh pro Tag...

Noch ein Nachtrag...

Ich habe das Intervall aller Server weiter auf 5 Minuten gelassen...

inux-control.0
	2024-10-22 14:00:56.363	info	getting data from proxmox (192.168.2.200:22)
linux-control.0
	2024-10-22 14:00:56.777	info	successful received data from proxmox (192.168.2.200:22)
linux-control.0
	2024-10-22 14:01:05.661	info	getting data from frigate (192.168.2.196:22)
linux-control.0
	2024-10-22 14:01:06.380	info	successful received data from frigate (192.168.2.196:22)
linux-control.0
	2024-10-22 14:01:17.716	info	getting data from docker (192.168.2.146:22)
linux-control.0
	2024-10-22 14:01:18.598	info	successful received data from docker (192.168.2.146:22)
linux-control.0
	2024-10-22 14:01:30.702	info	getting data from iobroker (192.168.2.201:22)
linux-control.0
	2024-10-22 14:01:31.356	info	successful received data from iobroker (192.168.2.201:22)
linux-control.0
	2024-10-22 14:03:34.968	info	getting data from debian (192.168.2.164:22)
linux-control.0
	2024-10-22 14:03:36.068	info	successful received data from debian (192.168.2.164:22)
linux-control.0
	2024-10-22 14:05:56.779	info	getting data from proxmox (192.168.2.200:22)
linux-control.0
	2024-10-22 14:05:57.312	info	successful received data from proxmox (192.168.2.200:22)

Mir scheint, die Abarbeitung des Zeitplans ist nicht sehr systematisch, bis auf die Einhaltung des individuellen Intervalls für jeden einzelnen Server ...
Dadurch ergaben sich schon recht hektische Lastspitzen ...