Synology, SNMP, Sysstat - MIBS werden teilweise nicht ausgelesen

[Floriky]

Hallo Miteinander,

ich hab da mal eine Frage: Habe meine Synology per SYSSTAT in FHEM eingebunden. Bisher habe ich die folgenden Mibs eingetragen, welche auch alle funktionieren:

Code: [Auswählen]

.1.3.6.1.4.1.6574.2.1.1.6.0:temp_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.6.1:temp_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.6.2:temp_hdd3 ,.1.3.6.1.4.1.6574.2.1.1.5.0:state_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.5.1:state_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.5.2:state_hdd3 ,.1.3.6.1.4.1.6574.2.1.1.3.0:model_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.3.1:model_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.3.2:model_hdd3 ,.1.3.6.1.4.1.6574.2.1.1.4.0:type_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.4.1:type_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.4.2:type_hdd3

Sobald ich

Code: [Auswählen]

.1.3.6.1.4.1.6574.3.1.1.5.0:raid_total
dazufüge funktioniert keines mehr der bisherigen Readings.

Per snmpget ist der Abruf kein Problem. Da liefert er mir:

Code: [Auswählen]

pi@raspberrypi:~ $ snmpget -v2c -c GRUPPE 192.168.2.111 1.3.6.1.4.1.6574.3.1.1.5.0
iso.3.6.1.4.1.6574.3.1.1.5.0 = Counter64: 7928574496768
Kann mir da jemand weiterhelfen? Hab das Gefühl, dass ich irgendwas ganz simples übersehen habe (als wäre das schon mal vorgekommen )

Vielen Dank vorab an alle Lesenden und Helfenden!

[chaotrach]

Hab ein ähliches Problem sobald die readings Counter64 oder strings anstelle von INTERGER Werten ist

Edit: Tippfehler korrektur

[hen]

Hallo an alle,

gibt es hierzu bereits eine Lösung? Liegt es vielleicht am Modul SYSSTAT?

Ich habe genau das gleiche Problem. Die Information über die Raidgröße + was davon frei ist, ist schon eine relevante Zahl

Danke schon mal für die Antwort(en)!

[Ullulaki]

Ich stand gestern genau vor demselben Problem, habe jetzt aber nach mehrstundigem testen und snmpwalken endlich die Lösung gefunden :-)
Ihr müsst euch die veränderte Beta des Sysstat-Moduls herunterladen und in FHEM austauschen, zu finden hier:
https://forum.fhem.de/index.php/topic,42771.0.html

Dann kamen bei mir zuerst im Log folgende, sich wiederholende Fehler:

Code: [Auswählen]

2019.04.12 08:57:07 2: NAS: unanswered query in queue, reconnecting
2019.04.12 08:57:07 2: NAS: starting: /usr/bin/ssh -q 192.xxx.xxx.xxx die bekommt man mit dem attribut

Code: [Auswählen]

noSSH 1 weg, da hier standardmäßig versucht wird eine Verbinung per SSH aufzubauen.

Habe testweise gerade einmal den raid_total mib ausprobiert und der funktioniert einwandfrei, genauso wie alle readings die vorher nicht funktionierten :-)

Damit das Modul bei einem Update von FHEM nicht wieder überschrieben wird, einfach nach dem Austausch der Datei mit dem Befehl in der Kommandozeile ausklammern:

Code: [Auswählen]

attr global exclude_from_update 32_SYSSTAT.pm

[sinemeter]

Hallo zusammen,

Mein NAS ist von Qnap allerdings schaffe ich es nicht das attr für snmp zu setzen

Versuche ich:
attr qnas snmp 1
erhalte ich nur:
qnas: unknown attribute snmp. Type 'attr qnas ?' for a detailed list.

Hier meine Raw Definition.

Die benötigten Pakete auf raspi an Stretch für snmp habe ich meines Wissens nach alle installiert.


defmod qnas SYSSTAT 60 600 192.168.172.35
attr qnas DbLogExclude .*
attr qnas alias qnas
attr qnas room Keller


Hat evtl. jemand dazu eine Idee?

Schon einmal vielen Dank im voraus!

sinemeter

[guhu]

.. macht einer nochwas hiermit?

Habe das mal auf mein Synology NAS losgelassen (die Version, die hier angehängt ist: https://forum.fhem.de/index.php/topic,42771.0.html )
Das klappt auch so weit gut, wenn ich die Daten manuell abfrage mit "get .. update"
Allerdings wird nicht regelmäßig gepollt.

Klappt das bei Euch? Sieht einer, woran das liegt?

Danke ..

Code: [Auswählen]

defmod synology SYSSTAT 60 600 192.168.101.4
attr synology DbLogInclude *
attr synology mibs .1.3.6.1.4.1.6574.2.1.1.6.0:temp_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.6.1:temp_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.5.0:state_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.5.1:state_hdd2
attr synology noSSH 1
attr synology room IT
attr synology snmp 1
attr synology snmpCommunity synology
attr synology stat 1
attr synology synologytemperature 1
attr synology uptime 1

setstate synology 1.18 0.63 0.47
setstate synology 2020-12-31 15:47:30 load 1.18
setstate synology 2020-12-31 15:47:30 state 1.18 0.63 0.47
setstate synology 2021-01-05 11:23:30 state_hdd1 1
setstate synology 2021-01-05 11:23:30 state_hdd2 1
setstate synology 2021-01-05 11:23:30 temp_hdd1 40
setstate synology 2021-01-05 11:23:30 temp_hdd2 42
setstate synology 2021-01-05 11:23:30 temperature 43

[joe99]

Hallo zusammen,
habe kürzlich meine DS410j durch eine DS420j ersetzt. Diese kann SNMP, und ich habe das nach Doku genutzt, um mittels SYSSTAT diverse Werte im fhem anzuzeigen. Dabei habe ich folgende unangenehme Erfahrung gemacht:
Plötzlich tauchten nachts im Log massenweise Fehlermeldungen auf, die vom PRESENCE und/oder nmap herrührten und Timeout beim Pingen der Rechner anzeigten. Alle oder etliche der überwachten Rechner lieferten timeout beim PRESENCE-Test. Das System war am Morgen via Handy oder Tablet praktisch nicht bedienbar, bis ich meinen PC eingeschaltet habe. Nach ca. 10 Minuten lief meist alles wieder. Zunächst habe ich ein Problem im lokalen Netz vermutet und auf einem alten Raspi ein zweites fhem aufgesetzt, das meine Rechner ebenfalls mit PRESENCE überwachte. Das funktionierte alles, Log war sauber. Es musste also am fhem liegen. Dazu muss ich bemerken, dass die meisten meiner Rechner (2 PC, die DS420j, ein hp-Mikroserver mit UnRaid, mehrere Raspi...) nur bei Bedarf eingeschaltet sind. Das Problem konnte ich nach einiger Suchzeit lösen, indem ich die SYSSTAT-Überwachung wieder herausgenommen habe. Offensichtlich blockiert SYSSTAT, wenn ein Rechner überwacht wird und dann heruntergefahren wird. Pings können dann nicht abgesetzt werden.

Code: [Auswählen]

2021.01.21 14:27:33 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 24941
2021.01.21 14:27:33 2: PRESENCE (ThinkPad) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2021.01.21 14:27:33 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 24943
2021.01.21 14:27:33 2: PRESENCE (LPRESENCE) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
2021.01.21 14:27:33 1: Timeout for PRESENCE_DoLocalPingScan reached, terminated process 24944
2021.01.21 14:27:33 2: PRESENCE (Phaser) - device could not be checked (retrying in 10 seconds): Timeout: process terminated
  :
  :
2021.01.21 14:27:50 2: PRESENCE (ThinkPad) - check returned a valid result after 1 unsuccesful retry
2021.01.21 14:27:50 2: PRESENCE (Phaser) - check returned a valid result after 1 unsuccesful retry
2021.01.21 14:27:50 2: PRESENCE (LPRESENCE) - check returned a valid result after 1 unsuccesful retry


[Wernieman]

Was für mich der Grund war, auf den Systemen zu pushen und nicht zu pollen. Also per Script auf dem System SELBER die Daten ermitteln und zu FHEM pushen. Wenn der Rechner nicht läuft, läuft natürlich das Script auch nicht, aber dann gibt es sowieso keine Daten ...

[NorbertP]

Also hier scheint es meiner Meinung nach ein generelles Problem mit dem Auslesen von mibs zu geben.
Für die Synology-NAS läuft folgender Eintrag einwandfrei:

attr XXX mibs .1.3.6.1.4.1.6574.2.1.1.6.0:temp_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.6.1:temp_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.5.0:state_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.5.1:state_hdd2

Dieser aber nicht:

attr XXX mibs .1.3.6.1.4.1.6574.2.1.1.6.0:temp_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.6.1:temp_hdd2 ,.1.3.6.1.4.1.6574.2.1.1.5.0:state_hdd1 ,.1.3.6.1.4.1.6574.2.1.1.5.1:state_hdd2, .1.3.6.1.4.1.6574.1.5.1:modelName

Wobei modelName kein numerischer Wert, sondern ein string ist.

Vielleicht gibt es hier ein coding problem?

[carlos]

Also bei mir funktioniert folgender Eintrag:

Code: [Auswählen]

.1.3.6.1.4.1.6574.1.5.1.0:model ,
.1.3.6.1.4.1.6574.1.5.1:modelName ,


Code: [Auswählen]

model      DS916+          2021-03-17 22:22:42
modelName  noSuchInstance  2021-03-17 22:22:42