Zabbix discovery rule legt Items an, sammelt aber keine Daten (failed: first network error, wait for 15 seconds)
Ich grüße euch!
Zabbix-Installation
Zabbix-Server Version: 4.4.0
Betriebssystem: centos-release-8.0-0.1905.0.9.el8.x86_64
Anforderung
Ich möchte den Status und die Temperatur der Festplatten meiner Synology (RS818RP+) über eine Discovery rule überwachen.
Problembeschreibung
Ich bekomme keine Werte geliefert, wenn ich die Festplatten über eine Discovery rule erkennen lasse und anschließend eine Abfrage läuft. Wenn ich die Werte einzeln als Item abfrage, funktioniert alles problemlos.
Zunächst einmal der Beweis, dass SNMP im Grunde funktioniert und ich auch die besagten Werte geliefert bekomme, wenn ich einzeln Abfrage:
Einstellungen meiner Discovery rule:
Wie nachfolgend zu sehen, werden die vier verbauten Festplatten erkannt und als Items angelegt:
Problem ist nur, dass keinerlei Werte ankommen, egal wie lange ich warte oder wie oft ich den Vorgang mit Check now anstoße.
Ein tail -f /var/log/zabbix/zabbix_server.log gibt mir unter anderem folgende Meldungen aus:
Ein tcpdump bei aktivierter Discovery rule gibt mir folgendes aus:
Dabei sieht man auch, dass wohl die richtigen OIDs abgefragt werden. Dazwischen sieht man immer einen GetRequest(31) E:6574.1.4.2.0, dass ist der CPU Lüfter Status der Synology, der wiederrum einen Wert liefert.
Ein direkter SNMPWALK vom Zabbix-Server funktioniert auch:
Neben snmpwalk -v 2c -c public 10.20.14.3 .1.3.6.1.4.1.6574.2.1.1.5 habe ich auch snmpbulkwalk -v 2c -c public 10.20.14.3 .1.3.6.1.4.1.6574.2.1.1.5 getestet und bekomme auch da das korrekte Ergebnis geliefert.
Mir ist im Zusammenhang mit dem zabbix_server.log aufgefallen, dass mein Zabbix-Server zeitweise keine Verbindung zu meiner Synology aufbauen kann, mit folgender Fehlermeldung:
Was irgendwo auch wieder quatsch ist, da SNMP ansonsten ja problemlos funktioniert.
Wireshark habe ich auch einmal angeschmissen. Hier zunächst eine Übersicht zweier Anfragen + Antworten:
Hier sieht soweit alles normal aus. Es wird der CPU Lüfter Status (Paket 43+44) + mein Bulk-Request (Paket 45+46) der Festplatten abgefragt und es kommt sogar eine Antwort zurück.
Hier der Bulk-Request im Detail:
Und hier der Response im Detail:
Sieht für mich alles korrekt und normal aus...
Ich habe den Haken meines Host Synology1 bei Use bulk requests mal rausgenommen (auch ohne Erfolg):
Ich bin aktuell an einem Punkt, wo ich nicht weiß, was ich noch tun kann. Womöglich ein Bug?
Zabbix-Installation
Zabbix-Server Version: 4.4.0
Betriebssystem: centos-release-8.0-0.1905.0.9.el8.x86_64
Anforderung
Ich möchte den Status und die Temperatur der Festplatten meiner Synology (RS818RP+) über eine Discovery rule überwachen.
Problembeschreibung
Ich bekomme keine Werte geliefert, wenn ich die Festplatten über eine Discovery rule erkennen lasse und anschließend eine Abfrage läuft. Wenn ich die Werte einzeln als Item abfrage, funktioniert alles problemlos.
Zunächst einmal der Beweis, dass SNMP im Grunde funktioniert und ich auch die besagten Werte geliefert bekomme, wenn ich einzeln Abfrage:
Einstellungen meiner Discovery rule:
Wie nachfolgend zu sehen, werden die vier verbauten Festplatten erkannt und als Items angelegt:
Problem ist nur, dass keinerlei Werte ankommen, egal wie lange ich warte oder wie oft ich den Vorgang mit Check now anstoße.
Ein tail -f /var/log/zabbix/zabbix_server.log gibt mir unter anderem folgende Meldungen aus:
Ein tcpdump bei aktivierter Discovery rule gibt mir folgendes aus:
Dabei sieht man auch, dass wohl die richtigen OIDs abgefragt werden. Dazwischen sieht man immer einen GetRequest(31) E:6574.1.4.2.0, dass ist der CPU Lüfter Status der Synology, der wiederrum einen Wert liefert.
Ein direkter SNMPWALK vom Zabbix-Server funktioniert auch:
Neben snmpwalk -v 2c -c public 10.20.14.3 .1.3.6.1.4.1.6574.2.1.1.5 habe ich auch snmpbulkwalk -v 2c -c public 10.20.14.3 .1.3.6.1.4.1.6574.2.1.1.5 getestet und bekomme auch da das korrekte Ergebnis geliefert.
Mir ist im Zusammenhang mit dem zabbix_server.log aufgefallen, dass mein Zabbix-Server zeitweise keine Verbindung zu meiner Synology aufbauen kann, mit folgender Fehlermeldung:
Was irgendwo auch wieder quatsch ist, da SNMP ansonsten ja problemlos funktioniert.
Wireshark habe ich auch einmal angeschmissen. Hier zunächst eine Übersicht zweier Anfragen + Antworten:
Hier sieht soweit alles normal aus. Es wird der CPU Lüfter Status (Paket 43+44) + mein Bulk-Request (Paket 45+46) der Festplatten abgefragt und es kommt sogar eine Antwort zurück.
Hier der Bulk-Request im Detail:
Und hier der Response im Detail:
Sieht für mich alles korrekt und normal aus...
Ich habe den Haken meines Host Synology1 bei Use bulk requests mal rausgenommen (auch ohne Erfolg):
Ich bin aktuell an einem Punkt, wo ich nicht weiß, was ich noch tun kann. Womöglich ein Bug?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 514576
Url: https://administrator.de/contentid/514576
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
9 Kommentare
Neuester Kommentar
kommt auf die Anzahl der Abfragen Pro Sekunde an. Aber wenn du den Server mit dem Server-Template monitorst, dann sagt er dir eigentlich, wenn du langsam voll läufst.
Ggf mal dein Timeout hochsetzen. Vielleicht braucht deine Synology zu lange? Auch in der Config Timeout=
Musste ich auch mal hochschrauben. Steht bei mir zZ auf 10
Ggf mal dein Timeout hochsetzen. Vielleicht braucht deine Synology zu lange? Auch in der Config Timeout=
Musste ich auch mal hochschrauben. Steht bei mir zZ auf 10
ach Gott das mit den Keys hab ich gar nicht gesehen.
Keys sind die "internen" Namen der Werte für das System. Da verweist man z.B in den Triggern drauf.
Grundsätzlich hast du hier freie Wahl, aber irgendwas sprechendes ist natürlich nicht blöd, damit man weis um was es da grad geht
Und mit dem geänderten Key funktioniert das ganze jetzt? ist ja auch sonderbar
Keys sind die "internen" Namen der Werte für das System. Da verweist man z.B in den Triggern drauf.
Grundsätzlich hast du hier freie Wahl, aber irgendwas sprechendes ist natürlich nicht blöd, damit man weis um was es da grad geht
Und mit dem geänderten Key funktioniert das ganze jetzt? ist ja auch sonderbar