Linux: Updatefälligkeit checken

Zwei kleine Scripts um unter Ubuntu/Debian oder Centos/RHEL zu checken ob Updates fällig sind. Die Scripts geben jeweils nur die Anzahl der fälligen Updates zurück – eignen sich also prima dazu mittels SNMP die Aktualität der Systeme abzufragen. Ein Beispiel für OpenNMS befindet sich hier (von dort stammt auch das erste Script, das zweite ist IMO eine bessere Variante des dort dargestellten).

Centos/RHEL

#!/bin/bash
yum check-update 2>/dev/null | grep -v Load | grep -v \* | grep -v '^$' \ | wc -l

Ubuntu/Debian

#!/bin/bash
/usr/bin/apt-get update > /dev/null 2>&1
/usr/bin/apt-get -qq -s dist-upgrade --allow-unauthenticated | grep ^Inst | wc -l

OpenNMS: Memcached mit SNMP überwachen

opennmsIn OpenNMS gibt es zwar auch einen „nativen“ Memcached-Monitor – aber dieser funktioniert nur wenn der Memcached direkt über das Netz vom Monitorserver aus erreichbar ist.

Mit der bekannten SNMP-extend Methode lässt sich der Memcached Daemon auch gut via SNMP mit OpenNMS überwachen. Hier nur kurz die wichtigsten Scripte und Schritte:

Service überwachen

Das geht am einfachsten über das „HostResourceSwRunPlugin“ Plugin welches die laufenden Prozesse via SNMP überwacht. Zunächst muss der Service überhaupt erkannt werden:

/etc/opennms/capsd-configuration.xml

    <protocol -plugin protocol="Process-memcached"
	class-name="org.opennms.netmgt.capsd.plugins.HostResourceSwRunPlugin"
	scan="on" user-defined="false">
	<property key="timeout" value="2000"></property>
	<property key="retry" value="1"></property>
	<property key="service-name" value="memcached"></property>
    </protocol>

Dann wird die Überwachung definiert:
/etc/opennms/poller-configuration.xml

   ...
<service name="Process-memcached" interval="300000"
    user-defined="false" status="on">
    <parameter key="retry" value="5"></parameter>
    <parameter key="timeout" value="10000"></parameter>
    <parameter key="service-name" value="memcached"></parameter>
    <parameter key="run-level" value="3"></parameter>
    <parameter key="match-all" value="true"></parameter>
</service>
 ...
    <monitor service="Process-memcached" class-name="org.opennms.netmgt.poller.monitors.HostResourceSwRunMonitor"></monitor>

Statistiken

Um noch ein paar Graphen zu generieren werden per SNMP noch die Statusdetails des Memcached Daemons übertragen…

„OpenNMS: Memcached mit SNMP überwachen“ weiterlesen

OpenNMS: Nur primäre Interfaces überwachen

opennmsOpenNMS ist klasse. Man merkt an vielen Stellen, dass es von Anfang an für große Netze konzipiert wurde. Das hat den „Nachteil“ dass einiges u.U. auf dem ersten Blick etwas umständlich wirkt. Ein Beispiel dafür sind z.B. die Filter. Anfangs habe ich diese nicht beachtet und diverse Parameter lieber händisch im Webinterface eingestellt oder viel mit IP-Ranges bei den Pollern gearbeitet.

Eines der Hauptprobleme war, dass OpenNMS immer alle Interfaces auf einem Server bei seinen Service-Checks einbezieht. Also z.B. den SSH-Dienst auf einem Webserver mit 30 virtuellen Interfaces auf jedem dieser Interfaces checkt. Das ist sinnlos. Beholfen habe ich mich damit, dass ich im Webinterface die ensprechenden Interfaces auf „unmanaged“ gesetzt habe oder die IP-Ranges bei den Checks eingeschränkt habe. Wenig elegant.

Wie schön sind dagegen doch die Filter. Kennt man sich ein wenig mit SQL aus, hat man das Prinzip dahinter schnell erkannt. Hinter OpenNMS arbeitet eine PostgresSQL-Datenbank welche die Interfaces, Kategorien, Events etc. verwaltet. Mit den Filtern kann man prinzipiell jedes Feld in dieser Datenbank abfragen und so z.B. die zu pollenden Interfaces bestimmen.

„OpenNMS: Nur primäre Interfaces überwachen“ weiterlesen

Ubuntu: SNMP IfSpeed Bug

Wegen unzureichender Zugriffsrechte kann der SNMP-Daemon die NIC-Geschwindigkeit nicht auslesen und setzt sie (merkwürdigerweise) auf 10MBit (10000000). Der Bug ist auch schon etwas älter. Ohne jetzt lange gesucht zu haben lasse ich snmpd einfach als root laufen (RedHat macht das ja auch ;)) – dann werden die Werte wenigstens richtig ausgelesen.

Die aktuelle Verbindungsgeschwindigkeit von Netzwerkinterfaces korrekt per SNMP auszulesen hat mir schon öfters Nerven gekostet: Hin und wieder taucht das Problem mit den 10MBit auch bei Bonding-Interfaces auf (z.B. bei der Astaro-Firewall).

Telnet per Bash-Script

Bei etlichen Routern die snmp-Community per telnet zu setzen kann mühsam werden. Ein Script muss her. Das telnet-Kommando ist anscheinend so nicht gut dafür geeignet um eingaben von STDIN zu verarbeiten. Durch google bin ich darauf gekommen, dass viele es mit „expect“ lösen. Hier mein Script:

#!/bin/bash
for host in `cat /root/hosts` ; do 
expect << EOF
spawn telnet $host
expect "Login: "
send "admin\r"
expect "Password: "
send "secret\r"
expect -exact "-->"
send "snmp set communityname xxx manager xxx\r"
expect -exact "-->"
send "user logout\r"
EOF
done;

Die Hosts stehen in der Datei /root/hosts. Je in einer Zeile.

OpenNMS: SNMP data collection failed

opennmsBisher lief die Einrichtung und Konfiguration von OpenNMS seit einigen Wochen sehr erfolgreich. Anfängliche Konfigurationsfehler sowie die Einrichtung weiterer Services konnten bisher immer mit Hilfe der Mailingliste und des Wikis schnell behoben werden.

Die (für OpenNMS sehr wichtige) SNMP Kommunikation lief aber nicht ganz so zuverlässig. Ab und an erschienen folgende Meldungen im Eventlog:

SNMP data collection on interface x.x.x.x failed.

snmp4j-internal.log lieferte dann andauernd:

Received response that cannot be matched to any outstanding request ...

Merkwürdigerweise immer nur bei bestimmten Hosts… Nach erfolgloser Suche bin ich dann nochmal die Konfiguration durchgegangen. In der snmp-config.xml fand ich dann die Ursache:

    <definition timeout="10" read-community="xxx" version="v1">

OpenNMS Experten werden jetzt sicherlich nur süffisant grinsen. Bei der anfänglichen Einrichtung von OpenNMS wusste ich damals noch nicht, dass OpenNMS generell Timeouts in Millisekunden angibt…

So ist es besser:

    <definition timeout="10000" read-community="xxx" version="v1">

Erstaunlich das es überhaupt so viele externe Hosts geschafft haben innerhalb der 10ms zu Antworten – spricht für die Infrastruktur 😉