Nagios und EventHandler via NRPE

Bei meiner VM auf der dieser Blog laeuft ist in den letzten Tage oefter mal MySQL abgestuerzt. Das ist ziemlich aergerlich da dann der Blog und einige andere Dinge auch nicht mehr funktionieren. Da ich nur eingeschraenkt vor dem Rechner sitze und es ueber mein Handy sehr umstaendlich ist mittels MidpSSH sich einzuloggen und den Dienst neuzustarten, hab ich mich kurz mit den EventHandlern bei Nagios auseinandergesetzt und im folgenden eine kurze Anleitung was ich gemacht habe:

Lesen: das und das und viele andere Dinge bis ich schliesslich bei dem Artikel „Event Handlers heute mal dynamisch“ (PDF) von RomanK im Nagios-Portal Forum gelandet bin.

Alle im folgenden hier genannten Skripte sind nicht mein Werk, sondern stammen aus besagtem Artikel und wurden von mir auf die Debian-Verhaeltnisse meines Servers und auf meine Problematik angepasst.

Definition des Befehls in der /etc/nagios3/commands.cfg:

define command{
	command_name	do_event
	command_line	/usr/lib/nagios/libexec/event/run_command  $SERVICESTATE$ $SERVICESTATETYPE$ $SERVICEATTEMPT$ $HOSTADDRESS$ $ARG1$
	}

Das Skript run_command in dem Ordner /usr/lib/nagios/libexec/event/ ablegen:

#!/bin/bash
case "$1" in
 
OK)
	;;
 
WARNING)
	;;
 
UNKNOWN)
	;;
 
CRITICAL)
 
	case "$2" in
	SOFT)
 
		case "$3" in
 
		3)
		echo -n "Restarting Service (3rd soft critical state)..."
		/usr/lib/nagios/plugins/check_nrpe -H "$4" -c "$5"
			;;
			esac
		;;
	HARD)
		echo -n "Restarting Service..."
		/usr/lib/nagios/plugins/check_nrpe -H "$4" -c "$5"
		;;
	esac
	;;
esac
exit 0

Auf dieser VM habe ich dann zwei neue NRPE-Checks in der /etc/nagios/nrpe_local.cfg eingerichtet, einen zum ueberpruefen ob MySQL laeuft, und einen der als Event Handler ausgefuehrt wird:

command[check_mysql]=sudo /usr/lib/nagios/plugins/check_mysql
command[restart_mysqld]=sudo /etc/init.d/mysql restart

und die dafuer erforderlichen Eintraege in der /etc/sudoers:

nagios     pregos =  NOPASSWD: /usr/lib/nagios/plugins/check_mysql
nagios     pregos =  NOPASSWD: /etc/init.d/mysql

Nun auf dem Nagios-Server den Servicecheck mit entsprechendem Event Handler definieren:

define service{
        use                             jan-service
        host_name                       pregos.info
        service_description             MySQL
        max_check_attempts              4
        event_handler                   do_event!restart_mysqld
        check_command                   check_nrpe_1arg!check_mysql
        }
}

Nun kann man noch ueberpruefen ob das ganze funktioniert, indem man einfach den MySQL-Dienst beendet und per Webinterface einige male hintereinander den Servicecheck manuell anstoesst.
Wenn man an der max_check_attempts in der config was aendern will, muessen natuerlich auch evtl. Aenderungen in der run_command bei der case-Anweisung gemacht werden.

Wann is noch der naechste routinemaessige fsck?

Einige von euch kennen sicherlich das Problem: Ein wichtiges Kernelupdate zwingt zum Reboot der Serverinfrastruktur. Per SSH wird das Update eingespielt und ein Reboot abgesetzt, aber nicht alle Server koennen ueber DRAC-Karten oder Web-KVM ueberwacht werden. Von Zeit zu Zeit bleibt einem das Herz dann stehen wenn ein Server nicht wiederkommt, die Pings kommen zurueck mit einem „Destiniation or Host unreachable“ oder vergleichbar…
Waerend man seine Jacke anzieht, Schuhe zubindet und parallel dazu fieberhaft ueberlegt was das Problem sein koennte und was da schiefgelaufen ist, schweift auf dem Weg zur Wohnungstuer noch ein letzter Blick zum Monitor und genau in dem Moment geht dann doch gerade der so herbeigesehnte erste Ping durch. Man rennt an den Rechner zurueck, loggt sich per SSH ein, ueberprueft das alles laeuft und waerend der Adrenalinspiegel sinkt kommt einem in den Sinn, dass das nur ein routinemaessiger Dateisystemcheck gewesen sein wird…

Wann der naechste check ausgefuehrt wird, kann man leicht mit dumpe2fs herausfinden. Bin ich aber ehrlich gesagt zu faul zu und vergesse ich auch jedes mal. Darum habe ich mir (nach einem entsprechenden Herzstillstand) ein kleines Skript geschrieben mit dem Namen nextfscheck, was ich unter /usr/local/sbin/ abgelegt habe und das ich vor einem Reboot aufrufen kann um zu wissen ob es einen fsck geben wird oder nicht. Das Skript ist simpel, das Skript ist billig. Als Parameter wird ein gueltiges gemountetes Device angegeben und dann bekomme ich die Info wieviele remounts noch zum naechsten fsck sind, bzw. an welchem Datum der naechste routinemaessige Dateisystemcheck durchgefuehrt wird. Fuer alle die die ebenfalls Interesse an dem Skript haben, hier:

#!/bin/bash
#
# Give information about the next filesystem check 
#
# 2009-11-08:	initial Version   / Jan Toenjes <mail@jan-toenjes.de>
# 2009-11-09:    changed dumpe2fs to "tune2fs -l" as suggested by kero / Jan Toenjes <mail@jan-toenjes.de>
 
 
# check if skript is run as root for tune2fs 
if [ `id -u` != "0" ] ; then 
  echo ""
  echo "     Usage: $0 /dev/disk"
  echo ""
  echo "     Error: You need to be root to run this skript"
  echo ""
  exit 3
fi
 
 
# check if needed programs are installed
which bc 1>/dev/null 
if [ $? -ne 0 ]; then
  echo "    ERROR: Cant find bc"
  exit 3        
fi        
 
 
# check if we got a parameter 
if [ "$1" == "" ] ; then
  echo ""
  echo "     Usage: $0 /dev/disk"
  echo ""
  echo "     Error: You need to give a valid mounted device as parameter i.e. /dev/sda1" 
  echo ""
  exit 3
fi
 
 
 
 
# check if the device given as a parameter exists
DEVEXIST=`mount | grep -ir "$1" | grep "/dev/" | wc | awk {'print $1'}`
if [ "$DEVEXIST" == "0" ] ; then
  echo ""
  echo "     Usage: $0 /dev/disk/"
  echo ""
  echo "     Error: The given parameter  \"$1\"  is not a valid mounted device."
  echo ""
  exit 3
fi
 
 
 
# get remaining mounts
MOUNTCOUNT=`tune2fs -l $1 2>&1 | grep "Mount count:" | awk {'print $3'}`
MAXIMUMMOUNTCOUNT=` tune2fs -l $1 2>&1 | grep "Maximum mount count:" | awk {'print $4'}`
REMAININGMOUNTS=`echo $MAXIMUMMOUNTCOUNT-$MOUNTCOUNT|bc`
 
 
 
# check if we have a fsck after a specific time value and give wanted information
TIMECHECK=`tune2fs -l $1 2>&1 | grep "Check interval:" | awk {'print $3'}`
if [ "$TIMECHECK" == "0" ] ; then
  echo "The next filesystem check of $1 will be after another $REMAININGMOUNTS mounts."
 
else
  NEXTCHECKAFTER=`tune2fs -l $1 2>&1 | grep "Next check after:" | sed 's/Next check after:[ \t]*$//g'`
  echo "The next filesystem check of $1 will be on $NEXTCHECKAFTER or after another $REMAININGMOUNTS mounts."
 
fi

Zeugs: Rythmbox autoaudiosink, NullPointer Luecke

Soundprobleme in Ubuntu 9.10 gehabt. Nach dem Update von 9.04 funktionierte Rythmbox nicht mehr. Fehlermeldung sagte, dass autoaudiosink fehle. Eine automatisch durchgefuehrte Suche brachte keinen Erfolg. Google angerissen und siehe da, Problem bekannt, Problem gebannt:

  • gconf-editor oeffnen
  • /system/gstreamer/0.10/default/
  • audiosink = autoaudiosink
    musicaudiosink = autoaudiosink
    autoaudiosink = halaudiosink uid=/org/freedesktop/Hal/devices/pci_8086_27d8_sound_card_0_alsa_playback_0

Ausserdem is heute (mal wieder) eine Null-Pointer Sicherheitsluecke im Kernel aufgetaucht. Fuer alle von Euch die Mehrbenutzer Debian-Servcr betreuen hier nochmal der bereits bekannte Workaround:

  • Pruefen ob verwundbar: cat /proc/sys/vm/mmap_min_addr
  • Wenn == 0, dann: sysctl -w vm.mmap_min_addr=“4096″

Wenn der Wert > 0 ist, dann is schon alles ok. Weiteres auch beim Linux-Magazin

Zum merken fuer heute:

Wenn nach Update von Debian etch auf Debian lenny einer Xen dom0 mit einem damit verbundenen Update von 2.6.18-6-xen-amd64 auf 2.6.26-2-xen-amd64 kernel und Xen Hypervisor 3.0 auf 3.2 irgendwas das xm console domU nicht mehr funktioniert, dann sollte man in der /etc/xen/domU.cfg die folgende Zeile anhaengen:

extra = "console=hvc0 xencons=tty"

Um bei einer Debian Maschine IPv6 komplett zu deaktivieren muss man in der /etc/modprobe.d/blacklist die Zeile

blacklist ipv6

einfuegen und den PC neu starten. Dann is das auch weg ;-)

[1] [2]