Schlagwort: monitoring

SNMP-Odysee mit Zabbix und Mikrotik

Aus mehreren Gründen (und aus Rache gegen vermeintlichen Vendor-Lock-In) bin ich auch privat auf Zabbix umgestiegen. Mikrotik mit SNMP einbinden und abfragen? Easy Peasy!

Bis zum Tag X, an dem zwei weitere Mikrotik Geräte mit RouterOS dazu kamen. Nix zu wollen! Ich dachte erst es ist ein Template-Problem bei Zabbix, weil ich Switche (aus guten Gründen, Danke Sandro 😉 mit RouterOS betreiben wollte.

cannot read from session: Bad parse of ASN.1 type (plaintext scopedPDU header type

snmpwalk mit v3, sah alles Top aus, keine Passwort oder IP oder Firewall Probleme. Alles ausgeschlossen. Nur sobald ich das in Zabbix haben wollte -> Nada!

Stunden später bin ich auf einen Beitrag aufmerksam geworden, dass die EngineID unterschiedlich sein muss, das auch sollte, aber aus irgendwelchen Gründen bei Mikrotik gleich ist.

Einfach einen eindeutigen String bei Engine ID suffix (ich hab mich dann für die Primäre MAC-Adresse ohne Doppelpunkte/Striche entschieden) eintragen, und das Thema ist durch.

Check_MK: DNS Cache

Check_MK hat einen internen DNS-Cache, der die IP-Adressen aufgelöster Hostnames eine gewisse Zeit speichert. Auch wenn der betriebssystemseitige Cache geleert wurde und das Betriebssystem korrekt auf neue IPs auflöst, nutzt Check_MK ggf. weiterhin veraltete IPs.

Um auch innerhalb Check_MK die Verwendung aktualisierter IP-Adressen zu forcieren, sind folgende Befehle nötig:

su -l monitoring
cmk -v --update-dns-cache
cmk -O

Quelle

Check_MK: Graphen werden nicht mehr aktualisiert

/omd/sites/monitoring/var/pnp4nagios/spool/ hatte ein Backlog mit mehreren hunderttausend Files.

Dateien löschen, wodurch jedoch die zur Verarbeitung anstehenden Messergebnisse wegfallen.

Zusätzlich ggf. die rdd-Files unter /opt/omd/sites/monitoring/var/pnp4nagios/perfdata/ löschen.
Dadurch gehen jedoch auch die historischen Graphen verloren.

Check_MK: Perl-Issue nach Upgrade auf Debian 10

In Folge eines Updates von Debian 9 (Stretch) auf 10 (Buster) kam es zu fehlerhaften Check_MK-Prüfungen in Zusammenhang mit Perl. Der Fehler zeigte sich bei RBL-Checks, wobei der Service-Check WARNING (null) ergab.

OMD[monitoring]:~$ /usr/lib/nagios/plugins/check_rbl -H 8.8.8.8 -s zen.spamhaus.org
Socket.c: loadable library and perl binaries are mismatched (got handshake key 0xdb80080, needed 0xce00080)

Die Ursache lag in den gesetzten Perl Environment Variablen:

OMD[monitoring]:~$ env | grep PERL
PERL5LIB=/omd/sites/monitoring/local/lib/perl5/lib/perl5:/omd/sites/monitoring/lib/perl5/lib/perl5:

Lösung:
In ~/.profile folgende Zeile auskommentieren und anschließend rebooten:

export PERL5LIB="$OMD_ROOT/local/lib/perl5/lib/perl5:$OMD_ROOT/lib/perl5/lib/perl5:$PERL5LIB"

Quelle

MariaDB Monitoring-Issue nach Upgrade auf Debian 10

In Folge eines Updates von Debian 9 (Stretch) auf 10 (Buster) kam es zu fehlerhaften Check_MK-Checks:

/omd/sites/monitoring/lib/nagios/plugins/check_mysql -H 192.168.23.42 -u user -p password
/omd/sites/monitoring/lib/nagios/plugins/check_mysql: error while loading shared libraries: libmariadbclient.so.18: cannot open shared object file: No such file or directory

Lösung:

aptitude install libmariadbclient-dev
ln -s /usr/lib/x86_64-linux-gnu/libmariadb.so.3 /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18

Quelle

MikroTik SNMP OID

MikroTiks RouterOS bietet auf der Kommandozeile die Möglichkeit, zu gewissen Werten die OIDs auszugeben. Dadurch erhält man schnell und einfach eine Zuordnung von Parametern zu OIDs, welche für das Monitoring mittels SNMP genutzt werden können. Mit Hilfe des folgenden Befehls können OIDs überall dort ermittelt werden, wo entsprechende Parameter seitens des Herstellers implementiert wurden:

print oid

Gängige Beispiele:

/system health print oid 
            voltage: .1.3.6.1.4.1.14988.1.1.3.8.0
            current: .1.3.6.1.4.1.14988.1.1.3.13.0
        temperature: .1.3.6.1.4.1.14988.1.1.3.10.0
  power-consumption: .1.3.6.1.4.1.14988.1.1.3.12.0

/interface print oid 
Flags: D - dynamic, X - disabled, R - running, S - slave 
 0  R  ;;; ether1 - WAN
       name=.1.3.6.1.2.1.2.2.1.2.463 
       actual-mtu=.1.3.6.1.2.1.2.2.1.4.463 
       mac-address=.1.3.6.1.2.1.2.2.1.6.463 
       admin-status=.1.3.6.1.2.1.2.2.1.7.463 
       oper-status=.1.3.6.1.2.1.2.2.1.8.463 
       bytes-in=.1.3.6.1.2.1.31.1.1.1.6.463 
       packets-in=.1.3.6.1.2.1.31.1.1.1.7.463 
       discards-in=.1.3.6.1.2.1.2.2.1.13.463 
       errors-in=.1.3.6.1.2.1.2.2.1.14.463 
       bytes-out=.1.3.6.1.2.1.31.1.1.1.10.463 
       packets-out=.1.3.6.1.2.1.31.1.1.1.11.463 
       discards-out=.1.3.6.1.2.1.2.2.1.19.463 
       errors-out=.1.3.6.1.2.1.2.2.1.20.463 

Quelle