Nagios - Automatische Überwachung einer IT-Infrastruktur, Teil 2

Erweiterungen

Von Alona Parunova, Christian Mohr

NSCA

NSCA ist ein Addon, das verteiltes Monitoring ermöglicht.

cjt Systemsoftware AG

NSCA

Dafür wird auf jedem Remote Host Nagios installiert, welches die Checks selber ausführt und die Daten an den Mainserver schickt. Um dafür zu sorgen, dass die Daten dort immer aktuell sind, richtet man einen ocsp-command (Obsessive Compulsive Service Processor Command) ein, der nach jedem Check ein Skript ausführt. Dieses schickt die Informationen über send_nsca an NSCA auf dem Hauptserver, welches wiederum die Daten in eine External Command-Datei schreibt, die von Nagios passiv ausgelesen wird. Bei großen Firmen kann es beispielsweise so aussehen:

cjt Systemsoftware AG

NSCA

Neben dem normalen Installationspaket auf einem Server benötigt man auch libglib-2.0 und libmcrypt auf beiden Servern. Beide lassen sich über YaST, Aptitude oder manuell installieren. Bei der manuellen Installation empfehlen wir libmcrypt Version 2.5.8, da eine ältere nicht funktionierte.

Über

./configure
make all

baut man das NSCA-Paket. In diesem sind die beiden Binaries nsca und send_nsca sowie die Konfigurationsdateien nsca.cfg und send_nsca.cfg wichtig.

Auf dem Mainserver kopiert man nsca und nsca.cfg in das Verzeichnis /usr/local/nagios/bin bzw. .../etc. Auf dem Remote-Host dasselbe mit send_nsca und send_nsca.cfg.

Einstellung beim Remote-Host

Optional ist zunächst das Abschalten der Benachrichtigung in der Hauptkonfigurationsdatei, da die Nachricht vom Hauptserver ausreicht.

enable_notifications=0

Außerdem ändert man

obsess_over_services=0

auf 1 und gibt bei oscp_command den Befehl submit_check_result ein.

Dieses Kommando sieht so aus:

define command {
 command_name submit_check_result
 command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result \
$HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$'
}

Falls man die Performancedaten mitschicken möchte, ändert man dies so ab:

 command_line /usr/local/nagios/libexec/eventhandlers/submit_check_result \
$HOSTNAME$ '$SERVICEDESC$' $SERVICESTATE$ '$SERVICEOUTPUT$ | \
$SERVICEPERFDATA$ [$SERVICECHECKCOMMAND$]'

Das Skript submit_check_result, das durch den obigen Befehl ausgeführt wird, kann man so aufbauen:

#!/bin/sh
return_code=-1
case "$3" in
 OK)
 return_code=0
 ;;
 WARNING)
 return_code=1
 ;;
 CRITICAL)
 return_code=2
 ;;
 UNKNOWN)
 return_code=-1
 ;;
esac
/usr/bin/printf "%s\t%s\t%s\t%s\n" "$1" "$2" "$return_code" "$4" | \
/usr/local/nagios/bin/send_nsca <Zentraler Server> -c \
/usr/local/nagios/etc/send_nsca.cfg

Wichtig ist noch, dass der Nagios-User das Skript ausführen darf:

chmod 777 submit_check_result

Einstellung am Mainserver

Wir haben uns für Xinetd entschieden, um die empfangenen Daten an NSCA weiterzuleiten. Dafür wird in /etc/services ein Eintrag benötigt:

 nsca 5667/tcp # NSCA

Ferner benötigen wir eine Datei in /etc/xinetd.d namens nsca:

# default: on
# description: NSCA (Nagios Service Check Acceptor)
service nsca
{
 flags = REUSE
 socket_type = stream
 wait = no
 user = nagios
 group = nagios
 server = /usr/local/nagios/bin/nsca
 server_args = -c /usr/local/nagios/etc/nsca.cfg --inetd
 log_on_failure += USERID
 disable = no
}

Xinetd muss jetzt noch neu gestartet werden.

/etc/init.d/xinetd restart

In den Konfigurationsdateien von Nagios müssen jetzt noch exakt dieselben Hosts und Services eingetragen werden. Einziger Unterschied ist der folgende Zusatz bei den Templates bzw. Services auf dem Mainserver:

active_checks_enabled 0
passive_checks_enabled 1

Damit werden die aktiven Checks aus- und die passiven eingeschaltet. In nagios.cfg muss ebenfalls

check_external_commands=1

gesetzt sein. Wichtig ist, dass sowohl nsca bzw. send_nsca als auch nsca.cfg bzw. send_nsca.cfg dem User nagios gehören, da sonst Xinetd bzw. Nagios diese nicht ausführen können.

Freshness-Checking

Ein Problem der passiven Checks wird deutlich, wenn ein Distributed-Server ausfällt. Nagios behält immer die letzten empfangenen Daten bei, auch wenn schon seit langem sich etwas anderes eingestellt hat, aber keine Daten mehr verschickt werden. Dafür gibt es die Möglichkeit, in der Hauptkonfigurationsdatei nach dem Alter der Checks zu schauen.

check_service_freshness=1
service_freshness_check_interval=120 ;(Zeit in Sekunden)

Dadurch versucht Nagios nach zwei Minuten, die Checks selbst durchzuführen und nicht mehr länger auf Daten vom verteilten Server zu warten. Dafür verwendet es den Befehl, der in den Services definiert ist.

Um zu verhinden, dass das Hauptnagios nicht alle richtigen Checks ausführt, schreibt man sich ein kleines Skript, das nur Critical zurückliefert, und definiert es auf dem Hauptserver als check_command in der Konfiguration des Services.

#!/bin/sh
/bin/echo "CRITICAL: Service results are stale!"
exit 2